> I've been feeling the same. When looking at how dynamic CL is, I start to understand why CL proponents say Scheme is closer to ALGOL than Lisp. // I'll miss t

> I've been feeling the same. When looking at how dynamic CL is, I start to understand why CL proponents say Scheme is closer to ALGOL than Lisp. // I'll miss the cleanness of Scheme if I go, but I can't escape the feeling that it might be time to move on. // OTOH, there are things I want to do that CL can't do. I'm in the process of designing a new dialect, sort of a "spiritual successor" to EuLisp (in a technical sense, not a political one). Essentially, I want a dialect that (1) embraces modern PL theory without abandoning tradition wholesale, and (2) incorporates advances made since the finalization of CL without being so minimal as Scheme. I've talked to the editor of the EuLisp (draft) standard (Julian Padget) and bounced some ideas and inquiries off of him. One thing I asked was whether there was anything he wished they would've wound up including in the final draft, and anything he thinks would've been good to have in retrospect; the things he mentioned were all already on my list B) So, I think I'm on the right track in terms of "spiritual succession", though not being from Europe I'd feel like too much of a sham to call what I come up with EuLisp, especially given that it's not EuLisp as it stands today. I've also been in contact with several folks who were involved with Le-Lisp (and later ISLISP) at INRIA (in the course of my questioning, I managed to initiate an open-sourcing of the original Le-Lisp and LLM3 implementations; last I heard, approval from INRIA was acquired and they were in the process of getting it to build on modern systems; I should ping them and see how it's going :) ). Anyway, I'd welcome collaboration if you happen to be interested. I'm drafting a "standard" (Nouvelle Académie Nord-Carolinien de l'Informatique (NANCI) X3J1337 "Programming Language Evelin" (Extensible, Vertible, and Expressive List and [artificial] Intelligence Notation)) and a reference implementation, both of which I intend to post for public review/comment when it's ready (a few months away still, at the very least). > For example, dynamically bound funtions: the idea you could have a function that shadows another function (maybe even a core function), and, for instance, provides diagnostic information about all calls to said function for the dynamic extent of the binding form. You can probably cover some of the use-cases with before/after methods, but I don't think they'd cover all of them. > It violates the standard macro abstraction (forms aren't just lists that you can CDR down, they're now "datums") Syntactic closures are also a new datatype that don't use the list abstraction. The nice thing about syntax-case is that you can actually write a metamacro that gives you an API akin to the synclo API and hides the dirty dealings with `syntax` values under the covers. It's actually pretty straightforward to implement IR macros on top of syntax-case. > Chibi is a really nice implementation. Agreed, and the next release is shaping up to be very nice. > But R6RS grew in the wrong ways. IMHO, it didn't so much add new libraries to do new things as add new libraries to do old things (although previously unstandardized) in very complicated, by theoretically "better" ways. I totally agree. Many of the additions abandoned tradition and ignored existing SRFIs. In the very few cases where I felt that breaking compatibility with relevant SRFIs was justified (records, for example), they came up with something worse than the SRFI rather than better. R7RS at least restored tradition and adopted some SRFIs, but I was disappointed that those very few cases where breaking compatibility was justified (records, parameters, etc.) wound up missed opportunities, as the SRFIs were adopted wholesale. Still, the situation is better than it was in R6RS. By the same token, some things that R6RS introduced that were novel and filled a role not otherwise covered by an SRFI (libraries, for example) were themselves ignored and abandoned by the R7RS committee, for seemingly no reason other than "R6RS bad". I think the R7RS libraries are nicer to use than the R6RS ones anyway, but it did irk some people. R7RS should have been two steps back and two or three steps forward, but it wound up being two steps back and one step forward. I don't hate it; I think it's one of the better standards Scheme has had. Nonetheless, I see quite a few missed opportunities there, which makes me feel a little wistful ;)