Roadmap and goals?

Roadmap and goals?

[Tanel Tammet]

Hi,

This here looks like a troll, but it isn't. 

I am sure the same question is asked now and then.
I looked through the site and part of email archives,
but could not find answers to my questions there.

Hence I am trying my luck with the mailing list :-)

Basically, I am wondering if anybody could tell
me something about the Guile development goals
and roadmap: what are the short-term goals,
what are the long-term goals, what are the priorities
(I mean concrete issues, not just the abstract
goal of being a good extension language).

I am asking since I was considering whether I
could possibly help with the development work. 

To do that, I'd have to understand where is
the Guile development moving, what are the prioritized
goals, crucial principles, etc. What would be
the projects inside Guile where a person
like me could possibly help.
 
Some background:

I am the original author of the Hobbit Scheme->C
compiler for SCM and although I did not work on
improving it for some years, I have recently 
taken it up again and worked a little on Hobbit
and SCM with Aubrey. I plan to continue making small
improvements for Hobbit for SCM. I can understand
the scope and goals of SCM and what are
the issues with which I could possibly help.

I am pretty happy with SCM. I have looked
briefly into bigloo and other systems, and
there are many cool things here and there.

However, I cannot really understand 
(*) what is the driving force behind Guile and
(*) what are the specific benefits of using Guile.

For example, why exactly should somebody
use Guile instead of SCM or Bigloo:
what are the specific advantages and
what is the downside. Why not use just
SCM or Bigloo (they are faster, you know :-)
There have to be answers to this question,
just that I do not know the answers.

In my brief encounters with other people
using scheme these issues have come up
now and then.

I guess it would benefit not only me 
but the Guile development and acceptance 
on a wider scale if such guides, policies,
roadmaps etc existed and were easy to locate.

Regards, 
       Tanel Tammet

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Neil Jerram]

>>>>> "Tanel" == Tanel Tammet <tammet@staff.ttu.ee> writes:

    Tanel> I am sure the same question is asked now and then.
    Tanel> I looked through the site and part of email archives,
    Tanel> but could not find answers to my questions there.

    Tanel> Basically, I am wondering if anybody could tell
    Tanel> me something about the Guile development goals
    Tanel> and roadmap: what are the short-term goals,
    Tanel> what are the long-term goals, what are the priorities
    Tanel> (I mean concrete issues, not just the abstract
    Tanel> goal of being a good extension language).

I'd say the answers are largely determined by the interests and
priorities of the developers active at any time, as influenced by what
interested users ask for.  I don't know if there is an official
roadmap ...

Some of the things that interest me are: documentation, both manual
and online; debugging facilities; Emacs integration; libguile
factorization; Elisp translation.

    Tanel> I am asking since I was considering whether I
    Tanel> could possibly help with the development work. 

    Tanel> To do that, I'd have to understand where is
    Tanel> the Guile development moving, what are the prioritized
    Tanel> goals, crucial principles, etc. What would be
    Tanel> the projects inside Guile where a person
    Tanel> like me could possibly help.

Well, one longer-term focus is reworking Guile's evaluation model to
support interesting kinds of compilation -- I guess you'd be pretty
helpful in that department.

However, in line with the logic above, what might work better would be
for you to poke around a bit and then form your own view of what
interests you.

    Tanel> I am pretty happy with SCM. I have looked
    Tanel> briefly into bigloo and other systems, and
    Tanel> there are many cool things here and there.

    Tanel> However, I cannot really understand 
    Tanel> (*) what is the driving force behind Guile and
    Tanel> (*) what are the specific benefits of using Guile.

For me I think the answers are (i) because it's GNU (ii) because it's
what I'm now familiar with, which makes me inclined to stick at it
until we get it right.  Plus in all the things that I've tried to do
with it, I've not yet hit any insurmountable technical or
philosophical barrier - it mostly "just works."

Allegedly Guile is good for integration with C projects, but to be
honest I haven't evaluated the competition.

    Tanel> In my brief encounters with other people
    Tanel> using scheme these issues have come up
    Tanel> now and then.

(A point for the wider Scheme community ...)  Guile has more SRFI
support than any of the implementations mentioned on the SRFI web
pages (including Guile itself - someone should get that updated...).

    Tanel> I guess it would benefit not only me 
    Tanel> but the Guile development and acceptance 
    Tanel> on a wider scale if such guides, policies,
    Tanel> roadmaps etc existed and were easy to locate.

