I have just a simple question to post to those of you concerned whith the
more basic aspects of LISP.
Firstly,
Lets say that I define a function:
(defun <F_Name> (<arglist>) <body>)
Here arglist is ussually any number of arguments from zero to what the
particular interpreter and or compiler will accept. This being so I see
a problem whith the generality of the syntax. Here is an example:
(defun Example Arglist <body>).
Now this is the most general form of function as far as passing arguments.
I will now compare the function Example to this new function which I define
as:
(defun One_arg (a) <body>).
A little explanation of the function Example is in order first though...
In the function Example the argument Arglist stands for any number of
arguments that are passed to Example (the full list of arguments). Lets
say that my version of LISP had no 'cond' and I wanted to define it. Now
using the normal syntax for a function I would have no way of performing
the definition. The only way I could do it was to make all of the conditions
under a single list, increasing speed and decreasing efficiency. Here are
the two definitions in either format:
Expanded syntax: Example function form.
(defun cond condargs
((if (cdr (car condargs)) (cdr (cdr condargs)))
(cond (cdr condargs)) ) ;;; end of cond
Standard syntax: One_arg function form.
(defun cond (condargs)
<repeat above body> ) ;;; end of cond
Now at first both Look the same but they are not. Whith the expanded version
I would be able to use the standard syntax for cond, whith the second I would
have to enclose all of my conditions under another parens. For instance if I
had:
(cond
[(atom a) (print "Hello " a)]
[t (print "Say that again?")] ) ;;; standard syntax whith Example form.
(cond
(
[(atom a) (print "Hello " a)]
[t (print "Say that again?")] )) ;;; added parens in One_arg form.
I know that some macro options in LISP do handel such features but why use
them for that if the more basic lambda definitions can handel it?
Secondly,
The car and cdr defintitions also seem abit too limited in scope for some of
the same reasons that I stated above (one second before you nail me to any
cross shaped wood!!). As far as I can tell there is a consistent syntax for
LISP implimentations:
(car <atom or list>)
(cdr <atom or list>)
(cons <atom or list> <atom or list>)
The question I have is why not have car and cdr have multiple arguments? For
instance here are some examples of the syntax I propose:
(car a m n) => a
(car a) => a
(car (a m n)) => a
(car (a m n) p) => (a m n)
(cdr a m n) => (m n)
(cdr (a m n)) => (m n)
(cdr a (m n)) => (m n)
in general
(car arg0 arg1 ... ) => arg0
(car arg0) => "normal car of arg0."
(cdr arg0 arg1 ... ) => (arg1 ... )
(cdr arg0) => "normal car of arg0."
That is pretty much it. If you do care to respond please please do not give
into the knee-jerk reaction of getting religious about the standards of LISP
syntax you are used to. I am allready familiar whith many of the arguments
for and against what I have proposed. I am looking for the what have I missed
or what I could add responses. Thanks for the time....
===============================================================================
······@orion.alaska.edu - lone programer heretic - Books contain no wisdom
===============================================================================
······@uaa.alaska.edu wrote:
> Lets say that I define a function:
> (defun <F_Name> (<arglist>) <body>)
The simple answer is that you have misread the definition of the syntax
of Lisp.
> Here arglist is ussually any number of arguments from zero to what the
> particular interpreter and or compiler will accept. This being so I see
> a problem whith the generality of the syntax. Here is an example:
There is a difference between (<arglist>) and <arglist>.
> (defun cond condargs
> ((if (cdr (car condargs)) (cdr (cdr condargs)))
> (cond (cdr condargs)) ) ;;; end of cond
Again, the above is simply illegal in Lisp. You have missunderstood the
definition of the syntax of Lisp.
> (car a m n) => a
> (car a) => a [*]
> (car (a m n)) => a [**]
> (car (a m n) p) => (a m n)
>
> (cdr a m n) => (m n)
> (cdr (a m n)) => (m n)
> (cdr a (m n)) => (m n)
Your proposal is self-referentially inconsistent. For one things,
you did not quote the lists in the arguments to car and cdr so
Lisp would try to evaluate them as function calls. But ignoring that:
Should (car '(1 2 3)) => 1 as you say in [*]
or (car '(1 2 3)) => '(1 2 3) as you say in [**]
Your specification requires both.
This is not a religious question and I'm not trying to crucify you.
You simply have misunderstood the definition of the syntax. Once
you understand it, you may still have criticisms. At this point
your criticisms are of something which does not exist.
I hope this helps. Definitions of the syntax of Lisp are available
on line. See the FAQ.
--
Benjamin Shults Email: ·······@math.utexas.edu
Department of Mathematics Phone: (512) 471-7711 ext. 208
University of Texas at Austin WWW:
http://www.ma.utexas.edu/users/bshults
Austin, TX 78712 USA FAX: (512) 471-9038 (attn: Benjamin
Shults)
······@uaa.alaska.edu wrote:
> The question I have is why not have car and cdr have multiple arguments? For
> instance here are some examples of the syntax I propose:
>
> (car a m n) => a
> (car a) => a
> (car (a m n)) => a
> (car (a m n) p) => (a m n)
>
> (cdr a m n) => (m n)
> (cdr (a m n)) => (m n)
> (cdr a (m n)) => (m n)
>
> in general
>
> (car arg0 arg1 ... ) => arg0
> (car arg0) => "normal car of arg0."
> (cdr arg0 arg1 ... ) => (arg1 ... )
> (cdr arg0) => "normal car of arg0."
> First, I suppose you mean (car 'a 'b 'c ...), otherwise you should also
change the meaning of car and cdr and not only their syntax.
I think that the main reason for not having it the way you say is because
car and cdr are the tools we have to break up a list. If you want (car a
b c..) to return a, why would you use the car function in the first
place? You already have a as a separate element, so why do you put it
together with b and c and then retrieve only a again?
The same applies to cdr. If on the contrary, you had a list '(a b c) and
you wanted to split it retrieving its first element, you would have to
define a new function which would work just as the standard car.
Having said that, I must admit that very often I need to modify car
a bit, defining a new function (that I call kar, and P. Graham calls
car1) which is:
(defun kar (x)
(if (atom x) x (car x)) )
This prevents car from giving an error when you pass it an atom as a
parameter, and it turns out to be quite useful.
In article <··········@news.alaska.edu> ······@uaa.alaska.edu writes:
> (car <atom or list>)
> (cdr <atom or list>)
> (cons <atom or list> <atom or list>)
If you're using Common Lisp, then I'd recommend that you use the
FIRST and REST functions instead of CAR and CDR. If you're used to
the CAR and CDR functions, or have some equally good reason for
using them, then fine. This is simply a matter of style, but I see
the names CAR and CDR as historical relics that will mean very
little to new Lisp programmers, unlike FIRST and REST, which are
very easy to associate with the behaviour of the FIRST and REST
functions.
I'm making this distinction between the functions and the names
of the functions because the functions defined for CAR and FIRST
may actually _be_ the same functions. If you find this confusing,
then you have my sympathy. The names CAR and CDR only make sense
when you understand what the names originally refered to, which
I understand is a purely historical relic from an ancient Lisp
implementation.
I know there's a tradition for function naming that gives us
functions like CDDR etc, but this is one of those features that
has less relevance today than it might have had a couple of
decades ago. If it adds to the confusion of new Lisp programmers,
than I'd suggest that it _may_ have outlived its usefulness.
See questions [1-5] and [1-6] in the Lisp FAQ for further details.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>In article <··········@news.alaska.edu> ······@uaa.alaska.edu writes:
>If you're using Common Lisp, then I'd recommend that you use the
>FIRST and REST functions instead of CAR and CDR. If you're used to
I would like to add my $.02.
Even FIRST and REST may be no more clear to a reader than car or cdr
if you are not explaining why you are taking a first or rest. For
instance, if you are extracting the arguments of an algebraic
function, you might use cdr (or rest), but it is probably even better
still to have appropriate accessors and use (extract-args ....) or
whatever.
Another issue deals with properties - however you define cons, car and
cdr, they must satisfy the following properties: (this was extracted
from sicp)
(cons (car p) (cdr p) = p where p is any pair
(car (cons x y))=x
(cdr (cons x y))=y
If a defnition satsifies these three properties, it is equivalent to
car and cdr, at least as far as Abelson and Sussman are concerned.
In article <···········@mule0.mindspring.com>
···@dur.mindspring.com "Michael Tuchman" writes:
> Even FIRST and REST may be no more clear to a reader than car or cdr
> if you are not explaining why you are taking a first or rest. For
> instance, if you are extracting the arguments of an algebraic
> function, you might use cdr (or rest), but it is probably even better
> still to have appropriate accessors and use (extract-args ....) or
> whatever.
My point concerned the naming of the functions, and the
relationship between the names and the behaviour of the
functions. The issue of deciding which functions (behaviours)
to use is very different.
Your point seems to me to concern a programming issue, and
I agree that being able to program may be more important that
your choice of programming style, but that doesn't make style
irrelevant. The names FIRST and REST are easier to associate
with their behaviour than CAR and CDR.
I didn't discover Lisp until the mid-80s, when the Common Lisp
dialect was available. This may be why I feel no obligation to
use ancient (and obscure) names. Some other Lisps use names
like HEAD and TAIL, which I feel are just as reasonable as FIRST
and TAIL. Fortunately, Lisp usually gives us a choice. If we
don't like a name for a particular function, we can do something
about it. Unfortunately, it takes time to learn enough to realise
this, and how easy it is. This is why I suggest that the names
CAR and CDR are a problem - for beginners.
Obviously, my perspective will be very different to somebody
who learned about Lisp years before I did. While I'd be far
less experienced with Lisp than such a person, I can offer my
experiences with Lisp, and the features I've had difficulty
with. Obscure names may be very minor problems to you or I,
but I suspect that we may be exceptions. I'm not entirely
comfortable with names like CAR and CDR, but I know that such
"trivial" things can bother some people enough to make learning
a language difficult.
If we can make Lisp easier to learn by instead using names
like FIRST and REST, why should we not make that effort? The
only reason that I can think of is that we might not care how
many other programmers use Lisp. I sometimes get the impression
that some people who use computers enjoy using software that
is obscure as possible. I'm not as patient with such software
as I once was, and I'm not sure that if I discovered Lisp now
instead of about 10 years ago whether or not I'd have bothered
using it, when there are alternatives with would appear so
much easier to learn.
Yet I'm still be more patient with languages like Lisp than
most programmers that I know. They seem like a typical bunch,
to me, but I hope I'm wrong. If I'm right, then Lisp doesn't
have many friends these days, at least not for the platforms
that I develop for. I'm not suggesting that using FIRST instead
of CAR and REST instead of CDR will be enough to change that,
but I'm sure that such things can _help_.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
In article <··········@news.alaska.edu>, <······@uaa.alaska.edu> wrote:
>
> I have just a simple question to post to those of you concerned
> whith the more basic aspects of LISP.
This is not meant as a flame, so I hope you won't take it as one.
It's good to hear from someone who wants to improve the language
by challenging some of its basic assumptions. That's how Sussman
and Steele got started, and we have all benefited from their work.
But I don't think you are going to get anywhere by posting an
article like that one in this newsgroup, because I doubt that anyone
in this group will be able to understand what you are trying to
suggest. It seems that you are using some kind of informal
meta-syntax, and mixing it indiscriminately with real syntax in
such a way that none of us can tell which level you are using at
any particular moment.
Either that, or it might be that you just don't understand the
language's current semantics. For example, the reason that COND
cannot be implemented as a lambda function has nothing at all to
do with the way argument lists are specified in a DEFUN form,
although that is what you seem to think. Perhaps you don't really
think that, and you are just confusing me with meta-syntax.
The problem seems to be one or both of the following: misunderstanding
of current Lisp semantics, and/or excessive informality of meta-syntax.
Fortunately I have a suggestion for you that will solve both problems.
You should get a copy of "The Structure and Interpretation of
Computer Programs" by Abelson and Sussman, considered by many to
be one of the best books on computer programming ever written.
Read it and work through the exercises and examples. When you have
done this, not only will you have a solid understanding of Scheme
semantics (easily transferred to Common Lisp), but also you will
know how to write a Lisp interpreter in Lisp, in just a few pages
of code.
Then you can write a modified Lisp interpreter that does what you
want, and make it available to the rest of us through the Net.
We'll be able to understand your ideas, and even try them out and
see if we like them. We won't be confused by informal meta-syntax,
because the only meta-syntax involved will be the actual interpreter
code that we can read and/or experiment with.
Good luck,
-- Robert