'modern' in the sense of Scheme being modern in 1975?
SCHEME: An Interpreter for Extended Lambda Calculus, Sussman/Steele, 1975
SCHEME: An Interpreter for Extended Lambda Calculus, Sussman/Steele, 1975
Scheme is actively developed by a large community.
Only the small language. Looks to me like a plain old Scheme slightly updated.
The first part of r7rs-large also got finalised as the Red Edition [0].
Scheme's roots do mean the standardisation process can move slowly at times, taking guidance from "living standards" like Chez. That's not necessarily a bad thing.
The differences just tend to be including SRFIs, that everyone already use, in the standard.
We refer to ES2017 as "modern", despite the fact that all it's shiny new features are ones that both CL and Scheme, and Smalltalk to a degree, had twenty years ago.
"Modern" tends to mean "under active work today". C++17, PHP7, Python 3.7, all these are referred to as "modern".
Scheme is actively developed today. That's modern enough. (And has had all the shiny features other language's consider "modern" for years).
> Especially if you look at Guile, the manual looks frightening - an implementation which has no clear language design, but accumulates stuff from SRFIs, R6RS, R7RS, own stuff
I have no idea where you're pulling that from.
The language design seems clear enough [0] to me, in the manual.
> but accumulates stuff from SRFIs, R6RS, R7RS, own stuff
I don't see how that's a problem. Common libraries are included, as well as backwards compatibility, and some extensions. How is that different from GCC, MSVC, Luajit, etc? Even CPython has extensions on Python's language reference.
In fact, what about SBCL? [1]
The manual seems straight-forward, and easy to understand to me. No different from any other language manual. More detailed and just as straight-forward as SBCL's.
[0] https://www.gnu.org/software/guile/manual/guile.html#About-D...
'modern' was not my word. See the discussion above.
> We refer to ES2017 as "modern"
I'm not part of your 'we'. In the context of Javascript the newer iterations may be slightly more modern, but in the wider context of dynamic / dynamically typed language there is very little 'modern'. If you read the language deltas, they are not THAT impressive.
> "Modern" tends to mean "under active work today"
Not for me. See for example in a dictionary: 'involving recent techniques, methods, or ideas'. Much of the stuff in Scheme is decades old and has been provided incompatible in multiple ways, none really satisfying. See 'Error handling'.
> I have no idea where you're pulling that from.
Just look at the table of contents:
https://www.gnu.org/software/guile/manual/guile.html#SEC_Con...
> I don't see how that's a problem.
Several error handling libraries, none really good and all not well integrated into the rest of the language. That's really basic stuff which hurts. Instead of at least an attempt at a coherent language it is a patchwork of tiny stuff.
> In fact, what about SBCL? [1]
What about it?
> More detailed and just as straight-forward as SBCL's.
SBCL has already the core language defined in detail. Example from above: there is one error handling mechanism (the Condition System) and it is used everywhere and it is well integrated.
Then nothing is modern in the programming language world, for you, and you're not up for a discussion.
Rust's type safety is old, Scala's DOTTY is the exploration of combining several older theories to create DOT, and both of those are supposed to be cutting edge.
Modern Scheme has:
* Lazy, immutable, mutable subsets
* Hygenic and unhygenic macros
* Fast and simple error handling
* Fast and simple compiling and evaluation
* Tail call elimination
* Procedures, closures, currying
* Safe eval, and generative environments
* Multi-threading and asynchronous callbacks
It's simple and powerful enough that people commonly plug object-orientation, type safety and DSLs into it.
What is left for you to consider modern?
> Just look at the table of contents
Wow. It looks like a table of contents. Starting with a short introduction, and slowly expounding on previous knowledge to detail the entire language. Looks remarkably similar to the manuals for SBCL and ECL, simpler than Python, Rust's Reference and Julia.
All you're giving me... Is that you're afraid of TOC pages. Which I'm hoping is not the case.
> Several error handling libraries, none really good and all not well integrated into the rest of the language. That's really basic stuff which hurts. Instead of at least an attempt at a coherent language it is a patchwork of tiny stuff.
I cannot agree with you here.
There are several ways of error handling, because error-handling lazy, immutable, mutable and object-oriented things can't be done in the same way, to the level of detail that Scheme will hand you.
But, if you want one simple, high level approach to handle them all... You're looking for the Exception stuff.
(with-exception-handler
...code...
(exception-handler ...error handling func...))
(In fact, most other error systems are only there for backwards compatibility with previous versions of the Scheme standard.)
> In fact, what about SBCL?
> What about it?
It differs from the Common Lisp spec in much the same way as Guile, as the link pointed out. Apparently you find only one of these facts confusing.
> SBCL has already the core language defined in detail. Example from above: there is one error handling mechanism (the Condition System) and it is used everywhere and it is well integrated.
And the same is true of Scheme. You have the Exception system, used everywhere. When finer-grained control is desired, you also have that available.
The Scheme "core language" is right here [1].
The semantics of the language are well spelled out, and the standard library is also spelled out.
The only difference any compliant-implementation, like Guile, has, is a larger standard library. Any infix-operators, or S-XML, or any of these other things... Is just a library. Anything beyond r7rs-simple, is just a library.
Your complaint with the spec seems to boil down to "Scheme keeps the most popular things around to make backwards-compatibility easy, and upgrading easy".
[1] http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7r...
> * Lazy, immutable, mutable subsets
> * Hygenic and unhygenic macros
> * Fast and simple error handling
> * Fast and simple compiling and evaluation
> * Tail call elimination
> * Procedures, closures, currying
> * Safe eval, and generative environments
> * Multi-threading and asynchronous callbacks
> What is left for you to consider modern?
Scheme had all of these 30 years ago, and most of them 40. What kind of an argument are they that it's "modern"?
> There are several ways of error handling, because error-handling lazy, immutable, mutable and object-oriented things can't be done in the same way
> You're looking for the Exception stuff. [...] In fact, most other error systems are only there for backwards compatibility with previous versions of the Scheme standard.
So which one is it? The second point seems to agree with lispm anyway; they complained about multiple redundant ways to do something in a "modern" language, and your explanation is that most of those ways are historical cruft.
What would you consider a modern feature? I don't know of anything in the last ten years that could be considered new. This is the second time I'm asking, if no one can answer that...
We can only have one conclusion: No language can be considered modern by this definition, rendering it fairly useless as a definition.
---
> So which one is it?
Allow me to quote myself:
> You have the Exception system, used everywhere. When finer-grained control is desired, you also have that available
> they complained about multiple redundant ways to do something in a "modern" language, and your explanation is that most of those ways are historical cruft.
That was not my explanation. Some are historical, some giver finer grained access.
syntax-error allows you to control error handling within macro-expansion time, for example.
scm-error allows you to output your own backtrace, including asm if the compiler supports it, and strerr allows you to output Unix errors.
For starters: one that was thought up (or at least added to the language, if we're being that context-sensitive) more recently than 30 years ago.
> No language can be considered modern by this definition, rendering it fairly useless as a definition.
I agree that it's a fairly useless descriptor.
This does not really follow what I quoted. I'd also say that 'modern' may have some context dependency, but selling 40 year old stuff in the context of Lisp as 'modern' will not do it.
I would for example consider the specific support of multi-methods in Julia as 'modern' and interesting. This would allow me to use CLOS like programming constructs in areas where high-performance is wanted.
> The Scheme "core language" is right here [1].
Does Guile implement R7RS small? The manual claims it does not implement the latest version...
> Anything beyond r7rs-simple, is just a library.
R7RS small is too small and for anything else there are multiple libraries with overlapping functionality. I'm also not a big fan of splitting up a language into tiny libraries.
If one removes the overlapping stuff from the Guile manual, I'd guess that 50% had to go and some of the rest needs to be redesigned and better integrated. Then it would still not be 'modern', but at least cleaner.
(define-method (+ (x <string>) (y <string)) ...)
(define-method (+ (x <matrix>) (y <matrix>)) ...)
(define-method (+ (f <fish>) (b <bicycle>)) ...)
(define-method (+ (a <foo>) (b <bar>) (c <baz>)) ...)
The point of r7rs-large is to eliminate overlap. As to *-small being... Too small... R5RS is still quite popular, and quite small, whilst still being quite capable.
However, Guile does not implement the whole of R7RS, yet. Instead they've implemented both R5RS and R6RS, for backwards compatibility, which is where you're seeing the overlap. When R7RS is a fully fleshed out spec, Guile intends to implement it, as well.
[0] https://www.gnu.org/software/guile/manual/html_node/Methods-...
A feature which is 30 years old.
What I was referring to is how multi-methods SPECIFICALLY are designed & implemented in Julia, not multi-methods as such. The Julia implementation of multi-methods looks 'modern' in the context of Lisp.
Scheme specifically doesn't specify how something should be implemented, just the result.
> The Julia implementation of multi-methods looks 'modern' in the context of Lisp.
Does it?
Guile's methods are generic functions, like in CLOS, and get JIT'd like with Julia. And the dispatch, being based on the given arguments, rather than the given object, is identical. If no qualifier is given for an argument, Guile treats it similarly to Julia's Any. Julia and Guile eliminate runtime-dispatch in a similar way.
Then people implement it. Developers then choose the implementation based on the capabilities of those.
> Guile's methods are generic functions, like in CLOS, and get JIT'd like with Julia
Julia uses generic functions throughout and it has a JIT. Guile uses Goops almost nowhere and a JIT is not released.
If one would remove Goops from Guile, would anyone notice? That's what the manual shows: a collection of unrelated/unused features.
I asked what you would wish to see, and then provided it.
I've teased details out of your sentences that are more implication than statement.
You're constantly shifting the bar for what would answer the original question, "Is Guile a modern Scheme?"
I'm bored of it.
So, I'll spell out a few more things, and then you can happily say you've won the argument.
> Then people implement it. Developers then choose the implementation based on the capabilities of those.
I said the Scheme specification was modern. This seems irrelevant to that statement.
If it's about Guile instead, the details are available, though it doesn't seem that you have read them.
> Julia uses generic functions throughout and it has a JIT. Guile uses Goops almost nowhere and a JIT is not released.
Patently false. Guile has had a JIT since 2.0.0. [0][1]
I should note that was in 2011, six years ago.
> If one would remove Goops from Guile, would anyone notice?
If I were to remove pattern matching from Clojure would anyone notice? Now allow me to complain that usage somehow is equivalent to integration.
> That's what the manual shows: a collection of unrelated/unused features.
Let me quote someone else from this thread:
> ...The Common Lisp spec is quite a bit more modern than 1958 ... it's a well-crafted ANSI standard. It does suffer from backwards-compatibility... [2]
Seems Common Lisp also has that problem... And you don't have a problem with it.
[0] http://lists.gnu.org/archive/html/guile-devel/2011-02/msg001...
It's the same old Scheme, repackaged.
> Patently false. Guile has had a JIT since 2.0.0. [0][1]
That's simply not true.
It's not in the 2.0.0 release. What you point to is experimental & abandoned code.
There is a new JIT called Nash for Guile, but it's also not in the released version.
https://www.youtube.com/watch?v=JM1uU07xMQs
> Now allow me to complain that usage somehow is equivalent to integration
Search through the Guile code. Goops is almost nowhere used. How can it be integrated?
Evidence falls on deaf ears.
Scheme is neat (in multiple meanings of the word), but honestly I don't think it's a good production tool. Being a Lisp-1 & lacking real macros means that it's more suited to being a pedagogical tool (n.b.: I believe that many Scheme implementations add real macros — but without a standard package system and a function namespace, this is not enough).
What do you mean by that? That implementers extend the language?
> Being a Lisp-1 & lacking real macros
Scheme has defmacro just like CL.
You can modify the reader and change the AST.
What does Scheme lack in macro-land?
> but without a standard package system
R7RS includes one. Currently implemented by Chez and Guile, to my knowledge