From: Pascal Bourguignon
Subject: Re: defgeneric, defstruct and no CLOS
Date: 
Message-ID: <87hdavmxhn.fsf@thalassa.informatimago.com>
verec <·····@mac.com> writes:
> So, my question realy is, assuming both:
> (defstruct grid ...) and
> (defstruct dict ...)
>
> how would I go about
>
> (defun load (grid) ... ) and
>
> (defun load (dict) ... ) and while I'm there, not shadow the
>
> standard cl::load ?

standard cl::load or standard cl::read are perfectly good:

(defstruct grid rows cols)
(defstruct dict words)

(let ((grid (make-grid :rows 15 :cols 10))
      (dict (make-dict :words '("suggests""using""packages""as"
                                "a""means""of""encapsulation"))))
  (with-open-file (out "dict.data" :direction :output 
                   :if-does-not-exist :create :if-exists :supersede)
     (print dict out))
  (with-open-file (out "grid.data" :direction :output 
                   :if-does-not-exist :create :if-exists :supersede)
     (print grid out)))

;; Now:

(defparameter my-grid (with-open-file (in "grid.data") (read in)))
(defparameter my-dict (with-open-file (in "dict.data") (read in)))

But what cood would it be to call (load grid) if the file contains a dict?
That's why you call load or read, and you get what value there is in the file.
You've not taken the red pill yet. ;-)


-- 
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"

From: verec
Subject: Re: defgeneric, defstruct and no CLOS
Date: 
Message-ID: <43685dbd$0$38043$5a6aecb4@news.aaisp.net.uk>
On 2005-11-02 05:26:12 +0000, Pascal Bourguignon <····@mouse-potato.com> said:

>> So, my question realy is, assuming both:
>> (defstruct grid ...) and
>> (defstruct dict ...)
>> 
>> how would I go about
>> (defun load (grid) ... ) and
>> (defun load (dict) ... ) and while I'm there, not shadow the
>> standard cl::load ?
> 
> standard cl::load or standard cl::read are perfectly good:

[snip]

> ;; Now:
> 
> (defparameter my-grid (with-open-file (in "grid.data") (read in)))
> (defparameter my-dict (with-open-file (in "dict.data") (read in)))

In the first part you didn't quote, I had written:
> Obviously, I can define:
> (defun load-dict (dict-name) ...)
> and
> (defun load-grid (grid-name) ...)

You are just proposing an alternate way to *not* define "load" or "load-dict"

In a second part you didn't quote, I had written:

> (defun locate (grid x y) ...
> ...
> (defun locate (dict word) ...

Which was meant to emphasize that my intention was to take advantage
of natural language verbs polysmey to mean different things at different
times (in different contexts).

This may not be the Lisp way. And that's why I asked a double question:
1. is it possible to do "overloading" in Lisp and
2. whether it is possible or not, is it compatible with the Lisp way
   and if it is not, what would be the Lisp way.

So far, I construe your answers as:
1. I could use packages, but that's ugly (and I would concur)
2. "overloading" is not the Lisp way

That's fine with me. But while most answers are of the form
"don't do this", few, if any, are of the form "do that, instead"
(your transforming my initial (defun load-dict ()) into
(defparameter my-dict ...) doesn't really count as another
way of _thinking_, does it?)

> But what cood would it be to call (load grid) if the file contains a dict?

That's very true, but not exactly relevant to the question ...

> That's why you call load or read, and you get what value there is in the file.

Don't focus on "load" as such. Tell me the same story, but using "locate"
this time, as an example. That way it won't clash with any preconceived
notion.

> You've not taken the red pill yet. ;-)

I'd rather have belgian chocolate :-)
-- 
JFB  (defun is more fun than define is fine)
From: Pascal Bourguignon
Subject: Re: defgeneric, defstruct and no CLOS
Date: 
Message-ID: <878xw7m3rv.fsf@thalassa.informatimago.com>
verec <·····@mac.com> writes:

> On 2005-11-02 05:26:12 +0000, Pascal Bourguignon <····@mouse-potato.com> said:
>
>>> So, my question realy is, assuming both:
>>> (defstruct grid ...) and
>>> (defstruct dict ...)
>>> how would I go about
>>> (defun load (grid) ... ) and
>>> (defun load (dict) ... ) and while I'm there, not shadow the
>>> standard cl::load ?
>> standard cl::load or standard cl::read are perfectly good:
>
> [snip]
>
>> ;; Now:
>> (defparameter my-grid (with-open-file (in "grid.data") (read in)))
>> (defparameter my-dict (with-open-file (in "dict.data") (read in)))
>
> In the first part you didn't quote, I had written:
>> Obviously, I can define:
>> (defun load-dict (dict-name) ...)
>> and
>> (defun load-grid (grid-name) ...)
>
> You are just proposing an alternate way to *not* define "load" or "load-dict"

Yes.


> In a second part you didn't quote, I had written:
>
>> (defun locate (grid x y) ...
>> ...
>> (defun locate (dict word) ...
>
> Which was meant to emphasize that my intention was to take advantage
> of natural language verbs polysmey to mean different things at different
> times (in different contexts).

You could have a look at Pascal Costanza's ContextL.  
But Lisp is not a natural language. 

If you want ambiguity, and resolving ambiguity with context and
semantics, you'll have to design a new language.


> This may not be the Lisp way. And that's why I asked a double question:
> 1. is it possible to do "overloading" in Lisp and

Everything's possible.  It's possible.  We've done it in c.l.l. a few
months ago when we designed some macros to be able to write overloaded
methods like in C++ with even different number of arguments.


> 2. whether it is possible or not, is it compatible with the Lisp way
>    and if it is not, what would be the Lisp way.

Lisp accepts all kind of torture.  If it needed by your problem at
hand, go ahead.


> So far, I construe your answers as:
> 1. I could use packages, but that's ugly (and I would concur)

Not really.  You only change one character in the names:

   grid-load     vs.   grid:load
   dict-load     vs.   dict:load


> 2. "overloading" is not the Lisp way

As I said, overloading is not in CLHS glossary.  This is not a CLOS
notion.  You can have dispatch based on the type of the arguments, and
you can have it automatically with generic functions, but the notion
of overloading is not native.


> [...]

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

In a World without Walls and Fences, 
who needs Windows and Gates?