Re: language translator help

[Marius Vollmer <mvo@zagadka.ping.de>]

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

> ok, i've chosen this to be the "application test load" for guile-1.4.2.
> why?  because guile-lang-allover-0.1 needs to install a private shared
> object library, which motivates design of how to support that.  this
> design can be used for guile itself.

Please don't do this in the context of 1.4 releases.  We have the 1.7
series for experiments like that.  Please keep the 1.4 releases
(if you feel that you must divert resources to them) as bug fixing
releases.

> in the process, libguilereadline and libqthreads will also be moved to
> $prefix/lib/guile/1.4.2 -- the only thing in $prefix/lib will be
> libguile -- and scheme bindings to lt_* will be introduced (where it
> makes sense).  this allows `load-extension' and ilk implementation
> experimentation.

On the specific point of what exactly a Guile extension or plugin is,
where to install it, how to link to it, etc, I remain convinced that
Guile itself should continue to treat its extensions as standard
operating system shared libraries, using libtool as the interface to
the operating system.

Experimentation can occur outside of Guile.  Packages that need to go
beyond the simplistic shared library view of the core Guile and want
to impose additional rules on the use of their shared libraries can do
so to a very large degree without needing any cooperation from Guile
itself.

For example, when we say that extension libraries should be installed
in $(libdir), a package can ignore this and install its libraries into
a special location and use 'load-extension' with an absolute filename.

> i encourage 1.5.x to continue, 1.6.x to be recast as 2.x (which allows
> all the deprecated stuff to be removed and compatibility to be thrown
> out the window w/ a clear conscience -- i.e., ttn will shut up),

Negative.  I don't have the feeling that we are dangerously
incompatible in the 1.6 series.  What do others think?  It would be
bad to switch strategies at this point, even if you have a point.

> and pushed out until at least the $prefix/lib/guile design is
> validated (through 1.4.2 release and user feedback)

What is wrong with Guile's current approach other than that you don't
like it?

> and incorporated.  this gives time to redo execution model right,
> too.  don't settle for poor quality, folks; that gives GNU a bad
> name and you will burn in Programmer Hell for it.

Well, Thien, there is enough opportunity for coding heros like
yourself to help us poor souls out.  Go and add interface versions to
lt_dlopen, for example.

> i will be communicating intent through modifying TODO, and findings and
> opinions through checkins under workbook/.  i will unsubscribe from
> guile-devel to protest its existence.  i don't believe in standing away
> from the users like that.

What?  The split is there so that people can choose not to be bothered
with developers chit chat.  You don't need a license to subscribe to
guile-devel.  It's a tool of organization, you process junkie, not of
dividing and conquering people.

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