[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: DLW at MIT-MC, HENRY at MIT-AI
- Cc: (BUG LISPM) at MIT-MC HENRY@MIT-AI 01/09/82 17:54:04 Re: Reading the Readtable
My specific application was a kind of printing function which
wanted to know if a character it was printing out was going to be
slashified. The original MacLisp code used (STATUS SYNTAX ...). I
finally resorted to checking the length of the printed
representation.
OK, probably what you are doing now is as good as anything. The
printer has to make this decision too after all. If you really wanted
a clean way to do this, I could extract the test the printer uses to
determine when to print with "|"'s and or "/"'s. Notice that simply
having a function that looks in the readtable for the syntax of a
character wouldn't work, because (I presume) you DON'T want to
slashify "E"'s, but "E" does NOT have alphabetic syntax.
In general, whenever there is a function which "changes the state
of the world", there also should be some way to examine that
state, if for no other reason than debugging so the user can see
what the state is if he forgot what he set it to. Other useful
applications are saving the current state in a variable, changing
it temporarily, and restoring the old state later. I find it
really hard to believe that there's "nothing meaningful that could
be returned". What I meant is that since
SET-SYNTAX-FROM-DESCRIPTION takes keywords, the user thinks of
those keywords as BEING the syntax of the character, so there
should be a function (CHARACTER-SYNTAX "A") is :ALPHABETIC, etc.
1) The keywords do not cover all possible syntaxes. They only cover a
few of the initial characters. I could make a function that returned
one of these keywords to you if it existed, but there would be nothing
to return in the other cases. You could force me to think up funny
words to cover all of the characters, but there would be no guarantee
that if a user made his own readtable he would be so kind to you.
2) You are being fooled by the fact that the readtable is an array
indexed by characters into thinking that the things stored therein are
meaningful in a context other than associated with that array. Taking
the stuff stored in one readtable at location #/: and storing it in
ANOTHER readtable at location #/$ will NOT necessarily cause the "$"
in the second readtable to act like a package prefix. It might make
it act like a ".". It might cause the reader to get an array out of
bounds error. I could write a function that took two characters and a
SINGLE readtable and told you if they had the same syntax, but then
again, in your application you would wind up slashifing all of your
"E"'s because they aren't alphabetic.
3) It is true that the user has no way to tell what the syntax of a
particular character is other than simply trying it. But I don't see
where it is a general principle that wherever there is a function to
change something there needs to be a way to see if that change has
been effected. There is a function to draw a line between two points
on your monitor, but there is no function to check to see if there is
ALREADY a line drawn between two points, and people don't go around
asking for one either.
Date: Sat ,9 Jan 82 18:53:00 EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
You sound upset. Could you please be calm about this?
I sound upset because I believe that if you though about this for ten
minutes (given that I KNOW that you understand how the reader is
implemented) you would understand that I am not stonewalling or
attempting to force my own views of anything on Henry. I am simply
trying to point out that it is IMPOSSIBLE to provide something that
has the same contract as MacLisp's (STATUS SYNTAX ...) does. (Even if
you are not allowed to examing the object returned.)
I gather from
what you say that the problems with Henry's suggestion are (1) it loses
information, and (2) it might be ambiguous because there might be more
than one "description" that applies to a particular character.
NO! I am trying to say that there character which HAVE NO DESCRIPTIONS!
Now,
indeed, it is going to lose information, and you can't just use the
"description" to move syntax attributes from one charcter to another.
However, it would be nice to be able to ask whether a certain character
is alphabetic in a certain readtable, even though there is other
interesting information to be had about the character.
What is meant by alphabetic here? See below.
Furthermore, it
looks to me (at a glance) like the set of "descriptions" documented with
si:set-syntax-from-description is non-overlapping. So it still looks
like the function Henry is asking for may have some value, although not
all of the value that you might ideally want it to have. This would be
both meaningful and useful without letting you use it later in a
different readtable. In answer to your question, yes, I do want them to
both return ALPHABETIC, and if I care that S can be used in small
flonums, well, there's no description for that anyway. Maybe we really
should have something like two-argument typep, though.
Try and think for a moment what you mean by "alphabetic syntax". Do
you mean that it is a member of the alphabet? Then you don't need a
readtable at all. Do you mean that it has the same syntax as "A" and
"&"? Then "E" is NOT alphabetic. Do you mean that it need not be
slashified to get it into the printname of a symbol? Then "E" will
certainly be alphabetic, but so will "3", ".", "1", and "4".
My best guess is that you mean: "Those characters that when they are
the one and only character in the printname of a symbol don't cause
that symbol to be printed slashified". This includes all the
characters with :ALPAHBETIC syntax (and more, like "E" and "+"), and
COINCIDENTALLY excludes all the other named syntaxes. I could write a
predicate to tell you when a character had that property as easily as
I could extract the complete slashifier tester from the printer. Do
you think that one or the other of these predicates would be useful?