Well, thinking about clojure as a new Lisp, I would like some good
rule to stablish the order of the arguments for functions. I don't
like this:
(contains? (set (range 100)) 10)))
(some #(= 10 %) (range 100))))
So I would suggest something like "what where" to order the
arguments, now:
contains what where
some what where
I think we can learn a lot of verbal language and look for analogies
to eliminate ambiguous questions like the order of the arguments.
A new dialect of Lisp should learn to not repeat bad design.
Perhaps you can suggest some useful rule. I think that what and
where can be clearly identified. For example in an element-list pair,
what is the element and where is the list.
On Feb 26, 10:07 pm, camponoblanco <·············@gmail.com> wrote:
> I think we can learn a lot of verbal language and look for analogies
> to eliminate ambiguous questions like the order of the arguments.
so use Perl.
On Feb 26, 4:07 pm, camponoblanco <·············@gmail.com> wrote:
> I think we can learn a lot of verbal language and look for analogies
> to eliminate ambiguous questions like the order of the arguments.
imho, this is one of the reasons for keyword args
On Feb 26, 10:07 pm, camponoblanco <·············@gmail.com> wrote:
> Well, thinking about clojure as a new Lisp, I would like some good
> rule to stablish the order of the arguments for functions. I don't
> like this:
>
> (contains? (set (range 100)) 10)))
> (some #(= 10 %) (range 100))))
>
> So I would suggest something like "what where" to order the
> arguments, now:
>
> contains what where
> some what where
>
> I think we can learn a lot of verbal language and look for analogies
> to eliminate ambiguous questions like the order of the arguments.
>
> A new dialect of Lisp should learn to not repeat bad design.
"Old dialects" use keywords. Think (hard and thrice) about
(find what where)
or
(member what where)
or
(some test where)
Naturally I omitted the full signature. It is left as an exercise for
the OP.
Cheers
--
Marco
camponoblanco <·············@gmail.com> writes:
> Well, thinking about clojure as a new Lisp, I would like some good
> rule to stablish the order of the arguments for functions. I don't
> like this:
>
> (contains? (set (range 100)) 10)))
> (some #(= 10 %) (range 100))))
>
> So I would suggest something like "what where" to order the
> arguments, now:
>
> contains what where
> some what where
Well, I can think of some general design principles, most of which are
followed in Common Lisp -- with some exceptions to handle backward
compatibility.
For various mapping and related functions (like MAP, MAPCAR, SOME, etc.)
it is pretty clear that you want to have the function come first. That
allows you to have a natural notation for situations where the function
that you are mapping or testing, etc. takes more than one argument.
Example:
(some #'= list1 list2)
would return true if there was at least one corresponding element in the
two lists that are equal. This is also similar to the way AREF works,
since it can take an arbitrary number of dimensions.
Otherwise, there perhaps should be some bias toward trying to have short
arguments come before long ones, but that is really hard to quantify.
Beyond that, you would perhaps want to think about what the name of the
function implies about argument order. So you might want to choose
between
(member item sequence)
(contains sequence item)
But the main principle seems to be to look at each function and
determine what makes the most sense for that function. It is only where
you don't really care (like in the MEMBER/CONTAINS) option that you can
choose based on some other consideration (like perhaps making sequence
arguments appear later in the argument list, wanting functions to appear
first.) Either of these would bias towards MEMBER, since you could
imagine a MEMBER-IF or SATISFIES test -- although I guess SOME would
also do for that functionality.
--
Thomas A. Russ, USC/Information Sciences Institute