From: Peter Seibel
Subject: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <m3ad7pta2b.fsf@javamonkey.com>
I suspect the actual answer is "both" because the only people who talk
about s-exprs are folks who already understand Lisp and who can tell
from context which aspect is meant.
But if one did want to distinguish between the textual representation
of Lisp data (i.e. the input to the reader) and the data
representation (i.e. the output of the reader), which would you refer
to as s-expressions. And what would you call the other?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Drew McDermott
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <bnetcr$ug9$1@news.wss.yale.edu>
Peter Seibel wrote:
> But if one did want to distinguish between the textual representation
> of Lisp data (i.e. the input to the reader) and the data
> representation (i.e. the output of the reader), which would you refer
> to as s-expressions. And what would you call the other?
I see I'm in the minority, but I always think of S-expressions as
noncircular list structures, i.e., trees, whose leaves are things like
symbols, numbers, strings, .... I have to trail off, because what I
mean is "A list structure that could have been the result of a 'read',"
and that class isn't very well defined. (Especially if you starting
fooling around with #., #i=, etc.)
--
-- Drew McDermott
Yale Computer Science Department
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9B062C.1E5AB977@setf.de>
Drew McDermott wrote:
>
> Peter Seibel wrote:
>
> > But if one did want to distinguish between the textual representation
> > of Lisp data (i.e. the input to the reader) and the data
> > representation (i.e. the output of the reader), which would you refer
> > to as s-expressions. And what would you call the other?
>
> I see I'm in the minority, but I always think of S-expressions as
> noncircular list structures, i.e., trees, whose leaves are things like
> symbols, numbers, strings, .... I have to trail off, because what I
> mean is "A list structure that could have been the result of a 'read',"
> and that class isn't very well defined. (Especially if you starting
> fooling around with #., #i=, etc.)
do you really think of "expressions" as "structures", or as notations for the structures?
...
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9AD6D6.653F3A84@setf.de>
the text.
Peter Seibel wrote:
>
> I suspect the actual answer is "both" because the only people who talk
> about s-exprs are folks who already understand Lisp and who can tell
> from context which aspect is meant.
>
> But if one did want to distinguish between the textual representation
> of Lisp data (i.e. the input to the reader) and the data
> representation (i.e. the output of the reader), which would you refer
> to as s-expressions. And what would you call the other?
>
> -Peter
>
> --
> Peter Seibel ·····@javamonkey.com
>
> Lisp is the red pill. -- John Fraser, comp.lang.lisp
"Peter Seibel" wrote:
> I suspect the actual answer is "both" because the only people who talk
> about s-exprs are folks who already understand Lisp and who can tell
> from context which aspect is meant.
The concept of s-expressions is clearly explained in John McCarthy's
original paper on Lisp
(http://www-formal.stanford.edu/jmc/recursive/node3.html#SECTION000300000000
00000000), and he uses the words 'character' and 'string', so he must means
the external (textual) representation. Of course, today s-expressions can
have more syntax than what McCarthy describes in this article because of
reader macros.
> But if one did want to distinguish between the textual representation
> of Lisp data (i.e. the input to the reader) and the data
> representation (i.e. the output of the reader), which would you refer
> to as s-expressions. And what would you call the other?
I would simply call the latter an 'object'.
Sebastian Stern
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all else
follows."
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9ADC35.F1321DF2@setf.de>
Sebastian Stern wrote:
>
> "Peter Seibel" wrote:
> > I suspect the actual answer is "both" because the only people who talk
> > about s-exprs are folks who already understand Lisp and who can tell
> > from context which aspect is meant.
>
> The concept of s-expressions is clearly explained in John McCarthy's
> original paper on Lisp
> (http://www-formal.stanford.edu/jmc/recursive/node3.html#SECTION000300000000
> 00000000), and he uses the words 'character' and 'string', so he must means
> the external (textual) representation. Of course, today s-expressions can
> have more syntax than what McCarthy describes in this article because of
> reader macros.
not only 'character' and 'string', but '(', ')', and '.', which have no
internal counterparts.
[despite mccarthy's reference to s-expressions as an "internal notation"
elsewhere in those notes.]
>
> > But if one did want to distinguish between the textual representation
> > of Lisp data (i.e. the input to the reader) and the data
> > representation (i.e. the output of the reader), which would you refer
> > to as s-expressions. And what would you call the other?
>
> I would simply call the latter an 'object'.
>
> Sebastian Stern
> "Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all else
> follows."
From: Peter Seibel
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <m3y8v9rqw4.fsf@javamonkey.com>
james anderson <··············@setf.de> writes:
> Sebastian Stern wrote:
> >
> > "Peter Seibel" wrote:
> > > I suspect the actual answer is "both" because the only people who talk
> > > about s-exprs are folks who already understand Lisp and who can tell
> > > from context which aspect is meant.
> >
> > The concept of s-expressions is clearly explained in John McCarthy's
> > original paper on Lisp
> > (http://www-formal.stanford.edu/jmc/recursive/node3.html#SECTION000300000000
> > 00000000), and he uses the words 'character' and 'string', so he must means
> > the external (textual) representation. Of course, today s-expressions can
> > have more syntax than what McCarthy describes in this article because of
> > reader macros.
>
> not only 'character' and 'string', but '(', ')', and '.', which have no
> internal counterparts.
Yup. I asked because I received at least one comment on my book from
someone who said, "Lisp syntax is really s-expressions, not text".
Which of course only makes sense if by s-expressions he meant the Lisp
objects, not the text. So my current inclination is to be clear that
by s-expressions I mean the text and then come up with some other term
to use to refer to the Lisp objects returned by the reader.
Suggestions welcome for that term. The standard use "forms"--maybe
I'll just use that, after defining it of course.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9AE7F2.DE508985@setf.de>
Peter Seibel wrote:
>
> ...
>
> Yup. I asked because I received at least one comment on my book from
> someone who said, "Lisp syntax is really s-expressions, not text".
> Which of course only makes sense if by s-expressions he meant the Lisp
> objects, not the text.
not necessarily "of course". given your initial opposition, "text" is the
closer of the two, but one can distinguish more than just "a sequence of
characters" and "lisp objects".
...
Sebastian Stern wrote:
> "Peter Seibel" wrote:
>
>>I suspect the actual answer is "both" because the only people who talk
>>about s-exprs are folks who already understand Lisp and who can tell
>>from context which aspect is meant.
>
>
> The concept of s-expressions is clearly explained in John McCarthy's
> original paper on Lisp
> (http://www-formal.stanford.edu/jmc/recursive/node3.html#SECTION000300000000
> 00000000), and he uses the words 'character' and 'string', so he must means
> the external (textual) representation.
You guys are all kidding right, when you say "text"?:
"We shall now define the S-expressions (S stands for symbolic). They are
formed by using the special characters:
. ( )
and an infinite set of distinguishable atomic symbols. For atomic
symbols, we shall use strings of capital Latin letters and digits with
single imbedded blanks."
What part of "S stands for symbols" is not understood? And then "For
atomic symbols, /we shall use/ strings..." emphasis added. So the
strings are not the symbols, they are used for them. And if one programs
in Lisp, I trust one knows that the name of a symbol (the string) is the
name of the symbol, not the symbol itself.
Tell me, why isn't read-from-string called read-from-symbol? Does
symbol-name return a symbol? Not. Look up sumbol in the HyperSpec. WEhat
do you know! Name is an /attribute/ of a symbol:
"The name of a symbol is a string used to identify the symbol. Every
symbol has a name, and the consequences are undefined if that name is
altered. The name is used as part of the external, printed
representation of the symbol"
I would say a little more rigor was required, but this does not even
require rigor to get straight.
>>But if one did want to distinguish between the textual representation
>>of Lisp data (i.e. the input to the reader) and the data
>>representation (i.e. the output of the reader), which would you refer
>>to as s-expressions. And what would you call the other?
>
>
> I would simply call the latter an 'object'.
When you realized you did not have a good answer, you should have said.
"Doh!" and changed your answer. The reader reads text and returns
symbolic-expressions.
And another thing!....
:)
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9B02B7.4FAC1062@setf.de>
Kenny Tilton wrote:
> ...
> What part of "S stands for symbols" is not understood? ...
which part of "stands for" is not understood?
>
> When you realized you did not have a good answer, you should have said.
> "Doh!" and changed your answer. The reader reads text and returns
> symbolic-expressions.
>
> And another thing!....
what does the printer produce given a ~S format control?
i note that k.pitman appears to have steered clear of this issue, but g.steele
does not.
concrete syntax is not abstract syntax is not data objects.
s-expressions are a notation. which puts them in the middle.
>
> :)
>
> kenny
>
> --
> http://tilton-technology.com
> What?! You are a newbie and you haven't answered my:
> http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
james anderson wrote:
>
> Kenny Tilton wrote:
>
>>...
>>What part of "S stands for symbols" is not understood? ...
>
>
> which part of "stands for" is not understood?
which part of is not understood?
>
>
>>When you realized you did not have a good answer, you should have said.
>>"Doh!" and changed your answer. The reader reads text and returns
>>symbolic-expressions.
>>
>>And another thing!....
>
>
> what does the printer produce given a ~S format control?
You're kidding again, right? READ and (I think you mean) FORMAT are for
I/O. As in "into" and "outof" Lisp. Symbolic expressions are for Lisp.
The reader takes text and produces symbols, PRINT takes symbols and
produces text. Because text and symbols are two different things, and
Lisp the language likes symbols but file systems and sockets do not.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9B096C.7923F144@setf.de>
Kenny Tilton wrote:
> ...
> >>And another thing!....
> >
> >
> > what does the printer produce given a ~S format control?
>
> You're kidding again, right? READ and (I think you mean) FORMAT are for
> I/O. As in "into" and "outof" Lisp.
no i meant "the printer". the format function is not distinct in this regard.
> Symbolic expressions are for Lisp.
> The reader takes text and produces symbols, PRINT takes symbols and
> produces text. Because text and symbols are two different things, and
> Lisp the language likes symbols but file systems and sockets do not.
that's fine. just step back a second and consider that perhaps, just perhaps,
s-expressions are neither sequences of characters, nor the data objects
produced by the reader and accepted by the printer. they can be encoded in the
former and modeled with the latter, but that does not mean that they the same
as either.
...
From: Drew McDermott
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <bngpeq$qta$1@news.wss.yale.edu>
james anderson wrote:
> concrete syntax is not abstract syntax is not data objects.
>
> s-expressions are a notation. which puts them in the middle.
>
S-expressions are a superset of the set of data objects that encode the
abstract syntax of Lisp. The abstract syntax of Lisp would specify the
syntax of each of the built-in special operators, which would be a
subset of of the S-expressions. So the abstract syntax might look like
form -> symbol | string | number | QUOTE object
| IF form form form | LOOP form*
| non-reserved-identifier form*
In a language like ML, we could translate this directly into
datatype form = Symbol of ... | ... | Quote of lispob
| If_exp of (form * form * form)
| Loop_exp of form list | ...
| Function_call of identifier * (form list)
These wouldn't _be_ the abstract syntax, but a data type isomorphic to
the abstract syntax.
In Lisp, we just help ourselves to a subset of the S-expressions. No
one would make such a choice today, now that we're sophisticated about
abstract datatypes. Imagine someone proposing representing program
syntax in ML this way, first defining a very general representation for
list structures and then declaring that programs were a not-very-well
specified subset of list structures. It's fortunate that Lisp was
discovered while we were still unsophisticated.
Note that the way Lisp is currently used is different from what McCarthy
envisioned. He thought the concrete syntax for function call would be
id[form,...,form]. The actual concrete syntax is (id form ... form).
This is one of the main reasons for Lisp's beauty: The concrete syntax
is almost impossible to distinguish from the abstract syntax (hence this
thread).
--
-- Drew McDermott
Yale Computer Science Department
From: james anderson
Subject: Re: Terminology question: are s-exps the text or the data or both?
Date:
Message-ID: <3F9CE647.8A82237C@setf.de>
Drew McDermott wrote:
>
> james anderson wrote:
>
> > concrete syntax is not abstract syntax is not data objects.
> >
> > s-expressions are a notation. which puts them in the middle.
> >
>
> ...
>
> Note that the way Lisp is currently used is different from what McCarthy
> envisioned. He thought the concrete syntax for function call would be
> id[form,...,form]. The actual concrete syntax is (id form ... form).
> This is one of the main reasons for Lisp's beauty: The concrete syntax
> is almost impossible to distinguish from the abstract syntax (hence this
> thread).
>
yes, one often appreciates that lisp affords one the opportunity to choose, at
ones advantage, to be in the audience or on stage, and to set the illumination
both in front of and behind the scrim, rather than having to negotiate a fire
curtain. yet, a discerning developer also appreciates the distinction, as one
cannot be in two places at once, that s-expressions are a notation for, and
are not identical with, the data objects produced by the reader.
just as even turner, who upon hearing from the disappointed buyer, that
"fingal's cave" was "indistinct", took it as his motto, that indistinctness
was his forte, still observed, upon receiving the complement, that someone
"liked" "snowstorm -- steamboat off a harbours's mouth", that "... no one had
any business to like it."
...
Kenny Tilton wrote:
>
>
> Sebastian Stern wrote:
> > The concept of s-expressions is clearly explained in John McCarthy's
> > original paper on Lisp
> >
(http://www-formal.stanford.edu/jmc/recursive/node3.html#SECTION000300000000
> > 00000000), and he uses the words 'character' and 'string', so he must
means
> > the external (textual) representation.
>
> You guys are all kidding right, when you say "text"?:
>
> "We shall now define the S-expressions (S stands for symbolic). They are
> formed by using the special characters:
>
> . ( )
>
> and an infinite set of distinguishable atomic symbols. For atomic
> symbols, we shall use strings of capital Latin letters and digits with
> single imbedded blanks."
Those "special characters" and "strings of capital Latin letters and digits
with single imbedded blanks" are an example of what is usually referred to
as "text".
> What part of "S stands for symbols" is not understood?
"S stands for symbolic" refers to the expressions that are formed by the
provided rules. S-expressions are symbolic expressions which are defined in
terms of a textual representation, i.e. they are formed by a sequence of
characters, including special characters and strings of alphanumeric
characters.
There are other possible representations for S-expressions. One such
alternate representation is the Lisp objects produced by the reader.
However, in that representation, the special characters, . ( ), do not
usually exist explicitly. This is a further indication that the referenced
definition is referring to a textual representation.
Note that the S-expressions formed by the defined notation are not text, and
nor are they Lisp objects. They are a conceptual entity with multiple
possible representations, but in the above link they are defined in terms of
their textual representation.
> And then "For atomic symbols, /we shall use/ strings..." emphasis added.
> So the strings are not the symbols, they are used for them.
Right, the strings are not the symbols, they are the textual representation
of the symbols. That's the point - the definition defines how text is used
to form S-expressions.
> And if one programs in Lisp, I trust one knows that the name of a
> symbol (the string) is the name of the symbol, not the symbol itself.
>
> Tell me, why isn't read-from-string called read-from-symbol?
Because read-from-string, like READ, converts a textual representation of
S-expressions into a Lisp object representation.
> Does symbol-name return a symbol? Not. Look up sumbol in the HyperSpec.
> WEhat do you know! Name is an /attribute/ of a symbol:
>
> "The name of a symbol is a string used to identify the symbol.
> Every symbol has a name, and the consequences are undefined
> if that name is altered. The name is used as part of the external,
> printed representation of the symbol"
>
> I would say a little more rigor was required, but this does not even
> require rigor to get straight.
Then again, perhaps it does... ;)
> When you realized you did not have a good answer, you should have said.
> "Doh!" and changed your answer. The reader reads text and returns
> symbolic-expressions.
The reader reads a textual representation of symbolic expressions and
returns an object representation.
Anton
Peter Seibel wrote:
> I suspect the actual answer is "both" because the only people who talk
> about s-exprs are folks who already understand Lisp and who can tell
> from context which aspect is meant.
>
> But if one did want to distinguish between the textual representation
> of Lisp data (i.e. the input to the reader) and the data
> representation (i.e. the output of the reader), which would you refer
> to as s-expressions.
If you want to be unambiguous, the correct answer is "neither". Both are
representations of S-expressions. The representation McCarthy defines at
[1] is a textual representation, but it's still only a representation, or
notation. At [2], McCarthy defines the "Representation of S-Expressions by
List Structure".
Anton
[1] http://www-formal.stanford.edu/jmc/recursive/node3.html
[2] http://www-formal.stanford.edu/jmc/recursive/node4.html
<g> After that long thread trying to decide (I'll get this wrong) if
Scheme /really/ handled (what?) or text, I had a laugh when I saw
Peter's question. Welcome back!
Anton van Straaten wrote:
> Peter Seibel wrote:
>
>>I suspect the actual answer is "both" because the only people who talk
>>about s-exprs are folks who already understand Lisp and who can tell
>>from context which aspect is meant.
>>
>>But if one did want to distinguish between the textual representation
>>of Lisp data (i.e. the input to the reader) and the data
>>representation (i.e. the output of the reader), which would you refer
>>to as s-expressions.
>
>
> If you want to be unambiguous, the correct answer is "neither". Both are
> representations of S-expressions. The representation McCarthy defines at
> [1] is a textual representation,
Nonsense. He wrote: "The symbols are atomic in the sense that any
substructure they may have as sequences of characters is ignored. "
That's the spec, guys: "ignored". Why might the text substructure be
there? In the prior sentence he said they were there just for the
mnemonic value. And in the implementation of the spec, symbols do /not/
have a structure /as/ text, they have one attribute out of several which
/is/ the text name.
Oh, well. It's Peter's book. Bye-bye, thread.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton wrote:
> <g> After that long thread trying to decide (I'll get this wrong) if
> Scheme /really/ handled (what?) or text, I had a laugh when I saw
> Peter's question. Welcome back!
Actually, this is a different issue, in which both Scheme & Lisp share
essentially the same behavior, in that both depend on the existence of a
textual representation for S-expressions. Without that textual
representation, you'd have to enter code by picking objects from a menu, or
something equally tedious.
Put it this way: if the cited page is *not* defining the textual
representation of S-expressions (in addition to the structure of
S-expressions themselves), then where is it defined?
Note that I'm not saying that S-expressions are text. I'm saying that
S-expressions should not be confused with their textual representations.
> >>But if one did want to distinguish between the textual representation
> >>of Lisp data (i.e. the input to the reader) and the data
> >>representation (i.e. the output of the reader), which would you refer
> >>to as s-expressions.
> >
> >
> > If you want to be unambiguous, the correct answer is "neither". Both
are
> > representations of S-expressions. The representation McCarthy defines
at
> > [1] is a textual representation,
>
> Nonsense. He wrote: "The symbols are atomic in the sense that any
> substructure they may have as sequences of characters is ignored. "
> That's the spec, guys: "ignored".
Symbols in S-expressions are atomic, and as such their "substructure" is
irrelevant, correct. But the whole point I'm making is that S-expressions
are not their representations, and confusing the two leads to... well,
confusion.
In the textual representation being defined, sequences of characters are
"formed by ... strings of capital Latin letters and digits with single
imbedded blanks". That is not at odds with "symbols are atomic". If you
think it's at odds, you're missing the point, which is to define symbolic
expressions, along with a textual notation for them. Two distinct things
are being defined on that page.
How else would you characterize the definition we're talking about? What is
being defined in terms of what? Make sure you don't phrase your answer as a
loop...
> Why might the text substructure be
> there? In the prior sentence he said they were there just for the
> mnemonic value. And in the implementation of the spec, symbols do /not/
> have a structure /as/ text, they have one attribute out of several which
> /is/ the text name.
>
> Oh, well. It's Peter's book. Bye-bye, thread.
This is actually a very clearly defined issue, for a change. However, it
requires a certain amount of clarity to discuss it meaningfully.
Anton