Am 25.07.2017 um 10:42 schrieb Shiro Kawai:

I do use "cute" time to time. Just grepped a bunch of my source tree to find about a few dozens of uses.
But I agree that having two variations of 'is' in a sense of cut/cute seems too much.

What I'm thinking of is this: Currently, 'is' macro has two functions, namely rearranging infix operators and shorthand of creating a closure, which are orthogonal to each other. Conflating orthogonal features doesn't seem a good idea. Every time a new macro that has additional function of the latter, we would go into the same discussion of cut/cute semantics, which symbol to use for placeholder, etc.

Instead, can we split those two orthogonal functions? So that the latter function is solved once and for all.

One way is to define an extension of srfi-26. It only allows <slot-or-expr> in the arguments, so we can't combine it with macros such as 'is'. But the restriction is because of difficulty of coming up a complete general semantics of allowing syntactic keywords in its arguments. It doesn't prevent to define an extension that allows *limited* use of syntactic keywords, e.g. we can define semantics of (cut is ...) or (cute is ...) specifically.

That sounds like an excellent idea! (And very much in the spirit of Scheme!)

In particular, it has one invariant which the previous proposal doesn't have: (cut(e) is ...) is always a procedure (possibly of zero arguments), while the previous proposal of (is ...) with underscores may or may not be a procedure depending whether underscores are present or not (and never a procedure with zero arguments, which misses a corner case).

With the proposal of Shiro Kawai (is ...) alone is always the result of applying binary predicates and never a procedure, making it much cleaner.

In case if you don't like '<>' as the placeholder, you can delve into yet another sectioning syntax, e.g. Clojure-esque #(is _ < x) etc. In that case, however, I feel it is better to have a separate srfi.

The only thing I would add to the SRFI 26 syntax was to allow the sequence <> ... instead of <...> to capture rest arguments.

Marc

On Mon, Jul 24, 2017 at 9:59 PM, Panicz Maciej Godek <xxxxxx@gmail.com> wrote:

2017-07-24 22:37 GMT+02:00 Shiro Kawai <xxxxxx@gmail.com>:

On Mon, Jul 24, 2017 at 4:55 AM, Panicz Maciej Godek <xxxxxx@gmail.com> wrote:

(is _ < x < y) is allowed, but it is bad programming style: within the scope of this expression,

(< x y) already has a definite value which doesn't have to be evaluated every time the function

is called.

It doesn't have a definite value if x and/or y are mutable variables or non-pure expressions; in such case (< x y) has to be evaluated every time.

Of course, strictly speaking you're right, but I can't imagine a realistic use case that wouldn't be considered bad programming style.

I do agree however that the limitation of allowing the underscore only in the position of the first or the second argument feels artificial,

and I am willing to fix that in the second draft

That's why srfi-26 has cut and cute.

While I managed to trace some uses of cut in the real world Scheme code base, I didn't find a single use of cute.

And while I think that one could add a variant of "is", say, "ise", that would evaluate certain complex expressions

only once, I believe that having an explicit "let" wrapped around both "is" and "cut" is cleaner than the use of "cute".

What do you think?

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=DSOz35jCh6KmKnBKsAUGHLH9A23l3Jov