Email list hosting service & mailing list manager

Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (02 Mar 2020 23:53 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Feeley (03 Mar 2020 04:46 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:29 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:43 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 07:51 UTC)
Identifier syntax, and using macros with call/kw Lassi Kortela (03 Mar 2020 08:57 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:00 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:06 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:19 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:48 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 10:03 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 10:12 UTC)
Re: Identifier syntax, and using macros with call/kw John Cowan (06 Oct 2020 20:20 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (07 Oct 2020 07:29 UTC)
Syntax for identifier syntax Lassi Kortela (03 Mar 2020 09:55 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 10:16 UTC)
Re: Syntax for identifier syntax John Cowan (03 Mar 2020 13:37 UTC)
Re: Syntax for identifier syntax Lassi Kortela (03 Mar 2020 13:42 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 14:59 UTC)
Re: Syntax for identifier syntax Jim Rees (04 Mar 2020 18:12 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (04 Mar 2020 18:18 UTC)
Re: Syntax for identifier syntax John Cowan (04 Mar 2020 23:48 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:13 UTC)
R7RS-large backward compatibility Lassi Kortela (03 Mar 2020 10:31 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (03 Mar 2020 11:31 UTC)
Specifying a meeting point for different keyword systems Lassi Kortela (03 Mar 2020 11:56 UTC)
Re: Specifying a meeting point for different keyword systems Marc Nieper-Wißkirchen (03 Mar 2020 15:03 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 19:36 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 19:51 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 20:03 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 20:17 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (08 Mar 2020 09:00 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 09:06 UTC)
Re: R7RS-large backward compatibility John Cowan (08 Mar 2020 21:58 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 22:40 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 07:42 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 11:46 UTC)
Re: [scheme-reports-wg2] R7RS-large backward compatibility Lassi Kortela (09 Mar 2020 12:07 UTC)
Re: R7RS-large backward compatibility Per Bothner (09 Mar 2020 16:30 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 16:48 UTC)

R7RS-large backward compatibility Lassi Kortela 03 Mar 2020 10:31 UTC

>     Since 177 needs to be usable immediately, it can't rely on new
>     kinds of macros. That means
>     177 should probably specify lambda/kw to return real lambdas.
>
> Now we have returned to the argument that, from a technical point of
> view, we seem to be specifying things in the wrong order. SRFI 177 is
> shaped by what is possible today. When SRFI 177 gets voted into
> R7RS-large, by the end of the day, it should be shaped by what is
> possible in R7RS-large. :(

Speaking specifically of 177, it was never meant to be R7RS-large only.
Its purpose is to be equally usable in R5RS, R6RS, R7RS-small and
R7RS-large Schemes. My overarching interest in Scheme is to make
standards and implementations compatible; I'm fine with a technically
inferior solution if it can cover more Scheme implementations. Against
that backdrop, a hack like parsing symbols is a very minor issue. I
agree that it's better to do without, and I will fully support any
efforts to explore how to get rid of hacks, but compatibility wins
easily for me.

Lisp is infamous for splintering into mutually incompatible camps on
technical grounds. Lisp outsiders, who evaluate whether to use a Lisp
dialect to write an application, will not listen to debates like that.
Last year I tried in earnest to use OCaml, but was stumped that it has
two completely different standard libraries. We can start from the
assumption that each division between two standards divides the
language's community in half, and additionally cuts off at least half of
new people evaluating whether to learn the language. Scheme is better
off than OCaml due to the wise decision that R6RS and R7RS are made
largely out of the same parts, so it doesn't present as big a hurdle as
OCaml and a lot of code is directly portable.

What I'm saying is that we are digging ourselves deeper into obscurity
with each new incompatible feature. Wearing one's R6RS or R7RS adherence
as a badge of pride is short-sighted zero-sum thinking. To the rest of
the programming world it looks like kids arguing in a schoolyard about
whose toy is cooler. Even though Scheme is legitimately one of the
coolest toys ever, it's time to venture outside the schoolyard and make
something that the wider world can easily use for big projects with
deadlines :) I got the impression that this is the main point of the
R7RS-large project, and if so, it is a laudable goal.

Again, R7RS-large is free to use something other than 177, but we should
make it first priority to ensure all systems we have are compatible.
It's important to keep in mind that 177 doesn't really introduce any new
semantics - it's just the lowest common denominator of 10 existing
Scheme implementations that are not going away.

> Again, it would be nice if could discuss and agree upon general runtime
> semantics first, then reader syntax, then the syntactic system, then
> keyword objects and then the applications.

This is fine. It's worth stating again that I very much appreciate your
& others' continued investment in the discussion, and I'm not in a hurry
to push 177 out the door before an acceptable consensus has been reached.