Scheme in Scheme on WASM in the browser | Hacker News Reader

Scheme in Scheme on WASM in the browser

spritely.institute

183 pointsparoneayea48 comments

I love this, I had this idea back in 2020, a lisp that compiles to WASM, and then can compile itself to WASM at run-time in the browser, or any WASM run-time, dogfeed itself. I'm not a compiler guru by any means, so its just one of many things on my bucket list.

The article is presenting a Scheme interpreter running in Scheme, compiled to WASM, not a Scheme compiler, but your idea is also cool. The WASM API apparently doesn't need a pre-made file as its input: you can pass raw bytes generated during runtime into the Module constructor, so it would be totally feasible.

When we have the compiler running in Wasm we'll post about that, too. That's the dream.

Someone actually wrote a scheme back in 2017 https://github.com/google/schism so this isnt new. Infact the whole idea of WASM is not new, 20 yrs back Sun had the same idea, embed compiled bytecode inside browser called applets, developed in JAVA. Even flash was a similar idea, though flash VM was riddled with security flaws. This failed to gain wider acceptance, now 20 yrs later we have a embedded bytecode compiler in the browser, but it may work this time.

Explain why you downvoted this? Self hosting scheme compilers on WASM is not new. HN a compliance Ghetto?

I don't know why you've been downvoted, I've given you an upvote for linking to an interesting project (even if it's linked in some way to Google). I'd also like to link to the updated GH link: <https://github.com/schism-lang/schism>.

Thanks.

This is what a Ghetto Looks like. If i had a way to delete my account i would be happy.

This is amazing. I am not finding the link to open a Scheme REPL in the browser (without doing my developer job). Am I missing something?

The demo is embedded in a iframe towards the bottom of the post. If you are using a browser that is Wasm GC and tail call capable, you'll see something that resembles the gif at the top of the post. If not, you'll see a message about needing to use a different browser.

May I suggest rendering it on a full page of its own and then linking to it, too?

The current form is too low-key since it looks like a screenshot.

I only looked at WASM when the spec was first released but at that time it looked like tail call was not possible. Has that been corrected?

Seemingly

https://v8.dev/blog/wasm-tail-call

Support is still mediocre (mainly because of safari)

Safari will have tail calls, eventually.

According to some other comments above, it appears that is already does.

In Javascript yes, in Wasm no: https://webassembly.org/roadmap/

Nice! Is there hope that V8 will also support proper tail calls in JavaScript?

Update: The ticket for v8 to support JavaScript tail call optimization remains open but hasn’t been updated in a couple years. https://bugs.chromium.org/p/v8/issues/detail?id=4698

Yes, there were some discussions about explicit tail call optimizations being the better solution.

Interesting, why would adding an optimize this keyword to JavaScript be better?

I don’t know their motivations, but having the same code work fine on one JS engine / browser / browser version, but totally stack overflow on another seems like suboptimal to me. Explicit tail calls let you error out properly at the call site, Babel-style downcompile it to a loop of some sort, all that stuff.

This could be surprising, but the scenario already exists in production. In JavaScript's strict mode, Safari applies tail call optimization, but systems relying on V8 don't.

To illustrate, the following code causes a stack overflow for me in both Google Chrome and in Node.js, but runs without issue in Safari.

  "use strict";
  const countdown = (n) => n == 0 ? console.log('done') : countdown(n-1);
  countdown(100000);

the same discussion is going on with rust. it lets the compiler enforce that you're actually using a tail call, instead of silently optimizing it when it sees it and otherwise being silent.

Generally the people that care about tail calls write code that relies on them. It isn't just an optimisation. The code is broken (will cause a stack overflow) if TCO isn't applied. So you need to guarantee it.

If I try to trace through the risk profile of bringing TCO into software engineers’ toolkits, it seems that the fear would be of the software engineers growing recursion-happy and writing functions that overflow the stack by inadvertently not leveraging TCO, more than they write recursive functions today that overflow the stack given that V8 offers no possibility of TCO at all? It just doesn’t add up, V8 with TCO and no safety keyword would simply be better than V8 today with neither, so it would still be a strange basis for not delivering the feature.

I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.

It adds up to me. It only takes being bitten once to learn that tail calls aren't optimized, and then you stop using them for recursion (or almost entirely stop). You write a for loop and things work. The overall level of broken code is very low.

If it's inconsistent, then people write a lot more tail calls and a lot more sites break on a lot more devices.

This is the description of a workaround for dealing with tail recursion being broken in V8.

It doesn’t add up if V8 is withholding TCO under the guise that it would cause programmers to write stack overflow bugs unless a new proposed keyword for it gets added to the language. The truth currently is that V8 itself has a stack overflow bug in its omission of TCO, it wouldn’t be right to shift the responsibility for that to the JavaScript programmers. But you’re right, unfortunately the JavaScript programmers are the ones who have to deal with the consequences of V8’s spec non-compliance which causes the stack to overflow when it shouldn’t.

I quite like that Clojure’s recur makes it easy to tell at a glance if a recursion will be efficient.

Yup! Hoot uses return_call and friends extensively. Chrome ships tail calls as of 119, Firefox will have them on by default in 4 days when 121 is released, and Safari will have them... at some point.

