On 2022-03-27 20:01 +0200, Marc Nieper-Wißkirchen wrote:
> Am Do., 24. März 2022 um 17:40 Uhr schrieb Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz>:
> > I'm not sure I understand.  You're suggesting that (curried () 4)
> > should evaluate to 4?
>
> Yes. This will not only let you remove one case in your specification
> (and this is usually a good hint that there was something fishy going
> on), it will also give you more invariants for your forms.

I agree, this seems much more consistent overall than the current
semantics.  I'd like to carefully check the interactions it has with
other cases before accepting it.

> > Your comment led me to something in the implementation which I don't
> > understand and which may be a bug.  Lines 34–36 of srfi-232.scm:
>
> Isn't the implementation yours?

Yes, though I referred to the paper's version throughout, and
apparently picked up a bugs in the process.  I originally intended
to include the Hemann implementation, but I never heard back from
him when I asked about doing so.  curried is different enough now
to render the point moot, I guess.

> > The invocation of the procedure body before applying it to the args
> > makes no sense to me, and contradicts the current semantics.  These
> > lines are identical modulo naming to the paper's version, but I can't
> > find any explanation of this extra application.  I *think* it's a
> > mistake and the SRFI semantics are right, but I'll investigate further.
>
> Well, by my above arguments, I think it should be:
>
> ((curried-1 () exp) exp)
>
> When applied to args, this will become
>
> (apply exp args)
>
> so, indeed, the extra application in the code snippet above does not
> make much sense IMO.

Thanks for reviewing it.  I've patched it out, but the whole clause
will be replaced if we modify the nullary case as discussed.

Thanks again!

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>