My resignation letter as R7RS-large chair | Hacker News Reader

My resignation letter as R7RS-large chair

groups.google.com

154 pointsnickmain176 comments

It'd be neat if someone familiar with Scheme standardization laid out some of the big disagreements in R7RS-large, or else most of this thread will just be a Scheme vs. Every Other Language discussion.

I've been trying to get up to speed myself. It seems like the best way is simply reading the mailing list and checking out the codeberg issues. This issue [1] was given as an example of a non-technical problem that's easy to get distracted by when most of the core technical work should be straightforward. It's referenced in this candidacy statement [2] for John's chair position which is a good read to understand what's happening. It's essentially the classic language debate of breaking compatibility with past version versus evolving the language, and seems pretty complicated. I'm sure there are other problems. I'm still reading.

[1]: https://codeberg.org/scheme/r7rs/issues/126 [2]: https://groups.google.com/g/scheme-reports-wg2/c/TUbmlPY9lR0

The second link provided here has a little overview of Daphne's thoughts on why things are dragging on:

> The establishment of the central issue tracker is, I reckon, more to blame for the current disputes. The old model of periodic ballots provided the community with focus; the issue tracker has the problem that, since all currently outstanding problems are listed in one place, any such problem can become a focus of attention at any time, and then arguments about the details of that problem erupt. John has observed in #scheme that the more into detail we get, the more we seem to argue, which seems accurate. It has also, in practice, become a place where issues related to the Foundations only are discussed, and work on the Batteries has mostly stalled. Mea culpa!

r6rs was hugely controversial for many reasons. r7rs-small went back to the r5rs roots, whereas many of us (yes, me included) thought building on r6rs would be the better choice.

Much of the process that was started in r6rs led to racket. Kent Dybvig was the head of the standards body and the racket folks were also active in the mailing lists. I think a big part of the disagreement was about correctness. r6rs guarantees some things about a running program that is difficult to do for many small hobby projects. There was also a discussion started about things like immutable data (pairs and strings, mostly) which got people all hot and bothered.

The problem with r7rs-large is that it will have to solve many of the problems solved by r6rs (low level macro system, how to handle unicode etc...) which means redoing the r6rs work.

Could someone fill in the background? R7RS seems like an unlikely venue for hot conflict, but then again I haven't been a scheme user in decaes.

What is R7RS?

Revised report version 7. The current scheme standardization. It proceeded R6RS which many felt was too large, and added too many things to the scheme standard (it’s only 90 pages long). R7RS was the compromise

Exactly. R7RS-small was meant to be a minimal core language, in the spirit of RnRS for n <= 5, whereas R7RS-large was meant to be a fairly complete set of standard libraries.

It's the Revised Revised Revised Revised Revised Revised Revised Report on the algorithmic programming language Scheme. That's 7 "Revised"s, hence R7RS. Basically the RxRSes are full specifications of what you need in a Scheme implementation to conform to the Xth iteration of the language.

(Revised (Revised (Revised (Revised (Revised (Revised (Revised Report)))))))

I like using arrow-macros (threading macros) myself;

  (-> report
      revised
      revised
      revised
      revised
      revised
      revised
      revised)

That is not in the style of srfi-197.

    (chain report
           (revised _)
           (revised _)
           ...)

There are benefits to this approach, such as it handling both applying returned lists and multiple return values by default.

(very (very (very (well (said)))))

