texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Applied patches for TeXmacs 1.0.1.2


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Applied patches for TeXmacs 1.0.1.2
Date: Mon, 27 Jan 2003 19:16:27 +0100 (MET)

> 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?). 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.

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

> 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 know you do not care how the rest of the world do things.

Are you the rest of the world?





reply via email to

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