What do you think about function overloading per valence and did some
of the previous dialects of lisp had it? I'm talking only about
completely different funcitons not &optional, &args ...
>(def risk-rate (x y) (/ xy))
>(def risk-rate (x y z) (/ (+ x z) y))
>(+ (risk-rate 3 4 5) (risk-rate 2 3))
..
It feels convenient to me but I'm interested what kind of problems it
could bring on.
cheers
bobi
From: Kent M Pitman
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <uprolkleq.fsf@nhplace.com>
Slobodan Blazeski <·················@gmail.com> writes:
> What do you think about function overloading per valence and did some
> of the previous dialects of lisp had it?
Not that I know of, but I could have easily missed some. There have
been many Lisp dialects.
Early Dylan, when it was still lispy, offered generic functions by
default, but generic functions are not overloads. I regard overloads
as unprincipled and semantics-free.
> I'm talking only about
> completely different funcitons not &optional, &args ...
There's no &args that I'm familiar with. :)
> >(def risk-rate (x y) (/ xy))
>
> >(def risk-rate (x y z) (/ (+ x z) y))
>
> >(+ (risk-rate 3 4 5) (risk-rate 2 3))
> ..
> It feels convenient to me but I'm interested what kind of problems it
> could bring on.
I'm uncertain whether you're referring to DEFUN here and just misnaming it
or if you're actually talking about making a new operator with this effect.
Certainly anyone can write a new function DEF with the semantics you suggest.
If your question boils down to whether anyone has ever done that, I don't
know. But if you're asking whether the DEFUN-equivalent in any prior language
has ever done this, and whether DEFUN should do this in CL, that's more
complicated and is the question I'll proceed to answer.
It's a very common design error to see a space that is defined totally and
where the "total" part is mistaken for "partly undefined". The problem is
that this is an incompatible change in a language that is designed around
interactive design and where this already has a useful meaning.
[Aside: People are always trying to do the same with EQUAL, assuming that it
is undefined on newly defined classes rather than assuming it's well-defined
and so wishing they could give their own definitions. It's not an empty
space there either, and again would be an incompatible change. That's not
to say that a customizable generic equality function is not possible; it's
just to say that it's incompatible with what the already extant EQUAL
function does, and would have to either take a different name or redefine
EQUAL with consequences that are both in terms of compatibility and loss of
useful functionality (in exchange for other functionality that you allege
to be useful as well--I'm not saying there's no benefit, I'm just emphasizing
that there is a clear loss in the process as well). But back to DEF(UN)...]
The primary problem it raises is that it already meant "I want to redefine
the function."
Consider the following abstract interaction:
I offer to sell you book X for $3.
I offer to sell you book X for $30.
If you were designing the English language, or perhaps just the subdialect
used by contract law, suggest that it would be fun to have this sequence of
statements be a synonym for:
I offer to sell you book X for $3 or $30.
However, this makes it hard to do the quite obvious thing of revising a
statement with another. It also makes it hard to understand
(defun foo (x) x)
as
(setf (symbol-function 'foo) (function (lambda (x) x)))
The reason that DEFMETHOD doesn't do the same thing is that it's designed
around a specific philosophy that says "when you want to do a redefinition,
you'll need to go to special trouble to do so." You can do FMAKUNBOUND for
example, or a series of specific undefinitions of all the methods. But it's
way more complicated because the ordinary paradigm of DEFMETHOD is to just
change one method.
I also didn't get into the issue of method congruency, but this plays
in here too. I really like that particular feature of CL, which is
not present in C++, because it encourages people not to do arbitrary
overloading of functions that have no relation to one another--it
means you have to think about why and how functions relate to one
another before you just jam random argument patterns together.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>
> > What do you think about function overloading per valence and did some
> > of the previous dialects of lisp had it?
>
> Not that I know of, but I could have easily missed some. There have
> been many Lisp dialects.
There's precedence for it in some of the built-in functions. - and /
behave differently depending on whether they're called with 1 or more
than 1 argument.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Kent M Pitman
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <ur690i02l.fsf@nhplace.com>
Barry Margolin <······@alum.mit.edu> writes:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> > Slobodan Blazeski <·················@gmail.com> writes:
> >
> > > What do you think about function overloading per valence and did some
> > > of the previous dialects of lisp had it?
> >
> > Not that I know of, but I could have easily missed some. There have
> > been many Lisp dialects.
>
> There's precedence
("precedent")
> for it in some of the built-in functions. - and /
> behave differently depending on whether they're called with 1 or more
> than 1 argument.
Although this is something of a grudging accommodation to Mathematics,
which has classically overloaded the - operation.
Why we overloaded / is harder to defend, and I won't try. I'll just say
I think it was a terrible idea and leave it at that.
For any thing like this you can find in the language, there are probably
problems that have come up with someone playing with APPLY and variable
length arglists and falling into a number of arguments that surprised them
unpleasantly in the way the apparent degenerate case didn't work in the
obvious way.
Bottom line: I don't favor overloading as a language construct.
Although a few details of the congruency rules seem wrong to me, I
think the general notion of having congruency constraints is really
quite cool and encourages a style that leads to better structured
programs and more easily extensible programs, to programs that are
more self-documenting, and to fewer program errors.
From: Pascal J. Bourguignon
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <7cwsit8ah9.fsf@pbourguignon.anevia.com>
Slobodan Blazeski <·················@gmail.com> writes:
> What do you think about function overloading per valence and did some
> of the previous dialects of lisp had it? I'm talking only about
> completely different funcitons not &optional, &args ...
>
>>(def risk-rate (x y) (/ xy))
>
>>(def risk-rate (x y z) (/ (+ x z) y))
>
>>(+ (risk-rate 3 4 5) (risk-rate 2 3))
> ..
> It feels convenient to me but I'm interested what kind of problems it
> could bring on.
(defun risk-rate (x y &optional (tau 1)) (* tau (/ x y)))
(risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
--
__Pascal Bourguignon__
On Aug 7, 11:01 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > What do you think about function overloading per valence and did some
> > of the previous dialects of lisp had it? I'm talking only about
> > completely different funcitons not &optional, &args ...
>
> >>(def risk-rate (x y) (/ xy))
>
> >>(def risk-rate (x y z) (/ (+ x z) y))
>
> >>(+ (risk-rate 3 4 5) (risk-rate 2 3))
> > ..
> > It feels convenient to me but I'm interested what kind of problems it
> > could bring on.
>
> (defun risk-rate (x y &optional (tau 1)) (* tau (/ x y)))
>
> (risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
How about &optional defining all valences? Like
(defun risk-rate (a b &optional c d ...) <=>
(progn
(defun risk-rate (a b) ..)
(defun risk-rate (a b c) ..)
(defun risk-rate (a b c d) ..))
>
> --
> __Pascal Bourguignon__
On Aug 7, 11:37 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Aug 7, 11:01 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Slobodan Blazeski <·················@gmail.com> writes:
> > > What do you think about function overloading per valence and did some
> > > of the previous dialects of lisp had it? I'm talking only about
> > > completely different funcitons not &optional, &args ...
>
> > >>(def risk-rate (x y) (/ xy))
>
> > >>(def risk-rate (x y z) (/ (+ x z) y))
>
> > >>(+ (risk-rate 3 4 5) (risk-rate 2 3))
> > > ..
> > > It feels convenient to me but I'm interested what kind of problems it
> > > could bring on.
>
> > (defun risk-rate (x y &optional (tau 1)) (* tau (/ x y)))
>
> > (risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
>
> How about &optional defining all valences? Like
>
> (defun risk-rate (a b &optional c d ...) <=>
> (progn
> (defun risk-rate (a b) ..)
> (defun risk-rate (a b c) ..)
> (defun risk-rate (a b c d) ..))
>
The semantics would be different from those of CL. For example, in CL
I can write
(defun dummy (&optional x)
(if x ...))
with your approach, I couldn't do that, and IMHO that would miss the
point of &optional...
>
> > --
> > __Pascal Bourguignon__
>
>
On Aug 7, 12:36 pm, Alessio Stalla <·············@gmail.com> wrote:
> On Aug 7, 11:37 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
>
>
> > On Aug 7, 11:01 am, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Slobodan Blazeski <·················@gmail.com> writes:
> > > > What do you think about function overloading per valence and did some
> > > > of the previous dialects of lisp had it? I'm talking only about
> > > > completely different funcitons not &optional, &args ...
>
> > > >>(def risk-rate (x y) (/ xy))
>
> > > >>(def risk-rate (x y z) (/ (+ x z) y))
>
> > > >>(+ (risk-rate 3 4 5) (risk-rate 2 3))
> > > > ..
> > > > It feels convenient to me but I'm interested what kind of problems it
> > > > could bring on.
>
> > > (defun risk-rate (x y &optional (tau 1)) (* tau (/ x y)))
>
> > > (risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
>
> > How about &optional defining all valences? Like
>
> > (defun risk-rate (a b &optional c d ...) <=>
> > (progn
> > (defun risk-rate (a b) ..)
> > (defun risk-rate (a b c) ..)
> > (defun risk-rate (a b c d) ..))
>
> The semantics would be different from those of CL. For example, in CL
> I can write
>
> (defun dummy (&optional x)
> (if x ...))
>
> with your approach, I couldn't do that, and IMHO that would miss the
> point of &optional...
I don't see what's the problem since
(defun dummy (&optional x)
(if x 1 2)) <=>
(progn
(defun dummy ()
(let (x) // gensymed x
(if x 1 2)))
(defun dummy (x)
(if x 1 2)))
On Aug 7, 2:26 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Aug 7, 12:36 pm, Alessio Stalla <·············@gmail.com> wrote:
>
>
>
> > On Aug 7, 11:37 am, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > On Aug 7, 11:01 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Slobodan Blazeski <·················@gmail.com> writes:
> > > > > What do you think about function overloading per valence and did some
> > > > > of the previous dialects of lisp had it? I'm talking only about
> > > > > completely different funcitons not &optional, &args ...
>
> > > > >>(def risk-rate (x y) (/ xy))
>
> > > > >>(def risk-rate (x y z) (/ (+ x z) y))
>
> > > > >>(+ (risk-rate 3 4 5) (risk-rate 2 3))
> > > > > ..
> > > > > It feels convenient to me but I'm interested what kind of problems it
> > > > > could bring on.
>
> > > > (defun risk-rate (x y &optional (tau 1)) (* tau (/ x y)))
>
> > > > (risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
>
> > > How about &optional defining all valences? Like
>
> > > (defun risk-rate (a b &optional c d ...) <=>
> > > (progn
> > > (defun risk-rate (a b) ..)
> > > (defun risk-rate (a b c) ..)
> > > (defun risk-rate (a b c d) ..))
>
> > The semantics would be different from those of CL. For example, in CL
> > I can write
>
> > (defun dummy (&optional x)
> > (if x ...))
>
> > with your approach, I couldn't do that, and IMHO that would miss the
> > point of &optional...
>
> I don't see what's the problem since
> (defun dummy (&optional x)
> (if x 1 2)) <=>
>
> (progn
> (defun dummy ()
> (let (x) // gensymed x
> (if x 1 2)))
> (defun dummy (x)
> (if x 1 2)))
Well I didn't infer that from your previous post :)
Anyhow, the point is, IMHO, that CL lambda list handling with its
&optional, &key, &rest is actually more powerful than function
overloading, or at least easier to program with... too often I find
myself writing in Java a lot of overloaded methods, or a single method
with a huge arg list, and missing optional arguments and keyword
arguments...
Just my $.02
Cheers
Alessio
From: Kent M Pitman
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <uljz8lxl2.fsf@nhplace.com>
Slobodan Blazeski <·················@gmail.com> writes:
> I don't see what's the problem since
> (defun dummy (&optional x)
> (if x 1 2)) <=>
>
> (progn
> (defun dummy ()
> (let (x) // gensymed x
";" is the comment character in Lisp, btw.
But a gensym is not needed here, and may be inappropriate depending on
whether x is proclaimed special and there is a function call in the body
to a function that uses special x.
> (if x 1 2)))
> (defun dummy (x)
> (if x 1 2)))
I cannot discern in this discussion whether you mean this to work the way
defmethod does, but you should know that even in CLOS methods, two methods
with args (x) and () can't work this way because their arglists are not
congruent. But even if you relaxed that restriction, you'd find that the
reason the congruency rules are as they are is to avoid certain complexities
about which arguments are dispatched against and which are not. For example,
you might think the arglists (x &rest y) and (x y &rest z) are the same,
but one is dispatched against one argument and one is dispatched against two
arguments, and this turns out to be material.
Also, if I wrote a system involving 100 functions involving 100
optional arguments each, are you saying I would definitely want be
writing ~5000 functions? Is that equivalent? Or is it worth
considering the computational overhead of the approach when thinking
about what is gained and lost by this approach? Certainly that would
not have been acceptable in the kinds of small address space
environments in which Lisp arose, and it might not work in embedded
systems even today.
Please note, all code is in pseudo lisp:
On Aug 7, 4:16 pm, Kent M Pitman <······@nhplace.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > I don't see what's the problem since
> > (defun dummy (&optional x)
> > (if x 1 2)) <=>
>
> > (progn
> > (defun dummy ()
> > (let (x) // gensymed x
>
> ";" is the comment character in Lisp, btw.
I decided to use // and /* */ in edi.
>
> But a gensym is not needed here, and may be inappropriate depending on
> whether x is proclaimed special and there is a function call in the body
> to a function that uses special x.
>
> > (if x 1 2)))
> > (defun dummy (x)
> > (if x 1 2)))
Let me see:
(progn
(defun dummy ()
(let (x) ..
(progn
(def dummmy
(lambda ()
(lambda (x) //let is just syntactic sugar for lambda right?
(if x ..
You are right, no need to gensym it.
>
> I cannot discern in this discussion whether you mean this to work the way
> defmethod does, but you should know that even in CLOS methods, two methods
> with args (x) and () can't work this way because their arglists are not
> congruent. But even if you relaxed that restriction, you'd find that the
> reason the congruency rules are as they are is to avoid certain complexities
> about which arguments are dispatched against and which are not. For example,
> you might think the arglists (x &rest y) and (x y &rest z) are the same,
> but one is dispatched against one argument and one is dispatched against two
> arguments, and this turns out to be material.
>
> Also, if I wrote a system involving 100 functions involving 100
> optional arguments each, are you saying I would definitely want be
> writing ~5000 functions? Is that equivalent? Or is it worth
> considering the computational overhead of the approach when thinking
> about what is gained and lost by this approach? Certainly that would
> not have been acceptable in the kinds of small address space
> environments in which Lisp arose, and it might not work in embedded
> systems even today.
I don't care about efficiency nor embedded systems, so slow and memory
hungry is Ok with me. Edi's mascot is turtle, and they don't go very
fast. Those who like something fast should look elsewhere. I like
unification, continuations, bactracking, embedded database, array
processing abilities and doing things like (apply resource-hungry-
macro long-list-of-arguments) If they are expensive who cares I have
a lot of RAM and cores to spare.
bobi
From: Kent M Pitman
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <uvdyci16r.fsf@nhplace.com>
Slobodan Blazeski <·················@gmail.com> writes:
> > Also, if I wrote a system involving 100 functions involving 100
> > optional arguments each, are you saying I would definitely want be
> > writing ~5000 functions? Is that equivalent? Or is it worth
> > considering the computational overhead of the approach when thinking
> > about what is gained and lost by this approach? Certainly that would
> > not have been acceptable in the kinds of small address space
> > environments in which Lisp arose, and it might not work in embedded
> > systems even today.
>
> I don't care about efficiency nor embedded systems, so slow and memory
> hungry is Ok with me. Edi's mascot is turtle, and they don't go very
> fast. Those who like something fast should look elsewhere. I like
> unification, continuations, bactracking, embedded database, array
> processing abilities and doing things like (apply resource-hungry-
> macro long-list-of-arguments) If they are expensive who cares I have
> a lot of RAM and cores to spare.
This question and answer illustrates plainly what I often point to as
the primary difference between a language and a subroutine library.
It is often useful to have a package where you say "I don't care about
x" at the library level. And one can just do that. It's intended
that you do that.
But you originally asked your question about languages and whether
languages (not libraries) had done this. Language designers have to
worry about the needs of their entire user base, not just about some
particular user or application. And so the fact that you don't care
doesn't mean it can be ignored. My questions, somewhat rhetorical,
were intended to answer the questions that you asked about whether
there were problems with what you suggested. As a language matter,
there are. I've enumerated some of them. They seem non-trivial to
me. Your mileage may, of course, vary.
At the library level--can you write such a macro? Sure. Who cares.
The language, having been written in a general way that sought to
cater to a wide variety of users, has adequate facilities for you to
write something that just makes arbitrary decisions and gets arbitrary
benefits as a result. So absolutely, go to it.
Just don't confuse what you're doing with language design unless
you're specifically designing a dialect with characteristics that
systematically and intentionally intend to dismiss the needs of the
communities I've cited.
People often write criticisms of languages showing their own personal
aptitude for doing something fun/cute/cool and wondering why the
language doesn't do it, and the answer is often like this
conversation. I'm not trying to be critical or defensive here but
this just seemed a good opportunity to highlight a subtlety that often
just slips by uncommented-upon.
(All of this just my personal opinion.)
On Aug 8, 6:24 am, Kent M Pitman <······@nhplace.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > > Also, if I wrote a system involving 100 functions involving 100
> > > optional arguments each, are you saying I would definitely want be
> > > writing ~5000 functions? Is that equivalent? Or is it worth
> > > considering the computational overhead of the approach when thinking
> > > about what is gained and lost by this approach? Certainly that would
> > > not have been acceptable in the kinds of small address space
> > > environments in which Lisp arose, and it might not work in embedded
> > > systems even today.
>
> > I don't care about efficiency nor embedded systems, so slow and memory
> > hungry is Ok with me. Edi's mascot is turtle, and they don't go very
> > fast. Those who like something fast should look elsewhere. I like
> > unification, continuations, bactracking, embedded database, array
> > processing abilities and doing things like (apply resource-hungry-
> > macro long-list-of-arguments) If they are expensive who cares I have
> > a lot of RAM and cores to spare.
>
> This question and answer illustrates plainly what I often point to as
> the primary difference between a language and a subroutine library.
> It is often useful to have a package where you say "I don't care about
> x" at the library level. And one can just do that. It's intended
> that you do that.
>
> But you originally asked your question about languages and whether
> languages (not libraries) had done this. Language designers have to
> worry about the needs of their entire user base, not just about some
> particular user or application. And so the fact that you don't care
> doesn't mean it can be ignored. My questions, somewhat rhetorical,
> were intended to answer the questions that you asked about whether
> there were problems with what you suggested. As a language matter,
> there are. I've enumerated some of them. They seem non-trivial to
> me. Your mileage may, of course, vary.
>
> At the library level--can you write such a macro? Sure. Who cares.
> The language, having been written in a general way that sought to
> cater to a wide variety of users, has adequate facilities for you to
> write something that just makes arbitrary decisions and gets arbitrary
> benefits as a result. So absolutely, go to it.
>
> Just don't confuse what you're doing with language design unless
> you're specifically designing a dialect with characteristics that
> systematically and intentionally intend to dismiss the needs of the
> communities I've cited.
>
> People often write criticisms of languages showing their own personal
> aptitude for doing something fun/cute/cool and wondering why the
> language doesn't do it, and the answer is often like this
> conversation. I'm not trying to be critical or defensive here but
> this just seemed a good opportunity to highlight a subtlety that often
> just slips by uncommented-upon.
>
> (All of this just my personal opinion.)- Hide quoted text -
>
> - Show quoted text -
Basically my problems comes from Prolog integration, Prolog facts and
rules could have any number of arguments, so I either have to allow
valence overloading or divide syntax for creating rules/facts from
functions(or in cl parle methods -since they could be overloaded on
type). I want to something like this:
Is it better to have def overloaded (def drinks ("gary" "beer))
(add drinks ("tom" "beer"))
(def likes (person beer) (drinks person beer))
or have some special syntax for rules like:
(rule drinks ("gary" "beer))
>drinks
(rule drinks ("tom" "beer"))
>drinks
(rule likes (person beer) (drinks person beer))
>likes
(drinks "sam" "beer")
>t
(drinks ? "beer")
>(stream "sam" "gary")
(map ; like cl mapcar but iterates over anything iteratable lists,
arrays, streams..
likes ; prolog like rule taking that facts are just rules without
body, that's implicitly t
(stream "beer) ; creates infinite stream of "beer"
'("gary" "sam" tom"))
>(t nil t))
What brings the cleaner approach, molding function/methods togather
with rules and facts or keeping them separate?
bobi
Slobodan Blazeski <·················@gmail.com> writes:
> Basically my problems comes from Prolog integration, Prolog facts and
> [...]
> What brings the cleaner approach, molding function/methods togather
> with rules and facts or keeping them separate?
Note that in prolog,
parent(HumanBaby,HumanMother,HumanFather) :- ... .
parent(ZorglubEgg,ZorglubGraber,ZorglubRapper,ZorglubKenner) :- ... .
define TWO different rules, parent/2 and parent/3. They have nothing
in common.
Therefore your problem is non-existant.
(defun parent/2 (hb hm hf) ...)
(defun parent/3 (ze zg zr zk) ...)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
From: Dimiter "malkia" Stanev
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <6g3jhaFdr59eU1@mid.individual.net>
Pascal J. Bourguignon wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>> Basically my problems comes from Prolog integration, Prolog facts and
>> [...]
>> What brings the cleaner approach, molding function/methods togather
>> with rules and facts or keeping them separate?
>
> Note that in prolog,
>
> parent(HumanBaby,HumanMother,HumanFather) :- ... .
> parent(ZorglubEgg,ZorglubGraber,ZorglubRapper,ZorglubKenner) :- ... .
>
> define TWO different rules, parent/2 and parent/3. They have nothing
> in common.
>
>
> Therefore your problem is non-existant.
>
> (defun parent/2 (hb hm hf) ...)
> (defun parent/3 (ze zg zr zk) ...)
>
Yup. I don't know Prolog, but really when I was skimming over the
Erlang's documentation (and it said that the language was based on
Prolog), the function names contained the number of parameters it used
(and that's why the /n). At first this sounded kind of ridicilous, and
reminded me of how you had to do some things with the older C
preprocessor - BINDFUNC(), BINDFUNC1(x), BINDFUNC2(x,x). Then again it
probably makes total sense, it's just that I was not able to see it the
first time.
"Dimiter \"malkia\" Stanev" <······@gmail.com> writes:
> Pascal J. Bourguignon wrote:
>> Slobodan Blazeski <·················@gmail.com> writes:
>>> Basically my problems comes from Prolog integration, Prolog facts and
>>> [...]
>>> What brings the cleaner approach, molding function/methods togather
>>> with rules and facts or keeping them separate?
>> Note that in prolog, parent(HumanBaby,HumanMother,HumanFather) :-
>> ... .
>> parent(ZorglubEgg,ZorglubGraber,ZorglubRapper,ZorglubKenner) :- ... .
>> define TWO different rules, parent/2 and parent/3. They have
>> nothing
>> in common.
>> Therefore your problem is non-existant.
>> (defun parent/2 (hb hm hf) ...)
>> (defun parent/3 (ze zg zr zk) ...)
>>
>
> Yup. I don't know Prolog, but really when I was skimming over the
> Erlang's documentation (and it said that the language was based on
> Prolog), the function names contained the number of parameters it used
> (and that's why the /n). At first this sounded kind of ridicilous, and
> reminded me of how you had to do some things with the older C
> preprocessor - BINDFUNC(), BINDFUNC1(x), BINDFUNC2(x,x). Then again it
> probably makes total sense, it's just that I was not able to see it
> the first time.
Well perhaps /n is actually a hint that you shouldn't name these
predicates this way. Thinking about them you could come with:
(defun human-parenthood (hb hm hf) ...)
(defun zorglub-parenthood (ze zg zr zk) ...)
Which doesn't prevent you to define:
(defun parenthood (decendence-list ascendence-list) ...)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
From: Pascal J. Bourguignon
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <7c3alg99ae.fsf@pbourguignon.anevia.com>
Slobodan Blazeski <·················@gmail.com> writes:
> On Aug 7, 12:36�pm, Alessio Stalla <·············@gmail.com> wrote:
>> On Aug 7, 11:37�am, Slobodan Blazeski <·················@gmail.com>
>> wrote:
>> The semantics would be different from those of CL. For example, in CL
>> I can write
>>
>> (defun dummy (&optional x)
>> � (if x ...))
>>
>> with your approach, I couldn't do that, and IMHO that would miss the
>> point of &optional...
>
>
> I don't see what's the problem since
> (defun dummy (&optional x)
> (if x 1 2)) <=>
>
> (progn
> (defun dummy ()
> (let (x) // gensymed x
> (if x 1 2)))
> (defun dummy (x)
> (if x 1 2)))
But I assume the point would be to write:
(define-valence-dispatched-method dummy () 2)
(define-valence-dispatched-method dummy (x) (if x 1 2))
or:
(define-valence-dispatched-function dummy
(:method () 2)
(:method (x) (if x 1 2)))
or even:
(define-valence-dispatched-method dummy (a ) (1+ a))
(define-valence-dispatched-method dummy (a x) (+ a x))
Which makes us notice that &optional (x default xp) takes more bits.
--
__Pascal Bourguignon__
From: Pascal J. Bourguignon
Subject: Re: Is function overloading per valence good or bad thing in lisp
Date:
Message-ID: <7cmyjp85lf.fsf@pbourguignon.anevia.com>
Slobodan Blazeski <·················@gmail.com> writes:
> On Aug 7, 11:01�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Slobodan Blazeski <·················@gmail.com> writes:
>> > What do you think about function �overloading per valence and did some
>> > of the previous dialects of lisp had it? �I'm talking only about
>> > completely different funcitons not &optional, &args ...
>>
>> >>(def �risk-rate (x y) �(/ xy))
>>
>> >>(def risk-rate �(x y z) (/ (+ x z) �y))
>>
>> >>(+ (risk-rate 3 4 5) (risk-rate 2 3))
>> > ..
>> > It feels convenient to me but I'm interested what kind of problems it
>> > could bring on.
>>
>> (defun �risk-rate (x y &optional (tau 1)) �(* tau (/ x y)))
>>
>> (risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
>
> How about &optional defining all valences? Like
>
> (defun risk-rate (a b &optional c d ...) <=>
> (progn
> (defun risk-rate (a b) ..)
> (defun risk-rate (a b c) ..)
> (defun risk-rate (a b c d) ..))
Yes, if you define this equivalence, it can work.
Then it's just a matter of building the body of the function from the
various parts, just like a generic function is built from the various
methods defined on it.
There remains that with &optional you get to define default values,
but we can assume that if you write it with separated definitions it's
because you don't need them.
Also, it depends on how integrated with existing CL you want it. You
wrote DEF, not CL:DEFUN, CL:DEFGENERIC or CL:DEFMETHOD. After all, if
you define your own DEFINE-VALENCE-DISPATCHING-FUNCTION, you can
restrict it to your own lambda list and can forbid &optional or
anything you don't like.
--
__Pascal Bourguignon__
On Aug 7, 12:47 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Aug 7, 11:01 am, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> Slobodan Blazeski <·················@gmail.com> writes:
> >> > What do you think about function overloading per valence and did some
> >> > of the previous dialects of lisp had it? I'm talking only about
> >> > completely different funcitons not &optional, &args ...
>
> >> >>(def risk-rate (x y) (/ xy))
>
> >> >>(def risk-rate (x y z) (/ (+ x z) y))
>
> >> >>(+ (risk-rate 3 4 5) (risk-rate 2 3))
> >> > ..
> >> > It feels convenient to me but I'm interested what kind of problems it
> >> > could bring on.
>
> >> (defun risk-rate (x y &optional (tau 1)) (* tau (/ x y)))
>
> >> (risk-rate a b c) ; what function to call? (risk-rate x y z) or (risk-rate x y &optional tau)?
>
> > How about &optional defining all valences? Like
>
> > (defun risk-rate (a b &optional c d ...) <=>
> > (progn
> > (defun risk-rate (a b) ..)
> > (defun risk-rate (a b c) ..)
> > (defun risk-rate (a b c d) ..))
>
> Yes, if you define this equivalence, it can work.
>
> Then it's just a matter of building the body of the function from the
> various parts, just like a generic function is built from the various
> methods defined on it.
>
> There remains that with &optional you get to define default values,
> but we can assume that if you write it with separated definitions it's
> because you don't need them.
Oh no, that functionality stays the same
(def rate (x &optional (y 7) ... <=>
(progn
(def rate (x)
(let (y 7) ...))
(def rate (x y) ..))
>
> Also, it depends on how integrated with existing CL you want it. You
> wrote DEF, not CL:DEFUN, CL:DEFGENERIC or CL:DEFMETHOD. After all, if
> you define your own DEFINE-VALENCE-DISPATCHING-FUNCTION, you can
> restrict it to your own lambda list and can forbid &optional or
> anything you don't like.
Sorry for not mentioning, I was talking about lisp as in lisp family
of languages, not about common lisp. Currently working on edi, my own
hybrid sort-of lisp so I wanted to know is multiple valences good or
bad thing. Actually I'm not sure is it pure lisp, since it has a lot
of prolog and apl genes in it,but as per my understanding it is at
least in the lisp family.
cheers
bobi
>
> --
> __Pascal Bourguignon__- Hide quoted text -
>
> - Show quoted text -
Slobodan Blazeski wrote:
> What do you think about function overloading per valence and did some
> of the previous dialects of lisp had it? I'm talking only about
> completely different funcitons not &optional, &args ...
>
>> (def risk-rate (x y) (/ xy))
>
>> (def risk-rate (x y z) (/ (+ x z) y))
>
>> (+ (risk-rate 3 4 5) (risk-rate 2 3))
> ..
> It feels convenient to me but I'm interested what kind of problems it
> could bring on.
Its a bad thing. Lisp's optional and keyword arguments are better.
C++-style overloading can get rather confusing at times (e.g. does
f(0,0,'a') match f(int,char*,int) or ??). Lisp keyword arguments
don't require looking up the function prototype.
Using a Stroustrup-like argument: CL already provides a simple way of
providing multivalent functions; just define risk-rate-2 and
risk-rate-3. The introduction of multivalent overloading would add
complexity to the language semantics without providing any new
functionality. Furthermore, somebody just felt it would be too confusing.
- Daniel
In article <································@comcast.com>,
D Herring <········@at.tentpost.dot.com> wrote:
> Slobodan Blazeski wrote:
> > What do you think about function overloading per valence and did some
> > of the previous dialects of lisp had it? I'm talking only about
> > completely different funcitons not &optional, &args ...
> >
> >> (def risk-rate (x y) (/ xy))
> >
> >> (def risk-rate (x y z) (/ (+ x z) y))
> >
> >> (+ (risk-rate 3 4 5) (risk-rate 2 3))
> > ..
> > It feels convenient to me but I'm interested what kind of problems it
> > could bring on.
>
> Its a bad thing. Lisp's optional and keyword arguments are better.
> C++-style overloading can get rather confusing at times (e.g. does
> f(0,0,'a') match f(int,char*,int) or ??). Lisp keyword arguments
> don't require looking up the function prototype.
That's overloading based on type, which certainly has ambiguity issues
when type conversions are possible.
Overloading on valence suffers from no such ambiguity, unless you mix it
with &optional-type arguments.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> In article <································@comcast.com>,
> D Herring <········@at.tentpost.dot.com> wrote:
>
>> Slobodan Blazeski wrote:
>>> What do you think about function overloading per valence and did some
>>> of the previous dialects of lisp had it? I'm talking only about
>>> completely different funcitons not &optional, &args ...
>>>
>>>> (def risk-rate (x y) (/ xy))
>>>> (def risk-rate (x y z) (/ (+ x z) y))
>>>> (+ (risk-rate 3 4 5) (risk-rate 2 3))
>>> ..
>>> It feels convenient to me but I'm interested what kind of problems it
>>> could bring on.
>> Its a bad thing. Lisp's optional and keyword arguments are better.
>> C++-style overloading can get rather confusing at times (e.g. does
>> f(0,0,'a') match f(int,char*,int) or ??). Lisp keyword arguments
>> don't require looking up the function prototype.
>
> That's overloading based on type, which certainly has ambiguity issues
> when type conversions are possible.
>
> Overloading on valence suffers from no such ambiguity, unless you mix it
> with &optional-type arguments.
Ehh... I've had similar problems with foo(int1, int2, ..., intN) and
the like. For some well-known functions (e.g. + and -), its fine.
When I'm hacking up C++ code, its ok. When I revisit that code, names
often get changed. Its not confusing, but it can become just as
tedious as the notorious ()s matching. For small N its passable; for
higher N, the types better be distinct or it just becomes confusing
(unless foo is really an associative binary function).
- Daniel