[Top][All Lists]

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

Re: The empty string and other empty strings

From: Mark H Weaver
Subject: Re: The empty string and other empty strings
Date: Fri, 13 Jan 2012 11:39:21 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

David Kastrup <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:
>> Hi Mark,
>> Mark H Weaver <address@hidden> skribis:
>>> What do other people think?
>> As you said, R5RS makes it clear that there can be several (in the sense
>> of eq?) empty strings, so I think what you did is the right thing.
> Since it uses the same verbiage with regard to '(), could you please
> point out _where_ R5RS states that "freshly allocated" means "not
> eq?"?

Section 3.4 (Storage model) of the R5RS states:

  Whenever this report speaks of storage being allocated for a variable
  or object, what is meant is that an appropriate number of locations
  are chosen from the set of locations that are not in use, and the
  chosen locations are marked to indicate that they are now in use
  before the variable or object is made to denote them.

> For me it means "does not contain any component in common with
> previously allocated material".  The fixed constant '() or (list) (the
> neutral element with regard to list concatenation) not containing any
> allocated pairs meets that description, and the fixed constant "" or
> (string) (the neutral element with regard to string concatenation) not
> containing any allocated characters meets that description.

I think this is a very reasonable interpretation, but this is not in
accordance with the standard.

> So why treat them differently?  What does it buy us except trouble?

I don't see how our current behavior buys us _any_ trouble.  We've
voluntarily opted-out of a (marginal) optimization opportunity, and
that's all.

In your proposed behavior: in _almost_ all cases, `scm_from_stringn' (et
al) would return an object that is not `eq?' to any other existing
object.  However, in a single edge case, you'd have it return something
that _is_ `eq?' to other existing objects.  This is the kind of behavior
that could easily buy us trouble.

To my mind, if the optimization is insignificant (and I suspect that it
is), then it is safer to treat the edge cases the same as the common
case, for the sake of simplifying the semantics.

However, my mind is not set in stone on this.  Does anyone else here
agree with David?  Should we defend the legitimacy of this optimization,
and ask the R7RS working group to include explicit language specifying
that empty strings/vectors need not be freshly allocated?


reply via email to

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