This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: finite state machines in guile



telford@eng.uts.edu.au writes:
> 
> My principles say that you shouldn't do something wrong yourself in an
> attempt to compensate for someone else doing the wrong thing -- you should
> do the right thing and encourage other folks to do so too.
> 

That's nice in theory, but in practice it would that any non-trivial
code meant to be protable on Unixoid operating systems would not run
on _any_, since they are all broken one way or another (yes, even
Linux and *BSD).

> I feel that Hobbit's job is to translate nicely expressed scheme code
> into nicely expressed C code. If a tail call in scheme is optimisable
> to a jump then Hobbit should try to find an equivalent C tail call that
> is also optimisable to a jump -- because that is basically the nicest
> way to express the equivalent concept in the C language.
> 

IMO Hobbit's output should be portable to as many C compilers as
possible while remaining as RnRS compliant as possible. Saying "wait
for every C compiler to optimize tail calls" is not a solution.

> Whether the C compiler picks up all available optimisations is quite a
> separate issue but as far as RESPONSIBILITY goes, Hobbit should try to
> overlap the C compiler as little as possible.
> 

C compilers can not be relied upon to optimize tail calls (in fact, it
may be undesirable in some ways, and impossible under some ABIs) - the
C standard does not require this. But the Scheme standard does require
this. So this property must be guaranteed without relying on C
compiler features beyond the standard.

If I were coding a compiler from C to Intel machine language,
and Intel machine language did not have some semantics that C might
need, I wouldn't wait for Intel's engineers to "do the right thing." A
compiler from language X to C should just treat C as portable assembly
language. It's a compiler, not a translator.

> 
> One further point is that Hobbit's output should be as readable as possible
> and trying to build optimisations into the C code is guaranteed to produce
> unreadable code. Yes, you should give the C compiler every chance by setting
> things up in a way that encourages optimisation but no you shouldn't make
> a messy hack.
> 

I'm not sure it was ever a goal of Hobbit to emit readable code. 

 - Maciej