Perhaps, but would they be real, or just hype?

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Christopher Cramer]

On Wed, Apr 17, 2002 at 03:21:47PM +0300, Tanel Tammet wrote:
> To do that, I'd have to understand where is
> the Guile development moving, what are the prioritized
> goals, crucial principles, etc. What would be
> the projects inside Guile where a person
> like me could possibly help.

There's some stuff in CVS discussing this, e.g.:

http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/workbook/policy/plans.text?rev=1.1&content-type=text/vnd.viewcvs-markup
http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/workbook/tasks/TODO?rev=1.33&content-type=text/vnd.viewcvs-markup

> For example, why exactly should somebody
> use Guile instead of SCM or Bigloo:
> what are the specific advantages and
> what is the downside. Why not use just
> SCM or Bigloo (they are faster, you know :-)
> There have to be answers to this question,
> just that I do not know the answers.

I haven't checked out SCM in a long time, so there is a slight possibility
this isn't true anymore, but the advantage Guile has over SCM is that
integration with C is much easier. There was some reason why I decided
to use Guile instead of Bigloo, but I really can't remember what it
was anymore. I know SCM is a little faster than Guile, but I was not
under the impression that Bigloo was.

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
Quoi que vous fassiez, écrasez l'infâme, et aimez qui vous aime.
	-- Voltaire

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Panagiotis Vossos]

Neil Jerram <neil@ossau.uklinux.net> writes:

> (A point for the wider Scheme community ...)  Guile has more SRFI
> support than any of the implementations mentioned on the SRFI web
> pages (including Guile itself - someone should get that updated...).

Just sent them an email asking to add a guile entry mentioning the
srfi's documented in 1.5.6 manual.

panagiotis

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[bitwize]

On 17 Apr 2002, Neil Jerram wrote:

> 
> Some of the things that interest me are: documentation, both manual
> and online; debugging facilities; Emacs integration; libguile
> factorization; Elisp translation.

It may be too much to ask, but I'd like to see a VM being integrated into 
guile-core. The one that Keisuke Nishida wrote a while back is supposedly 
really good; integrating it so that byte-compilation and execution of 
bytecodes becomes the default method of interpretation and execution (much 
as it is with mzscheme) would be a Good Thing for Guile, performance-wise.

Another thing is, I use Guile where many hackers would choose Perl or 
Python, as an all-purpose automation and glue language. It's there, it 
works, and Scheme is much easier to write things quickly in than those 
other languages. Anything that boosts Guile from a systems integration 
standpoint would be nice for my uses. Responding to .NET, SOAP, and all 
that hype-based hoopla with efficient Scheme-based simple RPC and 
secure mobile code mechanisms would be nifty.

That's my wish list for the time being. The TODO also mentions a decent 
Guile binding for Tk. I'm currently working on this using pTk; has anyone 
gotten any further?

> For me I think the answers are (i) because it's GNU (ii) because it's
> what I'm now familiar with, which makes me inclined to stick at it
> until we get it right.  Plus in all the things that I've tried to do
> with it, I've not yet hit any insurmountable technical or
> philosophical barrier - it mostly "just works."

The fact that "it's GNU" is perhaps instrumental to Guile's success. 
Scheme has overall been slapped with the Pascal stigma: it's an 
"educational language", which means it lacks utility in the Real World. 
Guile represents disproof by counterexample, by being quite central to 
many of the things GNU is doing (GNOME, etc.).

> Allegedly Guile is good for integration with C projects, but to be
> honest I haven't evaluated the competition.

SIOD may actually be better in this regard, because of its tiny size and 
liberal license. But then again, SIOD lacks RnRS compliance, and much of 
the other niftiness that Guile has.

-- 
Jeffrey T. Read
"LOBSTER STICKS TO MAGNET!"


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Rob Browning]

bitwize@wizards-of-source.org writes:

> It may be too much to ask, but I'd like to see a VM being integrated
> into guile-core. The one that Keisuke Nishida wrote a while back is
> supposedly really good; integrating it so that byte-compilation and
> execution of bytecodes becomes the default method of interpretation
> and execution (much as it is with mzscheme) would be a Good Thing
> for Guile, performance-wise.

A VM is possible, but see the other recent notes on what probably
needs to happen first, in particular Marius' (and my) recent mails
about the macro system, module system cleanups, etc.

