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 ?


9-Jul-00 15:56 you wrote:
> 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?

For now you have only two choices:
  1) embed guile as it is without nice features like translators - there are
NO sane interface for translators support and there are no big interest in
developing such interface HERE AND NOW (before GOOPS is integrated and module
system is reworked at least)
  2) help with guile development

> There is hardly any information about the actual process of embeding
> guile.

Want to change it ?

> 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).

So what ? Go and change it ! Whining will not help here. Yes, there are not
enough documentation but how it can be changed other then writing such
documentation ? Guile (not Scheme but Guile) is MUCH less mature
TCL/Perl/Python. Not exactly surprising if you'll recall that it's also
few years younger (it was announced in October of 1994 !).

>> 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" ?

What's the difference ?

> But that would imply that someone is working on this feature.

Of course.

> Is there?

Yes. Take look on http://www.cs.earlham.edu/~bickiia/tcl-scheme/ ,
http://www.cs.earlham.edu/~bickiia/logo-scheme/ ...
C->Guile and elist->Guile translators are also in [slow] development ...

> I'm not arguing against the idea of guile as an universal embeded
> language for GNU applications.

Then what exactly you are arguing against ?

> I just feel that the information on the web pages isn't really in sync with
> the available parts of the language.

Yeah, it's well known problem. Do you volunteer to fix it ?

> 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).

It's just limitation of current release. There ARE way to do so without
(re)writing program entry point. Not portable but works for LOTS of different
systems. Expect it to be included in guile version 8 (TCL) or 5 (like perl).

> -"... 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.

Yes, guile's web site is really obsolete and there are no volunteers to fix it.
Do you want to be one ?

> IMHO, if you advertise guile as GNUs embedable language then there
> must be up-to-date information on how to use it.

In perfect world - yes.

> 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.

Very true. Just I've not seen answer on small yet important question: WHO
should write this nice "up-to-date information on how to use it" ? There are
no paid stuff behind guile (or so I heard) so there are noone who you can
prescribe to do this work.




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