guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile history: your input needed!


From: Clinton Ebadi
Subject: Re: guile history: your input needed!
Date: Sun, 23 Nov 2008 20:17:55 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

"Linas Vepstas" <address@hidden> writes:

> Hi,
>
> 2008/11/23 Neil Jerram <address@hidden>:
>>  If we had a clearer statement of
>> the present, it would not matter so much how people describe the past.
>
> Is there a clear expression of a vision for the future?
> What might one look forward to? What needs to be
> done?

In the near future it looks like the task list is something like:

 * Merge the guile-vm branch into trunk
 * Ditch the Guile GC for BDW-GC (maybe; the lower latencies and
   parallel collector give it a clear advantage of the Guile GC IMO)
 * Unicode string support (perhaps for the first post stable-guile-vm
   release).
 * CFFIesque runtime loading of foreign functions

A 2.0 release with at least guile-vm would be nice (perhaps six months
or so from now?); the C API has stabilized nicely over the last few
years, and so it is now much easier to write extensions that won't
bitrot--it is not so difficult to write something that will work with
1.6->git-head (there used to be a lot more libraries for Guile; most of
them were written in the 1.3/4 days and are severely incompatible with
modern Guile).

After guile-vm is mainline it would be nice if Guile really became the
GNU Ubiquitous Intelligent Language for Extension. Finding GNU programs
that could use an extension language and embedding Guile, replacing
existing application specific scripting languages with FOO->Guile
translators, and binding useful GNU libraries should be done to as many
GNU projects as possible.

In the long long term the guile-vm compiler framework could be used to
translate other languages into Scheme (or GHIL/GLIL/vm-bytecode)
fufilling one of the original goals of Guile (embed Guile in your
application and now end users can use whatever language they please to
write extensions--with some interoperability between them). A good early
language to write a translator for would be ECMAScript; no one expects
consistency between embedded ES systems and the standard library is
small enough to implement quickly in Scheme.

In the u256_t term replacing the Emacs interpreter with Guile and an
elisp->{scheme/GHIL/GLIL/...} translator.

-- 
                     How can you accept social supression                      
                      This weak state of mind in our time                      
                        I demand release from hypocrisy                        
                 I'd rather die than be held down, forced down                 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]