guile-devel
[Top][All Lists]
Advanced

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

Re: strings rationale


From: Tom Lord
Subject: Re: strings rationale
Date: Mon, 6 Aug 2001 14:10:09 -0700 (PDT)

One of the original goals of the project was to max out on the
programming conveniences found in the language.  Doing so makes it
easier to more rapidly develop libraries, for example.  Eventually,
programmers using Guile should have been experiencing CL-like ecstasy
at always finding Just The Right Tool at their fingertips.  R5RS
doesn't help much with that, by design.

I think vague claims about the "community" don't hold much water,
especially when you have at least one Scheme hacker on the list
saying ``In my experience using this feature, it is worth having''
as I am about the old string lattice.  Ain't I community?

I don't think there's much point in making comparisons to perl, tcl
and python -- those projects are scripting languages which can also be
used as extension languages; Guile was an extension language that
could also be used for scripting: the difference in emphasis is not
small.  We don't have *any* applications that use Guile as it was
originally intended: as the primary implementation language of an
extensible application.  Therefore, it should be no surprise that
there aren't a lot of users.  As a scripting language, or a VB-style
extension language, Python etc. are probably way too far ahead
to worry about.  Ignore them, except as sources of ideas for
language features.

If we agree that the number of Guile users is too small, that's
another reason to think of re-organizing the language project around
an application project.  A good way to pick features, such as the
string lattice, is to write programs while asking yourself -- what
would make this code easier to write?  Then go back and come up with a
clean spec for the convenience feature.

An application project, if engineered well, is also a good motivator
for working on performance and robustness.

As for slib: You can get quite far from R5RS and still run R5RS code,
including slib, assuming you really want to bother.  And with modules,
you can implement an R5RS environment within a larger, non-R5RS
language, doing at most a little extra work to make sure it is safe to
pass data to and from the R5RS environment.

There isn't a lot of R5RS code out there that I've found particularly
useful.  I dropped slib from Systas a while ago.  FPS is nice, but
that runs just fine even in my #f==() environment.  The SRFI's I've
ported work just fine as well.

-t



   X-Authentication-Warning: marvin.ida.ing.tu-bs.de: dirk owned process doing 
-bs
   Date: Mon, 6 Aug 2001 19:38:53 +0200 (MEST)
   From: Dirk Herrmann <address@hidden>
   cc: address@hidden, address@hidden
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   X-UIDL: 6ba8c15234f48f66452c75895baddab1

   On Mon, 6 Aug 2001, Tom Lord wrote:

   > I don't understand your explanation.
   > 
   > Can symbols be used as strings?  Can there be substrings of symbols?

   No, there can't.  The reason is that R5RS does not allow it.  And, guile
   follows R5RS.  IMO, that is a good decision:  We benefit from the
   possibility to take scheme code from other schemes (slib is an
   example).  Introducing arbitrary incompatibilities does not help the
   community, which already is small compared to perl, tcl and python.

   Best regards,
   Dirk Herrmann






reply via email to

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