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 ?


10-Jul-00 14:14 you wrote:
> On Sun, Jul 09, 2000 at 09:49:13PM +0400, Khimenko Victor wrote:
>> > 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)

> I think this is not the main question. I personally can live with
> the current restrictions or use other languages. What i was trying to
> point out is that the 'official' webpage strongly focuses on two features
> of the language that are either problematic or not there (emedability and
> translators).

It's the same story as with GNU project itself: for more then 10 years there
were NO complete GNU operation system (not even alpha). Yet GNU project was
(and is) about creation of completely free operation system, not about creation
of great compiler or decent editor. GCC, emacs, bash and other stuff are great
but it's not goal - they were just necessary to make OS. Guile story is the
same: even if goal is to create nice, easily embeddable language with support
for a lot of other languages via translators decent module system and GOOPS
are needed first. HURD (and Linux) was not even on drawing-board when emacs
and gcc was used by thousands of users.

>>   2) help with guile development

> if i only where competent enough for doing this ...

Hmm. If you are not wizard it does not mean you can not help :-)

>> > There is hardly any information about the actual process of embeding
>> > guile.
>>
>> Want to change it ?

> Yes, of course. I'm more than happy to write a 'howto-embed' (or extend
> the current documentation) as soon as : i understand how it works; certain
> things are possible (like not eating up 'main').

Hmm. I've heard this whining about "eating up 'main'" for VERY long time.
What I can not understood: if it's THAT important for you then why not change
it ? It's not that hard. Why this trick is used in first place ? You need to
know where stack begins on your system for GC. But Boehm's GC has the same
problem ! And still on A LOT OF systems (Win32, Linux, *BSD, Solaris, HP-UX,
etc) it can be used without such trick (you can use it with BINARY Netscape
on Linux with LD_PRELOAD - very nice to prevent Netscape's memory leaks :-).
Yes, there are NEVER will be 100% portable way to it but for 99% systems our
there it's doable. It's weekend (or may be two :-) task for someone with
decent C (not even guile!) knowleadge. With so many whiners I can not believe
there are no one with decent C knowleadge and some spare time ...

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


> I'm sorry if my remarks are perceived as whinig--that's the last
> thing i want to do. I love guile and i enjoy reading this list very
> much. I just happened to realize that a lot (most) of the work done
> on guile recently isn't seen by the rest of the world.

Yes, it's true.

> Have a look at the recent postings in comp.lang.scheme/lisp on
> 'Guile as an embeded language' to see what i mean. There's a lot of
> missinformation arround and i think that the info on the webpages
> is partly responsible for it.

Hmm. May be. There are mixed "general ideas to be deployed somewhere in
future" and "already available features".

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

> I might give a more realistic picture on the current state of
> development of translators. I consider this important information
> for a programmer looking for an embedable language. As an application
> developer i would be--erm--not amused to find out that the language
> i just embedded actually does force my applications user to use
> scheme syntax.

Hmm. Ok. I see.

>> > 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 did. There is even a link to this site on the webpage, unfortunately
> under 'ideas'.

It's just idea as it is now :-( This thing need some changes in guile to make
it usable and such changes are feasible only after module system redesign and
GOOPS integration :-/ Still may be link from main page will be good.

>> > I'm not arguing against the idea of guile as an universal embeded
>> > language for GNU applications.
>>
>> Then what exactly you are arguing against ?

> The fact that the web pages focus so much on two features
> that are barely present and -- from all i have read in this
> mailing list -- are not at all the focal point of development.

It's like GNU OS: kernel is important part of project but while you C compiler
does not work IT will be focal point of development.

> If the purpose of the web pages is to advertise guile as _the_
> GNU extension language, why not point out the existing features
> of the langage: mature langauge with clean syntax, simple but
> powerfull C api (compare that with perls C api!) etc. etc.

Since it was not THE guile features. THE guile features are easy embeddability
and translators. They are not here yet, unfortunatelly :-/

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

> Yes, of course.

>> [...]

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

> I know. I didn't expect an answer, i just reacted to some posts here as well
> as in some newsgroups. I try to move most of my perl stuff to guile
> and seem to run against the same walls all the time (mostly documentation,
> i fear). I spend much more time reading c-code than actually writing
> guile (or even c-code to create new modules). Maybe i'm just the
> unfortunate first (but somehow i doubt that) but then again: i'm trying
> to use guile exactly for what it's advertised, so maybe my remarks
> as a _user_ of guile might be of some help.

Yes, guile lacks documentation A LOT. ANY documentation: web-site, user-level,
embedders-level, internal technical documentation, etc.

Few peoples started projects to change situation but so far looks like there
are serious lack of coordination between such projects :-/




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