Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbol element>*| to #"<string element>*"
Alex Shinn
(13 Mar 2012 02:08 UTC)
|
Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbol element>*| to #"<string element>*" Andrew Robbins (13 Mar 2012 02:31 UTC)
|
Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbol element>*| to #"<string element>*"
Arthur Smyles
(13 Mar 2012 03:37 UTC)
|
Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbol element>*| to #"<string element>*"
John Cowan
(13 Mar 2012 04:47 UTC)
|
Re: [Scheme-reports] Formal Comment: Change syntax of symbols from |<symbol element>*| to #"<string element>*"
Alan Watson
(08 Apr 2012 23:35 UTC)
|
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@gmail.com> 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@verizon.net> 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@scheme-reports.org >> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > > _______________________________________________ > Scheme-reports mailing list > Scheme-reports@scheme-reports.org > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports