Very cool. With closures and tail recursion, this could be a JavaScript killer for me.
Well, and with GC, and any macro-expander at all much less a Racket quality one, and with…. :smile:
It’s really fun to read the code and see it work at all in a couple thousand lines.
With Racket-On-Chez wouldn’t it make it almost straight-forward to have also Racket->WebAssembly?
Yes, personally I would wait for that to use in production.
Or if I needed something today, I’d try https://github.com/vishesh/racketscript ?
Or actually if I needed something today, I’d probably just try write reasonable modern Javascript.
probably true, still the vision of full Racket in the browser is quite amazing (subject to performance ;)
All good options. My opinion of JS is so low because it’s been the only option in the browser for so long.
Not sure it’s worth the trouble anymore
I did some work using ClojureScript about a year ago and enjoyed it. The dev experience was nicer than full Clojure JVM, for me. But when I first tried ClojureScript maybe 2 or 3 years ago, it was very much duct tape and magic spells. So I think, even Racket->JS, early days maybe we should have low expectations until the tooling is matured.
The reason I would welcome Racket on the WebAssembly is mostly due to its DSL capabilities, just thinking how long it took to develop new DSLs like jquery or JSX, it makes me feel where could we be already with languages/tools like Racket
For sure, yes! I’m just saying there are many months (years?) of tedious work by many people to get to where you and I could save time like that? Hopefully I’m wrong.
it makes one appreciate the hard work by Matthew and the rest of the team on current transition
yearh, wish I got my head in the game earlier so I could follow the progress more directly
I’m probably jaded from years of pre-Racket webdev. Java got way cooler once language implementers started taking full advantage of the JVM.
to the list of current alternatives I would add: https://github.com/soegaard/urlang
@lexi.lambda your syntax/parse bug report is the evilest thing I can imagine
@notjack imo it makes it clear that sort of identifier munging is a bad idea, and it ought to be done at the reader level (but that isn’t practical currently)
though, on second thought, I should temper that… I think that sort of identifier munging is not “the right thing”, but maybe it isn’t a bad idea with the current tools available
@mflatt The following file works on the old expander, but not the new one: https://gist.github.com/LeifAndersen/bf555a85203ec41761bce5b4d5046855
Or even this program: #lang racket/base
(define first "Hello")
(require racket/list)
Which seems like a bug to me.
@leif Yes, that’s a bug. I’ll look into it now.
Thanks.
how in the hell? google/schism is a self-hosted compiler, yet:
> As mentioned, the goal has been to prioritize features needed for self hosting. Here are some of the current restrictions: > > No lambda, no closures.
oh. (define (fn ...) ...) form works (but maybe doesn’t close over?)
@zenspider it’s not a scheme it’s just a lisp 1
@zenspider yea I know I was fooled too until I saw the features