> Responding to .NET, SOAP, and all that hype-based hoopla with
> efficient Scheme-based simple RPC and secure mobile code mechanisms
> would be nifty.

One thing you might want to check out is ice-9/safe.scm if you haven't
looked at it yet.  It's not what you're talking about above, but it
does allow you to create environments where it's supposed to be safe
to eval random-untrusted-code and have very careful control over what
it could possibly do.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Nicolas Neuss]

Dear Guilers.

Motivated by the recent message from Tanel Tammet on the guile-devel
mailing list (and the answers, which are IMO unsatisfactory), I want
to present also my point of view on Guile.

First, let me tell a little bit of my own history.  I was a C
programmer who searched an extension language for an application.
First, I thought about using Elisp (having immediately an integration
with the editor).  Thus I wrote to Stallman and asked him about this,
and, of course, he suggested Guile.  I came to Guile in 1998.
Maintainer was Jim Blandy at that time.  Somewhat later he gave up,
was followed by Maciej Stachowiak, who was joined by other developers
(Mikael Djurfeldt, Michael Livshin, and Marius Vollmer, if I remember
correctly).  Who is maintainer now?  I don't know precisely, because I
read the Guile mailing list only superficially since the year 2000.

Now, what are Guile's goals?  IMO, Guile arose from several ideas of
RMS: the first that Lisp-like languages are best, the second that
combining several languages (i.e. using extension languages as he did
with Emacs) is the way to go, the third that Elisp should be replaced
by Scheme, and the fourth that such software has to be under the GPL
and maintained by the FSF.  During the so-called TCL flamewar, a fifth
idea was brought up, namely that the FSF extension language should
emulate others.

Unfortunately, all those goals are very questionable.  First, non-lisp
languages get more and more of Lisp's capabilities[1] and the
advantage is not large any more, especially for the spartanic Scheme
branch.  Second, my guess is that most applications are written within
one language, because maintaining the interface between two languages
is a problem.  Third, replacing Elisp with Common Lisp would probably
be both easier and better (but is still difficult, see below).
Fourth, more liberal licenses than the GPL (e.g. some BSD license) or
GPLed software not maintained by the FSF is also a nice thing[2].
Fifth, emulating languages in an integrating way is easy to say, but
difficult to work out (this is proved by Guile not emulating one
single other language in a reasonable way).

Where does Guile stand now?  In my eyes, Guile is fighting on a lost
position.  I will elaborate a little bit on this in the following.

