Re: (ice-9 nice-9) module update

[Taylan Ulrich Bayırlı/Kammer]

Hmm, I just looked a bit closer into your other email:

Panicz Maciej Godek <address@hidden> writes:

> * blends named-let with match-let and srfi-71-style let for multiple
> values, legalizing usages like
>
> (let loop ((a (b c) (values 1 (list 2 3))))
>   ...
>   (loop (values 4 (list 5 6))))
>
> (although this may not seem to be a good way of programming, I think
> that imposing artificial limitations on how the language can be used
> would be even worse)

How does that one work?  AFAIUI, 'loop' would need to be a macro,
because otherwise you're returning multiple values to a single-value
continuation (<operand> slot of a procedure-call expression).

I haven't seen many uses of named-let where the name was being used for
anything else than directly calling it (though I have seen some, or at
least one, in GNU Guix's code), so maybe making it a macro would not be
too bad normally, but it goes against existing practice.

> * allows to destructure arguments to lambda, e.g.
>
> (map (lambda ((a . b)) (+ a b)) '((1 . 2) (3 . 4) (5 . 6)))
>
> [...]
>
> * allows to use curried definitions like (ice-9 curried-definitions),
> but such that are already blended with the pattern-matching lambda
>
> (define ((f (a b)) (c))
>   (list a b c))

Do you mean it allows currying *and* destructuring?  To be absolutely
honest, I would probably go mad while trying to read code using such a
feature. :-)

I'm not sure how often currying is used in Scheme.  Maybe it's just me;
do others use it occasionally?  I never felt like I needed such a
feature so far.  Would be a different thing is *all* procedures were
implicitly curried, but that's not the case...

If it's common to use currying in specific problem domains, such as
classical mechanics (since you mention SICM in the original email
starting this discussion), then IMO such extensions to 'define'
etc. should be kept private to code-bases working on such specialized
problem domains.  They shouldn't leak out to the general-purpose parts
of the language.

Supporting destructuring (and only that) in 'lambda' doesn't sound too
bad at face value, since I can't imagine many other possible semantics
for parenthesized forms in an argument list, but it worries me a bit
because then we will probably want to make 'let' consistent with
'lambda', and then we're again at the point where we discriminate
against other possible extensions to 'let'.

Therefore, in my opinion it's best to keep lambda and let pure, and just
use match-lambda, let-values, match-let, etc. where desired.  That's the
most "frictionless" way to go as I see it.


Sorry if I'm being negative in some regards.  All just my honest/blunt
opinions.

Taylan