CLIM mail archive
[Prev][Next][Index][Thread]

((sequence symbol) :separator #\space)

    Date: Wed, 15 Sep 1993 10:22 EDT
    From: Jeff Morrill <jmorrill@BBN.COM>


    Hi,

    I am using clim 2 via allegro 2.0.beta2.  I am sending this bug
    report to clim@bbn.com because I imagine all the vendors could have
    the same problem.

    There is a bug in the presentation type ((sequence symbol) :separator #\space).
    It works with one space between tokens and no trailing spaces:

    (accept-from-string '((sequence symbol) :separator #\space) "one two three")
    Returns:
    (ONE TWO THREE)
    ((SEQUENCE SYMBOL) :SEPARATOR #\space)
    13

    But if you include more than one space between tokens, or any trailing
    spaces, you get errors.  All of the following generate errors for me.

    (accept-from-string '((sequence symbol) :separator #\space) "one  two three")
    (accept-from-string '((sequence symbol) :separator #\space) "one two  three")
    (accept-from-string '((sequence symbol) :separator #\space) " one two three")
    (accept-from-string '((sequence symbol) :separator #\space) "one two three ")

    This is quite different from the default behavior of SEQUENCE (using
    commas as delimiters) which is appropriately tolerant of extra whitespace.

    I imagine what is happening is that the separator character is
    being used as an activation gesture.  This is OK as long as
    there is an extra call within the SEQUENCE parser to move past
    the whitespace.  I guess you could describe this as an unanticipated
    interaction here between the property of being a whitespace character
    and the property of being an activation gesture.

    In any case, trailing spaces should not matter.

Hmm, I dunno about this.  When you say that #\space is a separator
character, that declares that space unambiguously separates fields.
I am not sure that ignoring whitespace is appropriate when #\space is
a delimiter.  You surely wouldn't send this bug report if, instead of
#\space, the delimiter was #\, and CLIM complained when it saw extra
commas...

I might argue that, for the failing cases, the correct results are:

 ("one" "" "two" "three")
 ("one" "two" "" "three")
 ("" "one" "two" "three")
 ("one" "two" "three" "")

All that aside, it's not completely clear to me where exactly one
would put the DWIM in to ignore extra whitespace.  A few minutes of
investigation yielded some likely candidates, but I can't convince
myself that they won't introduce other problems.

I'll track this as a bug in case I can think of anything that isn't
too magic.
References:
Main Index | Thread Index