I'm new to scheme; can someone explain why this happens?
(mzscheme)
> '(1 . 2 . 3)
(2 1 3)
however, in chez scheme I get the following response
> '(1. 2 . 3)
Error in read: unexpected dot.
_spitFIRE <············@gmail.com> writes:
> I'm new to scheme; can someone explain why this happens?
You'll be wanting comp.lang.scheme to answer this. comp.lang.lisp
discusses mostly common lisp, but in any case does not discuss scheme
(except occasionally for comparison purposes).
> (mzscheme)
> > '(1 . 2 . 3)
> (2 1 3)
>
> however, in chez scheme I get the following response
> > '(1. 2 . 3)
> Error in read: unexpected dot.
While this is definitely NOT the answer to your question as posed,
those in the Lisp community not familiar with the maclisp HUNK datatype
might want to read
http://groups.google.com/group/comp.lang.lisp/msg/ae5ba1d4c7f74604
Kent M Pitman wrote:
> http://groups.google.com/group/comp.lang.lisp/msg/ae5ba1d4c7f74604
Hmm... I fear that might lead to "disappearing" data, well not
physically, but the stuff in the middle of the hunk might simply be
"forgotten" in a complex program's logics... both by functions which
treat it as ordinary conses aswell as well as by programmers maintaining
them. It's a cute hack but not every cute hack is always a good thing...
Matthias Buelow <···@incubus.de> writes:
> Kent M Pitman wrote:
>
> > http://groups.google.com/group/comp.lang.lisp/msg/ae5ba1d4c7f74604
>
> Hmm... I fear that might lead to "disappearing" data, well not
> physically, but the stuff in the middle of the hunk might simply be
> "forgotten" in a complex program's logics... both by functions which
> treat it as ordinary conses aswell as well as by programmers maintaining
> them. It's a cute hack but not every cute hack is always a good thing...
Well, first, I didn't say it was an unambiguously Good Thing nor did I
advocate its inclusion in modern languages. I just observed for
historical purposes a property of a language for the purposes of
stretching people's minds to what is possible. We often assume the
world has only ever been and can only ever be one way, and it's good
to see the different shapes it can take on. As with most things, this
was something with some good and some bad.
As for disappearing data, all abstraction can lead to that, otherwise
why would we call the term "data hiding". It's not for the purpose of
putting data out into the open. :) People use abstraction correctly
when they make sure they get the information they need out of the
representation they have chosen. You might argue that static type
systems that rely on type declarations to hide "irrelevant" parts of a
class are also guilty of this. It wasn't done this way, but you could
think of a hunk as a subclass of a cons that just added extra slots.
In that regard, the extra data is in no more peril than any other kind
of data that is subclassed. One must presume, when analyzing a
language, that people who program it know from the outset which
classes are subclassable and which are not, and build in protections
in their programs against ill effects that might come from such
things.
I think it went away in part because it was subsumed by classes, which
were more general both in the degree of control offered for storage
sizes and in the upper bound on size. In its specific implementation
details, it was tuned for PDP10 Maclisp's small address space, and
even its data layouts, and was not super-general. In its abstraction,
though, it did have a raw simplicity to it that was kind of elegant
and got lost in the mix. In that regard, its real failing wasn't the
basic design but the fact that its designers simply didn't decide
whether the type was intended to be a kind of cons or not, so they
left it to hopelessly straddling between several possible states.
That is, it didn't hurt MACLISP so much that they either were
cons-like or not, it hurt MACLISP that hunks were sometimes cons-like
and sometimes not, according to a single master switch that competing
libraries kept throwing in different, incompatible directions,
breaking each other.
Hunks probably would have been what tuples came to be in most other
languages if there had not been a bin-packing problem in small address
spaces, and I don't think tuples are argued to be such a terrible thing.
And they would, if present in Lisp, probably confront the same questions,
such as whether a two-tuple was possible to pass off as a cons. So it's
worth paying attention to how these things played out.
+ _spitFIRE <············@gmail.com>:
> I'm new to scheme;
Then you should ask on comp.lang.scheme.
> can someone explain why this happens?
> (mzscheme)
>> '(1 . 2 . 3)
> (2 1 3)
Looks like a bug to me. I believe the dot is only allowed before the
last element, in scheme as in common lisp.
> however, in chez scheme I get the following response
>> '(1. 2 . 3)
> Error in read: unexpected dot.
Looks like a bug to me.
I would have expected it to return (1.0 2 . 3).
If you had tried the same input as in the first case, however, the
"extra dot" error message is precisely what I would expect.
If you understand how lists are built from cons pairs, and how a dot
before the final element puts that element in the second slot (cdr) of
a cons instead of the first (car) slot, you may play around with
conses and see for yourself why it makes no sense to put the dot
anywhere other than before the final element.
(1 2 3) = (1 . (2 . (3 . nil)))
(1 2 . 3) = (1 . (2 . 3))
(1 . 2 . 3) = (1 . what-would-you-put-here?)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen wrote:
> Looks like a bug to me. I believe the dot is only allowed before the
> last element, in scheme as in common lisp.
The two-dot notation is PLT Scheme specific extension.
It gives you "infix notation". Try:
(1 . < . 2)
This notation can be disabled in the reader if one dislikes it.
--
Jens Axel S�gaard