First, there are several strong and healthy Schemes competing.  I
don't know about SCM and Bigloo which the previous poster suggested,
but I know a little about PLT Scheme.  This Scheme has an IDE making
it work under Windows, Mac and Unix very nicely.  And a lot of work is
put into it from several people at several universities (Matthias
Felleisen, Shriram Krishnamurti, ...).  [One can look at this as
unfair competition because Guile has no such direct university
support.  But that doesn't count, at least for me as a user.]  Its
license is even more liberal than the GPL, and therefore could be
accepted IMO.

Second, I have serious doubts that Scheme as a language succeeds (in
spite of PLT Scheme).  It is quite astonishing that at this time a
language is propagated as the ultimate weapon, which has neither OO
support nor modules/namespaces in a standardized way.  It seems that
the Scheme dogma of accepting only perfect solutions approaches now a
boundary where only several 90% solutions are available, and thus
cannot be extended further.  Even inside the Lisp language family,
Scheme looses against (ANSI) Common Lisp which supplies both a very
strong OO system and packages in a standardized way.  There are also
good and free CL implementations, namely CLISP (GPL, only
byte-compilation, very portable) and CMUCL (public domain, compilation
to native code, less portable). [3]

[Third, of course, it is questionable if Lisp itself will survive,
because the Lisp family as a whole is attacked by other languages like
Java, C++, ML, Smalltalk/Squeak, ...  But there were Kassandras for
Lisp all the time during its long life.]

What should Guile do?  In my opinion, there should be a drastic change
in direction.  First, of course, you should finish the current ?1.6?
release as fast as possible.  But then you should evaluate several
other Scheme implementations, as well as CLISP and CMUCL.  If it
should turn out that Guile has enough merits (apart from the merit
that it's the Scheme you know), fine, forget my words.  If not, you
should talk seriously to RMS.  Because then it is time to rethink this
project and take appropriate actions.  These actions may go from
joining with SCM on the one side[4] to shifting the whole project
towards Common Lisp as extension language on the other side (leaving
the domain "Scheme as an educational language" to PLT Scheme).

Concerning Elisp replacement, it would make sense to drop Scheme in
favor of CLISP, too.  This would make the project much easier, because
CL and Elisp are comparatively near (especially when you do (require
'cl) in Emacs:-).  Further, there are Emacs-like editors written in
CL, see Hemlock for CMUCL from which one could maybe take some code.
Also, there may be CL people willing to help, even Erik Naggum (see
footnote) once planned something like that.  One should keep in mind,
that it is still a hairy project[5].  But it could succeed, if
Stallman pushed it.

That's all I have to say.  What concerns myself, I have switched to
Common Lisp about two years ago.  I guess, I'll drop out of the Guile
mailing list soon.  I want to thank the people that were and are on
this list.  I learned a lot of things, but I prefer another playground
now.

Goodbye,

Nicolas.

[1] see the web page of Paul Graham at
    <http://www.paulgraham.com/articles.html>

[2] It seems that while the GNU system being under the GPL is
    certainly achievable, it does not really work that the FSF is the
    copyright hodler of all essential parts.  This goal should be
    abandoned.

[3] I do not mention GCL here, because it is not ANSI compliant, and
    appears not to be actively developed any more.  It seems to be one
    of those projects where you have to tell people NOT to use the FSF
    version (similar to the Hurd kernel, and maybe Guile).

[4] IMHO, it is a terrible nonsense that people work on so many Scheme
    implementations in parallel, only to feed the egos of their
    respective leaders.

[5] See the articles on this topic at the Xemacs web site
    http://www.xemacs.org/Architecting-XEmacs/index.html .


P.S.2: If some of you did not yet look at CL, you could start with
reading comp.lang.lisp. [You will meet several other (former) Guilers
there:-).] But when joining that newsgroup, please remember the
following things:

1. It is about (Common) Lisp, not about Scheme.  Scheme has an own
   newsgroup (comp.lang.scheme).

2. Many burning questions (why is () equal to #f?, why are there two
   namespaces?, replacing Elisp, ... and so on) have already been
   discussed, most of them several times.  You can find such info in
   the FAQ
   <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/top.html> or
   via Google group search <http://groups.google.com/groups?selm=>.

3. There is a guy called Erik Naggum who is very rude.  Nevertheless,
   he is one of the sharpest guy I know, and you do everyone a favor
   if you keep that in mind.  Don't get into a struggle with him,
   those exchanges are extremely annoying.

4. As with every newsgroup or mailing list, you should read it for
   some time without posting.

In parallel, you should read an introductory book (I'd recommend
Graham's "ANSI Common Lisp").  And install the Common Lisp Hyperspec
(because of this tremendous thing, documentation is not a problem with
CL).


P.S.2: I thought about sending this also to guile-user@gnu.org.  I
refrained from doing so, because Tamel did not do that, and because I
do not want to be too destructive.  But IMHO, also users should know
about these problems in Guile's design.  So, it remains for you
maintainers to inform them...

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Panagiotis Vossos]

Panagiotis Vossos <jacbre@internet.gr> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> > (A point for the wider Scheme community ...)  Guile has more SRFI
> > support than any of the implementations mentioned on the SRFI web
> > pages (including Guile itself - someone should get that updated...).
> 
> Just sent them an email asking to add a guile entry mentioning the
> srfi's documented in 1.5.6 manual.

Entry updated.  The only problem now is that they have linked to the
main guile page, where there is no reference to version 1.5.6.

panagiotis

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Marius Vollmer]

Christopher Cramer <crayc@pyro.net> writes:

> There's some stuff in CVS discussing this, e.g.:
> [...]

There is also

http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/workbook/policy/goals.text?rev=1.1&content-type=text/vnd.viewcvs-markup

which is less specific and therefore less out-dated.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Thien-Thi Nguyen]

   From: Panagiotis Vossos <jacbre@internet.gr>
   Date: Fri, 19 Apr 2002 12:14:35 +0300

   Entry updated.  The only problem now is that they have linked to the
   main guile page, where there is no reference to version 1.5.6.

this page has been updated recently to have that info:

  http://www.gnu.org/software/guile/

is this the page you refer to?

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 17 Apr 2002 21:59:07 +0100

   Perhaps, but would they be real, or just hype?

the real questions are: what is the mechanism for distinguishing these
two?  who will write that Program?  who will execute that Protocol?  can
these be defined soon?  these last two are hardest to do.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Thien-Thi Nguyen]

   From: Tanel Tammet <tammet@staff.ttu.ee>
   Date: Wed, 17 Apr 2002 15:21:47 +0300

   I guess it would benefit not only me 
   but the Guile development and acceptance 
   on a wider scale if such guides, policies,
   roadmaps etc existed and were easy to locate.

