On 23/11/2012, at 1:56 AM, Jacques Carette wrote:

On 20/11/2012 6:08 PM, Richard O'Keefe wrote:

...

On 21/11/2012, at 4:49 AM, wrote:

...

Well, I don't know. Would it save some time? Why bother with a core language? For a high level language (and for this purpose, even Fortran 66 counts as "high level") you really don't _want_ a direct translation from source code to object code. You want to eliminate unused code and you want to do all sorts of analyses and improvements. It is *much* easier to do all that to a small core language than to the full source language.

Actually, here I disagree. It might be much 'easier' for the programmers to do it for a small core language, but it may turn out to be much, much less effective. I 'discovered' this when (co-)writing a partial evaluator for Maple: we actually made our internal language *larger*, so that we could encode more invariants syntactically. This ended up making our jobs considerably easier, because we did not have to work so hard on doing fancy analyses to recover information that would otherwise have been completely obvious. Yes, there were a lot more cases, but each case was relatively easy; the alternative was a small number of extremely difficult cases.

I don't think we do disagree. We are talking about the same thing: ``not hav[ing] to work so hard on doing fancy analyses''. The key point is that an (abstract) syntax *designed for the compiler* and a syntax *designed for programmers* have to satisfy different design goals and constraints; there's no reason they should be the same. As a very very crude example of this, with its user-defined operators, Prolog lets you write rules using lots of (unquoted) operators to express yourself in an quasi-English sort of way, e.g., if Block must move and top of Block is not clear then clear top of Block. Readable. But lousy for processing. You'd want to change it to something like action(clear_top(Block), [ must_move(Block), \+ top_is_clear(Block)]).