On 9-mar-10, at 13:00, Steven Schveighoffer wrote:
On Tue, 09 Mar 2010 03:09:51 -0500, Alexander Suhoverhov <[email protected]
> wrote:
Steven Schveighoffer at "Mon, 08 Mar 2010 15:23:51 -0500" wrote:
SS> On Mon, 08 Mar 2010 15:12:24 -0500, bearophile <[email protected]
> wrote:
>> Steven Schveighoffer:
>>> Tell me how you would parse the following text serialization
string for a
>>> string[]:
>>>
>>> hello world how are you
>>>
>>> What if it was a string[][]?
>>>
>>> Compare that to:
>>>
>>> [hello world, [how are, you]]
>>
>> You are missing something:
>>
>> ["hello world", ["how are", "you"]]
SS> For completely unambiguous, yes. But still, I find often that
quotes are more noise than
SS> they are worth when just doing simple printouts. What we want
is the most useful
SS> default.
Commas are even more noise than than quotes. erlang:
[{app, "app1"}, {user, "user1"}, {score, 123456}, {date, 5000000},
{misc, "foo"}]
But if you just drop commas:
[{app "app1"} {user "user1"} {score 123456} {date 5000000} {misc
"foo"}]
If you are used to writing code, you should be used to having
commas. The two major use cases for 'to!string' are debugging and
maybe serialization, both programmer tasks. Plus, in your examples,
you have quotes for strings. That negates the need for commas, but
I don't know if having 'to' convert strings to having quotes only
for arrays makes sense. Outputting an array should be a recursive
thing. At the very least, we need either a non-whitespace separator
or quotes to delineate strings. Brackets are a must to see the
separation for multi-dimensional arrays.
-Steve
I don't know, I have something similar
writeOut(sink,type,formatting...), which is more flexible and
efficient, not just to string.
That is supposed to write out something for the user (no
serialization), and well it does not put "", but it does put "," in
arrays, but I can understand other choices (matlab for example has no
commas).
For dictionaries ":" and "," is nice I think.
It really come down to the meaning of to!(x), if it should be without
loss then one should have enough information to recover the original
value.
That is possible also without commas, but C/D programmers are used to
them... lisp, or other functional languages programmers might feel
more at home with spaces... both are possible.
I find it slightly funny that D would choose spaces, but in the end
any convention works
Fawzi
