type declaration syntax
7 points by abnercoimbre
7 points by abnercoimbre
I have to recommend Ginger Bill's take on the subject. I feel the differences it captures are more meaningful, though this article does have a couple things that stood out to me.
The mention of juxtaposition comes to mind: that complete absence of syntax, where one or more elements are just written one after another, with nothing but whitespace between them. Many languages fail to use it, or use it only anecdotally. But as the lightest syntax of them all, I feel it should on the contrary be front and centre.
f(x+y, z) and f (x+y) z.[1 2 3 5 8]. I would probably not do the same to function calls though: f(x+y z g(a b)) is not ambiguous, but unlike arrays nested expressions are much more common, and the lack of visual separation might be unreasonable.This whitespace business taught me a valuable lesson: to the extent it doesn't hurt something else you care about, the lightest constructs should go to the most used features, and the heaviest to the rarest. Helps pack more code in fewer characters, even fewer lines (it matters), without cluttering your screen full of line noise.
It's also a big reason why I wan on board with Jonathan Blow's idea of not committing to a given syntax from the get go: you gotta get a feel for how you are using (or want to use) your language first. Once you've measured things a bit you can start making adjustment. Beware syntax induced biases though, where you end up using something more or less just because of your initial syntactic quirks.
there is something almost meditative about forth-style concatenative syntax. there's just one thing and then there's another thing. I like the clarity of that.
when I wrote about juxtaposition, I was thinking about lua, where there is no syntactic delineation of statements; it's just completely ambiguous without any form of separator.
it's just completely ambiguous without any form of separator.
That's the magic: it's not! The parser knows exactly where to separate statements! Though it does disagree with humans when the latter instruction starts with an open parenthesis (it can look like a function call). So… yeah, kinda ambiguous. Thankfully the newline is an excellent visual separator.
This article sent me off on a failed investigation!
The type variable syntax goes back to Algol.
The variable: type syntax is harder to track down. Pascal is perhaps the earliest well-known language that uses it, but I haven’t found anything that says how Wirth came to choose a different syntax from Algol. The obvious “why” is that Pascal has a much richer type syntax which would make type-first variable declarations unwieldy, and the obvious “what” is that he was copying mathematical precedent. But I would like to know exactly which precedent: any specific texts on logic? I don’t know of any good sources on the history of mathematical notation and I don’t know enough about what kinds of notations would have been used as inspiration by programming language designers in the late 1960s.
WRT functional programming languages, AFAIK in the late 1960s they were dynamically typed (eg, ISWIM) so I didn’t find a notation for type annotations there.
IIRC Haskell swapped the choice of : vs :: for type ascription and cons because when it was designed they expected cons to be used a lot more (especially for teaching introductory programming to undergrads) so cons got the shorter spelling. Type ascriptions can be written in expressions as well as in declarations, so they must not collide with the cons operator.