texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Parameter ordering of 'filter'


From: david
Subject: [Texmacs-dev] Parameter ordering of 'filter'
Date: Tue, 28 Jan 2003 15:38:42 +0100
User-agent: Mutt/1.4i

On Mon, Jan 27, 2003 at 07:16:27PM +0100, Joris van der Hoeven wrote:
> 
> > On Sun, Jan 26, 2003 at 12:42:09PM +0100, Joris van der Hoeven wrote:
> > > 1004: Should be modified
> > >   I agree with all changes, except with the permutation
> > >   in the ordering of l and pred? in filter, separate, etc.
> > >   Please stick to the same ordering as the one used for
> > >   the other routines. As a general rule, I prefer to pass
> > >   the principal object of a routine as the first parameter
> > >   (in this case: the list on which we perform some operation).
> > >   Your passing style should rather be used for operators,
> > >   like in ((separate pred?) l).
> > 
> > I am very sad with this requirement. The rest of the world uses the
> > parameter ordering which is set by "Structure and Interpretation of
> > Computer Programs" (the Book of Scheme). Also, that is consistent with
> > the ordering used by map and for-each.
> 
> Thanks for the pointer to this book. However, you are wrong with
> your "the rest of the world" (is it hard for you to write in a less
> insulting manner?).

All apologies. I should have been softer in my formulation.

I would be interested in a pointer to a source code where the
alternate ordering is used. Lisp is more a culture than a language,
and I find that makes it hard to master.

About the book, you can find an on-line copy on the web. The MIT
website seems to be down at the moment so I cannot give the precise
URL. With Google, you are lucky when searching for "sicp".


> For instance, a standard routine like 'display'
> takes the important parameter (the thing we want to display)
> as its first argument and the less important one (the port)
> as its optional second argument.

Optional arguments are generally at the end of the argument list. By
the way, GOOPS also have an interesting convention for named
arguments.

> This way of ordering parameters is used consistently in
> all standard built-in scheme routines. I am happy to adhere
> to this convention.

I understand that the main parameter should be first. But in the case
of functions which apply a predicate to all elements of a list, it is
unclear whether the predicate or the list is the main parameter.

Common Lisp seems to consistently consider that the *predicate* is the
main parameter. My reference here is the (ice9 common-list) module of
GUILE. The 'filter' function is a special case of the 'some' function,
whose parameter list is (pred l . rest).

And my definitive argument is that SFRI-0 defines a filter functions
with the (pred l) argument list.

http://srfi.schemers.org/srfi-1/srfi-1.html#FilteringPartitioning


> > When any Scheme programmer reads "(filter ..." the expected parameter
> > ordering is pred and *then* list.
> 
> No, that would be the case if you see the filter with the predicate
> as an operator, in which case you would write ((filter pred?) l)
> instead of (filter l pred?).

I am not sure I really understand what you mean. If 'filter' was a
procedure returning a procedure, it would indeed make little sense to
have to use it as ((filter l) pred?). The closest useful thing I can
think of would be to design a general iteration construct which would
be used as (filter (iterator l) pred) using your ordering. But even that
would only bring added value in a message passing architecture. In the
usual functional style, it is simpler and essentially as efficient to
use (filter (to-list l) pred).

But I can understand that (filter pred l) can be considered a simple
writing of ((filterer pred) l). The point however is that there is no
benefit in using this construct because pred is an opaque object, so
one may as well use (filter pred l) which is syntaxically lighter and
does not involve the creation of a closure.

A counter example would be (match? l pat). Here there might be a
runtime benefit in using ((matcher pat) l) because it makes sense to
compile the pattern as a closure at initialization time.

> > I know you do not care how the rest of the world do things.
> 
> Are you the rest of the world?

Sorry for having been so categoric.

I just try to conform to style in can find in the code of experienced
Scheme programmers. So far I have seen a clear consensus about this
kind of issue so I am inclined to think that is the common practise.
If you can point me to source code where things are done differently I
am interested.

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]