Do you think Common Lisp would be a better language if everything
was an object like in Dylan and Smalltalk ? Even the so-called
lesser languages let you, for example, extend arithmetic
operators, etc. Also, Lisp already has type-tagged values, so
little performance would be lost by making everything an object.
By the way, is Dylan essentially dead? Is anyone but the
developers themselves using it? Or is it more correct to say that
Dylan has not been born yet?
420
From: Christopher C. Stacy
Subject: Re: everything is an object
Date:
Message-ID: <u8yozoken.fsf@dtpq.com>
>>>>> On Sun, 7 Sep 2003 21:37:40 -0700 (PDT), mike420 ("mike420") writes:
mike420> Do you think Common Lisp would be a better language if everything
mike420> was an object like in Dylan and Smalltalk ?
Do you write a lot of Common Lisp programs, or do you just
write endless trolling messages like this?
mike420> Even the so-called lesser languages let you, for example,
mike420> extend arithmetic operators, etc.
Common Lisp takes the position that users should not be trying
to extend the built-in operators, because they already do what
they are supposed to do. When you go to read any program,
you can esily tell what it means without having to guess if
the other guy changed things like that out from under you.
Prove to me that there's a point to your random questions:
what arithmetic opertor did you want to extend, what did you
want it to do, why, and why is that a great idea from my standpoint?
mike420> By the way, is Dylan essentially dead? Is anyone but the
mike420> developers themselves using it? Or is it more correct to
mike420> say that Dylan has not been born yet?
You should ask that question on comp.lang.dylan.
It was stillborn by deciding to abandon and alienate the existing
Lisp community and simultaneously failing to recognize the power
of the market(ing) forces that were bringing the world Java.
I remember asking someone over at Harlequin how they were going to
address this new Java thing that was coming out, and they just got
angry at me for asking the question. Then they went bankrupt.
······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> mike420> By the way, is Dylan essentially dead? Is anyone but the
> mike420> developers themselves using it? Or is it more correct to
> mike420> say that Dylan has not been born yet?
>
> You should ask that question on comp.lang.dylan.
No, not really. It's already big enough of a troll when asked here.
·······@ziplip.com wrote in message news:<········································@ziplip.com>...
> Do you think Common Lisp would be a better language if everything
> was an object like in Dylan and Smalltalk ?
What do you mean by everything? Should a GO tag be an object? When you
write `(foo ,@bar), should the backquote character be an object that
receives a left parenthesis as a message?
> Even the so-called
> lesser languages let you, for example, extend arithmetic
> operators, etc.
Lisp has this. You can define your own arithmetic operators that are
generic over your own objects as well as built-in types, in any
mixtures.
However, you can't redefine the functions and macros in the standard
library. Probably for efficiency reasons, Lisp's arithmetic library
consists of ordinary functions, rather than generic functions. So you
cannot add new methods on COMMON-LISP:+ to define ways to add new
objects. However you can make a generic function + in your own package
which does everything that + does, and is extensible in that way. You
can switch existing code to use that package.
> Also, Lisp already has type-tagged values, so
> little performance would be lost by making everything an object.
Those values are objects. Every value in Lisp is considered to have
some class under the object system, including basic types like numbers
and strings. You can dynamically dispatch methods on these types. Is
that close enough to ``everything is an object''?
···@ashi.footprints.net (Kaz Kylheku) writes:
> ·······@ziplip.com wrote in message news:<········································@ziplip.com>...
> > Do you think Common Lisp would be a better language if everything
> > was an object like in Dylan and Smalltalk ?
>
> What do you mean by everything? Should a GO tag be an object?
It already is, kind of:
* '(tagbody
(go end)
(print "Dead code")
end)
(TAGBODY (GO END) (PRINT "Dead code") END)
* (fourth *)
END
* (eval **)
Note: Deleting unreachable code.
NIL
If by "object" you (well, the trolling OP, but I prefer to ignore him)
mean "object" in the SmallTalk sense, it might be interesting to read
this thread from comp.lang.smalltalk:
<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3D1A9AE9.1010005%40keyww.com&rnum=1>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kaz Kylheku wrote:
>
> ·······@ziplip.com wrote in message news:<········································@ziplip.com>...
> > Do you think Common Lisp would be a better language if everything
> > was an object like in Dylan and Smalltalk ?
>
> What do you mean by everything? Should a GO tag be an object? When you
> write `(foo ,@bar), should the backquote character be an object that
> receives a left parenthesis as a message?
Backquote is a character containing a read macro which takes what
immediately follows it as its argument, so it already is an object;
Common Lisp doesn't use the message passing paradigm.
But I recognize what you're doing is answering a troll with another
troll, which makes perfect sense.
--
:ugah179 (home page: http://web.onetel.com/~hibou/)
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
·······@ziplip.com writes:
> Do you think Common Lisp would be a better language if everything
> was an object like in Dylan and Smalltalk ?
Everything is an object. So I guess not.
> Even the so-called
> lesser languages let you, for example, extend arithmetic
> operators, etc.
In spite of the propensity of some languages to inappropriately coopt
the term "object" to refer to some aspect of how an object was created,
the fact is that Lisp was had objects and was called object-oriented
long before it had user-extensible classes of any kind.
See "Parenthetically Speaking: What's in a Name?"
http://www.nhplace.com/kent/PS/Name.html
> Also, Lisp already has type-tagged values, so
> little performance would be lost by making everything an object.
Most performance of this kind is not gained or lost on dynamic typing
but in typed declarations that are acted upon by a compiler. It might
or might not be possible to make an efficient Lisp of the form you
say, but your one-sentence analysis of the issues here is seriously
deficient. A proper analysis would have to take into account the set
of performance optimizations presently done by the compiler that might
be lost if this or that specific name were changed. Your remark seems
to assume that Lisp is an interpreted-only language. It has not been
that in more than 30 years, if it ever was (which is something of a
philosophical question rather than one that yields neatly to objective
factual observation).
> By the way, is Dylan essentially dead? Is anyone but the
> developers themselves using it? Or is it more correct to say that
> Dylan has not been born yet?
Why are you asking us? If we say "Yes, it's dead." will that make it dead?
·······@ziplip.com writes:
> Do you think Common Lisp would be a better language if everything
> was an object like in Dylan and Smalltalk ? Even the so-called
Why do you ask? Have you run across a Common Lisp problem? If so, can
you provide any specific examples?
> By the way, is Dylan essentially dead? Is anyone but the
Better asked in a Dylan forum.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In the last exciting episode, ·······@ziplip.com wrote:
> Do you think Common Lisp would be a better language if everything
> was an object like in Dylan and Smalltalk ?
I thought that everything in CL _was_ an object. I must have been
wrong.
--
output = ("cbbrowne" ·@" "ntlug.org")
http://www.ntlug.org/~cbbrowne/lisp.html
Rules of the Evil Overlord #169. "If I have massive computer systems,
I will take at least as many precautions as a small business and
include things such as virus-scans and firewalls."
<http://www.eviloverlord.com/>
In article <········································@ziplip.com>,
·······@ziplip.com wrote:
> By the way, is Dylan essentially dead? Is anyone but the
> developers themselves using it? Or is it more correct to say that
> Dylan has not been born yet?
I think that's a question of outlook, rather than fact. I prefer to say
the glass is half full -- or that Dylan hasn't hit critical mass yet.
FWIW, I'm getting quite a lot of questions about Dylan at work from
people who are getting sick of fighting C++. I don't expect to be able
to push C++ out anytime soon, but at the same time I'm pretty sure that
if I can demonstrate Dylan playing well with the existing C++ programs
and libraries then we'll trial it. Meantime, we're making an experiment
with using Scheme to add some flexibility and easier programming in one
small place that benefits from lightweight threading via continuations.
We've also seem to have recently had a bit of an influx of visitors on
the #dylan IRC channel, but that's pretty subjective.
comp.lang.dylan is pretty dead, because most of the activity takes place
on the Gwydion mailing lists and #dylan IRC.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <········································@ziplip.com>,
> ·······@ziplip.com wrote:
>
>> By the way, is Dylan essentially dead? Is anyone but the
>> developers themselves using it? Or is it more correct to say that
>> Dylan has not been born yet?
>
> I think that's a question of outlook, rather than fact. I prefer to say
> the glass is half full -- or that Dylan hasn't hit critical mass yet.
``I feel better....''
·······@ziplip.com writes:
> Do you think Common Lisp would be a better language if everything
> was an object like in Dylan and Smalltalk ? Even the so-called
> lesser languages let you, for example, extend arithmetic
> operators, etc. Also, Lisp already has type-tagged values, so
> little performance would be lost by making everything an object.
Btw, are you so sure you can't do this in CL? Why not shadow NUMBER,
INTEGER, FLOAT, COMPLEX, REAL, NUMBERP, INTEGERP, +, -, etc.
... whatever you want to extend. Then make your own NUMBERP,
INTEGERP, etc. using method dispatch. Ditto for your shadowed +, -,
Make sure it dispatches on primitive numbers, too. Then extend to
your heart's content.
Whatever ill you may say about CL, it gives you a great deal of mechanism
for re-forming the parts of the language that you find offend you.
I personally do this kind of thing all the time. It's much more productive
than complaining that the language designers botched something, since waiting
for a "fix" to things any language designer has done is generally a multiyear
endeavor, whereas doing a few SHADOW's and DEFMETHOD's can be done inside
of a few minutes.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>·······@ziplip.com writes:
>
>> Do you think Common Lisp would be a better language if everything
>> was an object like in Dylan and Smalltalk ? Even the so-called
>> lesser languages let you, for example, extend arithmetic
>> operators, etc. Also, Lisp already has type-tagged values, so
>> little performance would be lost by making everything an object.
>
>Btw, are you so sure you can't do this in CL? Why not shadow NUMBER,
>INTEGER, FLOAT, COMPLEX, REAL, NUMBERP, INTEGERP, +, -, etc.
>... whatever you want to extend. Then make your own NUMBERP,
>INTEGERP, etc. using method dispatch. Ditto for your shadowed +, -,
>Make sure it dispatches on primitive numbers, too. Then extend to
>your heart's content.
Shadowing like this will allow your own applications to use the generic
functions, but it won't extend all the prewritten applications and built-in
functions that use the standard functions.
For instance, if you shadow + and = with generic versions, you still won't
be able to use your data types with INCF, LOOP, DOTIMES, etc. You'd need
to provide your own version of all these operators, as well as any
third-party libraries you want to use.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Barry Margolin" <··············@level3.com> wrote in message
·····················@news.level3.com...
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >·······@ziplip.com writes:
> >
> >Btw, are you so sure you can't do this in CL? Why not shadow NUMBER,
> >INTEGER, FLOAT, COMPLEX, REAL, NUMBERP, INTEGERP, +, -, etc.
> >... whatever you want to extend. Then make your own NUMBERP,
> >INTEGERP, etc. using method dispatch. Ditto for your shadowed +, -,
> >Make sure it dispatches on primitive numbers, too. Then extend to
> >your heart's content.
>
> Shadowing like this will allow your own applications to use the generic
> functions, but it won't extend all the prewritten applications and
built-in
> functions that use the standard functions.
>
> For instance, if you shadow + and = with generic versions, you still won't
> be able to use your data types with INCF, LOOP, DOTIMES, etc. You'd need
> to provide your own version of all these operators, as well as any
> third-party libraries you want to use.
Existing code probably won't function as expected anyway. The compiler and
code that
depends on + has been written with the assumption that + is associative,
commutative and
distributive, invertible, etc. Maybe even something like (+ x x x x) has
been changed to
(* 4 x) (or vice versa).
The complex numbers is the largest field that preserves these assumptions.
As soon as you
extend + to quartonions or octonions, matrices, strings, etc. you can
expected existing code to break
anyway.
Example.
Is the built in INCF bright enought to add the appropriate default '1'
matrix if its passed a matrix? No!
You are going to have extend incf in any case.
Rene.
Kent M Pitman <······@world.std.com> writes:
> Btw, are you so sure you can't do this in CL? Why not shadow NUMBER,
> INTEGER, FLOAT, COMPLEX, REAL, NUMBERP, INTEGERP, +, -, etc.
> ... whatever you want to extend. Then make your own NUMBERP,
> INTEGERP, etc. using method dispatch. Ditto for your shadowed +, -,
> Make sure it dispatches on primitive numbers, too. Then extend to
> your heart's content.
While self-compiled software can be built using a special MY-COMMON-LISP
package, the vendor supplied packages will still support only standard
Common Lisp types.
For example, in Dylan I can define my own subclasses of <sequence>.
While I could shadow every Common Lisp function which understands
sequences, I would have to convert my sequences into lists or vectors
when calling any of a myriad of implementation supplied extension
functions.
From: ··········@YahooGroups.Com
Subject: Re: everything is an object
Date:
Message-ID: <REM-2003sep11-007@Yahoo.Com>
{{Date: 09 Sep 2003 14:09:36 -0400
From: Kent M Pitman <······@world.std.com>
... doing a few SHADOW's and DEFMETHOD's can be done inside of a few
minutes.}}
Hmm, reading your article here reminds me of that wonderful article by
the/an author of Yahoo Stores explaining why keyword arguments are a
wonderful device for adding new features to functions without
disturbing old usage of the same functions. It would be interesting to
see a full article written by you explaining in full generality how
wonderful Lisp is regarding the ability to shadow built-in functions
and then re-define them to do more than they did before, by your
proposed DEFMETHOD technique, or by any other technique allowed by CL,
as appropriate. (Just a suggestion. I have no money to pay you.)
··········@YahooGroups.Com writes:
> {{Date: 09 Sep 2003 14:09:36 -0400
> From: Kent M Pitman <······@world.std.com>
> ... doing a few SHADOW's and DEFMETHOD's can be done inside of a few
> minutes.}}
>
> Hmm, reading your article here reminds me of that wonderful article by
> the/an author of Yahoo Stores explaining why keyword arguments are a
> wonderful device for adding new features to functions without
> disturbing old usage of the same functions. It would be interesting to
> see a full article written by you explaining in full generality how
> wonderful Lisp is regarding the ability to shadow built-in functions
> and then re-define them to do more than they did before, by your
> proposed DEFMETHOD technique, or by any other technique allowed by CL,
> as appropriate. (Just a suggestion. I have no money to pay you.)
Since I'm not Kent, and since you're broke, I wont write a full
article, but I will explain a couple of places where I've done the
same thing (shadow built-ins).
Example 1. ENOUGH-NAMESTRING with one argument computes the relative
path from *DEFAULT-PATHNAME-DEFAULTS*. In production code, I have
frequently found that programmers were not paying attention to the
value of *DEFAULT-PATHNAME-DEFAULTS*, and that the resulting
relative pathname would be incorrect, or worse yet, correct by
accident (for instance, *default-pathname-defaults* might be the
directory lisp was launched from). I shadowed ENOUGH-NAMESTRING
so that it would require the second argument. This greatly
reduced these kinds of errors. (Sort of software policy control
enforced by the language.)
Example 2. UNWIND-PROTECT does not guarantee protection if
asynchronous process kills or aborts occur. This is a surprise to
most programmers, and doing it right (deferring asynchronous
interrupts around the cleanup) is quite tricky. By replacing the
existing unwind-protect with the tricky version, we increase
reliability. In addition, the software did extensive logging, and
it was useful to know why cleanup was happening. The shadowed
unwind protect took an optional string just before the cleanup
forms (i.e., the first cleanup form could be a string). The macro
recognized this and added an annotation in the log when executing
the form.
Example 3. DIRECTORY is about as random a function as you can find in
Common Lisp. What it takes as an argument, whether it handles
:wild-inferiors, and what it produces as answers varies
considerably among the various lisp vendors. I shadowed DIRECTORY
so that it would do what I consider to be the correct thing. Even
if I'm wrong, it still does the *same* thing on all platforms.
Example 4. Sometimes when writing a COND clause, you'd like to bind
the result of the predicate form during execution of the result
form. There's various ways to do this, but I really like the syntax
that Scheme uses:
(cond ((null element) (error "Element doesn't exist"))
((lookup element table) => (lambda (result) (frob result :using #'foo)))
(t (take-default-action element)))
The `=>' syntax means ``funcall the next thing on the result of
the predicate''. The new macro rewrites the above expression roughly
like this (appropriate renaming is done to avoid name collisions):
(if (null element)
(error "Element doesn't exist")
(let ((result (lookup element table)))
(if result
(frob result :using #'foo)
(take-default-action element))))
In addition, the replacement COND macro warns if there is no
default clause. We often found errors that resulted from
unexpectedly `falling off' the end of a COND, so this ensures that
a `catch-all' clause exists.
Code like this:
(cond ((valid-p x) (do-something))
((too-big-p x) (complain 'too-big x))
((too-small-p x) (complain 'too-small x)))
would be better written as this:
(cond ((valid-p x) (do-something))
((too-big-p x) (complain 'too-big x))
((too-small-p x) (complain 'too-small x))
(t (error "programming error, see a wizard")))
because the error would be thrown immediately rather than having a
NIL accidentally propagated through the system. If NIL *were* the
correct default value, the programmer can easily append (t nil)
From: ··········@YahooGroups.Com
Subject: Re: everything is an object
Date:
Message-ID: <REM-2003sep11-006@Yahoo.Com>
{{Date: Sun, 7 Sep 2003 21:37:40 -0700 (PDT)
From: ·······@ziplip.com
Do you think Common Lisp would be a better language if everything was
an object like in Dylan and Smalltalk ? Even the so-called lesser
languages let you, for example, extend arithmetic operators, etc.
Also, Lisp already has type-tagged values, so little performance
would be lost by making everything an object.}}
The only reason why overloading functions and operators works in C++
and similar languages is a win is because types are associated with
places rather than with data objects, so only kind of data can be in a
place, whose type was declared before compile time, so the compiler can
automatically resolve all overloading, so efficient runtime code gets
generated. Requiring that every place allow only a single type of data
which was declared before compile time is totally contrary to the
philosophy of Lisp.
Objects in the full sense is the right way in Lisp only where there's a
single primary object and everything else is parameters to the
operation to be performed on that object. (For example, a window is an
object, and the x,y location of a click or drag is just a pair of
numbers that modify the meaning of the click or drag.)
Even generic functions make sense only in cases where there are several
very similar data types which can be coerced to each other as needed,
such as numbers used by arithmetic/trigonometric functions.
In most cases, a function should take only one type of data in each
argument position, and if you want to define analagous functions for
different but incompatible types of data (such as numbers vs. vectors
vs. matrices vs. tensors) you should just define two different
functions (for example * for numbers but DOTPROD for vectors and MATMUL
for matrices etc.). I see no value in overloading * for different
operations just because they are vaguely analagous in mathematics. In a
math paper, you can say at the start something like "Let * represent
functional composition" or "Let * represent matrix multiplication" or
"Let * represent the abstract operation of a finite group" etc. and
then throughout the paper it has that special meaning. But doing
something like that in a programming language would be too confusing to
people trying to maintain the program.
··········@YahooGroups.Com writes:
> In most cases, a function should take only one type of data in each
> argument position, and if you want to define analagous functions for
> different but incompatible types of data (such as numbers vs. vectors
> vs. matrices vs. tensors) you should just define two different
> functions (for example * for numbers but DOTPROD for vectors and MATMUL
> for matrices etc.). I see no value in overloading * for different
> operations just because they are vaguely analagous in mathematics. In a
> math paper, you can say at the start something like "Let * represent
> functional composition" or "Let * represent matrix multiplication" or
> "Let * represent the abstract operation of a finite group" etc. and
> then throughout the paper it has that special meaning. But doing
> something like that in a programming language would be too confusing to
> people trying to maintain the program.
In maths they've got the same notation, and are of the same kind of
operation. What's more, there are isomorphisms between most sets that
makes these operations IDENTICAL! So why would you not write them all
as * in Lisp?
Or why would you not distinguish in Lisp nat*, int*, rat*, rea*, com*,
ham*, etc?
Now, when you want to speak of bulldozers crossing houses, I would
agree that you should not denote this kind of events with *.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.