for some of this, see:

  http://www.glug.org/snap/workbook/

please consider critiquing everything under there (in
particular what does "defining the execution model"
mean) wrt compilation.  this would be immediately
helpful.  (additions gladly accepted, no q's asked.)

long-term direction is now in discussion.  process
awareness is seeded but not flourishing yet, so current
communication rates cannot be used reliably to predict
outcome.  you are invited to start a bof discussion
using subject-line prefix "[comp]".

it was because of hobbit that i became interested in
guile, so if hobbit long-term does not support guile, i
would have serious doubts about staying w/ guile.  on
the other hand, i also view this as an opportunity to
learn precisely what hobbit needs, so that perhaps
long-term, people can make guile support hobbit through
becoming more precise in what guile provides.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Panagiotis Vossos]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Panagiotis Vossos <jacbre@internet.gr>
>    Date: Fri, 19 Apr 2002 12:14:35 +0300
> 
>    Entry updated.  The only problem now is that they have linked to the
>    main guile page, where there is no reference to version 1.5.6.
> 
> this page has been updated recently to have that info:
> 
>   http://www.gnu.org/software/guile/
> 
> is this the page you refer to?

Sorry, my mistake.  They have linked to
http://www.gnu.org/software/guile/guile.html, from which you can find
1.5.6 via the recent news link.

panagiotis

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Kirill Lisovsky]

Hello!

Working for a long time with a half-dozen of different Schemes in IT and CS 
projects, I've some "comparative impression". 

Tanel Tammet wrote:
> (*) what are the specific benefits of using Guile.
> 
> For example, why exactly should somebody
> use Guile instead of SCM or Bigloo:
> what are the specific advantages and
> what is the downside. Why not use just
> SCM or Bigloo (they are faster, you know :-)
> There have to be answers to this question,
> just that I do not know the answers.
>

Bigloo has nice and fast compiler but its interpreter is slow and 
compiler-incompatible. It makes sense if the application has to be compiled
rather than interpreted.
Bigloo not quite Scheme in proper-tail recursion considerations, but it's
fast and may be useful for practical purposes.
Unix-oriented.
It has a usable JVM backend also.

SCM is a good Scheme, but it has no case sensitive reader, which 
is a big disadvantage for some applications (XML is most important example 
for me). 

IMHO, PLT is most advanced and most promising "big" Scheme.
Version 200 is a great improvement, its design and principles are 
reasonable and clear. 
A lot of libraries, active development, multiple platforms, and so on ...

I like Gambit a lot, but it's not free for commercial projects.
Compiler to C.
Extremely robust.

Chicken is relatively young but already usable.  
It has a solid theoretical basis and good C interface.
Compiler to C.

Guile - it is the slowest one, I'm afraid :-)
Well, it's better _interpreter_ than Bigloo ... 
IMHO, it's main advantage is large installation/users base.
But a mess with versions: 1.7.x , 1.6.x, 1.5.x  while latest Linux distros
are using 1.4.x or even 1.3.4! 
(1.3.4 is used by RedHat 7.2 which makes a lot of installed Guiles pretty
obsolete...)
Using Guile since 1999 I'm still ignoring its latest additions
due to this zoo of versions...

As the result, I mostly use Guile to run Scheme scripts on "just OS installed" 
Linux/BSD boxes. If I'm to install some Scheme, then (usually) it is not Guile...

So, this is my point of view:
  1. Guile may have a good future as fast and compact "R5RS SIOD" with
a lot of (optional !) libraries.
  2. Unification of Scheme implementations will be highly desirable from the
practical point of view. Co-existence of ten "major Schemes" is a major 
practical disadvantage.
  3. PLT is best _full-blown_ Scheme implementation now. It's designed as core +
libraries. Porting (best and absent in PLT) Guile's code as PLT collections is 
most realistic way to unification.

Best regards,
         Kirill Lisovsky.

http://pair.com/lisovsky/

P.S. Forward of Nicolas's message to guile-user@gnu.org
is the reason of this posting. Please, don't consider it as  
destructive :-)

