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 02:04:14PM +0100, Nic Ferrier wrote:
> Translators for Guile into other languages have not been completed
> yet but Scheme was chosen (AFAIK) because it is uniquely capable of
> doing this.
> 
> For example, Kawa (a GNU Scheme->Java-bytecode compiler) has
> translators for EMACS Lisp and for ECMAScript (JavaScript). 
> 
> Scheme has an extendable syntax so it is easy to build new constructs
> in the language, for non-LISP like languages one then has to simply
> define a REPL for the language.

Yes, but i never doubted this. My concerns are more of a practical
nature: if i write a GNU program and plan to embed a script language,
what do i do. Most naturally, i would check the GNU website and will
find a link to the guile website. There i find lot's of good arguments
for using scheme (not guile) as an embeded language and i'm told
that the users of my application can even choose from several
syntaxes. This sounds very cool! But now what do i do next?
There is hardly any information about the actual process of embeding
guile. I agree there is a lot of information somewhere (on the web,
in mailing list archives, in the code), but this is a big step to
take in the evaluation process (as compared to the available TCL/Perl/Python
documentation). 

> The idea is, that when these translators are complete, you will
> program in Guile/Python or Guile/Perl (or whatever) and not notice
> that Scheme is actually doing all the work.

Should this read: "once the translators are complete" ?
But that would imply that someone is working on this feature.
Is there? 
I'm not arguing against the idea of guile as an universal embeded
language for GNU applications. I just feel that the information on
the web pages isn't really in sync with the available parts of
the language. 
Just a quick look at the webpage :

-" ... nicely packaged as a library you can link into your programs. "
 as long as you (re)write your programs main entry point. I personally
 can live with that but it shure is different from embeding TCL (i have
 embeded TCL in apps. i didn't even have the source code).

-"... At the moment, we have a translator for Ctax, ..." 
 Hmm, i use the CVS version of guile and the Ctax code doesn't run. 
 Again, probably no big deal, but i feel that it migh scare away
 possible users of guile as an embeded language (BTW, there is a 
 working tcl->scheme translator, shouldn't that be mentioned on
 the page?).

etc. 
IMHO, if you advertise guile as GNUs embedable language then there
must be up-to-date information on how to use it. This is a fundamental
difference to a programming language where there are users (i.e. people
who write programs in the language) and implementors (people who design
the language). For embedable languages you also have 'embedors' that need
to have information about the 'public' api of the language.

Ralf Mattes




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