I’m currently organizing OFLA, the First Open Source Flash Conference. Details are available on OSFlash Wiki. It will be held entirely online and for free. If you’re interested in Flash and / or Open Source, please join the attendee list !
Following the post about NekoML syntax, I replied to a post on LtU with the following message.
—
[…] We all now here that while syntax does matters, it’s far from being the most important point in a programming language.
A language design is divided into the following categories (please tell me if I forget some) :
While the syntax is pure “style”, each of them having its proponents, the semantics is independant from the syntax and describe how the language is evaluated.
At this point we can say that what makes Ruby is not only the syntax, which can be easily changed using a “translator” but its semantics which can hardly be changed without breaking a lot of things.
The type system assists the semantics since except Bash which have only one type “string”, most of the languages have a more-or-less rich, more-or-less extensible type system featuring several “basic” types. The semantics of the language specify also if and how types are checked. Basicly dynamicly-typed languages have a type system, sometimes very rich, but the whole check is delayed at runtime. OTOH static type systems will check a lot of things at compile time and can (but not always do) eliminate a lot of checks at runtime. To be precise, some dynamicly typed language will add some checks at compile time that will enable them to skip some runtime checks if satisfied.
And then comes the features. Class systems are a possible feature when the language have objects in its type system. First class functions and closures are also features. Same for “generators” or continuations, same for embedded regular expressions (which are more a syntax feature - called syntactic “sugar”), and more…
All of theses things together are making a programming language, and syntax is far from being the most important point in language design since it’s the most easy to change. However, it shouldn’t be underestimated since a lot of programmers will judge a language from its syntax only before even starting playing with its semantics, type system, and features.
As a conclusion, it’s funny to see that language “wars” are mostly focused on two points : syntax and type checking (not type system itself), maybe because “original” shift between Lisp and Fortran.
After some holidays and some work on Dinoparc.com, I’m back to Neko development. I’m currently working on the NekoML compiler, I finished this week the pattern matching compilation (typechecking, completeness test and Neko generation) which was quite a big part. I’m currently playing with the compiler, trying to port the Neko compiler from Ocaml to NekoML. I’m also trying to improve the syntax.
I came up with an idea that I think is interesting. In OCaml syntax you don’t have like in C to use parenthesis and commas for calling functions : a b c can be translated into C a(b,c). One of the reason is “tuples”. a(b,c) also have a meaning, which is : call ‘a’ with one argument which is the tuple (b,c).
In NekoML, I wanted to be able to use C syntax, so I made the difference by specifying the tuple as argument : a((b,c)) will call a with the tuple while a(b,c) will call a with two arguments.
On the other hand, when you use imbricated calls for example, you don’t want to write : f(g(h)). OCaml notation f (g h) is more readable. So I added also the fact that a b c and a(b,c) will be both acceptable ways for calling a function.
That’s where the syntax get into trouble… in the following case : a b (c,d) are you doing a(b,(c,d)) or a(b(c,d)) ? I decided then to differenciate two kind of tokens for the left parenthesis : if there is any number of spaces at the left of an opening parenthesis, then it means we’re not doing any call. If there is no spaces then it is acceptable for a call.
That might sound a little bit strange for language designers since most of the time spaces are simply ignored, but when you write NekoML programs it comes very naturaly : a b (c,d) means a(b,(c,d)) while a b(c,d) means a(b(c,d)). In the same kind, you can rewrite the following Ocaml expression :
ETry(f e,ident,f e2)
Into what looks more natural in my opinion :
ETry f(e) ident f(e2)
There is several other improvements in NekoML syntax over OCaml, I’ll try to setup some documentation when I’m done with the compiler.