> ------- Start of forwarded message -------
> From: Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de>
> Subject: Re: Roadmap and goals?
> Date: 19 Apr 2002 10:38:06 +0200

...

> P.S.2: I thought about sending this also to guile-user@gnu.org.  I
> refrained from doing so, because Tamel did not do that, and because I
> do not want to be too destructive.  But IMHO, also users should know
> about these problems in Guile's design.  So, it remains for you
> maintainers to inform them...



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Rob Browning]

Kirill Lisovsky <lisovsky@acm.org> writes:

> Guile - it is the slowest one, I'm afraid :-)
> Well, it's better _interpreter_ than Bigloo ... 
> IMHO, it's main advantage is large installation/users base.
> But a mess with versions: 1.7.x , 1.6.x, 1.5.x  while latest Linux distros
> are using 1.4.x or even 1.3.4! 
> (1.3.4 is used by RedHat 7.2 which makes a lot of installed Guiles pretty
> obsolete...)
> Using Guile since 1999 I'm still ignoring its latest additions
> due to this zoo of versions...

After 1.3.4 it *should* be pretty clear -- the numbering scheme is the
same as that of the linux kernel now, given MAJOR.MINOR.MICRO,
releases with odd MINOR numbers are unstable, i.e. 1.5.* is an
unstable beta release, and even numbers are stable.  1.6.1 will be the
next stable release.  Perhaps this isn't yet well enough known since
it was only decided after 1.4 and so is only documented in CVS ATM.

The problem with RedHat is a separate problem I think I understand
pretty well, and that I'm planning to try and help fix soon.

One issue in the FWIW category with respect to performance -- I've got
a partially working set of benchmarks here that I can run via a
"make".  I'm planning to commit these tests to a CVS module (after I
make sure the copyrights allow that) so we can use it for checking our
work.  Most of the benchmarks I have working right now are taken from
stalin, and so I've had to tone their workload down by orders of
magnitude so they'll actually run in a reasonable time with guile --
stalin is of course ridiculously faster in these tests.

> P.S. Forward of Nicolas's message to guile-user@gnu.org
> is the reason of this posting. Please, don't consider it as  
> destructive :-)

Not at all, thanks for your comments.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Rob Browning]

(including guile-user since a copy was posted there too)

Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:

> Unfortunately, all those goals are very questionable.  First, non-lisp
> languages get more and more of Lisp's capabilities[1] and the
> advantage is not large any more, especially for the spartanic Scheme
> branch.

Even if that were true, to me that's a little like saying that there's
no reason Perl programmers shouldn't switch to Python, or Tcl to Perl,
or ... since they can do roughly the same things (presuming the
languages in question can do mostly the same things).

>  Second, my guess is that most applications are written within one
> language, because maintaining the interface between two languages is
> a problem.

Could be, and it deppends on what you mean bu "written within" but to
me the Gimp, Guppi, Gnucash, Emacs, snd, and Gnumeric are notable
counter-examples.

> Third, replacing Elisp with Common Lisp would probably be both
> easier and better (but is still difficult, see below).

I haven't checked, but I'd be a little concerned about size.  Last CL
implementation I looked at in much detail was quite large, but perhaps
that's not true anymore.

> Fourth, more liberal licenses than the GPL (e.g. some BSD license)
> or GPLed software not maintained by the FSF is also a nice thing[2].

Not sure if you know, but Guile's license has changed, it's no longer
covered under the GPL alone, there's an exception clause that allows
it to be linked against other applications without causing them to
automatically be covered under the GPL.  See the Guile copyright for
the precise terms.

> Fifth, emulating languages in an integrating way is easy to say, but
> difficult to work out (this is proved by Guile not emulating one
> single other language in a reasonable way).

I consider this an open question -- guile may or may not ever end up
emulating a large number of languages other than elisp, but after the
recent work, I do have reasonable hope for elisp.  <shrug>, we'll see.

> [2] It seems that while the GNU system being under the GPL is
>     certainly achievable, it does not really work that the FSF is the
>     copyright hodler of all essential parts.  This goal should be
>     abandoned.

I can't speak for RMS, but based on my experience, this is a
non-starter, and now that I understand the issues and have seen the US
legal system in action, I can understand the reasoning.

> [4] IMHO, it is a terrible nonsense that people work on so many Scheme
>     implementations in parallel, only to feed the egos of their
>     respective leaders.

You and me both -- what other possible reason could people have for
working on anything but Guile? ;>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[bitwize]

