verec wrote:
> I'm again a bit confused. Basically, what I want to do, is to be
> able to define a single "function" name, reused (ie: "redefined")
> for various combinations of arguments such that I can:
>
> (draw conclusion)
> (draw bank-account)
> (draw shape)
>
Adding to what others have said, overloading in the C++ sense is
something that is always decidable at compile-time. In CL, this means
that DRAW would typically be a MACRO, not a generic function.
SETF is a macro that does various things based on what kind of PLACE it
is given. It is also extensible. If is possible to create a framework
for overloading ala SETF for DRAW by using some macrology, but you would
typically have to give a bit more information than what you give above
so that the correct draw is statically decidable.
For example: (draw (conclusion c)) where DRAW is a macro could "resolve"
to (DRAW-CONCLUSION C) while (draw (on table) (with pencil) (a picture))
could expand to (DRAW-GRAPHIC :TABLE TABLE :PENCIL PENCIL :A PICTURE).
You just have to provide a decent amount of macrology.
astor
On Thu, 03 Nov 2005 18:01:10 +0100, Alexander Kjeldaas
<··········@fast.no> wrote:
> verec wrote:
>> I'm again a bit confused. Basically, what I want to do, is to be
>> able to define a single "function" name, reused (ie: "redefined")
>> for various combinations of arguments such that I can:
>> (draw conclusion)
>> (draw bank-account)
>> (draw shape)
>>
>
>
> Adding to what others have said, overloading in the C++ sense is
> something that is always decidable at compile-time. In CL, this means
> that DRAW would typically be a MACRO, not a generic function.
>
> SETF is a macro that does various things based on what kind of PLACE it
> is given. It is also extensible. If is possible to create a framework
> for overloading ala SETF for DRAW by using some macrology, but you would
> typically have to give a bit more information than what you give above
> so that the correct draw is statically decidable.
>
> For example: (draw (conclusion c)) where DRAW is a macro could "resolve"
> to (DRAW-CONCLUSION C) while (draw (on table) (with pencil) (a picture))
> could expand to (DRAW-GRAPHIC :TABLE TABLE :PENCIL PENCIL :A PICTURE).
>
> You just have to provide a decent amount of macrology.
>
> astor
CLOS defmehods are as definetive as C++. They are run at runtime.
SETF is a bit more complicated than what you are used too from c++.
Using defmaco requires a level of knowlege you don't have.
Putting it all into a email is futile and pointless..
I feel Peter Seiblel in his book http:/www.gigamonkeys.com/book/
describes the basic Lisp process fine. I would start there.
I am aware that you are a estabished programmer and that you
are working on a xword puzzle now. I have said before (and
will say again) learn your language. I say this from personal
experience. This is not a easy language to learn, but it is worth it.
Good luck!
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 2005-11-03 17:54:15 +0000, "John Thingstad" <··············@chello.no> said:
> On Thu, 03 Nov 2005 18:01:10 +0100, Alexander Kjeldaas
> <··········@fast.no> wrote:
>
>> verec wrote:
>>> I'm again a bit confused. Basically, what I want to do, is to be
>>> able to define a single "function" name, reused (ie: "redefined")
>>> for various combinations of arguments such that I can:
>>> (draw conclusion)
>>> (draw bank-account)
>>> (draw shape)
>>>
>>
>>
>> Adding to what others have said, overloading in the C++ sense is
>> something that is always decidable at compile-time. In CL, this means
>> that DRAW would typically be a MACRO, not a generic function.
Yep. I had come to the same conclusion.
I have been starting along these lines (low level plumbing):
;;; poly is a simple struct whose only purpose is to serve as
;;; a seed for the defpoly (semic) macro to refer to the map that
;;; maps a symbol to lamda in a context free way. Such a context,
;;; precisely, is to be provided by further structs that :include
;;; poly.
(defstruct poly
(map (make-hash-table)))
(defun poly-locate (symbol poly)
"returns the lambda associated with symbol in poly, or nil"
(let ((map (poly-map poly)))
(gethash symbol map)))
(defun poly-bind (fn symbol poly)
"binds fn to symbol in the context of poly"
(let ((map (poly-map poly)))
(setf (gethash symbol map) fn)))
With the idea of a
(defmacro defpoly ...) coming to crown the whole thing.
But I must explore this a lot more. At the moment the path I'm
thinking of would involve macro-expansion twice, once when creating
the poly, and once when the resulting poly is itself used at call time, ie:
(defpoly locate (grid x y) ... ) ;; for the first macro use, and
(defun some-code ()
...
(locate grid 3 5)) ;; ``locate'' would be a macro here too
in other words, defpoly would be a macro generating a deferred macro...
>> SETF is a macro that does various things based on what kind of PLACE it
>> is given. It is also extensible. If is possible to create a
>> framework for overloading ala SETF for DRAW by using some macrology,
>> but you would typically have to give a bit more information than what
>> you give above so that the correct draw is statically decidable.
>>
>> For example: (draw (conclusion c)) where DRAW is a macro could
>> "resolve" to (DRAW-CONCLUSION C) while (draw (on table) (with pencil)
>> (a picture)) could expand to (DRAW-GRAPHIC :TABLE TABLE :PENCIL PENCIL
>> :A PICTURE).
>>
>> You just have to provide a decent amount of macrology.
This, I am afraid, you are right about! Where I equate "decent" with
non trivial and more than half a page of code :-(
> CLOS defmehods are as definetive as C++. They are run at runtime.
> SETF is a bit more complicated than what you are used too from c++.
> Using defmaco requires a level of knowlege you don't have.
> Putting it all into a email is futile and pointless..
> I feel Peter Seiblel in his book http:/www.gigamonkeys.com/book/
> describes the basic Lisp process fine. I would start there.
I've been on his site quite a few times already, and I wished there
was ... a volume two! :-)
> I am aware that you are a estabished programmer and that you
> are working on a xword puzzle now. I have said before (and
> will say again) learn your language. I say this from personal
> experience. This is not a easy language to learn, but it is worth it.
If I didn't beleive it was worth it, I wouldn't have started along
this path.
Regarding this "polysemic overloading" stuff, the more I think about
it, the more I'm convinced that this is doable ... and that I shouldn't
bother and go the full CLOS route instead.
I may carry on on this for a few days as a "learning exercise" in
"double prong macro hackery", but I don't intend to pursue it more
than that.
That said, between the CLOS OO way, on one hand, and the Schemish
functional way, on the other hand, what I've read about Lisp here
or there seemed to hint at yet another "thinking approach" which,
so far, still eludes me.
Many Thanks to all.
--
JFB (defun is more fun than define is fine)