that's an interesting naming convention!

  CL-USER 21 > (let ((n 7)
                     (report '(report)))
                 (flet ((revise (report)
                          (cons 'revised report)))
                   (do ((report report (revise report))
                        (i 0 (1+ i)))
                       ((= i n) report))))
  (REVISED REVISED REVISED REVISED REVISED REVISED REVISED REPORT)

So weird seeing CL code without a bunch of (declare (type (integer 0) n))'s everywhere. That's the only thing which keeps me with CL instead of Scheme (I'm rather fond of syntax-rules, case-lambda, case sensitivity, and being able to do things like...

  (define range+ (make-range-merger +))
  (define (double-range range)
    (range+ range range))

, which I think is a little nicer than

  (setf (fdefinition range+)
    (make-range-merger #'+))

or having to precede range+ with funcall everywhere I want to use it).

Personally I find Common Lisp in some cases slightly uglier, but clearer.

  (define foo (make-foo))

What is it? A function or a non-function?

I prefer the Common Lisp version:

  (defvar *foo* (make-foo)
    "*foo* is the current input/output foo object.")

It's clear that DEFVAR usually defines a variable and not a function. Bonus: we can document the thing in a standard way.

For functions I would define a define macro.

  (define foo (make-foo)
    "foo is a function with two arguments of type bar, it returns ..."
    (ftype (function (bar bar) baz))

Which would expand into a (setf fdefinition), a type declaration and setting the documentation.

I prefer the uglier, but better standardized and slightly more practical language.

I don't have much more context than you, but one bit I did catch is that this resignation is for "R7RS-large" and not "R7RS-small" (which might even be complete already).

Traditionally, Scheme is as minimalist as possible by design. Therefore, the very idea of "R7RS-large" is likely controversial to some parties involved.

Apparently it has been an on-going argument for years on just what to include in R7RS-large, as we can see a Reddit thread from 2 years ago asking when it will be ready[0] and John Cowan (the person who is resigning from the committee) saying parts one and two are done and part three should "follow quiuckly thereafter".

> That depends entirely on how much time people can devote to it. The first two parts, Red and Tangerine, are already in place; Orange needs a few things pulled together before it can be voted on, and Amber should follow quickly thereafter.

I'm guessing getting that last 90+% of agreement stretched ever further and further on and as John said in the resignation letter, it was surely exhausting.

[0] https://www.reddit.com/r/scheme/comments/nohfwe/when_will_r7...

> "R7RS-small" (which might even be complete already).

I believe r7rs-small was finalized over 10 years ago.

Indeed, but not by a large margin. https://small.r7rs.org/attachment/r7rs.pdf says “July 6, 2013”

R7RS seems like an unlikely venue for hot conflict, but then again I haven't been a scheme user in decades.

It appears to be an instance of Sayre's Law: https://en.wikipedia.org/wiki/Sayre%27s_law

Scheme is an especially appealing elegant and powerful language. And it attracts people who aren't in software or programming languages for the money.

So, the stakes are very small, in terms of commercial value, but...

If you think of Scheme as an oasis, relative to most popular programming languages and communities, then the stakes can be quite large.

Right, that's what I mean. It doesn't mean something to everyone, but it means everything to a few.

Yeah, I think there's an ambiguous connotation sometimes, such as in "academic politics is so fierce, becuase the stakes are so small" that it might just be people being petty about, say, small-pond status, because they have nothing else.

In this case, however, it might be more that there's an innate value that a small number of people recognize as important, so they care about it in a way that seems outsized, to people who aren't aware of that importance.

I think programming language standards committees are not an unlikely venue for hot conflict, quite the opposite if you talk just about conflict without the word "hot". I don't have the background on this one though.

Do you have any experience reaching to similar organizations? for example reporting compiler or linker bugs or trying to get support for new features or platform that are not well documented? If you don't and think it sounds fun go ahead and have fun if you can do that work without getting dragged into hot conflict.

The Scheme community has long held tension between people who want to use Scheme as a teaching language, versus those who want to use it for writing real-world programs.

The former want the language to stay as minimal as possible with a tiny standard library so that there are fewer concepts and options for students to stumble over. The latter want a full-featured language (but still minimal, it is Scheme after all) with a large standard library of useful types and functions so they can get stuff done.

These two perspectives are both reasonable but fairly incompatible.

For most of its history, Scheme leaned towards education. Around the type of the sixth edition (RSR6), pulled somewhat the other way and the language and library spec got much bigger. This alienated a lot of folks who wanted to stay a small teaching language.

For RSR7, they tried to resolve that by simply splitting the language in two: a small one and a large one. Then each subcommunity can have what they want.

Around the same time, the language PLTScheme renamed itself to Racket to clarify that they aren't trying to be beholden to the overall direction of the Scheme community. Racket is also a "large Scheme" in that it's a Scheme-derived language that tries really hard to be batteries included for all sorts of uses. It also can be "subset" into smaller languages for use in teaching.

My impression (from far on the outside) is that Racket has taken up a lot of the oxygen, which may partially explain why RSR7-large never managed to reach consensus and ship.

That is extremely well written thank you.

Indeed, thanks for the explanation. Not being super familiar with the Scheme community, “R7RS” sounds like a high-performance Audi.

It's the Revised Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme, or (Revised)^7 Report on the Algorithmic Language Scheme, or R7RS.

(Because, of course, Scheme folks couldn't resist the urge to use a little recursion in the name of the spec instead of defining it as an iterated series of version numbers.)

But its both. Even if you don’t get the joke, you can pretty easily tell that R4RS, R5RS, RNRS represent an ordered list.

Thanks for the summary. Unless I am missing something, this seems like a pointless argument that the scheme community has. Why not just create a library separate from the standard and call it a day?

Because of homoiconicity and macros, the line between "language" and "library" is deliberately extremely blurry, if such a line exists at all.

Take a look at the list of proposed features and try to decide if you can clearly bucket them as language or library: https://srfi.schemers.org/

Thanks for giving some context on the matter. If the base language is not capable to provide a way to implement those, then that makes sense. I do like the idea of having the base being small but still capable to allow for these features to be implemented in a library. From the link you gave, it does seem that these would require more support than what is available in a smaller language.

> My impression (from far on the outside) is that Racket has taken up a lot of the oxygen

For real world applications rather than education Racket and Clojure as well, in fact Clojure has taken up a lot of the oxygen across a variety of niche FP language eco systems. The Clojure toolchain and library support (much of it through the JVM and Java ecosystem) is excellent and far ahead of Racket for most of the same applications. But Racket starts faster and has a much smaller memory footprint. Depending on your workload and compatibility demands either the one or the other will be a clear favorite with Clojure coming out ahead.

But all of these and scheme (which I think is mostly propped up by virtue of being used a lot in education, I've yet to come across scheme in the wild) are very much niche languages. Clojure really does have an advantage of standing on the shoulders of Java and the JVM, without that I don't think it would have gotten as large as it did.

…but, we were talking about scheme, not clojure right?

> Clojure really does have an advantage of…

Look, I’m a fan of clojure, I spent two happy years using it. …but it seems obnoxious to bring it up here like this.

Is there really any reason to think that clojure has taken the wind out of the sails of the group of people who were using scheme?

It seems like a massive, totally unsubstantiated take, that really doesn’t add anything here.

Well, that may be your impression. But I know of two cases where scheme was being considered for commercial work and in both of those the decision was made to go for Clojure instead. It was relative to Racket as a replacement for more real world applications of Scheme that I mentioned this.

The aggression in your response is entirely disproportionate to the comment you're replying to. I don't know who peed in your Cheerios, but it wasn't jacquesm.

We're talking about a minimal dynamically-typed Lisp language and speculating about its challenges around adoption and consensus. Given that Lisps are already a niche language, it's completely germane to bring up another minimal dynamically-typed Lisp that has almost certainly captured some of the overall small potential userbase.

The whole situation feels - as a total outsider - pretty bikesheddy. The lower the real world stakes, the higher the tension.

Spot on, that's why scheme is and probably always will be very much a niche language. They're not even trying. I wished we could collapse the Cambrian explosion of computer programming languages back into a small subset of what it is today to get fewer but healthier eco-systems. The amount of fragmentation is absolutely insane, and leads to a ton of duplicated effort and wasted resources. There are 100's of computer programming languages in active use and beyond say the top 100 or so there isn't much that isn't already covered multiple times.

But with the widespread connectivity that we have it is very easy to launch a new language and to gain some small level of adoption. Programming languages are like kids: you can launch them in a night but it takes a lifetime of dedication and support to make them successful and given how hard it is to distinguish a small effort going nowhere from a future winner all this does is saddle up outsiders with the cost of maintenance or ultimately a rewrite in some other, hopefully wider supported language.

It would be great if people would just label their languages clearly as 'experimental, not meant for production' and 'long term supported' up front. Some languages, notably, 'Haskell' are successful in spite of actively holding back large scale adoption. This is a much healthier approach. It shows that the language really has merit.

If you really want to undo the Cambrian explosion, you will get Fortran and Lisp. A better SQL, Prolog, and something like Haskell might also be useful/necessary.

ala Sayres law

https://en.wikipedia.org/wiki/Sayre's_law?wprov=sfti1

Well, a quick search into this found this talk from John Cowan that appears to be from 2011 on R7RS - https://www.youtube.com/watch?v=kC7xPBQWsVE

I honestly don't think there can be any value in a standard that takes so long to come up with. Now in an industry that moves as quickly as this one.

Lisp is 65 years old and its future will be longer than its past! Another way to look at a fast-moving industry is that it's all hype and flutter with the occasional solid achievement.

Thanks to John Cowan for all his work on a very challenging PL standards efforts.

Someday, I'd be interested in what were the process difficulties overcome, and how, and what are the remaining problems or costs.

(Disclosure: I was involved in the working groups, briefly and in a much lesser capacity.)

What's the overall Scheme community look like these days? How much are new libraries targeting the specifications (like R6RS) vs. just targeting a specific implementation like Racket, Guile or Chicken Scheme?

What forces are keeping the various implementations aligned and moving in the same direction? What is driving them apart? What does the future look like?

I'm just watching this as an observer, but I suspect a lot of it is:

People who want to write real-world Scheme code have a strong incentive for a single definition of the language so that their code will reliably run on multiple implementations. They want one language and are probably willing to deal with some breakage in places where implementations are alreaday incompatible in order to get there.

People who maintain Scheme implementations want backwards compatibility so that they aren't forced to rewrite a bunch of already working implementation code or try to support multiple different languages at the same time. They don't want to make breaking changes to their implementations and break all of their users in order to converge towards some other implementations' behavior they may not care about.

Teachers want a language that is maximally elegant and minimal. They are perfectly happy to make tweaks to the language to make it incrementally cleaner even if it breaks tons of existing code because most of their code is short-lived anyway.

Reconciling these very different incentives does not sound fun.

Like herding wild, feral and domestic cats - all at the same time.

https://en.m.wikipedia.org/wiki/Cat_Herders

Very well said. A fourth group is people maintaining existing user code (including libraries), who also want backward compatibility.

I am usually only targeting guile, mostly because of guix. Guile or chicken seems to be the most popular schemes, but Chez is a compelling choice when there are no external dependencies.

Racket is far and away the most popular Scheme (and I reject the claim that it is not Scheme).

Hi John! I have always made the claim that racket (minus the #lang bit) is the natural continuation of r6rs. Delimited continuations, immutable pairs, continuation marks and such. They also chose, in my opinion, some more sane paths with regards to the dynamic environment and laziness.

If one could make a wish list it would be the suggestions in Marc's proposal in the chez issue tracker, immutable pairs, immutable strings, and RRB trees in the standard library. Like an opinionated love child racket and Clojure :)

Even though I am more.of an r6rs guy I have always applauded r7rs large. At the same time I am glad you put your own health first. That is always the most important. Apart from the r7rs process, your contributions to all SRFIs I have been following has been amazing.

Take care.

Does anyone actually use Scheme for real projects? The only places I've ever seen it used have been in classrooms.

Like all lisps it is niche. I don’t use scheme but have used Common Lisp and clojure for a few years. Racket has a thriving community as far as I can tell. You just don’t see lisp much in the wild but it’s there.

My totally uneducated and uninhibitedly snarky guess is that people who use any Lisp family language (except maybe Clojure) don't go around talking much about that fact, or thumping their chests about it, unlike (some) Ruby, Python or JS users. They probably just quietly go about using it and having fun, and talk about it when they meet each other.

Guile Scheme is used extensively in the Guix linux distribution, and works quite nicely there.

extreme niche on extreme niche.

Which is terribly unfortunate, because it solves very non-niche packaging problems in a very elegant way.

I had to use Nix in a project of mine and was surprised at how clunky it felt compared to guix. Writing packages meant string concatenations and juggling outputs to the command line.

I prefer guix. Every day of the week.

Same here. I used NixOS as my desktop operating system for a few months I think. It did not go great. After hopping a to a few other distros, now I've been using Guix as my OS for a few years.

Guix is niche, but it's very much 'real software'. It does useful things well, and it solves some problems that very few competitors adequately do. It's used for reproducible scientific computing on some HPC clusters, which is a pretty cool niche if you ask me.

The Guix package collection is also sizeable and growing exponentially-- within a few years, it'll probably outgrow most Linux distros in terms of size.

Unless they have quietly rewritten it, HN itself is written in Scheme. Or, more precisely, it is written in Arc, which is implemented in Scheme.

For "precisely" read "correctly". Unless the implementation language is exposed to users of the implemented language, it doesn't matter what the implementation language is. gfortran is written in C and C++, but that does not mean Fortran programs are written in C or C++.

Okay, I think what I said was clear enough, but if we're splitting hairs, I'll say: that's a bad comparison because gfortran is compiled to machine code. When you run a gfortran program, you're not executing anything that was written in C.

When you run e.g. Python, the runtime written in C is indeed being executed. If nothing else in the world was written in C except the Python runtime, IMO it would still be fair to say that C is widely used. A security flaw in C compiler could potentially cause a vulnerability in any Python program.

The question was "is Scheme used for anything in production?" and it is correct to say "yes it is used for HN" even if HN is not directly written in Scheme.

It's currently used as a back-end for the Idris language. (Which is primarily a research language, admittedly.) It's a fairly popular target for languages to compile to, for similar reasons that C is -- small, well-defined, minimal, many implementations, runs just about everywhere. Very nice compilation target for functional languages in particular, as call/cc can, with reasonable efficiency, implement just about any kind of control flow/evaluation/threading model that you can think of.

Also, used as a scripting language in the GIMP.

C is neither minimal nor well-defined, as has been discussed extensively. Random blog post illustrating only some of the issues is here [1]. Just google “undefined behavior c” for a lot more. There are also a bunch of famous rants by Linus Torvalds on his topic.

[1] https://blog.regehr.org/archives/213

can we all agree that the undefined behavior is pretty well identified and documented? Plus, if you understand the entire language and then limit your imagination, C can be quite simple!

It's so simple to avoid undefined behavior, just never add two numbers, or dereference a pointer that you can't statically guarantee the value of.

Yes, it's a simple language. That's why there are no safe guards around INT_MAX + 1, or variants of that.

You can add two numbers. If the operands are signed you just need to check the operands before the addition to make sure you won't cause an overflow.

Which of course cannot be done portably except by drastic restrictions like "never add a number greater than MAXINT / 2 and never multiply a number greater than sqrt(MAXINT)".

Soon™ we will have ckd_add etc. in the standard for this sort of thing, after several decades finally exposing functionality that any non-exotic CPU provides.

Except RISC-V, because RISC-V. Or, I expect, because they must have gathered statistics from a big chunk of real-world (mostly C and -compatible) code and got a bit fat nothing for the usage of the overflow flag—not because it's useless but precisely because you couldn't get at it from (compiler-independent) C.

Overflow isn't the only flag RISC-V doesn't have.

If floating point extensions aren't present, there aren't even flags.

Since we're talking about implementing a compiler that merely uses C/++ as a convenient intermediate representation, it doesn't matter much.

The Unison language JIT is being written in Scheme: https://www.unison-lang.org/whats-new/jit-announce/

I don't think the intention of Idris is to be a research language.

> Idris is primarily a research project, led by Edwin Brady at the University of St Andrews, and has benefited from SICSA (https://www.sicsa.ac.uk) and EPSRC (https://www.epsrc.ac.uk/) funding. This does influence some design choices and implementation priorities, and means that some things are not as polished as we’d like. Nevertheless, we are still trying to make it as widely usable as we can!

-- https://idris2.readthedocs.io/en/latest/faq/faq.html

At this point, the creator has described it as "Pac-Man complete", able and easy to implement a game like Pac Man. (Or itself - it compiles to Scheme but is written in itself.)

Dependent types are still rather new; I believe Idris and its libraries are one of the largest, if not the largest, body of general-purpose software that uses them. (F* maybe?) How to use dependent types properly in a standard library seems be an ongoing development.

The Pac-Man Complete bit is tongue-in-cheek. It's an observation that TC is rarely (if ever) actually needed in practice.

(This might sound strange to people unfamiliar with dependently typed langs, but infinite streams etc., servers that "loop forever" doing request-repsonse can still be modeled without TC.)

What is “TC”?

Turing complete

However it appears that Idris is Turing complete https://cs.stackexchange.com/questions/19577/what-can-idris-... https://gist.github.com/porglezomp/b7bbbecbac1c2289fc890a53d... so I'm confused.

Note the "codata" and also note that "main" is marked as "partial". Only the total subset of Idris is non-TC.

Note also the use of Fuel -- this is to provide "fuel" for the computation, but it's a data structure which can only decrease in 'size' -- which is used by the compiler to prove totality (termination).

("codata" is a way to model 'infinite' computations as data structures.)

Thanks for the correction. I misremembered reading something by Brady.

It's intended to be a practical research language. Its niche is as a dependently typed language that is useful for writing real programs. But it also needs to be a toolkit for research into dependently typed programming, since most of the devs have to publish.

I think the biggest issue with any lisp is that it's just too damn powerful of a language. This makes it super easy for developers to create their own little ecosystem of macros and functions that nobody else can understand. This can be absolutely disastrous for large teams and companies looking to hire.

Languages that force you to be more verbose and don't let you build your own ultra-powerful abstractions seem to work better for large teams where you can force everyone to adopt a standard style. This makes onboarding much easier too.

I dunno, I got a (Common) Lisp job, and I don't think I've ever had a problem where I didn't understand the semantics of a macro; people aren't just making a ton of them all the time for no reason, and the ones that are popular are from popular libraries (e.g. alexandria and iterate) and have clear semantics.

I think the same problem applies perfectly well to developers who "create their own little ecosystem of classes and functions nobody else can understand" -- I don't think [0] would be made any harder to understand by having macros involved.

[0]: https://old.reddit.com/r/programming/comments/15s0lp6/how_we... (only picking on it because I saw it recently)

People say this, but it hasn't been my experience in practice—the worst, most complex codebases I've seen have been in Python and Java.

But I guess they look simple and uniform at a superficial, syntactic level. If you can't follow that it's your fault, if you can't follow Lisp code it's Lisp's fault...

We use Gerbil/Gambit scheme in production. The new actor system makes it a very compelling.

How do you handle Gerbil's incomplete docs? I'll admit, when I was looking at them I had no clue how Schemes worked, but I found the lack of documentation to be a very difficult barrier.

i would wager that anyone ballsy enough to use gerbil in production is at a minimum very active on gitter and probably a contributor to the language

Remember Gerbil is a layer on top of Gambit, which has been 30 years in the making.

Gitter has been a great resource. Vyzo is very helpful in answering questions. The docs could use some work. But the code is fairly trivial to follow on most things.

Isn't Julia's parser still in Scheme?

Femptolisp, a "Scheme dialect"

For now, yes. The upcoming 1.10 release (which is now in beta) will switch to a pure Julia parser as the default (with the old Scheme parser available as an option).

Not because of any fault with Scheme per se (afaik), just that contributors to Julia are more likely to know Julia than Scheme, so it makes sense from a maintanence point of view.

note that in 1.10 scheme is still used for lowering (simplifying AST to IR which is a lot of code for julia)

Chicken Scheme is a high performance source-to-source (C) Scheme that supports the R5RS and R7RS (work in progress) http://www.call-cc.org/

I use Racket (a Scheme) for option trading.

https://github.com/evdubs/renegade-way

Great example, very readable and with a GUI as well!

Fascinating!

If you hadn't gone with Scheme, what's another language you'd have considered for this project?

Java and JavaFX.

How was your experience with Racket in this case vs Java (assuming you've had some FX experience to contrast it to)?

With Racket:

* I really enjoy using numeric towers and it is upsetting to me every time I go to another language where I can't just work with rationals as a default.

* Having statistics functions, a GUI library, and a plot library all part of the standard distribution is wonderful. Dependencies are kept to a minimum, which I appreciate. Everything feels coherent and not over-engineered.

* Poking around in the large standard library was straight forward and not difficult. I added candlesticks [1] to the plot library without understanding much of the plot library's design or implementation details. I think this would have been much more involved in many other languages.

Where I perceive Java as nicer than Racket:

* I wish Racket had real threads like Java. Having futures and places for actual concurrency / parallelism is not as nice.

* I wish Racket had the rich data structures built in as Java has. You need to reach for an external library for a sorted data structure; this is not ideal.

* Java's performance is great and its future is promising. Java already has some great GCs including low pause time GCs, Project Valhalla will add value objects to Java, and Project Loom will enhance the concurrency functionality offered in Java.

I don't have much JavaFX experience, but my perception is that it would be fine and just as "cumbersome" as Racket's GUI and plot libraries.

[1] https://docs.racket-lang.org/plot/renderer2d.html?q=candlest...

I've used Scheme a bunch in the past.

These days, I've been using PowerShell for economy data and some options stuff:

https://github.com/dharmatech/options-chain-marketdata.ps1

https://github.com/dharmatech?tab=repositories

I used it just the other day to work an aime problem for my middle schooler.

scheme@(guile-user) [5]> (exp (* (atan 1) -2))

$9 = 0.20787957635076193

scheme@(guile-user) [5]> (expt 0+1i 0+1i)

$10 = 0.20787957635076193+0.0i

a problem c/c++/java/js/python/rust/go can't handle after decades of progress. even my favorite R can't work this problem. scheme ftw.

Hmm. Python 3.11 (didn't test in earlier)

>>> from math import atan, exp

>>> exp(atan(1)*-2)

0.20787957635076193

>>> 1j**1j

(0.20787957635076193+0j)

thank you. i tested this on lc playground and yeah it does work.

What's the "aime problem" and why can't c/c++/java/js/python/rust/go handle it?

I did a little googol and found out it's like an accelerated math thing https://artofproblemsolving.com/wiki/index.php/American_Invi...

Okay, I was just wondering if there's something non-obvious here. I guess OP is just woefully misguided about languages other than scheme or "these languages can't handle it" means something more like "I don't know how to use those languages".

Decent complex types and library calls to do exponentiation, etc, don't always come for free in any given language environment. It's nice that it "just works" in many scheme environments (but this is not the only language runtime where this is true and it's not something that you can't work around).

The example the OP cited doesn't involve complex numbers. Atan(1) is pi/4.

Sigh.

1i is an imaginary number. We are discussing the difficulty in calculating i^i, not whether a language can do atan(1).

To be clear, it's a competitive exam and one of the primary feeders into the USA Math Olympiad team.

Many problems are quite challenging.

yeah it looks like everybody's focused on the mechanics of the computation and not appreciating the math i.e. why the two expressions compute to the same value.

We are not in an algebra II class. We are talking about the merits of scheme. You posted a relatively opaque comment and made a relatively unfounded assertion about whether other languages could do it.

It might have been better for you to have been a little more direct-- "I like that exponentiation of complex types just works in Scheme; I don't think that works in other languages!"

I'm not sure why you think scheme is unique in being able to do this-- indeed, it's one of the examples of std::pow on cppreference:

https://en.cppreference.com/w/cpp/numeric/complex/pow

> std::cout << "i^i = " << std::pow(i, i) << '\n';

> i^i = (0.207880,0.000000)

I also hope it wasn't a way to humblebrag that you have a kid in middle school that knows math that lots of other people around here don't (having forgotten it from alg2/precalc or just having trouble reading your comment). Know your audience and prevailing context, and be clear.

I think this is probably because you did not know how to type a complex number in R. The coefficient of i is not optional.

    > exp(-2 * atan(1))
    [1] 0.2078796
    > 1i ** 1i
    [1] 0.2078796+0i

As well as python noted in a sibling, Ruby handles this quite well out-of-the box.

Is your complaint just that some popular languages don’t have complex numbers as part of the core/stdlib?

The issue is that lots of languages don't make complex numbers part of what Lispers call the numeric tower, fully integrated into numeric operations, even if there is a complex library. Here's Guy Steele's 3-part smoke test for early Common Lisp implementations:

1. At the REPL, if you type `T` (true), and you get back `T`, the test passes.

2. Define factorial. Then type `(/ (factorial 100) (factorial 99))`. If you get back 100, the test passes.

3. Type `(atanh -2)`. If you get a complex number, the test passes. If you get the correct complex number [namely -0.5493061443340549+1.5707963267948966i] extra credit. Far too many non-Lisp languages return NaN or throw an exception.

Yes, the very website[1] on which you posted this comment is written in Scheme[2], for example.

[1] https://en.wikipedia.org/wiki/Hacker_News

[2] https://en.wikipedia.org/wiki/Arc_(programming_language)

Both of the links you share contradict your statement. ARC isn't scheme, and the hacker news link you posted as a source doesn't mention scheme either.

It's a dialect on top of mzscheme iirc. You're right it's not in scheme per se but used as "runtime target".

Naughty Dog used Racket as part of the development of The Last of Us.

[0] https://www.youtube.com/watch?v=oSmqbnhHp1c

Around 20 years ago I worked on commercial email filtering/archiving system implemented in MzScheme (now PLT) - it was relatively small code base, but very powerful.

I wrote an article about it in Russian (almost 15 years ago), for some reason google translate doesn’t work for archive url: https://web.archive.org/web/20210506123442/http://fprog.ru/2...

I chose Racket for a project that involved lots of AST manipulation. Those ASTs were already in s-expression format, so Scheme seemed a natural fit.

The lack of static types was annoying; Typed Racket helped, but was so slow I only enabled it during unit tests (more precisely: Typed Racket functions can be faster than those written in normal Racket, but calling them from normal Racket functions will be slow as it performs run-time checks)

https://github.com/Warbo/theory-exploration-benchmarks/tree/...

I assume that Cisco is using Chez Scheme for something since they bought it (and open sourced it).

Racket is very used in the PLT community (programming language theory) for prototyping programming languages. Lots of cool stuff in this area.

For example, the MIR formality [0] project of the Rust programming language to formalize MIR (their intermediate language) was first prototyped in Racket [1], then rewritten in Rust. [1]'s readme give a rationale:

> For the time being, the model is implemented in PLT Redex. PLT Redex was chosen because it is ridiculously accessible and fun to use. It lets you write down type system rules and operational semantics and then execute them, using a notation that is very similar to what is commonly used in published papers. You can also write collections of unit tests and fuzz your model by generating test programs automatically.

> The hope is that PLT Redex will prove to be a sufficiently accessible tool that many Rust contributors will be able to understand, play with, and extend the model.

> One downside of PLT Redex is that it doesn't scale naturally to performing proofs. We may choose to port the model to another system at some point, or maintain multiple variants.

[0] https://github.com/rust-lang/a-mir-formality

[1] https://github.com/rust-lang/a-mir-formality/tree/1f40120f09...

I hate that the world sometimes requires a human sacrifice in order for change to happen. I can empathize with people that say this is a stupid way to fix a problem, but unfortunately the world is full of stupid things that actually work.

On one project, we had a horrible integration test system that required a human to read and interpret the output. The guy who wrote it made his own DSL. As we struggled with it, he noped out and left the project. The next guy had partly the right idea. He figured out how to translate the whole thing into Python with a couple of macros. So at least you could step through it. Then he noped out. Since I do a lot of CI/CD work and my primary goal on the project had already been fulfilled, I took over. What a mess. I made it better but I still couldn't nail down pass/fail statuses reliably. Pointless system.

I kept harping on how we needed to throw out the whole thing. It was a false sense of safety at best. When I left to work on something closer to my life goals, at the very last big meeting one of my people I'd been mentoring said, "The last 3 people to leave this team worked on this one project. Maybe we should get rid of it." and everyone started nodding. Son of a bitch.

Now, I wouldn't have stayed anyway, but someone else might have. I've seen other situations like this play out, and while there's always gonna be someone who 'takes their ball and goes home', often enough it's someone reasonably determining that they cannot or will not be responsible for the chaos represented by Option A over Option B. This will burn down, fall over, and sink into the swamp.

If you mean me, I am definitely not a human sacrifice. I walked away because I had had enough.

That's what I mean. For this to be some place people like working, someone has to leave over the status quo. Which means they don't get to benefit from any of the work done so far or subsequently.

FYI John Cowan is also known as editor of the XML 1.1 spec, as well as other works related to markup languages and Unicode.

https://github.com/johnwcowan/r7rs-work/blob/master/R7RSHome...

I still have no idea what exactly R7RS is

It's a specification of the scheme programming language: https://en.wikipedia.org/wiki/Scheme_(programming_language)

It's the latest version of a language specification for the Scheme family of programming languages.

The 7th version of the Scheme standard/specification, basically. There's a "small" and "large" version of it, for different use cases/preferences (there's a bit of drama behind this: R6RS introduces a lot of "large" features that many implementers felt were too "bloated", which was eventually resolved by splitting the standard in small/large variants).

It seems like "core language" vs "standard library" almost. The Large spec includes things like lists, vectors, streams, and generators [0].

[0] https://practical-scheme.net/gauche/man/gauche-refe/R7RS-lar...

I thought it was a Xaiomi smart chair posting on the internet

There used to be a website a long time ago, but for now your link is it, unfortunately.

R7RS is the Revised⁷ Report on the Algorithmic Language Scheme, the latest common-ground description of the language.

Revisions up to and including R5RS were fairly minimalistic (even if not all of the features new to R5RS are uncontroversial) and specified essentially no library facilities, which were usually either completely implementation-specific or released as RFC-style documents called SRFIs (Scheme requests for implementation). As a result, toy, teaching, or research implementations of Scheme were fairly easy to make, but moving programs between implementations was a bit of a crapshoot.

The reaction to that was R6RS, which is—if not the length of the Common Lisp spec—similar in scope, with utility and OS interface libraries, an extensive macro system, a freshly designed module system, and a lot of other stuff. When SRFIs for the new functionality existed, R6RS certainly took inspiration from them, but its redesigns were neither fully compatible nor taken through the public SRFI process (the standard was still subject to public discussion, but in a different venue with different procedures). And people wanting a minimal standard to implement on their own (a not insubstantial part of Scheme users) were told that R6RS wasn’t for them and pointed back to R5RS.

Long story short, the few commercial Scheme vendors (first of all Chez Scheme, prior to the Cisco acquisition and open-source release) largely adopted R6RS; the rest of the implementor community largely ignored it or cherry-picked some parts—and that means not only the myriad hobby implementations, but also the medium-scale ones like Chicken, Gambit, or Gauche. I think even Guile (whose stance on minimalism mirrors that of most other GNU software) requires some wrangling to get it close to R6RS.

R7RS was intended to close that divide: there’s R7RS-small, which is an R5RS-style lean spec, and R7RS-large, which was intended to be a R6RS-style real-world language, but composed with more respect to existing practice and SRFIs and with more implementor buy-in. It was to be released in several issues organized by topic (data structures, I/O, etc.). John Cowan managed to get a couple of these out the door over the last decade, but the efforts seem to have stalled. AFAIK Chez, the gold standard of real-world implementations how that PLT Scheme has reinvented itself as Racket and gone its own way, has also indicated no interest in even looking at R7RS-large however nice it turns out, because they have customers now and that takes priority over ecosystem health.

R7Rs Small: https://small.r7rs.org/

R7Rs Large: https://practical-scheme.net/gauche/man/gauche-refe/R7RS-lar...

R6RS: https://www.r6rs.org/

R5RS: https://conservatory.scheme.org/schemers/Documents/Standards...

R4RS: https://people.csail.mit.edu/jaffer/r4rs_toc.html

Or more simply https://github.com/johnwcowan/r7rs-spec/tree/errata/rnrs, where you can get Every Scheme Standard Evar. It's unsurprising that there is no one place for R7RS-large, considering how inchoate it is.

> moving programs between implementations was a bit of a crapshoot.

You just summarized the historical reason why LISP and its various incarnations (Scheme among others) failed.

So many different patois, no way to move code from one to the other without giant headaches.

Eh. Giant headaches is overstating it, I think, if we're talking Lisp post 2005 or 2010: Common Lisp implementations are largely compatible; Racket only has one implementation (and no spec); in Scheme you'll have to spend a bit of time porting between the three or four big implementations that can actually run your stuff, big whoop. (On this forum I probably have to mention Arc, but I don't believe it ever grew beyond a personal project.) I'd say that the main obstacle to adoption was rather the (apparent) absence of shinies (and boy were there a lot of competing shinies at the time).

Even if this were correct, though, my experience is that I find very little enjoyment in things that are targeted at what in your terms is success. For example, Go feels dreadfully unpleasant even though I can't deny the good—occasionally downright brilliant—engineering that went into it, kind of like a mass-produced concrete residential building. Let's be honest, I'm in this largely for the hackery, a little bit for the feeling of having solved somebody's problem, and not in the slightest for the social acceptance. You might not agree here (or you might!), but I hope that, if one day nobody does, I still have the self-awareness to step away from the computer and go do something else.

> For example, Go feels dreadfully unpleasant even though I can't deny the good

For me Go feels like Pascal cut off C's face and is wearing it Hannibal Lector style.

That said, it's an absolutely fabulous language, standard library included, for implementing a worldwide ads serving network. Gotta give them that. For other problems that are more or less technically similar it's also great.

That’s not quite so true. The Common Lisp standard actually works pretty well for having many conforming implementations. For example SBCL, which it’s fair to call a nontrivial program, is portable across itself, CMUCL, Clozure CL, CLISP, ABCL, and ECL.

On the other hand, a theorem prover written by John McCarthy in 1958 was trivially adaptable to both Common Lisp and Scheme. Not too many languages get to make that claim.

Thanks, that is helpful background. I can see how it would be difficult find agreement between groups who want compatibility with R6RS, and those who want compatibility with SRFIs.

> AFAIK Chez, the gold standard of real-world implementations how that PLT Scheme has reinvented itself as Racket and gone its own way

Well, sort of. They were running their own base system for a long time, but current Rackets are implemented as extensions of Chez Scheme.

Racket is not an extension of Chez; Chez is an implementation language for Racket (it replaces most of the C code in earlier versions). See my comment above about implementation languages.

The main benefit of basing Racket on Chez instead of C was maintainability. A bit of performance and a few fairly unimportant features (like single floats) were lost.

You said:

> Unless the implementation language is exposed to users of the implemented language, it doesn't matter what the implementation language is.

But Racket can call Chez Scheme procedures, and vice versa.

For that matter, gfortran can call gcc functions.

I got involved with scheme back in the days of R{5,6}RS (as a user, not in the standards process). Even then it was an argument for the BDFL model over design by committee.

R4RS was a gem. Let's revert.

call/cc without dynamic-wind is pretty nasty.

I wonder if the optimum is a benevolent dictator controlling the language and committee controlling the associated library. The community is then a sort of third ring of library evolution.

Inconsistency is more expensive the closer to the language definition it arises as the blast radius is wider.

Compromises and redundancy are more valuable in the library layer.

Lisp blurs the lines somewhat but it's usually possible to subdivide a system into a core and stuff built on that core.

As someone who works on a combined language/core library team, it's really nice to have them both under the same roof. We can provide a much better overall user experience when we can design features that involve the language and core libraries working in concert with each other.

For example, we recently added tuples as a language feature to Dart, and also added a function in the async library that lets you await a tuple of futures in parallel and returns a future of the tuple of the resulting values.

When we added extension methods to the language, we also rolled out some extension methods in the core library.

We have had four models:

Committee consensus took us up through R5RS. There were about 30 members of the committee, though obviously some were more active than others. The problem with that was that we got no change except at the margins. Implementations were extended in random incompatible ways.

Then we had consensus of a small committee (5 members, later 4) for R6RS, followed by a community ratification vote. A lot of people thought the resulting standard was over-engineered, and I am quite sure that many people didn't understand all of it (I didn't for sure, especially macros and records.) Some implementers adopted it, others declared they never would.

For R7RS-small and the early stages of R7RS-large, we had the open SRFI process (anyone can propose, the community helps refine, the author decides when to freeze the result).

Now we have a (de facto) Sitzfleisch process: however stays in their seat and is still arguing the longest, wins. I eventually ran out of energy for this one.

Note that in all cases the text controls the meaning, not the author(s), and when the standard and an implementation collide, it is the implementation that is wrong. This is very nearly a sacred principle, as in C/C++ and various other multiple-implementation languages.

While reading I had a thought:

What if they (whoever it is, who could or should do this) worked on a proposal, that specifies, how language features should be added to the language? I mean, there are things like continuations and macros. Those need to be really solid. But based on them, could one not make everything else an optional addition, implemented on top of them, instead of in a dialect's core? So that Schemes could all go for R7RS small (except those that object to things in it) and then basically have a "folder" in their sources of things that are additionally necessary to have R7RS large things? Those things being implemented in the way that the standard proposes? Then we could get to a R7RS large step by step, feature by feature.

I guess this depends on whether things in R7RS large are at their core incompatible with how R7RS small works. Probably it also depends on those dialects implementing the standards correctly for the primitives, that the extension mechanism is supposed to be based on.

I also don't know enough to tell what attempts have already been made to resolve things, so perhaps someone already had this idea and it does not work.

Alas, no. There are quite a few other things that are needed in what is now being called the Foundations in order for adding features to be done through libraries. Scheme, like other Lisps, is almost all "library" and very little "language", once you get past variables, constants, and function/macro calls. The only "language" feature added so far (in R7RS-small) is that previously a vector constant had to be quoted, whereas now it is self-evaluating: you used to have to say (vector-ref '#(a b c) 0), whereas now you can leave out the quote mark.

Disappointed. Thought I was going to see a resignation letter shaped like a large chair.

Sorry, not sorry. Here's one for you: .

Damn, my emoji got eaten. See https://emojipedia.org/chair.

Who will convince Kent to come back and make r6.1rs? https://github.com/cisco/ChezScheme/issues/574

If you want a large language, isn't it a better idea to build it on top of something the makes better guarantees for the user? I prefer my program to not continue executing after reaching an erroneous state.

Not if it's so constraining to the implementer that you can't get any implementations. Nobody's paying us to do this stuff.

Of course not, but knowing that the program should never continue executing in an erroneous state is for me a pretty nice-to-have. Scheme enforces correctness and safety in many places and I think that one in particular is important enough to warrant being opt-out rather than opt-in.

i never actually understood how r7rs is supposed to work in practice, because when i learn a scheme i’ve always just learned how to use implementation-specific functionality

Jcowan always been a class act.

Additional background would be nice. I clicked the link out of curiosity to see what it meant for a piece of furniture to resign from something. After clicking the link, I was no better informed.

Took me a few moments to realize this isn’t a satirical text about a large seating furniture.

I almost posted this an hour ago, and feel more comfy now that it’s an hour later:

I’m sad how quickly this rocketed to top 3 on front page and how little content there is, it’s just someone resigning from a project virtually none of us know about. The “My resignation letter” was titillating enough to skyrocket upvotes and engagement

> a project virtually none of us know about

You may be surprised! For context, R7RS is the latest standard for Scheme. Actually it's two standards: a 'small' one for the core language (similar to R5RS; this was finished a decade ago), whilst this involves the 'large' standard, which is trying to agree on a "standard library".

Some reasons people may have upvoted this, or otherwise be interested in Scheme:

- R7RS has been dragging on for so long, it may be nice to see some/any sort of status update

- Scheme has so many diverse implementations (Racket, Guile, Gambit, Chicken, Chez, Stalin, etc.) that it's really important to have some common standards.

- Scheme was a major influence on Javascript (along with Self)

- Scheme pioneered many features that are now taken for granted, e.g. first-class functions (it's a "1-lisp"), lexical scope, tail-call elimination, continuation-passing style, call/cc, etc.

- Scheme is commonly used as a scripting language by applications written in other languages (similar to Lua). Indeed, Guile is the "official" extension language of the GNU project (e.g. see Guix, Shepherd, etc.).

- Scheme was/is taught at many schools and university courses

- Well-known textbooks like SICP use Scheme; and indeed guide the reader through writing their own implementation!

- Scheme is used for programming language research (e.g. "towers of interpreters", (delimited) continuations, miniKanren, etc.). Indeed Racket used to be called PLT Scheme (PLT = Programming Language Theory)

> - R7RS has been dragging on for so long, it may be nice to see some/any sort of status update

that's why i upvoted! this is a pretty significant status update if you're interested in r7rs or scheme in general.

I upvoted because I'm involved in a growing OSS project that's tangling with similar questions of scope and governance. Simultaneously being responsible for everything from software deployment and PR reviews to project scoping and interpersonal conflict de-escalation is absolutely exhausting. I'm fantasizing/extrapolating that many of the people writing "so sorry to see you go" messages were the ones being quarrelsome and refusing compromise, and now they're getting the defect-defect outcome.

Not the case. Anyway, it's not about being quarrelsome, it's about having a different point of view. As for compromise, it's hard to compromise between strictness vs. laxness, for example.

Child A: I want the whole pie!

Child B: How about we split it 50/50?

Adult C: You two need to compromise. A gets 75%, B gets 25%.

(I am not implying that any particular persons are A, B, and C here.)

Many of us learned Scheme or Lisp and are familiar with Scheme even if we never use it.

I knew about it! I have been following JCowan's work on this and other similar areas (like SRFI https://srfi.schemers.org/ which may be a more tractable approach to growing Scheme). He's an amazing force for good!

Reply on news.ycombinator.com