Arjen van Weelden
A.vanWeelden at cs.ru.nl
Wed Nov 23 05:32:28 EST 2005
Ketil Malde wrote:
> Cale Gibbard <cgibbard at gmail.com> writes:
>>This really isn't so bad in practice though. I've certainly never been
>>confused by it.
> Well, what can I say? Good for you?
>>You'd have to go out of your way to construct a
>>situation in which it's potentially confusing
>>There are much more important issues to deal with than this, really.
> Like inventing as many new and wonderful symbolic operators as
> possible! Hey, why not allow quoted function names? So that I can
> defined a function "f " different from "f "? Or differentiate
> (+4) from completely different (+ 4), ( +4) and ( + 4) which
> *obviously* are entirely differen things?
>>might be relevant in the IOHCC, but not in ordinary programming.
> So why not go for the Obfuscated Language Design Contest instead?
>>In a sane language, small amounts of whitespace sensitivity are going
>>to be around no matter what you do.
> And if you already are using whitespace to separate words, surely the
> logical (not to mention aesthetical) way forward would be to introduce
> evene more whitespace sensitivity - here is the Holy Grail
> I don't understand why this isn't obvious to people who generally
> appear fairly bright, but: introducing extension that turns working
> programs into non-working ones is generally a bad idea. Having it be
> due to spacing habits around symbolic operators is worse. That
> spacing changes suddenly starts bringing very complex language
> extensions into the picture, with an associated heap of
> incomprehensible error messages is *not* a nice thing for anybody -
> except, perhaps, the two academics who wrote the paper, and the three
> academics who read it.
> Okay, I'm being unfair here. Haskell is an academic language, its
> primary purpose is to produce papers, not software. And as a mere
> programmer, I'm in a minority. I think Haskell is really cool, but I
> don't really belong here, and I realize of course that my voice isn't
> going to carry a lot of weight.
> But IF there is a desire for Haskell to be used for Real Work, I think
> there should be a certain degree of stability. Taking the function
> composition operator and turning it into record selection -- depending
> on spacing, of course -- is, IMO, madness.
> But good luck on those papers, and see you later, probably on the
> Clean mailing lists.
Speaking about Clean...
Clean uses record.field for record selections and it combines record
syntax (using field names) with array syntax (using indices) in a nice
Function composition is defined as: (o) f g = \x -> f (g x)
Using the lower case letter o as an approximation to the mathematical
symbol. (Actually, it is a macro, but that is a totally different thread.)
give some inspiration for new record syntax (and maybe array syntax).
I'm sorry for promoting Clean on a Haskell list, but both languages are
very similar yet they have a very different approach to records, so it
might be interesting to compare them.
More information about the Haskell-Cafe