I understand your point that SRFI 177 shall be compatible with existing keyword systems as far as this is feasible.
But we also have to make sure that SRFI 177 is compatible with whatever SRFI about keyword arguments that will finally make it into R7RS-large. As we don't know that SRFI yet, we may have to be a bit conservative.
****
To me, now the question comes up how to write specifications for SRFIs that want to make use of keyword arguments. There implementation may depend on a specific system like SRFI 177, but the interface should be opaque.
How would you write this?
A related question is: How can we make sure that if we have two implementations of a keyword system, say of SRFI 177 and of SRFI 277, in a Scheme system, they can talk to each other?
> 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.
Marc