This is exciting stuff! It feels like Hoot is moving forward at lightning speed these days. Love seeing all these cool demos.

I don't have favorites, but Spritely is definitely an equal favorite for the projects we support at the Filecoin Foundation for the Decentralized Web. Others HNers may also be interested in include:

* Internet Archive's Democracy's Library https://blog.archive.org/2022/10/19/announcing-democracys-li...

* Distributed Press https://distributed.press/

* Guardian Project https://guardianproject.info/

* MuckRack Document Cloud https://muckrack.com/

* Harvard Library Innovation Lab https://lil.law.harvard.edu/

* Human Rights Data Analysis Group https://hrdag.org/data-publication/

Longer list here: https://ffdweb.org/explore/#partners

Preferable to doing the Javascript edition of SICP.

Alas, the focus is on optimizing job placement at graduation, so intellectually engaging choices are lower priority. We’re in a situation where CS departments are incentivized to spend every year that a student is in school optimizing their ability to produce BFS or DFS in Python within 15 minutes.

Maybe I'm missing something, but it sounds like you're making a general statement from a very specific and personal situation?

It's not specific and personal. Obviously it doesn't apply 100% but there is definitely a trend towards rote memorization and single language focus.

definitely a trend towards rote memorization and single language focus

What's some evidence of this trend you can think of?

Leetcode?

I'd be interested in seeing an analysis that traces the programming language paths built into university curricula and how those paths have tended to change over the years. The weakening of theory components is also of interest. My sense is that the trends are real, based on what I've noticed and conversations with instructors in higher education, but I don't have an empirical dataset to support it.

A decent theoretical model can be extrapolated from Goodhart's law. Graduates' performance on programming and leetcode-style interviews is a measure that many stakeholders care about, so it's a target for university departments that would lose value as a measure of educational quality. As a CS department optimizes its performance on that measure, elements of the curriculum are reprioritized. It becomes okay for the department to sacrifice educational quality in order to enhance performance on the measure. What doesn't go directly into the measure, such as experience outside of a core programming language intended for programming interviews, gets chipped away over the years through market pressures as universities' graduates compete for relative performance on the measure. This is a theoretical model, but to me it's convincing.

Well, it's up to the reader to follow the implications. But the industry does hold sway in the design of university curricula, sometimes to the disappointment of academics, and this is nothing new.

For example, back in 2001, Dijkstra expressed his dismay at Java replacing a different functional programming language, Haskell, in UT Austin's introductory programming course. https://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs...

Also consider that MIT used the Scheme version of SICP as their introductory programming textbook for years, and it remains a classic, but nowadays MIT leans into Python for introductory programming courses.

Dijkstra was a great computer scientist who was also very generous with his expressions of dismay. You can find him expressing dismay over a great variety of topics not all of which have turned out to merit it in the long run.

This says nothing about whether or not this specific instance of dismay is warranted. All you've said is a man can't be right 100% of the time which I don't find very useful.

You have been voted down, but this is 100% truth. I’d been a professional software developer for 10 years and programming since a young child when I stumbled across the MIT Scheme open course (this was nearly 10 years ago now). Learning Scheme as an exercise dramatically improved me as a software developer, as it is the near perfect teaching language. The fundamentals of most computer science concepts are so clearly laid out, with no distractions. I wish I’d had the exposure at a younger age!

MIT Scheme is pretty much useless as a practical language, vastly less useful than Python. Python is infinitely more powerful to actually “make things”. But this is not the point of University!

The academic languages are powerful for learning, and it is a huge shame that they are being replaced with “professionally relevant” languages.

Real software engineering is a drudgery of stitching together other people's libraries and APIs, responding to the product team's "can't we just...?" queries, and alphabetizing your HTML properties. College doesn't prepare you for that. Shiny happy Schemeland doesn't prepare you for that. It's like the old joke about Bill Gates and the beta version of hell.

> College doesn't prepare you for that. Shiny happy Schemeland doesn't prepare you for that.

I see no problem with that. That's not what university should be about. They're not supposed to be software dev bootcamps for companies.

Not a fan of Python, but it isn't too bad pedagogically speaking. JS on the other hand... I hope WASM can one day kill it, leave it obsolete, and have it forcefully deprecated like Flash.

Can you explain what you find bad about js ? I use typescript and I am honestly finding it awesome; and I am the type of person that coded in lisp for a long time.

We have lambdas, flexible structures, FP methods (map, filter, reduce...), can express recursion easily, we have ternary operators, array and object destructuring (const {a,b,...rest}=init()). We have a nice way to deal with asynchronicity. We have some kind of class system. And thanks to typescript we have a really great and expressive type system that's very cool and eases the job a lot.

Sadly true - I majored in math in college and had no plans of going into a programming-heavy job, so I was able to take fun “applied” CS classes like a “language grand tour” or physically based rendering, but skip core classes with those pressures like algorithms etc. entirely.

Ihave been using guile extensively for a couple of years. It has destroyed writing recursive functions in other languages for me. There are no stack overflows in guile, and a recursive function won't fail until you have used all a avilable memory. This lets you write very elegant functions in places where the state is a tree or a linear data structure. Doing the same in python means having to actually deal with state. It just feels so unnecessary and error prone.

Reply on news.ycombinator.com