Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, 09 Sep 2009 11:05:53 -0400, John Cowan wrote: > Andre van Tonder scripsit: > >> This, however, makes it difficult to write program transformers (for >> example macro expanders), that need to insert generated symbols for >> which the requirement is that they cannot be typed in user programs. > > As others have posted, I think using a separate (and implementation > specific) identifier type is now a win. At run time, gensyms are > basically > just strings that satisfy "symbol?" (and have p-lists, if your Scheme > does p-lists), and if you need to play with such things, you are better > off redefining "symbol?" or moving up to an informally-expressed union > datatype of strings and true symbols. Don't we already have an 'identifier?' procedure? We already have a system that distinguishes symbols and syntax. I'm not sure what the problem is. I may have missed the discussion... Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Sep 13, 2009, at 3:03 PM, Abdulaziz Ghuloum wrote:
> Having read/write invariant on gensyms has nothing to do with whether
> a call to gensym returns a fresh symbol or not (the reader does not
> have to call gensym when it reads #{foo bar}, instead, it may consult
> the "gensym table" first).
Since I managed to confuse two people with my wording here: this is
the point I was intending to make; readable gensyms ala Chez and
Ikarus are *not* broken.
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Sep 9, 2009, at 5:42 PM, Brian Mastenbrook wrote:
>> (gensym)
> #{g0 f3s6pdjhhzxupwds-a}
>> (define gensyms-readable
> (lambda ()
> (let ((g (gensym))
> (p (open-output-string)))
> (write g p)
> (let ((r (open-input-string (get-output-string p
> (eq? (read r) g)
>> (gensyms-readable)
> #t
>
> The actual requirement for the use of gensyms in this situation is
> that a gensym must not be eq? to any other symbol which already
> exists.
Having read/write invariant on gensyms has nothing to do with whether
a call to gensym returns a fresh symbol or not (the reader does not
have to call gensym when it reads #{foo bar}, instead, it may consult
the "gensym table" first).
A good way to think of Chez's/Ikarus's gensyms is that they're like
UUIDs: you can make as many of them as you need, and they're very
unlikely to match with other UUIDs, but you can still type them in
and read them back.
And don't use gensyms for cryptographic purposes. [there was at least
one web site that had security issues due to the host system generating
gensyms in some predictable sequence and the web application relying on
it as a source of randomness].
Aziz,,,
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, 09 Sep 2009 10:42:52 -0400, Brian Mastenbrook
wrote:
> On Sep 9, 2009, at 7:51 AM, Andre van Tonder wrote:
>
>> This, however, makes it difficult to write program transformers (for
>> example
>> macro expanders), that need to insert generated symbols for which the
>> requirement is that they cannot be typed in user programs.
>
> Is that the requirement? If so, Chez is already in violation of this:
This isn't exactly true.
> > (gensym)
> #{g0 f3s6pdjhhzxupwds-a}
> > (define gensyms-readable
> (lambda ()
>(let ((g (gensym))
> (p (open-output-string)))
> (write g p)
> (let ((r (open-input-string (get-output-string p
>(eq? (read r) g)
> > (gensyms-readable)
> #t
This only occurs if you first generate a printed representation for the
gensym, which, by definition, means that it can be written by the user or
anything else to get that same symbol. This situation will not arise if
you never print the gensym or grab its representation. Because the actual
representation of the symbol is never generated until the moment it is
needed, you are very unlikely to run into any conflicts. EQ? comparisons
and the like should not cause this sort of representation generation, so
you're pretty safe, especially within a given single machine.
> The actual requirement for the use of gensyms in this situation is
> that a gensym must not be eq? to any other symbol which already exists.
It also should not be eq? to future symbols that are created. Indeed, on
should not in general be able to create a symbol collision. It is always
theoretically possible for this to happen.
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On 09/09/2009 08:33 PM, John Cowan wrote: > Per Bothner scripsit: > >> \||\|\| => the 3-character symbol (string->symbol "|\\|") > > I don't understand that. I'd expect to see the symbol |\|\\\||, parsed > as |, \|, \\, \|, |. Or in that case I might fall back to Unicode > escapes: \x5C;\x7C;\x5C;. I misremembered the reader rules, thinking that \ was treated literally inside |...|, but that is not the case for either Kawa or Common Lisp. -- --Per Bothner [email protected] http://per.bothner.com/ ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Per Bothner scripsit: > \||\|\| => the 3-character symbol (string->symbol "|\\|") I don't understand that. I'd expect to see the symbol |\|\\\||, parsed as |, \|, \\, \|, |. Or in that case I might fall back to Unicode escapes: \x5C;\x7C;\x5C;. -- John Cowan [email protected]://ccil.org/~cowan You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> \||\|\| => the 3-character symbol (string->symbol "|\\|") Ugh. My way you can just say ||\\|| instead, ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On 09/09/2009 06:09 PM, Brian Harvey wrote: > Yah, I see how either of the two original proposals falls naturally out of > simple parsing rules. What I don't see is how it would happen that someone > who meant foonbar (or, to take a slightly more realistic example, > the symbol foo(n)bar) would type '|foo(|n|)bar| instead of just '|foo(n)bar|. > So if the user /does/ type '|foo(|n|)bar| I claim the only plausible > reading of that /as a communication from a human being/ is that s/he wants > the symbol foo(|n|)bar, including the vertical bars. In addition to supporting the package-prefix-case mentioned before (compound symbol |foo|:|bar| vs simple symbol |foo:bar|) there is also the use-case case of symbols with either | or \: or both: \||\|\| => the 3-character symbol (string->symbol "|\\|") (assuming one has both |-escapes and \-escapes, as in Common Lisp - and Kawa). -- --Per Bothner [email protected] http://per.bothner.com/ ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> In Chez Scheme, '|foo|n|bar| is treated as 'foonbar because the first | > matches with the second, the third with the fourth, and the middle is > parses without the extra treatment. Yah, I see how either of the two original proposals falls naturally out of simple parsing rules. What I don't see is how it would happen that someone who meant foonbar (or, to take a slightly more realistic example, the symbol foo(n)bar) would type '|foo(|n|)bar| instead of just '|foo(n)bar|. So if the user /does/ type '|foo(|n|)bar| I claim the only plausible reading of that /as a communication from a human being/ is that s/he wants the symbol foo(|n|)bar, including the vertical bars. I view this as a UI issue rather than a big principled Do The Right Thing issue, so I vote for doing what the user obviously meant. But I'm not going to the barricades to fight over this one. ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Brian Mastenbrook scripsit: > The grammar for admits four productions (named in the quote I > gave) which require implicit termination; all others are explicitly > terminated. Tokens which have explicit terminators may be followed > immediately by another token, because nothing else would forbid it. Or > is there something else I'm missing? Hmm. I suppose you are right. So "foo"n"bar" is three S-expressions, as the Scheme gods intended. -- "The serene chaos that is Courage, and the phenomenon [email protected] of Unopened Consciousness have been known to theJohn Cowan Great World eons longer than Extaboulism." "Why is that?" the woman inquired. "Because I just made that word up", the Master said wisely. --Kehlog Albran, The Profit http://www.ccil.org/~cowan ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Sep 9, 2009, at 3:09 PM, John Cowan wrote: > True. But I see nothing about tokens which don't require implicit > termination because they have explicit terminators. The grammar for admits four productions (named in the quote I gave) which require implicit termination; all others are explicitly terminated. Tokens which have explicit terminators may be followed immediately by another token, because nothing else would forbid it. Or is there something else I'm missing? -- Brian Mastenbrook [email protected] http://brian.mastenbrook.net/ ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Brian Mastenbrook scripsit:
> (length '("foo"n"baz")) -> 3 in any implementation conforming to the
> R5RS. (7.1.1 "Tokens which require implicit termination (identifiers,
> numbers, characters, and dot) may be terminated by any ,
> but not necessarily by anything else.")
True. But I see nothing about tokens which don't require implicit
termination because they have explicit terminators.
> I strongly agree with the analogy of | to ". The Common Lisp behavior
> of |foo|n|bar| -> |fooNbar| (assuming standard readtable case) is
> broken.
As I pointed out earlier, it has to be that way, because of the magic
colons in CL names.
--
John Cowan [email protected]
http://www.ccil.org/~cowan
Humpty Dump Dublin squeaks through his norse
Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
Humpty Dump Dublin's grandada of all rogues. --Cousin James
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Sep 9, 2009, at 1:40 PM, Ray Dillinger wrote:
> On Wed, 2009-09-09 at 18:22 +0200, Peter Bex wrote:
>
>> If a user types "foo"n"baz", that's also parsed as "foo" n "baz".
>> For
>> reasons of symmetry, I propose to keep the behaviour of || the same.
>
> I am not at all sure that this is universally true. But I have
> never tested it, as I would never and have never written code
> without separators between tokens.
>
> Does no implementation insist on separators between tokens?
(length '("foo"n"baz")) -> 3 in any implementation conforming to the
R5RS. (7.1.1 "Tokens which require implicit termination (identifiers,
numbers, characters, and dot) may be terminated by any ,
but not necessarily by anything else.")
I strongly agree with the analogy of | to ". The Common Lisp behavior
of |foo|n|bar| -> |fooNbar| (assuming standard readtable case) is
broken. In CL terms, #\| ought to behave as a terminating macro
character.
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 09, 2009 at 02:51:33PM -0400, John Cowan wrote: > > I am not at all sure that this is universally true. But I have > > never tested it, as I would never and have never written code > > without separators between tokens. > > PLT, Gauche, Chicken, Bigloo, scsh, Guile, Kawa, and Chez all > behave exactly the same way: "foo"n"bar" is "foo" n "bar". > > > Does no implementation insist on separators between tokens? > > Seemingly not. I couldn't find anything in the spec, but admittedly I only scanned it quickly. If this is not yet specified, maybe R7 is the time to make this explicit. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgprp8HifGHNI.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Ray Dillinger scripsit: > I am not at all sure that this is universally true. But I have > never tested it, as I would never and have never written code > without separators between tokens. PLT, Gauche, Chicken, Bigloo, scsh, Guile, Kawa, and Chez all behave exactly the same way: "foo"n"bar" is "foo" n "bar". > Does no implementation insist on separators between tokens? Seemingly not. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker [email protected] saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, 2009-09-09 at 18:22 +0200, Peter Bex wrote: > If a user types "foo"n"baz", that's also parsed as "foo" n "baz". For > reasons of symmetry, I propose to keep the behaviour of || the same. I am not at all sure that this is universally true. But I have never tested it, as I would never and have never written code without separators between tokens. Does no implementation insist on separators between tokens? Bear ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Ray Dillinger scripsit: > Also, I see | as *not* counting as a delimiter, so > separate identifiers would still need to be separated > by actual delimiters (whitespace or parens) which > eliminates the second case. I still like the strong analogy between | and ". Still, it's a small point compared to the acceptance of | into a standards proposal at all. It should also be noted that |...| as currently specified is incompatible with Unicode escapes, so an ASCII-only Scheme in case-folding mode will have to print the symbol whose name is "O�ω" (that's an omega) as \x4F;\x3C9;. -- John Cowan [email protected] http://www.ccil.org/~cowan C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux, de rapport nyait pas. --Jacques Lacan, "L'Etourdit" ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> It reads as 'foonbar in PLT as well. Likewise in MIT Scheme. ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, 2009-09-09 at 06:10 -1000, Shiro Kawai wrote: > Just a remainder of a small detail: We'll need to clearify > whether |...| only escapes an entire symbol or it can escape > a part of a symbol. > That is, should |foo|n|baz| be parsed as three symbols, > foo, n, and baz, or a single symbol foonbaz? > CL uses the latter. Gauche uses the former. It looks like an error to me. I see |...| as escaping a whole symbol, and expect any uses of | in the middle of that symbol to require an escape with a backslash, which eliminates the first case. Also, I see | as *not* counting as a delimiter, so separate identifiers would still need to be separated by actual delimiters (whitespace or parens) which eliminates the second case. Presumably the user using the above form is in a default-upper-case casefolding scheme; otherwise none of these identifiers require escapes. And in such an implementation, If the user meant... He shoulda typed ... identifier/s syntax "foonbaz" |foonbaz| ;; case 1 "foo n baz" |foo n baz| ;; case 2 "foo|n|baz" |foo\|n\|baz| ;; case 3 "foo","n","baz" |foo| |n| |baz| ;; case 4 case 1 is a lowercase identifier. case 2 is a lowercase identifier with 2 spaces in the name. case 3 is a lowercase identifier with 2 (escaped, so they don't terminate the symbolquoting form) vertical bars in the name. case 4 is 3 different lowercase identifiers, and therefore separately escaped and separated by whitespace. Bear ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 9, 2009 at 2:17 PM, Aaron W. Hsu wrote: > On Wed, 09 Sep 2009 12:14:43 -0400, Brian Harvey > wrote: > >>> That is, should |foo|n|baz| be parsed as three symbols, >>> foo, n, and baz, or a single symbol foonbaz? >> >> It seems to me that a single symbol foo|n|baz (terrible as that would be) >> would probably be closer to what a user who typed that in really meant >> than either of your two choices. Given the ambiguity, perhaps it should >> just be flagged as an error? > > In Chez Scheme, '|foo|n|bar| is treated as 'foonbar because the first | > matches with the second, the third with the fourth, and the middle is > parses without the extra treatment. It reads as 'foonbar in PLT as well. -- sam th [email protected] ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, 09 Sep 2009 12:14:43 -0400, Brian Harvey wrote: >> That is, should |foo|n|baz| be parsed as three symbols, >> foo, n, and baz, or a single symbol foonbaz? > > It seems to me that a single symbol foo|n|baz (terrible as that would be) > would probably be closer to what a user who typed that in really meant > than either of your two choices. Given the ambiguity, perhaps it should > just be flagged as an error? In Chez Scheme, '|foo|n|bar| is treated as 'foonbar because the first | matches with the second, the third with the fourth, and the middle is parses without the extra treatment. Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 09, 2009 at 12:49:22PM -0400, John Cowan wrote: > > > That is, should |foo|n|baz| be parsed as three symbols, > > > foo, n, and baz, or a single symbol foonbaz? > > > CL uses the latter. Gauche uses the former. > > > > Chicken also uses the former. > > Are you sure? I just asked csi to evaluate '(foo|n|baz), and it replied > (|foo\|n\|bar|), a list of length 1. I guess if you start a symbol with anything other than a pipe symbol, the pipe loses its special meaning and is taken to be just another character in the symbol's name. Note that you asked it for 'foo|n|baz and I asked it for '|foo|n|baz|. I checked with Gauche; it doesn't do this the same way. It appears to parse 'foo|n|baz as 'foo, n, baz Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpptU76c8B3b.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Shiro Kawai scripsit: > Just a remainder of a small detail: We'll need to clearify > whether |...| only escapes an entire symbol or it can escape > a part of a symbol. > That is, should |foo|n|baz| be parsed as three symbols, > foo, n, and baz, or a single symbol foonbaz? > CL uses the latter. Gauche uses the former. Thank you for pointing this out. CL needs the latter rule because : is special in CL symbols, separating the package name from the symbol name proper. Thus, |Foo|:|Bar| is the symbol named "Bar" in the package named "Foo", whereas |Foo:Bar| is the symbol named "Foo:Bar" in some currently accessible package. Since Scheme has no packages in this sense, I believe the Gauche rule is more sensible. -- If I read "upcoming" in [the newspaper] John Cowan once more, I will be downcoming http://www.ccil.org/~cowan and somebody will be outgoing. [email protected] ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Peter Bex scripsit: > > That is, should |foo|n|baz| be parsed as three symbols, > > foo, n, and baz, or a single symbol foonbaz? > > CL uses the latter. Gauche uses the former. > > Chicken also uses the former. Are you sure? I just asked csi to evaluate '(foo|n|baz), and it replied (|foo\|n\|bar|), a list of length 1. -- John Cowan http://ccil.org/[email protected] There are books that are at once excellent and boring. Those that at once leap to the mind are Thoreau's Walden, Emerson's Essays, George Eliot's Adam Bede, and Landor's Dialogues. --Somerset Maugham ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 09, 2009 at 09:14:43AM -0700, Brian Harvey wrote: > > That is, should |foo|n|baz| be parsed as three symbols, > > foo, n, and baz, or a single symbol foonbaz? > > It seems to me that a single symbol foo|n|baz (terrible as that would be) > would probably be closer to what a user who typed that in really meant > than either of your two choices. Given the ambiguity, perhaps it should > just be flagged as an error? If a user types "foo"n"baz", that's also parsed as "foo" n "baz". For reasons of symmetry, I propose to keep the behaviour of || the same. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpRepgynBAWe.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 09, 2009 at 06:10:41AM -1000, Shiro Kawai wrote: > Just a remainder of a small detail: We'll need to clearify > whether |...| only escapes an entire symbol or it can escape > a part of a symbol. > That is, should |foo|n|baz| be parsed as three symbols, > foo, n, and baz, or a single symbol foonbaz? > CL uses the latter. Gauche uses the former. Chicken also uses the former. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpmbVmwJqQGs.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> That is, should |foo|n|baz| be parsed as three symbols, > foo, n, and baz, or a single symbol foonbaz? It seems to me that a single symbol foo|n|baz (terrible as that would be) would probably be closer to what a user who typed that in really meant than either of your two choices. Given the ambiguity, perhaps it should just be flagged as an error? ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
From: John Cowan Subject: Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity Date: Wed, 9 Sep 2009 11:51:26 -0400 > The R6RS rationale says that this is "a popular choice" among R5RS > implementations. To my mind, what is popular and not obviously broken > should be a candidate for standardization, so I have added |...| > to the lexical syntax features at http://tinyurl.com/thing-one. Just a remainder of a small detail: We'll need to clearify whether |...| only escapes an entire symbol or it can escape a part of a symbol. That is, should |foo|n|baz| be parsed as three symbols, foo, n, and baz, or a single symbol foonbaz? CL uses the latter. Gauche uses the former. --shiro ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Arthur A. Gleckler scripsit: > +1. > > MIT Scheme also supports this syntax. The R6RS rationale says that this is "a popular choice" among R5RS implementations. To my mind, what is popular and not obviously broken should be a candidate for standardization, so I have added |...| to the lexical syntax features at http://tinyurl.com/thing-one. -- John Cowan [email protected] http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> The R6RS team rejected this idea, which is already implemented in some
> Schemes (Chicken that I know of) because it can make S-expressions hard to
> read: look at (|(| |foo bar| |)|), for example, a list of three symbols
> whose print names are "(", "foo bar", and ")". But perhaps, given the
> persistence of R4RS/IEEE/R5RS case-folding code, and the extreme ugliness
> of the Unicode escapes as the sole mechanism, it ought to be reconsidered
> for Thing One and Thing Two.
+1.
MIT Scheme also supports this syntax.
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Andre van Tonder scripsit: > This, however, makes it difficult to write program transformers (for > example macro expanders), that need to insert generated symbols for > which the requirement is that they cannot be typed in user programs. As others have posted, I think using a separate (and implementation specific) identifier type is now a win. At run time, gensyms are basically just strings that satisfy "symbol?" (and have p-lists, if your Scheme does p-lists), and if you need to play with such things, you are better off redefining "symbol?" or moving up to an informally-expressed union datatype of strings and true symbols. -- John Cowanhttp://ccil.org/[email protected] Economists were put on this planet to make astrologers look good. --Leo McGarry ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Sep 9, 2009, at 7:51 AM, Andre van Tonder wrote:
> This, however, makes it difficult to write program transformers (for
> example
> macro expanders), that need to insert generated symbols for which the
> requirement is that they cannot be typed in user programs.
Is that the requirement? If so, Chez is already in violation of this:
> (gensym)
#{g0 f3s6pdjhhzxupwds-a}
> (define gensyms-readable
(lambda ()
(let ((g (gensym))
(p (open-output-string)))
(write g p)
(let ((r (open-input-string (get-output-string p
(eq? (read r) g)
> (gensyms-readable)
#t
The actual requirement for the use of gensyms in this situation is
that a gensym must not be eq? to any other symbol which already exists.
In practice, I think that the use of gensyms in macro transformers is
a bad design decision. Using a gensym requires carrying around another
table (or using symbol properties) to hold information about the
original lexical context. Using an identifier type of some kind solves
these problems, preserving both the original name of the identifier
and a pointer to the lexical context it was originally used in.
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net/
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> An alternative is to adopt some form of Common Lisp's |...| convention +1. ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
From: Andre van Tonder Subject: Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity Date: Wed, 9 Sep 2009 08:51:21 -0400 (EDT) > On Wed, 9 Sep 2009, Peter Bex wrote: > > > I'm not familiar with the CL syntax, but I also really appreciate this > > feature. It makes a lot of sense too, since it makes it possible to > > enter any kind of string as symbol literal. This means that if you > > can do (string->symbol ), you can also type in > > and get the symbol. > > This, however, makes it difficult to write program transformers (for example > macro expanders), that need to insert generated symbols for which the > requirement is that they cannot be typed in user programs. It's orthogonal to the symbol syntax. *Any* interned symbol that has external representation has potential of unintended conflict; uninterned symbol can solve this, but I'm not sure having that in Scheme standard is a good thing or not. (Gauche has it.) BTW, in R6RS, if I understand it correctly, I can create one symbol that doesn't have external respresentation: (string->symbol "") CL-style escape allows it to be printed as ||. --shiro ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, 9 Sep 2009, Peter Bex wrote: > I'm not familiar with the CL syntax, but I also really appreciate this > feature. It makes a lot of sense too, since it makes it possible to > enter any kind of string as symbol literal. This means that if you > can do (string->symbol ), you can also type in > and get the symbol. This, however, makes it difficult to write program transformers (for example macro expanders), that need to insert generated symbols for which the requirement is that they cannot be typed in user programs. Andre ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 09, 2009 at 08:23:30AM -0400, Marc Feeley wrote: > Sorry... typed without thinking... I was focused on lining up the two > lines. So your code is correct. Okay, that's good to hear :) > I like this syntax because it looks like the CL syntax, and it is very > simple concept to grasp once you know the string syntax (i.e. few of > my precious neurons are consumed by this feature). I'm not familiar with the CL syntax, but I also really appreciate this feature. It makes a lot of sense too, since it makes it possible to enter any kind of string as symbol literal. This means that if you can do (string->symbol ), you can also type in and get the symbol. Without this syntax, you can create symbols that are impossible to enter literally. That's weird and can't really be explained. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgp3zTogRdCxr.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On 9-Sep-09, at 8:20 AM, Peter Bex wrote: > On Wed, Sep 09, 2009 at 08:03:28AM -0400, Marc Feeley wrote: >> That's what Gambit does. Take the syntax of strings, exchange the >> meaning of " and | and you get symbols that preserve their case: >> >> (string? "Hi there!") -> #t >> (symbol? |Hi there!|) -> #t > > Are "escaped symbols" implicitly quoted in Gambit, or did you forget > the '? In Chicken: > > (symbol? '|Hi there!|) => #t > > (define |Hi there!| "A very strange identifier") > > |Hi there!| => "A very strange identifier" Sorry... typed without thinking... I was focused on lining up the two lines. So your code is correct. I like this syntax because it looks like the CL syntax, and it is very simple concept to grasp once you know the string syntax (i.e. few of my precious neurons are consumed by this feature). Marc ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 09, 2009 at 08:03:28AM -0400, Marc Feeley wrote: > That's what Gambit does. Take the syntax of strings, exchange the > meaning of " and | and you get symbols that preserve their case: > >(string? "Hi there!") -> #t >(symbol? |Hi there!|) -> #t Are "escaped symbols" implicitly quoted in Gambit, or did you forget the '? In Chicken: (symbol? '|Hi there!|) => #t (define |Hi there!| "A very strange identifier") |Hi there!| => "A very strange identifier" Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpqFkzhTnOic.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On 9-Sep-09, at 4:00 AM, John Cowan wrote:
> The R6RS team rejected this idea, which is already implemented in some
> Schemes (Chicken that I know of) because it can make S-expressions
> hard to
> read: look at (|(| |foo bar| |)|), for example, a list of three
> symbols
> whose print names are "(", "foo bar", and ")". But perhaps, given the
> persistence of R4RS/IEEE/R5RS case-folding code, and the extreme
> ugliness
> of the Unicode escapes as the sole mechanism, it ought to be
> reconsidered
> for Thing One and Thing Two.
+1
That's what Gambit does. Take the syntax of strings, exchange the
meaning of " and | and you get symbols that preserve their case:
(string? "Hi there!") -> #t
(symbol? |Hi there!|) -> #t
Marc
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Arthur Gleck scripsit:
> If someone's case-sensitive code imports `FOO' from a case-folding
> library that exports it as `foo', should it find it?
I'd say no. Since Unicode case-folding is basically downcasing (for
reasons explained in my Unicode post), the situation of case-preserving
code importing names from case-folding code is straightforward:
normal names without escape sequences arrive as lower case. The only
circumstance in which case-folding code can export names with uppercase
letters is when the case-folding code contains escape sequences:
see below.
Shiro Kawai scripsit:
> For example, what will you suggest a natural interface to
> import Xlib? It defines symbols like XK_A and XK_a,
> corresponding user's key input of uppercase and lowercase
> 'a', respectively.
>
> We can use xk_capital_a and xk_small_a, or xk_\x41; and xk_a,
> respectively.
[Note: I changed 65 decimal to 41 hex above]
I think the latter observation is the key to the solution. Given
the presence of escape sequences in Thing One names, all Thing One
implementations, whether in case-preserving or case-folding mode, will
be able to support identifiers with both upper and lower case characters
in them.
That means that the symbols whose print names are "Foo" and "foo" are
always distinct as identifiers. It's just that in case-folding mode,
the first is spelled \x46;oo or \x46;OO (or variants thereof), whereas
the latter is spelled foo or FOO or Foo (or variants thereof).
In case-preserving mode, though, foo, Foo, and FOO spell distinct
identifiers, known to case-folding mode as foo or Foo or FOO, \x46;oo
or \x46OO, and \x46;\x4F;\x4F, respectively. Yes, the last is horrible;
but if case-folding code needs to import names from case-preserving code,
at least it's *possible*.
An alternative is to adopt some form of Common Lisp's |...| convention
for symbols. All characters within vertical bars are part of the symbol
(only \ and | must be escaped) and no case-folding is done. In this
way, the case-folded names of the case-preserving identifiers foo, Foo,
and FOO are simply foo or FOO, |Foo| and |FOO|.
The R6RS team rejected this idea, which is already implemented in some
Schemes (Chicken that I know of) because it can make S-expressions hard to
read: look at (|(| |foo bar| |)|), for example, a list of three symbols
whose print names are "(", "foo bar", and ")". But perhaps, given the
persistence of R4RS/IEEE/R5RS case-folding code, and the extreme ugliness
of the Unicode escapes as the sole mechanism, it ought to be reconsidered
for Thing One and Thing Two.
> Case-folding symbol comparison seems to me to bring exceptions
> into rules. The fact that it is very rare makes situations only
> worse---people are tempted to make programs that ignore rare cases,
> which work 99% of the time but break unexpectedly.
I would say instead that the rules, though fixed, have very messy
consequences in certain cases.
--
Said Agatha Christie / To E. Philips Oppenheim John Cowan
"Who is this Hemingway? / Who is this Proust? [email protected]
Who is this Vladimir / Whatchamacallum, http://www.ccil.org/~cowan
This neopostrealist / Rabble?" she groused.
--George Starbuck, Pith and Vinegar
___
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Tue, Sep 08, 2009 at 09:19:14PM -0700, Brian Harvey wrote: > > For example, what will you suggest a natural interface to > > import Xlib? It defines symbols like XK_A and XK_a, > > This is a strong argument, that definitely made me think hard about my > position; interfacing with That Language code does seem to require some > degree of following its rules. > > But I think the issues are more general than case-folding. What if some > C library exports the symbol car? Is a Scheme program that interfaces > with that library going to forgo using lists? With a module system, the library could export 'car', and another library could import the C library with either a prefix or simply omit 'car' from the set of imported bindings. I see no problem here. > So I'm afraid that the FFI library is going to end up using strings to > represent the foreign symbols anyway. I don't see why that is necessary. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpe7PsKszDIb.pgp Description: PGP signature ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
On Wed, Sep 9, 2009 at 12:19 AM, Brian Harvey wrote: > > For example, what will you suggest a natural interface to > > import Xlib? It defines symbols like XK_A and XK_a, > > This is a strong argument, that definitely made me think hard about my > position; interfacing with That Language code does seem to require some > degree of following its rules. > > But I think the issues are more general than case-folding. What if some > C library exports the symbol car? Is a Scheme program that interfaces > > with that library going to forgo using lists? > > So I'm afraid that the FFI library is going to end up using strings to > represent the foreign symbols anyway. > > The advent of hygeinic macros marked the end of the era in which symbols could be equated with identifiers. Identifiers have a lot more information in them. Lynn ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> For example, what will you suggest a natural interface to > import Xlib? It defines symbols like XK_A and XK_a, This is a strong argument, that definitely made me think hard about my position; interfacing with That Language code does seem to require some degree of following its rules. But I think the issues are more general than case-folding. What if some C library exports the symbol car? Is a Scheme program that interfaces with that library going to forgo using lists? So I'm afraid that the FFI library is going to end up using strings to represent the foreign symbols anyway. ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> If someone's > case-sensitive code imports `FOO' from a case-folding library that > exports it as `foo', should it find it? I can see that this is an important question in principle, but in practice the only two choices (supposing there is no local symbol FOO in the case-sensitive code) are to give an error or to find it. Given that choice, it seems clear to me that it's more useful to allow the match than to give an error message. (It wouldn't kill me if you want to give a /warning/ that the symbol can be resolved only by case-folding.) It also wouldn't kill me if case-insensitive programs export only in lower case. But it would clearly violate the case-insensitive program's view of the world if the symbol were exported only in whatever case the programmer happened to use at some particular point in the program, and it would be extra bad if two spellings of the same identifier (from this program's point of view) turned into different identifiers when exported. ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
From: Brian Harvey Subject: Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity Date: Tue, 8 Sep 2009 18:48:41 -0700 > > Nothing. If you mean "What happens at file boundaries?", which is a more > > plausible question, then I think the answer is "reset to the default". > > I don't think that quite answers the question, which is, if I'm understanding > correctly, what happens when a module/file/whatever exports two symbols that > are the same except for case, but are meant to be different identifiers. > And I think the answer has to be that that's an error; otherwise, it will > be impossible for a program written by a Lisp traditionalist to use a library > written by a C/Javaesque whippersnapper. [:-) <- note smiley] > > This can be an error that implementations are not required to catch, as long > as the people who write canonical libraries follow the rule. > > I don't think there's a problem the other way; non-case-folders won't have > any trouble using case-folding libraries. I can live with that "case is preserved, but folded in comparison" approach 99% of time, but it breaks in rare edge cases. For example, what will you suggest a natural interface to import Xlib? It defines symbols like XK_A and XK_a, corresponding user's key input of uppercase and lowercase 'a', respectively. We can use xk_capital_a and xk_small_a, or xk_\x65; and xk_a, respectively. The problem is that there won't be a general rule applicable automatically, preserving human readability. For each of such exceptional library somebody has to look through the exported symbols and decide which ones should be treated specially. Users of the library has to look up the document for such special cases. What I like in Scheme is that it has limited number of orthogonal rules that can be combined freely, without worring about exceptions. Case-folding symbol comparison seems to me to bring exceptions into rules. The fact that it is very rare makes situations only worse---people are tempted to make programs that ignore rare cases, which work 99% of the time but break unexpectedly. --shiro ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> I don't think there's a problem the other way; non-case-folders won't have > any trouble using case-folding libraries. Actually, that's what I was worried about. If someone's case-sensitive code imports `FOO' from a case-folding library that exports it as `foo', should it find it? As far as the case-folding library is concerned, they're the same, but the case-sensitive importer won't agree. At the boundary, there has to be some agreement about how a case-folding library's names will be presented to a case-sensitive importer. Should they always be presented as lower case? Who's doing the matching in the DMZ -- the importer, the exporter, or some third party? ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
> Nothing. If you mean "What happens at file boundaries?", which is a more > plausible question, then I think the answer is "reset to the default". I don't think that quite answers the question, which is, if I'm understanding correctly, what happens when a module/file/whatever exports two symbols that are the same except for case, but are meant to be different identifiers. And I think the answer has to be that that's an error; otherwise, it will be impossible for a program written by a Lisp traditionalist to use a library written by a C/Javaesque whippersnapper. [:-) <- note smiley] This can be an error that implementations are not required to catch, as long as the people who write canonical libraries follow the rule. I don't think there's a problem the other way; non-case-folders won't have any trouble using case-folding libraries. ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Proposed features for small Scheme, part 4B: case-sensitivity
Arthur A. Gleckler scripsit: > But what happens at module boundaries? Nothing. If you mean "What happens at file boundaries?", which is a more plausible question, then I think the answer is "reset to the default". -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; [email protected] Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind.--Tao 33 (Bynner) ___ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
