My Guile Wishlist

My Guile Wishlist

[Evan Prodromou]

So, while I've been thinking about Guile, I've been considering some
of the things that I wish were part of the system that aren't. Because
they're on my mind right now, I figure I'll post them.

1. I wish there weren't so much detritus in the Scheme interface that
   Guile provides.

2. I wish that there was One Good Way To Do It, and that other ways
   were optionally loadable with a module for compatibility.

3. I wish that when I loaded Guile, I could get a system with only
   R5RS Scheme + modules support, until I started loading stuff. I
   wish that anything in Guile that was an enhancement to Scheme had
   to be loaded with (use-modules).

4. I wish that I could do this:

   #! /usr/bin/env guile                         
   !#

5. I wish I could figure out the scm_ interface.

6. I wish that I could add Guile to existing programs, like Apache,
   with those programs' loadable module systems, without having to
   modify the program's "main" function.

7. I really, really wish there was a mod_guile. Did I mention that
   already?

8. I wish that GUMM was up and working.

9. I wish that Guile was so good that GNU projects wouldn't even
    think about using any other scripting/extension language.

10. I wish that there was a project library with everything under the
    sun that you could want in it.

11. I wish that starting-off Guile programmers felt a little
    disappointed because it was too easy.

12. I wish that when I went through the documentation for Guile, I
    would be constantly amazed at the elegance and utility of the
    design, rather than thinking, "What the hell is a low-level object
    interface, why do none of the functions have reasonable
    documentation, and why the hell would I ever use this?" or, "Who
    cares what Aubrey Jaffer did in 1993?"

So, let me re-iterate: I love Guile. I use it all the time. But these
things would make me happier than I am now.

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us


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

Re: My Guile Wishlist

[Rob Browning]

Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

> So, while I've been thinking about Guile, I've been considering some
> of the things that I wish were part of the system that aren't. Because
> they're on my mind right now, I figure I'll post them.
>
> 1. I wish there weren't so much detritus in the Scheme interface that
>    Guile provides.

There's a plan to clean this up -- presuming you're talking about the
scm_/gh_ interfaces.  See devel/policy/names.text.  We've also decided
to eventually drop the gh_ interface and fully document/cleanup the
scm_interface.  This is a GOOD THING as it takes the status of both
out of limbo and makes it clear where efforts should be spent.

However, this transition will take a while and there will have to be
scm_c_ equivalents for all the important gh_ functions first.

> 3. I wish that when I loaded Guile, I could get a system with only
>    R5RS Scheme + modules support, until I started loading stuff. I
>    wish that anything in Guile that was an enhancement to Scheme had
>    to be loaded with (use-modules).

This has long been a goal, but hasn't gotten a lot of attention lately.

> 4. I wish that I could do this:
>
>    #! /usr/bin/env guile                         
>    !#

I suspect some kind of functionality like this, though perhaps invoked
via a different binary name will probably come -- if I recall
correctly, this (or something similar) is what the SRFI wants.

> 5. I wish I could figure out the scm_ interface.

See (1) -- this should be forthcoming as we make the transition and
clean things up.

> 6. I wish that I could add Guile to existing programs, like Apache,
>    with those programs' loadable module systems, without having to
>    modify the program's "main" function.

As you wish -- see the docs for scm_init_guile in the 1.5.X info
pages, and give thanks to those who figured out the attendant stack
trick(s) :>

> 7. I really, really wish there was a mod_guile. Did I mention that
>    already?

Talk to Dale Smith.  (Hi dsmith :>)

> 9. I wish that Guile was so good that GNU projects wouldn't even
>     think about using any other scripting/extension language.

We'll see if we can arrange that :>

> 10. I wish that there was a project library with everything under the
>     sun that you could want in it.

This is an *important* point, but I'm not quite sure how to address it
yet.

> So, let me re-iterate: I love Guile. I use it all the time. But these
> things would make me happier than I am now.

In addition, one looming concern I have, is that we make sure not to
put ourselves in an ugly position because libtool and more
particularly ltdl make it *very hard* to DTRT.  You can't
create/install multiple versions of a shared library in a way that
would allow you, even with an explicit path to open the particular one
you need at runtime.  i.e. there's no

  lt_dlopen_interface("libfoo", 12);

and we *really* need one.

I do have some ideas how to fake this, though -- presuming the libtool
people aren't able to or don't want to fix it.  I believe it's the
underlying cause of the libreadline problems people have been having.

-- 
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-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: My Guile Wishlist

[Evan Prodromou]

>>>>> "RB" == Rob Browning <rlb@defaultvalue.org> writes:

So, thanks for your response. I think the one that makes me happiest
is the one about embedding Guile in Apache. After that, heck, I don't
care too much.

    >> 10. I wish that there was a project library with everything
    >> under the sun that you could want in it.

    RB> This is an *important* point, but I'm not quite sure how to
    RB> address it yet.

Well, I think that the Guile project list is a good start, and I think
that GUMM needs some attention -- it's probably my next hacking
project after I finish the one I'm working on.

I think the main thing is having more Guile programmers and giving
them an easy way to register modules with the library. I _don't_ think
this is a job for the Guile development group, though.

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us


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

Re: My Guile Wishlist

[Neil Jerram]

>>>>> "Evan" == Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

    Evan> So, while I've been thinking about Guile, I've been considering some
    Evan> of the things that I wish were part of the system that aren't. Because
    Evan> they're on my mind right now, I figure I'll post them.

Useful list - thanks!

    Evan> 1. I wish there weren't so much detritus in the Scheme interface that
    Evan>    Guile provides.

One thing that we need to do here is figure out how to divide up
everything currently in boot-9.scm.

I totally agree with everything else, except for ...

    Evan> 3. I wish that when I loaded Guile, I could get a system with only
    Evan>    R5RS Scheme + modules support, until I started loading stuff. I
    Evan>    wish that anything in Guile that was an enhancement to Scheme had
    Evan>    to be loaded with (use-modules).

I think it is OK for `guile' to include some Guile extensions, as long
as we also provide a `guile --pure' for what you want.

    Evan> 4. I wish that I could do this:

    Evan>    #! /usr/bin/env guile                         
    Evan>    !#

Nah.  OS-dependent eye candy, IMO.

    Evan> 12. I wish that when I went through the documentation for Guile, I
    Evan>     would be constantly amazed at the elegance and utility of the
    Evan>     design, rather than thinking, "What the hell is a low-level object
    Evan>     interface, why do none of the functions have reasonable
    Evan>     documentation, and why the hell would I ever use this?" or, "Who
    Evan>     cares what Aubrey Jaffer did in 1993?"

