[bitc-dev] White space

[Ben Kloosterman]

>Ben Kloosterman wrote:
 >> Disclosure My functional experience is limited to Lisp and Ocaml and
 >the
 >> learning curve was steep...and hence my comments :-)
 >
 >You should try Haskell. The learning curve is certainly steep, but the
 >results and the rewards are much nicer.

Maybe later  :-) At the moment most of my work is system related so I'm
stuck with C and waiting on BitC to see if its suitable..eg im currently
protyping and seeing if it's worth using non temporal instructions to
minimize cache pollution  and need to do some 16 byte alignment for SSE2.


 >With how ubiquitous lists are in functional languages, I'd think that
 >(a::b::c::zs) is preferable to (Cons a (Cons b (Cons c zs))). Are you
 >suggesting we say (Pair x y) instead of (x,y) ?

Actually for initializing data lists etc most people won't mind  a special
syntax and I rather have a specific definition for construction  , what I
dislike is :: then being used in the logic I would much rather see something
like first or prepend  which are both clear ( if you need to prepend a lot
of static data just declare it and then prepend the lists ). This is similar
to the comments on  C++ stream operator .  The symbol seems to encourage
people to throw logic in and once you see a shift and a ",1" in  cout line
it takes a while to decipher.

A language should subtlety discourage users from doing this and Java and C#
do well. Having a different initialization syntax while not as elegant means
there is less initialization in logic.

I don't know why it is but when I write c I put a lot more logic per line
etc but I don't in C# and Java. And its not just me it's a lot of code I see
. Im no language expert  maybe you guys can say why , maybe it's due to the
fact that in c you often use small variables ( i,j,k are ubiquitous) and
human beings don't like to see lines with few characters so the more compact
the symbols the more logic you get per line. 

 >
 >Certainly people will differ in where they draw the line between nice
 >and succinct vs line noise. But I don't think that eschewing symbolic
 >function names is really the solution. That way lies LISP. While the
 >Lispers and Schemers will defend s-expressions to their death, that has
 >been and continues to be one of the major impediments for people
 >adopting languages in that tradition.


I agree it's a not a case of one or all but where to draw the line. The fact
that C style languages already have a fairly full symbol list for working on
mutable data means we are going to get a lot of operators...so it's wise to
go gentle in the functional direction 

Regards, 

Ben