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, <[email protected]> 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)]).
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
