3 ms·

>R7RS-large, though, is shaping up to be something I find really quite distasteful as a Schemer, possibly even moreso than R6RS Why so? It seems alright to me,

>R7RS-large, though, is shaping up to be something I find really quite distasteful as a Schemer, possibly even moreso than R6RS Why so? It seems alright to me, but I haven't been a Schemer as long as you have. >and after learning CL, EuLisp, ISLISP, and Le-Lisp, my ideas of what it means to "be Lisp" have changed a bit (not that I find Scheme bad in the least, quite the opposite, but I've developed an appreciation for the more traditional dialects, and I've discovered that my ideal is somewhere in the middle). 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. 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. Imagine a macro like: (report-usage cdr (foo)) Which would show every usage of cdr within foo, and what args it was called with. AFAIK, you can't do this in CL. You can in PicoLisp, but that's because PicoLisp is essentially Lisp 1.5 reborn, with all the benefits and disadvantages thereof. Like slowness. >I know we've had this discussion before, but please remind me why it is you don't like syntax-case. The API is both syntactically and semantically overcomplicated. It violates the standard macro abstraction (forms aren't just lists that you can CDR down, they're now "datums"), for little benefit, IMHO, and in general seems satisfied to heap complexity upon itself. Because of the semantic complexity, I think any new API that stands a chance at fixing the system would have to radically alter the internals. >Gambit's debugger is a dream. Is Guile's similar? I haven't used Guile much since 2.0, but that's going to change soon. Both seem to be semi-inspired by CL's error system. So yes, I think. I haven't had a ton of time with either, though... >IR macros are my favorite low-level system by far. Their implementation in chicken (which I once ported to Chibi) That was you? I remember that! >Shinn made a v2 of snow and included it with Chibi. I've got my fingers crossed that it gains traction this time. I hope so, too. Chibi is a really nice implementation. >That feeling right there is what prompted R6RS to grow so much ;) 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.

groovy2shoes 10y ago
> 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 ;)

groovy2shoes 10y ago

> 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 ;)