Racket branch of Chez Scheme merging with mainline Chez Scheme
groups.google.com
groups.google.com
[1] Example gif: https://docs.racket-lang.org/define-attributes/examplecodear...
[2] > Lexical Structure: The lexical structure is shown with arrows overlaid on the program text. When the mouse cursor passes over a variable, DrRacket draws an arrow from the binding location to the variable, or from the binding location to every bound occurrence of the variable.
(so, not much chance of adding that to my Chez extension ;)
I have had the pleasure if witness a couple Matthew Butterick talks first hand and they are excellent. He is a great speaker and thinker. I have also seen the subject the article lose his cool a couple times. Which is not cool. Esp given his prominent place in the community. At this point and think he should make himself a bystander.
If you don’t mind Smalltalk, the modern Pharo ecosystem is also amazing.
Just like Notebooks are miles away from that experience, and yet they allow millions of programmers to have an experience that wouldn't have otherwise, even with Lisp Machines/Interlisp-D providing a much better one.
What do you think is inspired by some Lisp Machine? REPLs existed before. Editors existed before. IDEs existed before. Lisp IDEs existed before. For example Interlisp had a Lisp IDE in the early 70s, long before it was morphed into something like a Lisp Machine with Interlisp-D.
It would allow you to define variables which were actual images. The image was a thumbnail in the code, which you could assign and print. It was mind blowing.
Also your Lambda keywords could be replaced with an actual Lambda symbol, which was the pinnacle of coolness.
This, as well as the super snappy and responsive split REPL, made the overall development experience with Scheme feel super futuristic and just a pure enjoyment all around.
What's missing from my life is a good FOSS equivalent. There are several wonderful tools which do similar things, e.g. Jupyter, org-babel, TeXmacs, Sage, mathics. None of them feel quite right though.
I did recently pay for an entire year of Wolfram Desktop in the hope of really getting into it. I have code experiments for all the stuff I love (machine learning, deep learning, LLM, semantic web, etc.) but to be honest using the Wolfram Language does not give me the joy that I get using Common Lisp,and various Schemes, and, for some things Python is the most practical language.
Like in many free tooling most people rather do with what they have instead of improving them, hence why all great developer experiences are either commercial or corporate sponsored.
GNU Emacs disagrees.
I know Eight Megabytes of Continuous Memory Swap since those 8MB actually mattered.
It's "Eight Megabytes And Constantly Swapping".
Someone said they might be possible with CodeMirror https://codemirror.net/
(Just in general - not specifically for racket- I’d love to see this for rust and elixir)
They are possible, but not using the "normal" editor window, you need a "custom" one: https://code.visualstudio.com/api/extension-guides/custom-ed...
The once a year RacketCon conference was two weekends ago, and in addition to the technical talks, I enjoyed hearing the 4 academics who are primary implementers and maintainers taking questions from the audience about why Racket is not targeted at industry. I am just finishing up writing a Racket book, that really just consists of my own little code experiments (no big deal). You can read it free online https://leanpub.com/racket-ai/read
That's interesting. That seems like a flip from a few years ago. What was the summary regarding this?
"Why isn't Racket used in industry like OCaml is used by Jane Street."
And what can you answer to that? Of course the Racket would like for some both commercial users as well as sponsors.
In fact [1] Racket changed its license from LGPL to Apache 2.0 or the MIT license to make sure it can be used commercially.
The fact is that language popularity isn't determined by quality of language/implementation alone. Having companies like Apple (Swift) and Google (Go) backing a language helps tremendously.
[1] https://blog.racket-lang.org/2019/11/completing-racket-s-rel...
The corporate world is mostly obsessed with OOP to the extent that every new imperative/procedural language like Go or Rust has to pretend to be OOP to get corporate adoption. Functional languages can't pretend to be OOP so they can't get past the corporate filter except at a handful of firms that use them for competitive advantage.
It also isn't easy to get the few functional programming jobs that do exist because they're often looking for developers who already have professional functional programming experience and that isn't easy to get unless you're already at a company that uses functional programming.
[0]: One of the most compelling pro-functional programming arguments is this one which argues that mutable state (being able to alter a variable's value after you set it) and variables being able to be null are harmful like GOTO statements: https://spectrum.ieee.org/functional-programming
What I said was (in part) "I am sure there are ways we can improve to attract people inside of academia, outside of academia, in open source, in commercial development, and we want to improve in all of those ways".
(This current submission is really nice; you get to hear more from Matthew about what’s going on.)
Chez Scheme (pronounced “shay-scheme”) is the most performant and compliant Scheme implementation out there. [1] For a long time it was closed-source, but was recently open-sourced.
It now forms the foundation of the Racket language. (So, I guess that means HN relies on it, provided Arc is using a recent version of Racket.) I asked Matthew why he picked Chez to base Racket off of, and I want to say that he picked it because it implemented continuations really really well and had a good garbage collector too. I could be wrong.
(Maybe I'll find a way to resume using Scheme/Racket. The last few years, I've been using Python, JS, and Rust, partly for employability reasons. They have their merits, but I'm aware of what I'm missing.)
Racket is used extensively in education and research relating to Scheme and programming languages in general. Lots of work on gradual typing, programming language semantics comes out of the Racket community. Many colleges around the world use Racket. Scheme/Racket is very pared down language and lends itself to this kind of work -- the principles of whatever you are studying shine through quite easily in a way that it may not if you were using C, Rust, Python etc. in the problem domain.
As noted elsewhere in the comments, Idris 2, an important dependently typed language outputs to Chez/Racket Chez. Previously it output C code which was then compiled.
See: https://en.wikipedia.org/wiki/Racket_(programming_language)#...
In general, Chez is probably a great language to use as a "base". It lends itself to embedding and is performant. Lua and some Javascript implementations come to mind as comparables. In general, we might not know much about Chez being used a lot in the wild because it could be tucked deep into various proprietary company products.
* https://defn.io/2023/08/10/ann-franz-source-available/
HN itself runs on Racket.
In the way those Dyson bladeless fans pull more air through. In your case, many folks know you (some from UIUC too like me) and know your upvote is worth reading, ending up upvoting too.
Isn't it an ancient version of Racket, though?
This is a quite common pattern in the Lisp and Scheme world where examples of real world usage are given, but they're effectively outdated.
[1] https://docs.racket-lang.org/reference/unsafe.html#%28def._%...
In Racket the batteries are included. Two examples of programs I had to write like two years ago for work:
* A bot to reply emails that uses IMAP, SMTP and web scrapping. (It's not 100% automatic. It replies only the easy cases and adds labels so I reply the tricky ones.)
* An program to cleanup Moodle backups that uses gzip and xml. I compiled it and send it to my coworkers. (The backups have too much info, so before restoring it in another site it's better to remove the unused parts.)
In both cases, and all the features were installed by default. There are many user defined libraries that can be downloaded as packages, but I didn't need to use them.
And it's tough to get support as there's very few people who know the stack well enough, and those people are the busiest and also professors, so their time is limited.
For support you can ask in https://racket.discourse.group/ , most questions are answered the same day. I don't know if someone is available for consulting/hiring.
I would say that the key difference is that F# and Elixir are backed by industry whereas Racket is primarily backed via academia. Thus, the incentives and goals are more aligned for F# and Elixir to be used in industrial settings.
Also, both F# and Elixir gain a lot from their host VMs in the CLR and BEAM. Overall, F# is the cleanest language of the three, as it is easy to write concise imperative, functional, or OOP code and has easy asynchronous facilities. Elixir supports macros, and although Racket's macro system is far more advanced, I don't think it really provides any measurable utility over Elixir's. I would also say that F# and Elixir's documentation is better than Racket's. Racket has a lot of documentation, but it can be a little terse at times. And Elixir definitely has the most active, vibrant, and complete ecosystem of all three languages, as well as job market.
The last thing is that F# and Elixir have extremely good notebook implementations in Polyglot Notebooks (https://marketplace.visualstudio.com/items?itemName=ms-dotne...) and Livebook (https://livebook.dev/), respectively. I would say both of these exceed the standard Python Jupyter notebook, and Racket doesn't have anything like Polyglot Notebooks or Livebook. (As an aside, it's possible for someone to implement a Racket kernel for Polyglot Notebooks, so maybe that's a good side project for me.)
So for me, over time, it has slowly whittled down to F# and Elixir being my two languages that I reach for to handle effectively any project. Racket just doesn't pull me away from these too languages as it doesn't really offer anything over them, and I would also say that Racket is a bit too locked to DrRacket. I tried doing some GUI stuff in Racket, and despite it having an already built framework, I have actually found it easier to write my own due to bugs found and the poor performance of Racket Draw. However, I do reach for Racket anytime I want a Scheme for learning purposes.
I agree that sometimes the docs of Racket are complete but too short. When I had to write code to download a webpage, I had to guess how to use the 10 arguments of the functions, in particular how to split https://www.example.com/here/thispage.html I think that the docs of PHP has a huge collection of user submitted examples, that sometimes are good and sometimes are bad, but most of the times there is one that saves you a lot of time.
Porting Racket to the the CLR and BEAM (and JVM) would be nice. I'm not sure the garbage collectors have all the necessary support for weird stuff like weak boxes and ephemerons. IIRC ephemerons were backported from the Racket fork to Chez Scheme a few years ago.
A Jupyter-like interface would be nice. My wife is using Python in Google Colab an she loves it. About the Racket kernel in Polyglot: Should it be written in some CLR language or it can be a thin wrapper around the main Racket executable?
Edit:
I searched in Discourse, and I found these two posts about using Racket in Jupyter.
https://racket.discourse.group/t/racket-meet-up-saturday-7-m...
https://racket.discourse.group/t/running-racket-in-the-cloud...
(I'm too busy to help just now, and I never made the VB6 -> VB.net transition.)
I know racket is very static in this regard.
IIRC every lisp and scheme I've used has supported this. It's pretty typical, but not universal.
But some implementations use an interpreter for evalulating code at runtime. ChezScheme uses the compiler.
What I was saying is that every implementation I have used did this, not that all of them do. It seem common.
FWIW I've done a lot more CL than scheme, though.
Compilers that compile directly to machine code do not have similar problems.
For fun, do you know a Common Lisp implementation that compiles via C? How do they implement `eval`?
The post I was replying to was about scheme's in general though, not scheme->c implementations, right? Anything with an intermediate language or machine language output avoids this problem...
At any rate, the CL's I've used most have native compilers. I think GCL is CL via c, but can't remember the details of its implementation. In any case 'eval and 'compile are not equivalent, and the system may change whether or not 'eval compiles first or just interprets, depending on settings.
[update] I was curious, so had a look at https://get.scheme.org/
Not sure how complete that list is, but that has 4 native compilers and 3 scheme-to-c, which I guess leaves the other dozen or so interpreted, but that gets muddied with intermediate languages and retargetable (e.g. gambit).
On a different tangent, I am suddenly reminded of:
https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-lang...
(funcall (compile nil `(lambda () ,form)))
So the question is really, how do Lisps that compile to C implement the dynamic compile function? Typically it's all part of the same framework as file compilation.
There is a run-time dependency on the C compiler: for run-time compile to work, it has to be installed. The compile function writes something to a file, or perhaps a pipe. The compiler is invoked and produces a .o file; the function then loads that into the image and bind it to a funcall-able object.
It's a dependency that's a bit hard to swallow, since a C toolchain is hundreds of megabytes nowadays.
[1] Assuming that the merge has happened since the announcement was on Oct 16
https://github.com/cisco/ChezScheme
There is more work to be done before release 10.0.
Rather, this announcement is about going the other way around, and about merging changes back into Chez: when Racket was migrated to Chez several years ago, as a matter of practicality they had to fork it and significantly modify it to maintain feature parity with the existing implementation. The changes were very large; multiple new supported ISAs and ABIs, new compiler optimizations, an entirely new build system, etc. For years, nobody was totally clear about what would happen with this fork, but the hope was that it would all go back to the upstream Chez codebase. That is finally happening, and so this post is not about merging code from Chez into upstream Racket, but rather merging code from Racket back into upstream Chez.
The hope is changes will soon be available as a new major Chez Scheme release, version 10.0, and so the fork and the upstream version will finally be unified. (Racket will likely continue to use its own fork of Chez scheme as a practical matter of engineering, but presumably it will only need very minor tweaks and small patches, if any, for it to work.)
https://docs.racket-lang.org/sicp-manual/
(SICP Scheme isn't quite standard, and there's also some SICP-specific libraries.)