Please feel free to suggest patches, no matter how small.  (In fact
small is better, since it doesn't raise paperwork issues.)

        Neil


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

Re: My Guile Wishlist

[Neil Jerram]

>>>>> "Evan" == Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

    Evan> 1. I wish there weren't so much detritus in the Scheme interface that
    Evan>    Guile provides.

    Evan> 2. I wish that there was One Good Way To Do It, and that other ways
    Evan>    were optionally loadable with a module for compatibility.

Further thought on these two, as I realized how central this is both
to many of the changes between 1.4 and 1.6, and to the lessons we're
learning in trying to get 1.6 out.

Take, for example, the module system, obarrays and so on (vcells,
variables, builtin bindings ...).

On the one hand, these related areas have been dramatically simplified
since 1.4, in pursuit of the goal that there should be one simple,
easy to understand way of doing things.

On the other hand, this has left us with a problem as regards
documenting what's changed clearly enough for people using the old C
interface.

In other words, we have to start from where we are, and the biggest
brake on us trying to reach One Good Way To Do Things is the need to
provide backwards compatibility and to explain changes, and the
limitations of the tools we have available to help us do that.

        Neil


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

Re: My Guile Wishlist

[Robert A. Uhl]

On Tue, Mar 19, 2002 at 07:56:11PM +0000, Neil Jerram wrote:
> 
>     Evan> 4. I wish that I could do this:
> 
>     Evan>    #! /usr/bin/env guile                         
> 
> Nah.  OS-dependent eye candy, IMO.

Ah, but it's the _only_ OS.  And Unix is what, by and large, Guile
runs on (heck, _is_ there a Windows port?).  And it sure beats having
to have wrapper scripts for everything.

-- 
Robert Uhl <ruhl@4dv.net>
Cooking is great--it's a socially acceptable excuse to play with knives
and fire.

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

Re: My Guile Wishlist

[MJ Ray]

Evan Prodromou <evan@prodromou.san-francisco.ca.us> wrote:
> 2. I wish that there was One Good Way To Do It, and that other ways
>    were optionally loadable with a module for compatibility.

Related to this, I wish more people would submit good general interfaces to
the SRFI process ( http://srfi.schemers.org/ ) and more people would
implement more of them.


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

Re: My Guile Wishlist

[Evan Prodromou]

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

    NJ> On the other hand, this has left us with a problem as regards
    NJ> documenting what's changed clearly enough for people using the
    NJ> old C interface.

Well, the example of modules is particularly difficult thing to work
with. 

But I think the current strategy of phasing things out over 2 releases
(deprecate in 1.6, remove in 1.8) is more than fair.

~ESP

-- 
Evan Prodromou
evan@glug.org

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

Re: My Guile Wishlist

[Evan Prodromou]

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

    Evan> 3. I wish that when I loaded Guile, I could get a system
    Evan> with only R5RS Scheme + modules support, until I started
    Evan> loading stuff. I wish that anything in Guile that was an
    Evan> enhancement to Scheme had to be loaded with (use-modules).

    NJ> I think it is OK for `guile' to include some Guile extensions,
    NJ> as long as we also provide a `guile --pure' for what you want.

OK, but I'm using 1.5.6, with an un-modified (ice-9 boot), and
readline in my .guile, when I start Guile I can do this:

---8<---
      guile> (<tab>
      Display all 1589 possibilities? (y or n) n
      guile> (
---8<---

One thousand, five hundred and eighty-nine completions, out of the
box, without (use-modules)'ing anything. Now, you can say that that's
all out of stuff added with (ice-9 boot), but regardless of where it
comes from, this is what I see when I start Guile.

I think this might make Guile the largest language in history. I don't
think Common Lisp has more than six or seven hundred or so built-ins.

~ESP

-- 
Evan Prodromou
evan@glug.org

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

Re: My Guile Wishlist

[rm]

On Tue, Mar 19, 2002 at 08:14:45PM +0000, Neil Jerram wrote:
>  ...
> Take, for example, the module system, obarrays and so on (vcells,
> variables, builtin bindings ...).
> 
> On the one hand, these related areas have been dramatically simplified
> since 1.4, in pursuit of the goal that there should be one simple,
> easy to understand way of doing things.
> 
> On the other hand, this has left us with a problem as regards
> documenting what's changed clearly enough for people using the old C
> interface.

Thanks, this expresses very well my recent feelings about the upcoming
changes. Even so i'm lurking on guile-user as well as guile-developer
it sometimes took me hours (if not days :-) to adapt existing (C-) code
to the CVS guile. I can well imagine that application developers that
spent more time on their apps and less on the guile mailing lists will
cry out in horror when confronted with these rather dramatic changes.
As a test case, try porting SCWM (currently in stable Debian) to the new
guile ...
A few observations:

 - many changes are just "cosmetic". Renames of typedefs/functions etc.
   can be softened by the use of a comaptibility header that gets included
   in all files. [1] [2] 

 - Given the neccesary information most changes are rather trivial. The 
   sometimes frustrating part is the 'compile-and-see-what-disapeared'
   cycles. Maybe some authomatic code scanner could help here. I started
   to use 'rats' (http://www.securesw.com/rats/)  for this task, unfortu-
   nately i currently don't have enough time nore insight to create  the 
   full database of changes (rats uses a xml based database file that 
   optionaly can include tips and background information. I'm pretty shure 
   that such a database could be maintained as an online resurce. Thinking
   of it: i could probably provide the online space and set up a web interface
   if someone wants to help with the actual content).


 Ralf Mattes
[1] It would be helpfull to include suggestions on how to replace deprecated
    defines/functions into the NEWS or ChangeLog files.
[2] It's rather irritating if newly introduced functions use deprecated
    symbols (file NEWS, line 981: 
    ** New function: scm_c_read (SCM port, void *buffer, scm_sizet size)

> In other words, we have to start from where we are, and the biggest
> brake on us trying to reach One Good Way To Do Things is the need to
> provide backwards compatibility and to explain changes, and the
> limitations of the tools we have available to help us do that.
> 
>         Neil
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user

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

Re: My Guile Wishlist

[Evan Prodromou]

>>>>> "EP" == Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

    EP> So, while I've been thinking about Guile, I've been
    EP> considering some of the things that I wish were part of the
    EP> system that aren't. Because they're on my mind right now, I
    EP> figure I'll post them.

You know, I enjoyed doing this list so much, I'm going to throw out a
couple of extra wishlist items that I thought of after I sent out my
message.

* I wish that Guile had a single mechanism, using lex-and-yacc-style
  syntax, to define emulators for other languages. I'm not
  particularly crazy about the whole language-emulation hoohaw, and
  I'd never, ever use it, but it's driving me nuts (arr) seeing very
  smart people waste their time on one-off emulation tools. I'd really
  love to see them become trivial -- or at least semi-trivial --
  efforts.

* I wish that Guile had a single, _core_ compilation feature --
  whether the compilation is into bytecode, or native code, or is
  just-in-time compilation using GNU Lightning. Not that I love
  compiled code oh-so-much, but again because I'm tired of seeing all
  these one-off side projects that get bit rot and die.

OK, those are the ones I thought of.

~ESP

-- 
Evan Prodromou
evan@glug.org

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

Re: My Guile Wishlist

[Rob Browning]

Evan Prodromou <evan@glug.org> writes:

> * I wish that Guile had a single mechanism, using lex-and-yacc-style
>   syntax, to define emulators for other languages. I'm not
>   particularly crazy about the whole language-emulation hoohaw, and
>   I'd never, ever use it, but it's driving me nuts (arr) seeing very
>   smart people waste their time on one-off emulation tools. I'd really
>   love to see them become trivial -- or at least semi-trivial --
>   efforts.

You and me both.  Very strange that :>

I've heard good things about Zebu, but never used it.  It's here along
with many others...

  http://www.cs.indiana.edu/scheme-repository/code.lang.html

> * I wish that Guile had a single, _core_ compilation feature --
>   whether the compilation is into bytecode, or native code, or is
>   just-in-time compilation using GNU Lightning. Not that I love
>   compiled code oh-so-much, but again because I'm tired of seeing all
>   these one-off side projects that get bit rot and die.

This is *DEFNIITELY* on the (virtual) list -- but after talking with
Marius, I tend to agree that doing it "right" will probably take a
little bit of time.  It likely a non-trivial shift from the purely
interpreted system that we have now, to something structured in a
fashion more amenable to compilation.

-- 
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-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: My Guile Wishlist

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Tue, 19 Mar 2002 21:53:25 GMT

   Related to this, I wish more people would submit good general
   interfaces to the SRFI process ( http://srfi.schemers.org/ ) and more
   people would implement more of them.

semi-OT question: anyone do the srfi "auto-subscribe" thing and not get
automatically subscribed to new lists?  (e.g., i think it's up to 28 now
but there was nary a mention in my mailbox of 24 25 26...)  maybe this
service is no longer supported?

thi

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

Re: My Guile Wishlist

[Thien-Thi Nguyen]

   From: rm@fabula.de
   Date: Wed, 20 Mar 2002 14:18:01 +0100

    - many changes are just "cosmetic". Renames of typedefs/functions
      etc.  can be softened by the use of a comaptibility header that
      gets included in all files.

this is a good idea.  i will add it to TODO.

re documentation, info node "scm transition summary" probably covers a
good bit of the change space.

      create the full database of changes (rats uses a xml based database
      file that optionaly can include tips and background information. I'm
      pretty shure that such a database could be maintained as an online
      resurce.

we currently have Scheme/C interface lists for any pair (guile interpreter,
libguile.so) and api-diff to do a set-difference on any two of these.  we
don't run api-diff automatically (and publish output) at the moment, but
you are free to use what's there to try to finangle proper input xml for
downstream programs.

here's a simple program to get you started:
  #!/bin/sh
  glugsnap='wget http://www.glug.org/snap/'
  ${glugsnap}guile-core-1.4/doc/guile-api.alist -O 1.4.alist
  ${glugsnap}guile-core-1.6/doc/guile-api.alist -O 1.6.alist
  ${gnugsnap}guile-core/scripts/api-diff
  chmod +x api-diff
  api-diff 1.4.alist 1.6.alist

i might add this to glug.org at some point...

thi

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