This is the mail archive of the guile@sources.redhat.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: PHP fork project- Guile vs Python vs ?


On Sun, Jul 09, 2000 at 08:41:51PM +0200, Mikael Djurfeldt wrote:
> "Khimenko Victor" <guile@khim.sch57.msk.ru> writes:
> 
> > Yes, guile's web site is really obsolete and there are no volunteers
> > to fix it.  Do you want to be one ?
> 
> There actually are volunteers working on this.  We also have a
> volunteer working on a real Guile reference manual.
> 
> I've just moved to a new school.  After a month or so, things will
> have settled for me so that I can help coordinate things around Guile
> again.  Until then I hope that Maciej or Marius might have some time
> to do it.  Jim has a very valid reason not to work on Guile for some
> time.
> 
> I think we should begin to develop some language support tools, such
> as table-driven lexical analyzers and lalr parsers so that we can
> define the tokens and grammar in Scheme syntax, compile this into
> tables, and use them in Scheme primitives which does the actual
> parsing.  Such tools could actually replace the current reader.
> Bigloo has such tools.  I have previously rewritten the flex lexical
> analyzer to use tables provided from Scheme and started to do the same
> for Bison.  There is, however, currently no one working on this.  Any
> contribution in this area would be very good.

I've found lalr parser generator for scheme in the scheme repository
by Dominique Boucher.  It implements the algorithm used in bison and
is GPLed.  The URL is
ftp://ftp.cs.indiana.edu/pub/scheme-repository/code/lang/lalr-scm.tar.gz
Some of the problems with it are: lack of documentation (there is some
in the source, but...); sometimes uses inconsistent case conventions;
and if someone wants to add the generated code in a module, (s)he have
to do it manually.

Nevertheless, I think it's very good and we should use it.

> 
> Regarding what intermediate representation to use during translation,
> there is research going on on using a lambda calculus intermediate
> representation for efficient compilation of Java.

-- 
Ivan Toshkov

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