Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbol element>*| to #"<string element>*"

[Andrew Robbins <andjrob@x>]

I would like to second that remark (by Arthur Smyles). My rationale follows.

While (vertical bar) might be compatible with a great number of Scheme
implementations, namely Racket and Chibi, it is in my opinion an
anachronism from Lisp. There are several aspects of identifiers that
need to be considered here:

 - lexical space
 - value space
 - transmission

In terms of transmission, the (inline hex escape) lexical space of
R6RS is sufficient to encompass most of the value space of (vertical
bar) identifiers, with the added bonus of being able to be transmitted
to interpreters and compilers via 8-bit unsafe channels and 7-bit
encoded ASCII text files. Neither (vertical bar) nor Unicode
identifiers (also added in R6RS) can make this claim. While some may
argue that this is talk from the 90's, I do not believe it is
unwarranted. Unicode input methods may be ubiquitous (I write to my
friends in Japanese all the time), but some people still use editors
that are not Unicode ready. Both Unicode identifiers and (vertical
bar) identifiers require an excellent text editor to display and
encode your identifiers in the manner you wish.

What really bothers me is that the value spaces of all three syntaxes
are nearly identical. The value space of Unicode identifiers is all
Unicode strings except those including whitespace, delimiters and the
empty string. The value space of (inline hex escape) identifiers is
all Unicode strings except the empty string. The value space of
(vertical bar) identifiers is all Unicode strings, including the empty
string. So when we compare all three identifier syntaxes, we find that
the *only* advantage to (vertical bar) identifiers is the empty
string. Why would we add 1114111 redundancies to Scheme identifier
lexical space when the only addition to the value space is ||?

Regards,
Andrew Robbins

P.S. If you really want an identifier syntax that doesn't need to be
escaped, I would recommend looking for one that doesn't conflict with
Racket's bytevector syntax.

P.P.S. scsh is not the only lisp that uses | differently. Both Lisk
and Liskell (both sexpr versions of Haskell) use | in a way that is
consistent with Haskell, and not most other lisps.

On Mon, Mar 12, 2012 at 10:08 PM, Alex Shinn <alexshinn@x> wrote:
> #"..." is a bytestring in Racket, and possibly some other
> implementations.  Gauche has string extensions for #*"..."
> and #`...` (which is also quasisyntax in R6RS).  #|...| is
> used by SRFI-30 and the current draft.
>
> There are not a whole lot of character sequences left,
> though that in itself is an argument not to take too many
> just for string escapes.
>
> --
> Alex
>
> On Tue, Mar 13, 2012 at 10:53 AM, Arthur Smyles <atsmyles@x> wrote:
>> I understand that most implementations use the pipe syntax since that
>> was what Common Lisp standardized in the 90's. The consequences for
>> standardizing this syntax is a permanent increase in the complexity of
>> the reader and permanently breaking ideas like SCSH in the future.
>> However, using this new syntax will still allow implementations to
>> continue supporting their current implementation as a deprecated syntax.
>>
>> Arthur
>>
>> On 3/12/12 8:27 PM, John Cowan wrote:
>>> Arthur Smyles scripsit:
>>>
>>>> Summary:
>>>>
>>>> Change syntax of symbols from |<symbol element>*| to #"<string element>*"
>>> Formal comment ticket #360 filed; change ticket #361 filed.
>>>
>>> I don't think this idea will fly, because no existing implementations
>>> provide it.
>>>
>>
>> _______________________________________________
>> Scheme-reports mailing list
>> Scheme-reports@x
>> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
>
> _______________________________________________
> Scheme-reports mailing list
> Scheme-reports@x
> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports