Re: Direction

["Ian Bicking" <bickiia@earlham.edu>]

> 1: generic extension library/interpreter. This is the direction
>    we advertise the most, and the one chapioned by projects like
>    CTAX, tcl->scheme, Sonya, etc. If this is the path we want to
>    follow, the priority should be in constructs to allow bizarre
>    Perl and Python constructs (one example that comes to mind:
>    Python's "type" type)

I'm quite dubious that there's any real commitment to this from 
Guile developers.  CTAX has been dormant for most of Guile's life.  
Tcl->Scheme is now in just about the same position.  Yet 
translation remains one of Guile's advertisements -- I imagine this 
must look pretty pathetic from the outside.  Guile was born out of 
politics, and perhaps this is why things are as they are.

Perhaps it's the culture of it -- anyone who wants a different 
language doesn't want Scheme, and anyone who isn't good with 
Scheme certainly can't make a translator.  But that would explain 
why there aren't many translators, not why they don't reach 
maturity.

The annoying part is that it wouldn't be that hard to bring them the 
last steps.  They need to be tested enough to be robust and 
relatively fast.  Then it's mostly packaging -- annoying, but not 
intellectually difficult.  It's being able to do "rpm -i guile-ctax" and 
then put "(syntax ctax)" at the beginning of a CTAX script.  Less 
than that will be too much for the intended audience, for whom 
Guile is only an intermediate.


I am somewhat sceptical about how well the translators can 
actually perform.  Underlying Scheme semantics are infectious, 
and it can make the difference between a translator and an 
interpreter challenging to define.  But shallow/syntactic translation 
is quite possible and would be a significantly better than the 
present situation.  If people *really* wanted translation to happen 
there aren't that many barriers.


--
Ian Bicking <bickiia@earlham.edu>