Hi,
Why can't we define methods within labels form?
(defun foo ()
(labels
((defmethod bar ((s string))
t)
(defmethod bar ((s t))
nil))
(bar '3)))
(foo)
[Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
Thanks.
--
Kamen TOMOV
Kamen TOMOV wrote:
> Hi,
>
> Why can't we define methods within labels form?
Well, cause that's not what labels does. Labels is a lot lower level
than the CLOS object system. Labels just defines lexically scoped
bindings between the function-slot of a symbol and a function body.
However, you can certainly roll your own.
Something like this (mostly untested):
(defmacro with-method ((name args &body method-body) &body body)
`(unwind-protect
(progn
(defmethod ,name ,args ,@method-body)
,@body)
(remove-method
(symbol-function ',name)
(find-method (symbol-function ',name)
nil
(mapcar (lambda (arg)
(find-class
(if (listp arg)
(second arg)
t)))
',args)))))
(defmacro with-methods ((&rest methods) &body body)
(if methods
`(with-method ,(first methods)
(with-methods ,(rest methods)
,@body))
`(progn ,@body)))
(with-methods ((foo (x) (+ x 1))
(bar (y) (- y 1)))
(list (foo 3)
(bar 3)))
Note: this does not handle method qualifiers like :after and :before.
Justin Dubs
On Thu, Feb 23 2006, ······@gmail.com wrote:
>> Why can't we define methods within labels form?
>
> Well, cause that's not what labels does. Labels is a lot lower
> level than the CLOS object system. Labels just defines lexically
> scoped bindings between the function-slot of a symbol and a function
> body.
How is it possible CLOS not to be low level as everything is an object
in CL AFAIK?
Thanks you very much for your code suggestion.
--
Kamen TOMOV
Kamen TOMOV wrote:
> On Thu, Feb 23 2006, ······@gmail.com wrote:
> >> Why can't we define methods within labels form?
> >
> > Well, cause that's not what labels does. Labels is a lot lower
> > level than the CLOS object system. Labels just defines lexically
> > scoped bindings between the function-slot of a symbol and a function
> > body.
>
> How is it possible CLOS not to be low level as everything is an object
> in CL AFAIK?
Probably because any given object system is limited, just like perhaps
any program's model is.
One criticism is that Lisp has "seams" between its OOP and
not-so-modifiably-OOP historical parts, like a city which has some
parts where you can see old architecture/materials from previous
societies. But I think Lisp was created for the needs of multiple
interests, not to mention that it had finite time and people. (Plus,
Alan Kay recently pointed out that commercialization froze Smalltalk
innovation; and I believe McCarthy claimed the same about Lisp at the
recent ILC too. This may not just apply to these languages; Alan argued
that the entire computing industry has anti-innovation pressures.)
(Keep in mind all this is just my current guess, and I'm just musing.)
Tayssir
Tayssir John Gabbour wrote:
> Kamen TOMOV wrote:
>
>>On Thu, Feb 23 2006, ······@gmail.com wrote:
>>
>>>>Why can't we define methods within labels form?
>>>
>>>Well, cause that's not what labels does. Labels is a lot lower
>>>level than the CLOS object system. Labels just defines lexically
>>>scoped bindings between the function-slot of a symbol and a function
>>>body.
>>
>>How is it possible CLOS not to be low level as everything is an object
>>in CL AFAIK?
>
> Probably because any given object system is limited, just like perhaps
> any program's model is.
>
> One criticism is that Lisp has "seams" between its OOP and
> not-so-modifiably-OOP historical parts, like a city which has some
> parts where you can see old architecture/materials from previous
> societies.
After Common Lisp / CLOS, EuLisp and Dylan were two Lisp dialects that
were designed to be object-oriented (similar to the CLOS model) from the
ground up.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Sat, Feb 25 2006, Tayssir John Gabbour wrote:
> Probably because any given object system is limited, just like
> perhaps any program's model is.
>
> One criticism is that Lisp has "seams" between its OOP and
> not-so-modifiably-OOP historical parts, like a city which has some
> parts where you can see old architecture/materials from previous
> societies. But I think Lisp was created for the needs of multiple
> interests, not to mention that it had finite time and people.
I enjoy very much the OOP model developed around the generic
functions. It brings power, so great that I don't see a way away from
Lisp.
> (Plus, Alan Kay recently pointed out that commercialization froze
> Smalltalk innovation; and I believe McCarthy claimed the same about
> Lisp at the recent ILC too. This may not just apply to these
> languages; Alan argued that the entire computing industry has
> anti-innovation pressures.)
They are so right about the commercialization of the computing. Alan
Kay is right to call it a pop culture.
Nevertheless, I do not understand why there would be anti-innovation
pressures. Perhaps the masses are too slow to adopt intelligent
technologies. It took them almost 50 years to find value in the OOP
concept. We can also add to it the fact that the big companies need to
be selling their pitiful products.
--
Kamen TOMOV
Kamen TOMOV wrote:
> On Sat, Feb 25 2006, Tayssir John Gabbour wrote:
> > (Plus, Alan Kay recently pointed out that commercialization froze
> > Smalltalk innovation; and I believe McCarthy claimed the same about
> > Lisp at the recent ILC too. This may not just apply to these
> > languages; Alan argued that the entire computing industry has
> > anti-innovation pressures.)
>
> They are so right about the commercialization of the computing. Alan
> Kay is right to call it a pop culture.
I agree with some of what Wikipedia says re: pop culture.
"Popular culture has multiple origins. A principal source is the set of
industries that make profit by inventing and promulgating cultural
material."
http://en.wikipedia.org/wiki/Popular_culture
The set of industries affecting the programming world include
Microsoft, Sun and Google. Occasionally they may take a look at
countercultural eddies like Lisp, scrutinizing them to see whether
they're effective investments.
"To take the example of popular music, it is not the case that the
music industry can impose any product they wish. In fact, highly
popular types of music have often first been elaborated in small,
counter-cultural circles (punk rock or rap would be two examples)."
> Nevertheless, I do not understand why there would be anti-innovation
> pressures. Perhaps the masses are too slow to adopt intelligent
> technologies. It took them almost 50 years to find value in the OOP
> concept. We can also add to it the fact that the big companies need to
> be selling their pitiful products.
I suspect the problem is that big computing companies have strong
anti-innovation incentives (as well as pro-innovation ones). They use
tools such as patents, copyright and secrecy to lock up technologies in
order to monopolize innovations on them (even though fundamental
innovations are driven by heavy government subsidy). "Kicking out the
ladder from beneath them."
Also, there seems to be pressure on the government to reduce blue-sky
funding for more practical short-term innovations ("deliverables")
which most benefit established companies.
http://www.nytimes.com/2005/04/02/technology/02darpa.html?ei=5088&en=6ca69efefeb9c0dc&ex=1270094400&adxnnl=1&partner=rssnyt&pagewanted=1&adxnnlx=1140995055-GcmZ3ktb7EK7dEb0C1bnpg
Further, big companies view innovations just like other companies do --
as investments. For example, if the opportunity cost of investing in
Lisp is too great, they won't pursue it. Sound, sane business.
This is why many people are out to lower that cost, by undertaking the
marketing costs and risks. At times, some Lisp concepts come close
enough within reach for a Sun to grasp them:
"And you're right: we were not out to win over the Lisp programmers; we
were after the C++ programmers. We managed to drag a lot of them about
halfway to Lisp. Aren't you happy?"
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html
Tayssir
I like most the part that says: "popular culture tends to be
superficial".
Even though Lisp offers very powerfull programming environment, it is
not popular enough and AFAIK the reason is neither in the patents nor
in the secrecy or in locked up technologies. Perhaps silence is what
the big companies's most efective weapon is. As a result even the GNU
system, which is mainly a democratic incentive is with so little Lisp
in it.
"Java being halfway drag between C++ and Lisp" - Java VCs, pay
attention to what your commander-in-chief, Guy Steele, says!
--
Kamen TOMOV
Kamen TOMOV <·····@evrocom.net> writes:
> "Java being halfway drag between C++ and Lisp" - Java VCs, pay
> attention to what your commander-in-chief, Guy Steele, says!
He means: "Java is halfway drag FROM C++ TO Lisp".
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
Kamen TOMOV <·····@evrocom.net> writes:
> Hi,
>
> Why can't we define methods within labels form?
>
> (defun foo ()
> (labels
> ((defmethod bar ((s string))
> t)
> (defmethod bar ((s t))
> nil))
> (bar '3)))
> (foo)
>
> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
I guess because the the Hyperspec says so:
===
flet, labels, and macrolet define local *functions* and *macros*, and
execute forms using the local definitions.
===
(http://www.lispworks.com/documentation/HyperSpec/Body/s_flet_.htm)
--
vedm
Kamen TOMOV wrote:
> Hi,
>
> Why can't we define methods within labels form?
>
> (defun foo ()
> (labels
> ((defmethod bar ((s string))
> t)
> (defmethod bar ((s t))
> nil))
> (bar '3)))
> (foo)
>
> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
Language lawyer's response: because it's not specified.
Language designer's response: because it's hard to give this a
reasonable semantics.
Something similar was actually attempted to be specified for ANSI Common
Lisp, but got rejected because it was hard to figure out the details.
See http://www.lispworks.com/documentation/HyperSpec/Issues/iss181_w.htm
for a discussion.
BTW, your code example suggests that you using try-and-error as your
approach to learn Common Lisp. It may be better to use a good tutorial,
and it's probably also a good idea to spend some time on getting
comfortable with reading the HyperSpec, so that you can answer such
questions for yourself.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Thu, Feb 23 2006, Pascal Costanza wrote:
> Kamen TOMOV wrote:
>> Hi,
>> Why can't we define methods within labels form?
>> (defun foo ()
>> (labels
>> ((defmethod bar ((s string))
>> t)
>> (defmethod bar ((s t))
>> nil))
>> (bar '3)))
>> (foo)
>> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
>
> Language lawyer's response: because it's not specified.
Thanks you. Actually this is the answer I was looking for.
> Language designer's response: because it's hard to give this a
> reasonable semantics.
The fact that there has been a discussion about it and because the
idea to put methods there came naturally to me means (for me) that
there is some semantics. Initially, it seemed a good idea in the
application that I am writing. Eventually it turned out that the
method I wanted to define is one that I would have moved out of LABELS
even if it was possible for it to work from there.
> Something similar was actually attempted to be specified for ANSI
> Common Lisp, but got rejected because it was hard to figure out the
> details. See
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss181_w.htm
> for a discussion.
It is interesting. I suppose a generic labels would allow the freedom
to use that construct.
> BTW, your code example suggests that you using try-and-error as your
> approach to learn Common Lisp. It may be better to use a good
> tutorial, and it's probably also a good idea to spend some time on
> getting comfortable with reading the HyperSpec, so that you can
> answer such questions for yourself.
I have read a good tutorial - Peter Siebel's one was perfect for me. I
have been in the programming's business (unfortunately with Algol
derived languages) for quite a lot of time and for me the interaction
with the Lisp machine is the best way to learn currently. The best
part is that the community is very cooperative and I am thankful :-)
Regards,
--
Kamen TOMOV
Hi,
Pascal Costanza <··@p-cos.net> writes:
> Kamen TOMOV wrote:
>> Hi,
>> Why can't we define methods within labels form?
>> (defun foo ()
>> (labels
>> ((defmethod bar ((s string))
>> t)
>> (defmethod bar ((s t))
>> nil))
>> (bar '3)))
>> (foo)
>> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
>
> [snip]
>
> BTW, your code example suggests that you using try-and-error as your
> approach to learn Common Lisp.
From what did you derive that?
The reason for me asking is that I find myself in that try-and-error
trap from time to time and I'd like to have a clue when I'm getting
near to it thus standing a better chance to avoid it.
Regards,
Stefan
--
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.
Stefan Kamphausen wrote:
> Hi,
>
> Pascal Costanza <··@p-cos.net> writes:
>
>
>>Kamen TOMOV wrote:
>>
>>>Hi,
>>>Why can't we define methods within labels form?
>>>(defun foo ()
>>> (labels
>>> ((defmethod bar ((s string))
>>> t)
>>> (defmethod bar ((s t))
>>> nil))
>>> (bar '3)))
>>>(foo)
>>> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
>>
>>[snip]
>>
>>BTW, your code example suggests that you using try-and-error as your
>>approach to learn Common Lisp.
>
> From what did you derive that?
Having 'defmethod forms as the defining elements for a 'labels form is a
complete mismatch of the roles of the respective operators. Defining
forms (def... ...) are always in evaluated positions.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Stefan Kamphausen wrote:
>> Hi,
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>>Kamen TOMOV wrote:
>>>
>>>>Hi,
>>>>Why can't we define methods within labels form?
>>>>(defun foo ()
>>>> (labels
>>>> ((defmethod bar ((s string))
>>>> t)
>>>> (defmethod bar ((s t))
>>>> nil))
>>>> (bar '3)))
>>>>(foo)
>>>> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
>>>
>>>[snip]
>>>
>>>BTW, your code example suggests that you using try-and-error as your
>>> approach to learn Common Lisp.
>> From what did you derive that?
>
> Having 'defmethod forms as the defining elements for a 'labels form is
> a complete mismatch of the roles of the respective operators. Defining
> forms (def... ...) are always in evaluated positions.
Obviously, Kamen meant:
(defun foo ()
(methods ((bar ((s string)) t)
(bar ((s t)) nil))
(bar '3)))
(foo) --> nil ; expected result
(bar '3) --> error: undefined function BAR ; expected result
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
On Fri, Feb 24 2006, Pascal Bourguignon wrote:
>>>>[snip]
>>>>
>>>>BTW, your code example suggests that you using try-and-error as
>>>>your approach to learn Common Lisp.
>>> From what did you derive that?
>>
>> Having 'defmethod forms as the defining elements for a 'labels form
>> is a complete mismatch of the roles of the respective
>> operators. Defining forms (def... ...) are always in evaluated
>> positions.
>
> Obviously, Kamen meant:
>
> (defun foo ()
> (methods ((bar ((s string)) t)
> (bar ((s t)) nil))
> (bar '3)))
>
> (foo) --> nil ; expected result
> (bar '3) --> error: undefined function BAR ; expected result
Yeah, that's right. Thanks. It is hard to write code that one knows it
won't work :-)
--
Kamen TOMOV