Re: Shared substrings

[erik hilsdale <ehilsdal@xxxxxxxxxxxxxx>]

ms == d96-mst-ingen-reklam@xxxxxxxx (Mikael Ståldal)

  ms> I still don't like the current practice of allowing START and
  ms> END parameters to almost every procedures, since this encourage
  ms> a bad programming style. If you need the performance of shared
  ms> substrings, you should use a Scheme implementation which have
  ms> that, or write your programs in C instead, IMHO.

If we were writing a language spec then I might fight to keep these
optional parameters out.  Then I would have the power to require all
implementors of the language to implement shared substrings.  I might
even require them to optimize

        (string-foo (substring mystr 33 99))
        ==> (%string-foo mystr 33 99)

so even programmers who are as miserly about generating garbage as I
am would be comfortable with using shared substrings, knowing that the
sharing would only be virtual in the common case.

But we're not writing (well, editing? taking pot shots at?) a language
spec.  We're writing a library spec, and one that should be useful to
even those few unimportant Scheme implementations developed by people
who for some reason or another had better things to do than add shared
substring support to their runtime.

I wish that I could treat the three elements of a substring as one
argument and yet be guaranteed it would be passed in three
registers/framelocs/whatever in the common non-heap-allocated case.
That is, I wish Scheme had/required ML's tuple unpacking.  It (the
language, and all implementations of it that I'm aware of) doesn't and
it (the language) never will.

But I sometimes need the speed that such unpacking would give me.  I
like the optional arguments.  I'll use them when I need such
efficiency.  Heck, I've already used versions of half of them
(versions that, alas, didn't have the benefit of Olin's consistent
design) in my CGI scripting in Chez Scheme.  Bad programming style?
I'm not convinced.  An idiom forced upon us to get efficiency out of a
non-statically-typed-and-frequently-incrementally-compiled language?
Sure.

  ms> However, I have a compromise idea. Instead of the optional START
  ms> and END parameters, allow using a list '(s start end) instead of
  ms> the string parameter. 

I'm not sure I understand how this is a win over the optional
start/end parameters, apart from generating more garbage and feeling
more Lispy ("Lists can do anything!  We can even treat them as
strings.  Sometimes").

-erik