The combination #\ is annoying and hard to type.
It's on separate keys, far apart on the keyboard,
and one of them requires shift and one of them
requires non-shift.
Does it have value beyond its historicity? Is it
one of Paul Graham's "Onions?" Would there be a
problem in a Lisp where characters were single-quote
delimited as in other languages and the backslash
was used for quoting? It would look a lot less like
Martian to most programmers.
Bear
Ray Dillinger wrote:
>
> The combination #\ is annoying and hard to type.
>
> It's on separate keys, far apart on the keyboard,
> and one of them requires shift and one of them
> requires non-shift.
>
> Does it have value beyond its historicity? Is it
> one of Paul Graham's "Onions?" Would there be a
> problem in a Lisp where characters were single-quote
> delimited as in other languages and the backslash
> was used for quoting? It would look a lot less like
> Martian to most programmers.
I agree that the #\x syntax sucks for the most part.
I thought about it and found no satisfying solution.
Single quotes are problematic in lisp/scheme. What
does 'a'a lex as?
Is it [#\a a]? Or is it [quote a quote a]?
Or were you thinking that the quote in 'a should go
away and be replaced by \a?
Aziz,,,
Abdulaziz Ghuloum wrote:
> Ray Dillinger wrote:
>
>>
>> The combination #\ is annoying and hard to type.
>>
>
> I agree that the #\x syntax sucks for the most part.
>
> I thought about it and found no satisfying solution.
>
> Single quotes are problematic in lisp/scheme. What
> does 'a'a lex as?
>
> Is it [#\a a]? Or is it [quote a quote a]?
>
> Or were you thinking that the quote in 'a should go
> away and be replaced by \a?
I was thinking that \a should be syntax for (quote a)
and that 'a should not be.
Then, I'd take the ' character and use it for
delimiting character constants, so I'd be writing
'a' instead of #\a. So your example
'a'a would be either a syntax error (trailing
delimiter required after character constant) or
it would parse the same as current lisps parse
#\a a.
Bear
Ray Dillinger <····@sonic.net> writes:
> I was thinking that \a should be syntax for (quote a)
> and that 'a should not be.
>
> Then, I'd take the ' character and use it for
> delimiting character constants, so I'd be writing
> 'a' instead of #\a.
I'm all for it. It would help people transition to s-expr syntax more
easily. Since there's always one character between the single quotes,
''' could even be valid. The #\ syntax could be kept for numeric
character constants.
--
http://ourdoings.com/ Let your digital photos organize themselves.
Sign up today for a 7-day free trial.
"Bruce Lewis" <·······@yahoo.com> wrote in message
····················@biohazard-cafe.mit.edu...
> Ray Dillinger <····@sonic.net> writes:
>
>> I was thinking that \a should be syntax for (quote a)
>> and that 'a should not be.
>>
>> Then, I'd take the ' character and use it for
>> delimiting character constants, so I'd be writing
>> 'a' instead of #\a.
>
> I'm all for it. It would help people transition to s-expr syntax more
> easily. Since there's always one character between the single quotes,
> ''' could even be valid. The #\ syntax could be kept for numeric
> character constants.
what about backspace, return, tab etc?
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Bruce Lewis" <·······@yahoo.com> wrote in message
> ····················@biohazard-cafe.mit.edu...
> >
> > I'm all for it. It would help people transition to s-expr syntax more
> > easily. Since there's always one character between the single quotes,
> > ''' could even be valid. The #\ syntax could be kept for numeric
> > character constants.
>
> what about backspace, return, tab etc?
Two alternative ideas:
(1) Use #\ for those too.
(2) #\[ ==> '['
#\tab ==> '[tab]'
#\newline ==> '[newline]'
etc.
The second bit adds a little complexity to the parser, but in the 30
seconds I've invested into this idea I haven't come up with likely
scenarios of ambiguities / confusing error messages it would cause.
Coby Beck wrote:
> "Bruce Lewis" <·······@yahoo.com> wrote in message
> ····················@biohazard-cafe.mit.edu...
>
>>Ray Dillinger <····@sonic.net> writes:
>>>I was thinking that \a should be syntax for (quote a)
>>>and that 'a should not be.
>>>Then, I'd take the ' character and use it for
>>>delimiting character constants, so I'd be writing
>>>'a' instead of #\a.
>>I'm all for it. It would help people transition to s-expr syntax more
>>easily. Since there's always one character between the single quotes,
>>''' could even be valid. The #\ syntax could be kept for numeric
>>character constants.
> what about backspace, return, tab etc?
I think that with opening and closing singlequotes, you can use
character names as easily as character literals. So instead of
having a situation where there's always one character between
the single quotes and ''' is valid, I'd have character names
between single quotes, and most keyboard characters have a name
that's one character long. But a few exceptions would exist,
so valid characters would look like
'a' 'b' 'c'
'backspace' 'singlequote' 'return' '\' ·@', and so on.
It even gives you a nice typeable interface to unicode characters,
where you can use the unicode names directly and say things like
'latin lowercase a with accent grave'
Of course you'd probably want a way to define shorter character
names for them.
Bear
lin8080 wrote:
> Ray Dillinger schrieb:
>>Of course you'd probably want a way to define shorter character
>>names for them.
> That is called "Icon". Right?
> stefan
Sorry, I don't know what Icon is. Can you elaborate?
Bear
Bruce Lewis wrote:
> Ray Dillinger <····@sonic.net> writes:
>
> > I was thinking that \a should be syntax for (quote a)
> > and that 'a should not be.
> >
> > Then, I'd take the ' character and use it for
> > delimiting character constants, so I'd be writing
> > 'a' instead of #\a.
>
> I'm all for it. It would help people transition to s-expr syntax
more
> easily. Since there's always one character between the single
quotes,
> ''' could even be valid. The #\ syntax could be kept for numeric
> character constants.
Hmm. I don't think syntax like 'a' _looks like_ there is always one
character between the single quotes. Some users would be reminded of
Perl/shell string quoting, and would try to put in more than one
character. An important plus of the admittedly ugly current prefix
syntax for character literals is that it reinforces the notion that
characters are units, not sequences. So I prefer #\a over even the
perspicuous (character "a"). Indeed, I'll go all out and admit a
preference for 'a over (quote a) and #'a over (function a), for the
same reasons. Character constants are far from the best place to use
up the relatively few bracketing syntax options we have.
Bear wrote:
>
> The combination #\ is annoying and hard to type.
Agreed.
> It's on separate keys, far apart on the keyboard,
> and one of them requires shift and one of them
> requires non-shift.
Yes, this is true on dvorak as well. As a half-assed work-around,
consider making a macro in your editor of choice. (I have a shortcut for
typing lambda (which emacs can display as the greek character, so it's
even shorter than 'fn'.))
> Does it have value beyond its historicity?
Yes, one valuable aspect is that it works for all characters.
Consider:
#\\
#\'
Another is that it's always self-evaluating.
A third is that the concatenation of #\# and another character is
standard syntax in lisp for non-sexp:y stuff. #' in CL comes to mind.
> It would look a lot less like
> Martian to most programmers.
But we are on Mars, figuratively speaking. The #\c construct is afaik
older than the 'c' one.
That said, I'm not fundamentally opposed to seeing a lisp which uses the
'c' construct, possibly in conjunction with another syntax for (quote).
I don't like \( because it's a "false friend" to "non-Martians"; a
non-Martian could parse that as "This paren doesn't need to close" or
something like that.
I wrote:
> That said, I'm not fundamentally opposed to seeing a lisp which uses the
> 'c' construct, possibly in conjunction with another syntax for (quote).
To clarify:
It is possible in theory to have a lisp where:
'a' is #\a
and
'a is the symbol a
For people who want to play with this:
http://www.call-with-current-continuation.org/manual/Reader-extensions.html
and/or CL read-tables
Ray Dillinger <····@sonic.net> writes:
> The combination #\ is annoying and hard to type.
i don't write enough literal chars to care, but if you really really
really must:
CL-USER> (defun read-char-for-macro-char (stream char)
(declare (ignore char))
(read-char stream))
READ-CHAR-SANS-SHIFT-CHARS
CL-USER> (set-macro-character #\^ #'read-char-for-macro-char nil)
T
CL-USER> ^a
#\a
CL-USER>
it's easiest if you chose a single prefix char, parsing '<char>' (with
different semantics depending on what comes after the char) is doable
but i'll leave that as a excercise.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Ray Dillinger wrote:
>
> The combination #\ is annoying and hard to type.
Ack. And while we're at revolutionizing the language, let's include
standard C notation for characters and strings.
"Hi\n\tthere" and the like. It sucks that newline is #\newline, not a
\n in a string.
On Thu, 24 Feb 2005 15:02:34 -0600, Ulrich Hobelmann <···········@web.de> wrote:
> Ack. And while we're at revolutionizing the language, let's include
> standard C notation for characters and strings.
>
> "Hi\n\tthere" and the like. It sucks that newline is #\newline, not
> a \n in a string.
It's there if you want it:
<http://weitz.de/cl-interpol/>
I don't use it myself, though. Go figure...
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> It's there if you want it:
>
> <http://weitz.de/cl-interpol/>
>
> I don't use it myself, though. Go figure...
As long is it works when it's convenient... :)
Thanks
On Thu, 24 Feb 2005 04:08:44 +0000, Ray Dillinger wrote:
>
> The combination #\ is annoying and hard to type.
>
> It's on separate keys, far apart on the keyboard,
> and one of them requires shift and one of them
> requires non-shift.
Who cares? For obvious reasons, in emacs, I've switched
the $ key and the ` key when I'm programming perl.
This is also possible for the #\ combination.
>
> was used for quoting? It would look a lot less like
> Martian to most programmers.
I personally like #\...
Ray Dillinger <····@sonic.net> writes:
> The combination #\ is annoying and hard to type.
You want this for a new language right? So why not forget about characters and
use strings?
'as
Ray Dillinger <····@sonic.net> writes:
> It's on separate keys, far apart on the keyboard,
> and one of them requires shift and one of them
> requires non-shift.
Differently shifted on _your_ keyboard, not on mine. I suggest you
fix your keyboard. Or of course your reader, which is fairly easy to
do for the inhabitants of one half of the groups you posted to:
;; I believe @ and \ are both unshifted on US keyboards
(make-dispatch-macro-character ··@ t)
(set-dispatch-macro-character ··@ #\\
(get-dispatch-macro-character #\# #\\))
(type-of @\e)
but since for me typing #\ isn't a problem...
Followups set.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> ;; I believe @ and \ are both unshifted on US keyboards
Actually, @ is shifted (shift-2).
Totally off topic:
I do find it funny whenever I encounter a non-US keyboard. I'm never
quite sure what to do as all my muscle memory immediately seems like a
boat anchor, dragging me inexorably to a state of unintelligible
gibberish. ;-)
My brother-in-law has been living all over the world for
the past decade and has collected all manner of laptops over that time
(he's now living just outside London). I have more than once been
visiting him while on a business trip and tried to quickly compose an
email to my wife. What is normally a 2 minute process becomes 5
minutes of "pick and peck" typing.
I actually tried converting my keyboard mappings to Dvorak for a
couple of weeks a few years ago but finally threw in the towel when I
realized that even if I retrained myself, I'd have this problem in
spades, even when using a keyboard in the next cubicle.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
On Thu, 24 Feb 2005 09:54:35 -0800, Dave Roberts wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> ;; I believe @ and \ are both unshifted on US keyboards
>
> Actually, @ is shifted (shift-2).
>
> Totally off topic:
>
> I do find it funny whenever I encounter a non-US keyboard. I'm never
> quite sure what to do as all my muscle memory immediately seems like a
> boat anchor, dragging me inexorably to a state of unintelligible
> gibberish. ;-)
I always like when FreeBSD starts up in single-user mode without keyboard
settings (only if I forget to set it as default in the kernel, of course)
and I have to type some lines quite full of punctuation to get the
punctuation keys where they belong... ;)
Regards,
--
Julian Stecklina
-- Common Lisp can do what C, C++, Java, PASCAL, PHP, Perl, (you --
-- name it) can do. Here's how: --
-- --
-- http://www.amazon.com/exec/obidos/ASIN/1590592395 --
Sunnan <······@handgranat.org> writes:
> Christophe Rhodes wrote:
>> ;; I believe @ and \ are both unshifted on US keyboards
>
> Nope, it's shift-2.
Oh well. I hope this doesn't obscure the main point...
Christophe
[ Replying only to comp.lang.lisp;
See http://www.nhplace.com/kent/PFAQ/cross-posting.html
]
Ray Dillinger <····@sonic.net> writes:
> The combination #\ is annoying and hard to type.
>
> It's on separate keys, far apart on the keyboard,
> and one of them requires shift and one of them
> requires non-shift.
>
> Does it have value beyond its historicity? Is it
> one of Paul Graham's "Onions?" Would there be a
> problem in a Lisp where characters were single-quote
> delimited as in other languages and the backslash
> was used for quoting? It would look a lot less like
> Martian to most programmers.
The Lisp reader has some roots in history and some basic contraints
and some serendipitous attempts to solve practical problems of the
present day. All are in play here.
It's a constraint of the character syntax that it wants to accomodate
the literal insertion of all characters. e.g., we could have made
control-q (q for quote) a readmacro character that would eat another
character and return it. If we did, though, text editors like Emacs
AND others that are not so programmable, might have trouble recognizing
that
(eq x ^Q))
was a balanced expression. It is a non-accidental aspect of the choice
of #\ that most text editors naturally treat
(eq x #\))
as balanced because whether they understand the '#' part or not, they
figure the '\' part quotes the subsequent character.
So why didn't we just make the character syntax be \x?
Well, first, there was some history saying that was one name of the symbol
|x|. So there was a compatibility problem. But also, it wasn't an accident
that we put \ in symbol names. We LIKE that. That is, the ability to write
add-\(
as a symbol name is handy. And a lot more fun than
|ADD-(|
which is often the alternative. [I'll steer clear of the gaping chasm to
my left, where at the very, very, bottom I see a tiny sign saying "here lie
the bodies of those who foolishly opened the canonical case debate at
this point".]
So \ was taken. That leaves only <something>\. Well, we could have made
a different dispatching readmacro syntax than '#', but we were already using
# as the canonical all-purpose dispatching readmacro in CL. To grab yet
another character out of the space of chars available to implementations and
users seemed inappropriate.
So really only #\ was available.
- - - - -
Footnote:
And no, we couldn't do something like 'x' like in parsed languages. One
aspect of Lisp's reader that is very handy is that you don't have to have
ESP to know which parser to invoke next. When you see the '#' you invoke
the sharpsign reader. When it dispatches on \, it invokes the character
name reader. That syntax is cleverly designed so that a normal token read
can follow it (allowing names like #\Return to also be possible). But one
never has to look ahead to find out if there's a single-quote or other
terminator character farther down the line. If there is, it's a required
consequence of something before it (as in "...", where the first doublequote
commits to requiring the second). But if we made 'x' be a character syntax,
we'd lose 'x as a quoting syntax for expressions like x and (some list) and
so on.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: character syntax revisited
Date:
Message-ID: <871xb5snju.fsf@qrnik.zagroda>
Kent M Pitman <······@nhplace.com> writes:
> It's a constraint of the character syntax that it wants to accomodate
> the literal insertion of all characters. e.g., we could have made
> control-q (q for quote) a readmacro character that would eat another
> character and return it. If we did, though, text editors like Emacs
> AND others that are not so programmable, might have trouble recognizing
> that
> (eq x ^Q))
>
> was a balanced expression. It is a non-accidental aspect of the choice
> of #\ that most text editors naturally treat
> (eq x #\))
>
> as balanced because whether they understand the '#' part or not, they
> figure the '\' part quotes the subsequent character.
Ah, so this is where this braindamage of Emacs syntax tables comes from.
How to teach Emacs that \ in a string quotes the next character, but \
outside a string is an operator and doesn't quote anything? In particular
that a bracket in \[ is balanced with ]?
Emacs seems to assume that all languages use a Lisp syntax with only
some characters permuted...
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Emacs seems to assume that all languages use a Lisp syntax with only
> some characters permuted...
Not at all.
Emacs is fully programmable, but the people who use these other languages
have not done their job.
The quoting and nesting of TeX is very different than Lisp, yet I had no
trouble in Teco-based Emacs making TeX Mode do the right thing, years and
years ago. (And I think whoever ported my Teco-based TeX mode into modern
Lisp-based Emacs did it correctly, too.)
But code does not write itself. If you see something broken, fix it.
If you find that you are unable to customize it appropriately, there exist
newsgroups on which to get help. I'd be VERY surprised if you were unable
for any reason of substance.
Ray Dillinger <····@sonic.net> writes:
> The combination #\ is annoying and hard to type.
I agree and add: and ugly.
That's why I always write: (character "x") instead of #\x
(And if you did not notice, I also use (function x) instead of #'x
and I may use (quote x) instead of 'x slightly more often than other
contemporary lisp programmers).
But I guess you'll rather like Marco's macro char; only use ? instead
of ^, since that's what emacs uses.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
+ Pascal Bourguignon <····@mouse-potato.com>:
| That's why I always write: (character "x") instead of #\x
Write that as #.(character "x") and the irony is palpable.
Ah, the things we do for our good looks.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
I really don't see what's wrong with a change in shifting -- and I'd
hate to use single-quotes to delimit characters, first because of all
of the code that would be horribly broken, second because QUOTE would
no longer have a meaningful mnemonic, and third because the single-
quote key is so close to the return key, which always bites me --;
however, there is one thing I'd like to change in the character syntax:
the named versus literal characters. I think it would make much more
sense to have two different octothorpe dispatch characters for a
character syntax: one for exact or literal characters & one for named
characters. Maclisp did this, if I recall correctly: #/x read as the
literal character x, while #\FOO read as the character named FOO, such
as #\NEWLINE or #\SPACE. I think this would be a useful convention to
adopt, and it wouldn't have to horribly break every bit of code ever
written in Scheme that uses character literals. (Existing readers
would just need to add #/ as a literal character syntax and leave the
reader for #\x unchanged.)