Complexity Shock Horror II: the Sequel (was Re: MD5 in erlang.)

[Robert Virding]

I will reply to this mail instead of Raimo's reply to my reply.

----- Original Message -----
From: "Raimo Niskanen" <raimo.niskanen@REDACTED>
To: <erlang-questions@REDACTED>
Sent: Wednesday, April 02, 2003 10:00 AM
Subject: Re: Complexity Shock Horror II: the Sequel (was Re: MD5 in erlang.)


> The Erlang style Base#Integer notation is such an odd freak that it also
> should not have a letter of its own. I will use b/B for signed
> unprefixed instead so you won't have to use x/X with empty prefix.

It may be odd and slightly freakish but it is part of the language so it
should be supported if we are going to output based integers. After all we
are adding some thing to the *ERLANG* libraries! That is why there should be
a ~#!

> This gives the general x/X:
> io_lib:format("~.16x", [-31,"0x"]) -> "-0x1f"
> io_lib:format("~.16X", [-31,"0x"]) -> "-0x1F"
> b/B is just x/X with empty prefix:
> io_lib:format("~.16b", [-31]) -> "-1f"
> io_lib:format("~.16B", [-31]) -> "-1F"

No I defintely don't like it! Two major objections:
1. You are adding a completely new concept with an option to have an
included string in the middle of an output, this is not consistent with
anything. I am strongly for consistency and simplicity. Otherwise why not go
for the complete set of Common Lisp options and we can scrap half of the
libraries in one fell swoop.
2. If you are using x/X for hex then b/B definitely suggests _B_inary!
3. I don't really understand why we need to directly support other language
formats. This just a grumble!

Also if u/U and b/B mean hex why the .16? Or do you mean that they mean bit
output and you give the base in the precision? So can you write "~.8b" to
get octal? Otherwise it is completely redundant and very confusing.

> and u/U is the same as b/B with the argument integer 'band'ed with
> ((1<<WordSize)-1):
> io_lib:format("~.16U", [31,32]) -> "1F"
> io_lib:format("~.16u", [-31,32]) -> "ffffffe1"
> io_lib:format("~8.16.0u", [31,32]) -> "0000001f"
> io_lib:format("~8.16.0U", [-31,32]) -> "FFFFFFE1"

Some objections here:

1. I assume the second argument is the "word size". Why add an extra option
for something which already exists in the language? Why can't the user just
write 31 band 255 and be done with. As people have rightly pointed out there
is already too much junk in the libraries without adding more unneccessary
stuff!
2. You are using the field width inconsistently! It does not mean the width
of the outputed data but the total width of allowed field to output the
data. If there is not enough data to fill the field padding is inserted.
Using the precision is consistent with intent. Like I did! :-)
3. (Sarcastically) If I do io:format("~8.16u", [31,"0x"]) will that insert
"0x" somewhare in the output?

> Objections, anyone?

Yes, defintely lots of objections! Too many inconsistencies and wrong usage
of existing features to be allowed in! Cover the language needs first and
let the users handle special cases. Adding this would be Big Lose!

I know the io:format options aren't the best but at least they are
consistent.

You mentioned somewhere else a ~- option, this could be useful for
io:fwrite. The io:fread option would be useful but I think the option
shouldn't use a generic u.

Robert