guile-devel
[Top][All Lists]
Advanced

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

Re: strings rationale


From: Rob Browning
Subject: Re: strings rationale
Date: 15 Aug 2001 10:51:14 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Tom Lord <address@hidden> writes:

> 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.

But it's not designed to hurt that either.  If you want a function
that can take a symbol or a string as an argument, you can write that.

> We don't have *any* applications that use Guile as it was originally
> intended: as the primary implementation language of an extensible
> application.

Huh?  What about gnucash?  It's a *giant* application composed of an
awful lot of guile code.

> 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.

You asked about design considerations in another thread.  IMO, one of
the fundamental design considerations is that Guile be at *least* an
RXRS compliant implementation of the Scheme language, though it may
well be more.  To me, making #f and () or strings and symbols
interchangable means that Guile is no longer Scheme, and is in fact at
least somewhat incompatible.

If we want to have a switch, or a module that you load that optionally
enables features like this within a local scope somehow, then that's
fine.  I don't mind that, but it shouldn't be the default.

I'm also one of those who tends to think that #f, () interchangability
is a mistake, not a feature, and I've written a fair share of CL/CLOS
code and scheme code, so I'm not just speculating idly, though I
wholeheartedly agree with you that Scheme needs a richer set of
*well-defined and portable* libraries, but I'm encouraged by the SRFI
process which seems to be delivering them.

Finally, on the string/symbol issue.  I tend to think that making them
interchangable may actually hurt.  It encourages people to think of
symbols as strings, when to my mind, they should be thought of more
properly as set elements that just happen to have human readable
names, names that you can get at as strings if/when you need them.

i.e. in many cases the question is whether I'm trying to represent a
set of discrete items, or a list of arbitrary names, and from a
code/implementation standpoint, it's the difference betweeen:

  (cond ;; presume we know x is a string
    ((string=? x "foo") ...)
    ((string=? x "bar") ...)
    ...)

and

  (case x ;; presume we know x is a symbol
    ((foo) ...)
    ((bar) ...)
    ...)

Without heroic optimizations, the former will always require some kind
of string comparison, hash lookup, whatever, where the latter can
possibly be optimized by a good compiler to the equivalent of

  switch(x) {
    case 0: ...
    case 1: ...
    ...
  };

which will be *much* faster.  If we preserve the type distinction and
the mental model, then people can (and hopefully will) choose the
appropriate type for their task, and if/when we write a really good
compiler, the benefits will be dramatic where appropriate, and even if
you could optimize the case where strings and symbols were
indistinguishable, I still think that such a composition doesn't
preserve an algorithmically important distinction.

FWIW

-- 
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



reply via email to

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