mixin: method was referenced in definition, but is not in any of the from-interfaces
method name: enable-macro-stepper?
from-interfaces:
context...:
C:\Program Files\Racket\collects\racket\private\class-internal.rkt:4888:0: obj-error
C:\Program Files\Racket\collects\racket\private\class-internal.rkt:4986:0: check-interface-includes
C:\Program Files\Racket\share\pkgs\javascript\drscheme\tool.ss:37:0
C:\Program Files\Racket\share\pkgs\drracket-core-lib\drracket\private\tools.rkt:318:4
C:\Program Files\Racket\share\pkgs\drracket-core-lib\drracket\private\tools.rkt:72:0: load/invoke-all-tools
.../unit/lang.rkt:84:9
C:\Program Files\Racket\share\pkgs\drracket-core-lib\drracket\private\link.rkt:57:0
body of "C:\Program Files\Racket\share\pkgs\drracket-core-lib\drracket\tool-lib.rkt"
body of "C:\Program Files\Racket\share\pkgs\drracket-core-lib\drracket\private\drracket-normal.rkt"
body of "C:\Program Files\Racket\share\pkgs\drracket-core-lib\drracket\drracket.rkt"
So, thing one: it appears that you can more or less ignore this error. Specifically, you can write and run programs in the #lang javascript language just by starting your program with that string, and you can ignore the "languages menu" version of the package.
However, I'm curious to know what it is you'd like to do with this package. It was written by Dave Herman, back in about 2007, probably at about the time he was graduating and moving to Mozilla to eventually form and lead the research team that would create Rust. Not that that has anything to do with your question. It looks like @samth moved the package over from PLaneT to a package in 2016, and it does in fact still appear to work, in the sense that I can run the program
#lang javascript
var x = 3 + 4
and click run, and then, in the interactions window, evaluate x and get 7. More than this I do not warrant. I ... would not expect this to be a useful way to run JavaScript code in 2026? Is that an unfair statement?
(To directly address your problem: it appears that this code is trying to flip the switch labeled "enable-macro-stepper?", which I believe was removed by Carl Eastlund in 2010. So I believe this bug has been present at least that long.)
Thanks for your interesting and informative answer. I'm using the parenthetical javascript feature to generate javascript for a web application. To be more specific, I'm generating javascript to create DataTables option objects. It's almost json, but it includes callbacks and I've wanted to try generating the code for a while.
I gave the ecmascript module a look, but there is almost no documentation.
It supports an archaic version of javascript. I tried to run Tau Prolog, but it didn't work. For generating code, it doesn't matter. At least, not for my purpose.
Cool! I haven't tried the parenthetical JavaScript, though I wound up doing similar (but far more half-baked) for python a number of years ago. I can see that the PJs part of the javascript package would probably still work fine, especially if you're the main client, meaning that you can steer around any observed potholes.
If the internal error gets irritating, it probably wouldn't be too hard to get rid of it. Specifically, the error is triggered by a mixin that is trying to handle/support/disable(?) the macro stepper, and my guess is that if you just commented out this mixin wrapper, you'd get rid of the error, and it wouldn't be any more broken than it is now. I think I sam @samth 's name on the repo, too, which means you should probably be able to make a pull request if you like.
I'm glad to be reminded of this project; the next time I'm writing JavaScript I'll try to remember to look at it again.
I located the file and I tried fixing it, but I don't understand it well enough and it just caused other errors. I'm going to continue ignoring the error for the time being.
Going back to what I'm doing, I tried RacketScript and ClojureScript and I couldn't get either one working. So I thought that -- rather than trying to replicate a complex language in javascript -- maybe a better approach is to do explicit metaprogramming and just generate the js I want. This is going well so far.
@nealburns5 Have you taken a look at the Urlang package? I think it does exactly what you want, and it's being actively maintained (Jens Axel Soegaard is active on this very forum, and the most recent issue activity on the urlang package is four days ago).
Here's the link to the docs
including this example:
> (urlang
(urmodule fact ; module name
(export fact) ; fact is exported
(import + - * = displayln ref console)
(define (fact n) (if (= n 0) 1 (* n (fact (- n 1)))))
(fact 5)))
... with this generated output:
"use strict";
function fact(n){return (((n===0)===false)?(n*(fact((n-1)))):1);};
console.log((fact(5)));
exports.fact=fact;
Urlang looks really interesting. I'm going to look into it. It looks a lot more ambitious and complicated than PJs. It's using the NanoPass compiler to generate the javascript. I think PJs is building an intermediate AST, but it's pretty basic.
The intended use of Urlang is to use 1) to write (generate) a Racket runtime in JavaScript. The middle-end of the Racket-to-JavaScript compiler will produce output as Nanopass structures, so 2) will be used as the backend for the Racket-to-JavaScript compiler.
I wish him luck. I've tried a lot of javascript transpilers and most of them didn't work for me and appear to be abandoned. One that did work is Fable for F#. It didn't seem to offer a big benefit over just writing Javascript, but maybe now that I'm better at F# it would. But I'd rather write Racket than F#. Tau Prolog is really interesting, because it offers something truly different than javascript, and I've had some success with it.
The compile Racket to JavaScript-compiler is however abandoned by now.
Instead I am working on a Racket to WebAssembly compiler.
That would be great. I watched a video on YouTube where Adam Perlin talked about the difficulties of targeting WebAssembly because of how NanoPass generates code. That was from 2023, and I was wondering what has happened since.
I was Adam Perlin's Master's thesis advisor. He was fantastic, but he graduated and went off to work at Microsoft, and I'm not aware of further work on his code. I should try to strong-arm some talented undergraduates to take a look at it. It's a hard project to get up to speed on.
Instead I am working on a Racket to WebAssembly compiler.
What if, on the way to the compiler, you release a package that's something like a toolkit for working with WebAssembly?
That's lower hanging fruit and less time to a useful product. Adam Perlin no doubt had good intentions, but the project took longer than his PhD and it's unfinished.
Using the "real" compiler and adding WebAssembly as a new backend is the ideal solution.
Features implemented at the Racket or Chez Scheme level will then automatically work without any worries about compatibility. If I understand correctly the goal of Adam's work was just that - finding a way of adding a WebAssembly backend to existing compiler.
The problem is that WebAssembly is a "safe" version of assembly.
Some of the tricks used in the normal Racket backends are not allowed in WebAssembly.
The most important is that WebAssembly doesn't allow direct manipulation of the call stack.
Instead of worrying too much about getting a 100% solution, I have instead written a compiler that only reuses the Racket expander. That is, it compiles from fully expanded Racket code directly to WebAssembly.
Having a single backend makes the compiler simpler. But, the code it generates is nowhere near as efficient as what the Chez Scheme compiler produces. [In hindsight, I should probably have used use the output of cp0 instead of fully expanded Racket.]
This approach also means that I need to reimplement many features - currently only a subset of Racket is supported (see the readme). There are however broad coverage of the primitives in racket/base.
I hope having a ready-to-use compiler for a subset of Racket will inspire the community to learn more about WebAssembly and eventually crack the code of adding a WebAssembly backend to Chez Scheme. In the meantime, we can have fun and experiment with WebRacket.
What if, on the way to the compiler, you release a package that's something like a toolkit for working with WebAssembly?
There is not much need. WebAssembly uses S-expressions. It even has a "folded" format, which allows me to implement primitives directly in WebAssembly:
Since WebAssembly uses S-expressions, I can use quasiquote and unquote to generate WebAssembly. Here is how the functions first, second, etc. are generated in the runtime:
