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

Re: A short name.

This page is part of the web mail archives of SRFI 26 from before July 7th, 2015. The new archives for SRFI 26 contain all messages, not just those from before July 7th, 2015.



On Thu, Feb 21, 2002 at 12:41:38PM -0600, Mario Latendresse wrote:
> 
> I make this little proposition to Sebastian for a short syntax to his
> curry srfi.
> 
> I think the most practical use of it is to reduce clutter in Scheme
> code.  
> 
> Instead of `curry', I propose `_j'. This name comes from the
> projection notation in math. Also, I would use `_' instead of `<>'and
> `._.'instead of `<...>'.
> 
> So it would look like this
> 
> Instead of:                       You see:
> 
> (curry cons a <>)                 (_j cons a _)
> (curry list 1 <> 3 <> 5)          (_j list 1 _ 3 _ 5)
> (curry list)                      (_j list)
> (curry list 1 <> 3 <...>)         (_j list 1 _ 3 ._.)
> 
> And you get rid of the name problem of curry, partial, etc.
 
Mmm. In Mathematica, this operation is denoted with the & symbol.
(And the slots are denoted with #.)
So let me one-up your proposal and suggest we use &.

 (& cons a _)
 (& list 1 _ 3 _ 5)

As an added bonus, it makes Scheme look like Perl...

OK, so this isn't a serious proposal, but at least it is better
than using curry . I really don't understand how people can seriously
suggest to choose curry and go for a head-on clash with the whole FP
lterature. Especially since "real" curry *is* really possible to write
in Scheme, moreover, it is even occasionally useful. If you want a
short nice name, then in ${DEITY}'s name, please use _j, or &, or
tandoori, rather than curry.

If it really must be `curry', then I'm afraid that I am not going to
use this SRFI. OK, so that didn't scare anybody ;-) ,  but I want
to leave no doubt that I feel very strongly about this point, and
I haven't seen a single convincing reason to stick with curry.
There are 26^5 names with the same "shortness properties" as curry
and most of them do not clash with any established FP jargon.

Greetings,

Stephan