4 ms·

I can't speak for others, but I know that, and I think that it is consistent, rather than inconsistent, with my points 1) that Scheme is fine as an academic lan

I can't speak for others, but I know that, and I think that it is consistent, rather than inconsistent, with my points 1) that Scheme is fine as an academic language and 2) Common Lisp is preferable for real programs. Scheme's simplicity is awesome if you're implementing it; it's awesome if you're learning it; it's not so awesome if you're trying to actually use it. As LoL notes, it's dumb to throw away information in conditionals. As LoL also notes, hygienic macros are toys and DEFMACRO is generally what you really want. I'll add that having only a single namespace for variables, classes, functions, types, packages & everything else means that you end up having to be extremely verbose: foo, fooClass, fooFunc, fooType, fooPackage. call/cc is incredibly cool & powerful, but also really hurts efficiency in a way that I don't think is acceptable in a production system (it's fine, of course, in a teaching language, because the experience of understanding it is really useful). dynamic-wind is broken compared to UNWIND-PROTECT. And on & on & on. Steele also wrote the Java spec, and he wasn't wrong when he said 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp,' but I don't think in 2019 anyone thinks that his involvement with Java means it is anywhere near as good, powerful or acceptable a language as Lisp.

bjoli 8y ago
This is uninformed and wrong. You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case). The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to be comparable to unwind-protect, but that would render continuations useless for other things than escapes. The single namespace has roughly one one common consequence: having to name your lists lst, which is easy. Types and classes are by convention <type>. Continuations are cool and useful, although full blown ones are ugly. Delimited continuations are making their way into some schemes. In guile they are used to build guile-fibers, which are really cool. The only thing common lisp really brings is cross-implementation compatibility. Compared to <your favourite scheme> it is mostly a matter of taste and, compared to some implementations, maturity.
- kazinator 8y ago
  > You can implement defmacro in 8 lines of syntax case. Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda lists) Hygienic macros are basically wrong. A good way to express why they are wrong is by analogy. In visual art, as a joke, we can paint paintings that perpetrate deliberate errors of perspective: some feature obviously in a distant background reaches into the foreground in an incorrect way and overlaps or interacts with foreground objects. There is precisely such an absurd situation between the lexical scope of a hygienic macro definition, and that of the macro call site. The macro injects code into distant call sites, yet that code makes lexical references into the macro definition, like the silly character jumping out of an inner painting into an outer painting. I don't ever want that; I don't want the code generating system (the macro) to be wrongly mixed up with the generated site. If the macro generates some symbol X, that should refer to an X definition that is lexically (or in any other manner) apparent at the call site, even if that is a bug. If I make that bug, I will own that bug. I do want macro generated code to refer to a clearly defined set of run-time support symbols, if that is required, not coming from some random lexical scope enclosed in a macro definition, but from a global scope. Referring to a private scope of the macro definition is horribly wrong. That scope must completely die when the dust settles. It's not necessarily even on the same machine. When the macro is running and its scope is active, it's on some build farm. When the code is running, it's on a target system. Why would the target environment refer to the build environment? No hacker interested in constructing practical systems from the ground up could have invented hygienic macros; they are an ironic joke coming from idle minds.
  - bjoli 8y ago
    Having a macro in one module refer to bindings it has no idea about what they are seems nasty to me. I'd rather have hygiene and break it where I chose to. That seems less error prone.
    - 8y ago

bjoli 8y ago

This is uninformed and wrong. You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case). The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to be comparable to unwind-protect, but that would render continuations useless for other things than escapes. The single namespace has roughly one one common consequence: having to name your lists lst, which is easy. Types and classes are by convention <type>. Continuations are cool and useful, although full blown ones are ugly. Delimited continuations are making their way into some schemes. In guile they are used to build guile-fibers, which are really cool. The only thing common lisp really brings is cross-implementation compatibility. Compared to <your favourite scheme> it is mostly a matter of taste and, compared to some implementations, maturity.

kazinator 8y ago
> You can implement defmacro in 8 lines of syntax case. Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda lists) Hygienic macros are basically wrong. A good way to express why they are wrong is by analogy. In visual art, as a joke, we can paint paintings that perpetrate deliberate errors of perspective: some feature obviously in a distant background reaches into the foreground in an incorrect way and overlaps or interacts with foreground objects. There is precisely such an absurd situation between the lexical scope of a hygienic macro definition, and that of the macro call site. The macro injects code into distant call sites, yet that code makes lexical references into the macro definition, like the silly character jumping out of an inner painting into an outer painting. I don't ever want that; I don't want the code generating system (the macro) to be wrongly mixed up with the generated site. If the macro generates some symbol X, that should refer to an X definition that is lexically (or in any other manner) apparent at the call site, even if that is a bug. If I make that bug, I will own that bug. I do want macro generated code to refer to a clearly defined set of run-time support symbols, if that is required, not coming from some random lexical scope enclosed in a macro definition, but from a global scope. Referring to a private scope of the macro definition is horribly wrong. That scope must completely die when the dust settles. It's not necessarily even on the same machine. When the macro is running and its scope is active, it's on some build farm. When the code is running, it's on a target system. Why would the target environment refer to the build environment? No hacker interested in constructing practical systems from the ground up could have invented hygienic macros; they are an ironic joke coming from idle minds.
- bjoli 8y ago
  Having a macro in one module refer to bindings it has no idea about what they are seems nasty to me. I'd rather have hygiene and break it where I chose to. That seems less error prone.
  - 8y ago