What is the future of programming? I retain a romantic belief in the potential of scientific revolution. To recite one example, the invention of Calculus provided a revolutionary language for the development of Physics. I believe that there is a "Calculus of programming" waiting to be discovered, which will analogously revolutionize the way we program. Notation does matter." More here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-07-30
Thanks for your reply.
My point is that I'm mainly writing programs for scientific computation (containing lots of vectors, matrices, ...) and for this domain every language without (overloadable) infix operators makes things much more difficult.
It's been a long time since I last tried Lisp but if I remember correctly the equation
x=y*b^c + x
would read roughly like this in Lisp
(set x (+ (*y (^b c)) x))
Now this was a SIMPLE equation...
See my problem?
I really do believe theres a reason infix notation is used in math...
Member since:2006-04-04
>It's been a long time since I last tried Lisp but if I >remember correctly the equation
>x=y*b^c + x
>would read roughly like this in Lisp
>(set x (+ (*y (^b c)) x))
For this specific problems I think you can define a macro that permits you to write
(infix-expr x = y * b ^ (a-function c d) + x)
rather easily.
Member since:2005-08-21
Member since:2005-07-06
Perl6 is supposed to have a fully programmable syntax. If works, that'd be a significant advancement in language design indeed. Though it'll be some years yet before Perl6 has a mature implementation, much less a body of practical experience that can judge whether it works or not.
Member since:2006-08-25
That said, I don't see the point of fancy syntax, in that fancy syntax gets in the way of programmable semantics. In other words, I'd rather have a bare-syntax like Lisp, plus the power of a fully-procedural macro system, than a rich-syntax without the power of procedural macros. To date, no language has been able to encompass both together, and its not even clear that its possible.
What about O'Caml and camlp4? You can have fancy syntax, and replace it, extend it, etc. Basically, it manipulates the ocaml AST.
Member since:2005-07-06
Let me revise that. "To date, no language has been able to encompass both together, in a useful way, and its not even clear that its possible."
Camlp4 has the right features (in particular it lets you call procedures in the expansion of a macro), but almost nobody actually uses it. It's enormously complicated, and exposes the details of parsing the Ocaml AST to the programmer. You have to deal with operator precedence, the types of various AST nodes, etc. Heck, until recently, it required the use of a special "revised" Ocaml syntax in parts of the macro, presumably because it has too hard to deal with the regular syntax. Not to mention the fact that its not well-integrated with the environment, as it seperates macro-expansion into a pre-compile phase.
In comparison, Lisp macros are very simple, even though they do in effect manipulate the AST (it's just that the Lisp AST is almost trivial). Also, Lisp macro code looks just like regular Lisp code, and Lisp macros are deeply integrated into the compiler, so macro-expansion is available at any time (even at runtime). All this makes Lisp macros much more accessible, even for relatively novice programmers, and thus much more useful.
There is some work in getting the simplicity and generality of Lisp macros in an infix language. Jonathan Bachrach wrote a paper on "Dexprs", which was a proposal to extend Lisp-like macro facillities to Dylan (which uses an infix syntax). The paper pointed out the futility of trying to do infix macros at the AST level, and proposed doing them at the SST level. In other words, macros operate on the basic "shapes" of constructs in the language, rather than on AST nodes. Of course, it helps that the Dylan syntax is very simple and regular, so the language actually contains very few "shapes" in the source code. This idea has some promise, and there is an implementation of it within the Open Dylan compiler (where it is used extensively), but there is no use of it outside of that project (the compiler doesn't expose the feature to user-code, as its a non-standard extension), so there is little consensus about how it works in practice.
Member since:
2005-07-06
You can do a lot more than defining infix operators on top of Lisp. The Lisp macro system is fully procedural, meaning the input to a macro body can look like pretty much whatever you want it to look like, within the bounds of certain keyword and punctuation constraints in the parser.
The weakness of Lisp in this regard is that its mainly the semantics that are truely programmable . The language helps you mutate the semantics of the language to fit your needs. It'll let you (largely) mutate the syntax of the language, but it won't help you do so. At the limit case, you could define a DSL that had a syntax nothing like Lisp, but then you'd basically have a parser in your macro to parse that language. Writing just a parser is better than writing a whole language implementation, which is what you'd have to do in most any other language, but its clear that Lisp's level of support for syntax programming is not at the level of something like what PERL6 is supposed to have.
That said, I don't see the point of fancy syntax, in that fancy syntax gets in the way of programmable semantics. In other words, I'd rather have a bare-syntax like Lisp, plus the power of a fully-procedural macro system, than a rich-syntax without the power of procedural macros. To date, no language has been able to encompass both together, and its not even clear that its possible.
Edited 2006-09-03 18:54