On 19 Apr 2002, Nicolas Neuss wrote:

> Unfortunately, all those goals are very questionable.  First, non-lisp
> languages get more and more of Lisp's capabilities[1] and the
> advantage is not large any more, especially for the spartanic Scheme
> branch.  Second, my guess is that most applications are written within
> one language, because maintaining the interface between two languages
> is a problem.  Third, replacing Elisp with Common Lisp would probably
> be both easier and better (but is still difficult, see below).
> Fourth, more liberal licenses than the GPL (e.g. some BSD license) or
> GPLed software not maintained by the FSF is also a nice thing[2].
> Fifth, emulating languages in an integrating way is easy to say, but
> difficult to work out (this is proved by Guile not emulating one
> single other language in a reasonable way).

What about .NET? :) (Actually, this too is proof of your point; in order 
to shoehorn certain languages, such as Perl and even Visual Basic, into 
.NET's architecture some pretty significant changes had to be made to 
these languages' syntaxes and paradigms.)

This hacker couldn't care less about the ideology and motivation behind 
Guile. Perl and Tcl annoy me, but Guile is fun and it's useful, and I can 
quickly hack up workable programs with it that would have taken quite a 
long time with another language. (I once wrote a fairly complete, albeit 
non-validating, XML parser in Guile over an evening or two.) It is for 
these reasons that I joined guile-devel not too long ago (after lurking on 
guile-user for X years): I want to help keep Guile strong.

> Where does Guile stand now?  In my eyes, Guile is fighting on a lost
> position.  I will elaborate a little bit on this in the following.

I disagree with this position. There are many things that Guile has going 
for it.

> Second, I have serious doubts that Scheme as a language succeeds (in
> spite of PLT Scheme).  It is quite astonishing that at this time a
> language is propagated as the ultimate weapon, which has neither OO
> support nor modules/namespaces in a standardized way.  It seems that
> the Scheme dogma of accepting only perfect solutions approaches now a
> boundary where only several 90% solutions are available, and thus
> cannot be extended further.  Even inside the Lisp language family,
> Scheme looses against (ANSI) Common Lisp which supplies both a very
> strong OO system and packages in a standardized way.  There are also
> good and free CL implementations, namely CLISP (GPL, only
> byte-compilation, very portable) and CMUCL (public domain, compilation
> to native code, less portable). [3]

As I mentioned before, the fact that "it's GNU" means a great deal to 
Guile. There are a lot of disparate variations of Scheme out there, that's 
true. (Some, such as SIOD, call themselves Scheme but don't adhere to any 
published Scheme standard.) Part of Scheme's problem is its Pascal stigma: 
it's an "educational" language, so no one will use it for any *real* 
work, so why not slap your own umpteenth extension on it. Even 
though Guile is Scheme, it possesses some really robust APIs, particularly 
in the string handling, file, and networking side of things, that make it  
useful for  real-world tasks. It is also central to several GNU projects, 
including  TeXmacs and GNOME. Because it is a living, functional part of 
the GNU  project, Guile is well suited to shake off the Pascal stigma and 
*become* a sort of de facto standard, one whose APIs and paradigms other 
Schemes hopefully will emulate.

The SRFI process, which helps crystallize the Scheme community around some 
good ideas and provide implementations that work across Schemes, is a 
step in the right direction. Maybe more Guile hackers should contribute 
SRFIs that encapsulate Guile's strong points.

> [Third, of course, it is questionable if Lisp itself will survive,
> because the Lisp family as a whole is attacked by other languages like
> Java, C++, ML, Smalltalk/Squeak, ...  But there were Kassandras for
> Lisp all the time during its long life.]

LISP has a lot of things going for it too, but I don't want to start an 
advocacy flamewar. LISPers see enough advantages in LISP that Perl, 
Smalltalk, Java, et al. have yet to match in any significant way. "Those 
who do not understand LISP are doomed to reimplement it, poorly." :) We 
could debate the technical points all we like, but LISP has an ineffable 
nature about it that most other languages lack... or maybe no programmer 
has yet effed it in a suitable manner. In contrast I find Perl's nature to 
be quite effable; I find myself frequently muttering, "This effing 
syntax..." :)

My point is that LISP (and by extension, Scheme (and by extension, 
Guile)) is more than the sum of its parts and will remain a strong 
language for a variety of applications.

> What should Guile do?  In my opinion, there should be a drastic change
> in direction.  First, of course, you should finish the current ?1.6?
> release as fast as possible.  But then you should evaluate several
> other Scheme implementations, as well as CLISP and CMUCL.  If it
> should turn out that Guile has enough merits (apart from the merit
> that it's the Scheme you know), fine, forget my words.  If not, you
> should talk seriously to RMS.  Because then it is time to rethink this
> project and take appropriate actions.  These actions may go from
> joining with SCM on the one side[4] to shifting the whole project
> towards Common Lisp as extension language on the other side (leaving
> the domain "Scheme as an educational language" to PLT Scheme).

AFAIK Guile is a derivative, and extension, of SCM. SCM's goals appear to 
be different from Guile's.

> Concerning Elisp replacement, it would make sense to drop Scheme in
> favor of CLISP, too.  This would make the project much easier, because
> CL and Elisp are comparatively near (especially when you do (require
> 'cl) in Emacs:-).  Further, there are Emacs-like editors written in
> CL, see Hemlock for CMUCL from which one could maybe take some code.
> Also, there may be CL people willing to help, even Erik Naggum (see
> footnote) once planned something like that.  One should keep in mind,
> that it is still a hairy project[5].  But it could succeed, if
> Stallman pushed it.

There are Emacs-like editors written in Scheme too: see MIT Scheme's 
Edwin. :)

> That's all I have to say.  What concerns myself, I have switched to
> Common Lisp about two years ago.  I guess, I'll drop out of the Guile
> mailing list soon.  I want to thank the people that were and are on
> this list.  I learned a lot of things, but I prefer another playground
> now.

Sorry to see you go. That's the way these things go, I guess.

-- 
Jeffrey T. Read
"LOBSTER STICKS TO MAGNET!"



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Kirill Lisovsky]

On Mon, 22 Apr 2002 bitwize@wizards-of-source.org wrote:

> long time with another language. (I once wrote a fairly complete, albeit 
> non-validating, XML parser in Guile over an evening or two.) It is for 
> these reasons that I joined guile-devel not too long ago (after lurking on 
> guile-user for X years): I want to help keep Guile strong.
> 
You may be interested in SSAX XML parser, which works on Guile.
http://ssax.sf.net

IMHO, Scheme is most effective XML-scripting language, and SSAX/SXML
provide the proper infrastructure for this.

Best regards, 
          Kirill.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[rm]

On Mon, Apr 22, 2002 at 10:36:54PM +0400, Kirill Lisovsky wrote:
> On Mon, 22 Apr 2002 bitwize@wizards-of-source.org wrote:
> 
> > long time with another language. (I once wrote a fairly complete, albeit 
> > non-validating, XML parser in Guile over an evening or two.) It is for 
> > these reasons that I joined guile-devel not too long ago (after lurking on 
> > guile-user for X years): I want to help keep Guile strong.
> > 
> You may be interested in SSAX XML parser, which works on Guile.
> http://ssax.sf.net
> 
> IMHO, Scheme is most effective XML-scripting language, and SSAX/SXML
> provide the proper infrastructure for this.

I agree with that, but remember, XML _needs_ unicode strings (no way arround
that) and unfortunately guile doesn't have builtin unicode support. Pretty much
a show stopper :-(

  Ralf
 
> Best regards, 
>           Kirill.
> 
> 
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Rob Browning]

rm@fabula.de writes:

> I agree with that, but remember, XML _needs_ unicode strings (no way
> arround that) and unfortunately guile doesn't have builtin unicode
> support. Pretty much a show stopper :-(

This is one of the things I'd like to put on the post 1.6.1 agenda.  I
know it's been beaten to death more than once here, but last time it
sounded like we almost came up with something we could all live with.

I'd also like to discuss compilation, and versioning of scheme level
modules via (use-modules (foo bar :interface 3)) or similar.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Roadmap and goals?

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Sat, 20 Apr 2002 00:47:10 -0700

      From: Tanel Tammet <tammet@staff.ttu.ee>
      Date: Wed, 17 Apr 2002 15:21:47 +0300

      I guess it would benefit not only me 
      but the Guile development and acceptance 
      on a wider scale if such guides, policies,
      roadmaps etc existed and were easy to locate.

   for some of this, see:

     http://www.glug.org/snap/workbook/

for compilation specific notes, see:

  http://www.glug.org/snap/workbook/compilation/

it's still pretty sparse, but perhaps that will change.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel