The features of Pyret make it the most advanced compile-to-JS language I know of.
ClojureScript is pretty sophisticated since it is considered production ready for commercial work and leverages much of Clojure's ongoing library development directly.
• allowing arbitrarily deep call stacks (e.g., deep recursion)
• allowing computation to be interrupted
• turning async interfaces into sync ones
This means you can't just compile altjs function calls to JavaScript function calls. That's the work that @jpolitz is referring to. The last we checked, ClojureScript did not address these issues as well (though it does other awesome things!).
I think the PLT group does amazing work in general and in education in particular. The well designed teaching languages hide complexity while providing power for expressing important concepts. And nobody makes installing a full blown IDE and versatile tool chain easier for beginners.
My emphasis was on an a Blub->JS alternative for production. I am not sure Pyret is a priority alternative for a green field project due to the language's intended purpose and the directions in which that purpose is likely to drive and not drive its development and tooling. That is to say that features are likely to flow Pyret->Clojure faster than Clojure->Pyret.
Absolutely. To be honest, we don't want Pyret to stay in the "education cellar" forever. But, we need a set of coherent design constraints, and education is a good one because it prevents premature cruft.
The current stack treatment is pretty elaborate for pedagogic reasons. There's absolutely no reason we can't just turn it off for programmers who are willing to write short-running computations, for instance (as production developers are willing to do)—that would be a "#lang"-style configuration. The tooling would, of course, be the bigger issue.
Overall, I'm happy for all good altjs projects. The core Pyret team burnt their fingers on a lot of aspects of JavaScript and see clearly its difficulties for education and even for development.
By the way, this is one of the reasons we're putting a lot of effort into JS interop. This isn't really important for education but it is for development—and in particular, development for education.
I think tooling is only theoretically surmountable under the current incarnation of PLT and its culture [and I am not saying that this is a bad thing because that culture is extremely valuable].
By which I mean that PLT culture does not spin off the right tooling in the right direction relative to typical production operations. Racket works well with DrRacket and sorta with Emacs: compare Geiser or Hendershott's M-x racket-mode to Cider. Good luck finding out of the box integration of Racket with Eclipse, Visual Studio etc.
The reasons include, I think, the fact that consultants on mutli-million dollar contracts are not going to start with Racket. This means that 1000 hours building a tool for Eclipse that saves 10% on a $4,000,000 contract never happens. What happens instead, and it is a good thing, is that people tend write tools that solve the problems of academia, including implementation of research topics at one end and producing well formatted text on the other, and of course pedagogy on the third end [maths are not my strength, apparently].
As an example, listening to the Flatt interview, the sub-module system makes sense. The extra level of indentation for namespace construction though feels kludgey from a typing code into a box perspective because top-level concepts from the perspective of the enclosing namespace are indented - I look and ask myself, did I miss a right-banana?: The sub-module syntax is at odds with the core principles of pretty-printing as a tool. That sort of design engineering isn't a priority for PLT [and I am not saying it should be, only that it makes moving out of education less likely].
On the subject of tools: I'd like to clarify that Scribble was not designed to solve academic text-formatting problems; it was designed for Racket documentation. It's fair to say that we subsequently improved Scribble in academic-friendly paper- and book-writing directions, but like so much of what the current Racket developers do, it was motivated by programmer experience rather than academic tasks or credit. The current developers can only work so fast, but I hope Racket continues to attract more contributors who build more tools.
On the topic of parentheses and submodules: I can understand why some consider parentheses to be an obstacle, but I'm puzzled that you've singled out their use for submodules. Syntactic forms in `#lang racket` use parentheses, and I think they've worked well in practice for submodules. That said, submodules are most powerful when you don't use them directly and instead use (or create) constructs that are implemented as submodules. For the example you have in mind, a new syntactic form may well fit better --- and maybe should be one of the many constructs that are available out of the box.
What was the motivation to start from scratch rather than compile at least a subset of Racket to JS? I imagine Pyret was a massive amount of work. Same effort could've brought Racket to the browser.
---
Big thank you to the PLT group for HTdP that introduced me to programming and PLAI class that taught me PL hacking and ultimately landed me a job writing compilers
We've already compiled a very good chunk of Racket to JS. It's called Whalesong (http://cs.brown.edu/~sk/Publications/Papers/Published/yk-wha...). The initial version of Pyret was in fact built as a #lang in Racket, and used Whalesong to obtain an in-browser implementation.
We ran into two major problems with this.
1. It was really slow. Whalesong faithfully implements Racket, including delimited continuations and all sorts of other fun stuff. But it suffers in performance. See the paper—we went through three different implementation strategies. But for all of them, Pyret proved to be too slow.
2. We wanted an entirely in-browser experience. The earlier Pyret implementation used Racket to do initial compilation, and Racket itself is not designed to run in the browser (it depends on its own virtual machine). Though Whalesong went a long way, it could not go all the way without substantially reimplementing Racket, which is an enormous enterprise. Absent all that, we would always have to rely on a "compile server". This was an obstacle for us in a previous system (http://www.wescheme.org/) so we didn't want to repeat that experience.
Ultimately, however, bringing Racket to the browser was not what we were setting out to achieve in Pyret. Rather, we were out to build a new language based on what we've learned from (a) teaching, (b) building systems, and (c) doing various projects on scripting languages. Pyret is our attempt to condense all that experience into a language that represents our needs well (it's still a work in progress). It just so happens that one of our (externally-imposed) constraints is to run in the browser with minimal server support.
In terms of effort, Whalesong was about four years of work by primarily one person, and it's still nowhere near done (because of how big Racket is). The initial Pyret was about 1.5 person years (though some of that was also spent building a peer-review system: http://cs.brown.edu/~sk/Publications/Papers/Published/ppkf-c...). The new Pyret is about two person years, and much farther along than the original #lang-based Pyret was. Indeed, the new Pyret is solid enough to be used in several classes without noticeable problems. So no, I would not agree with your assertion that the "same effort" would have brought Pyret to the browser.
Effort stats for both Whalesong and Pyret are impressive and humbling. Manifesto actually touches the importance of tackling "assemblers" including JavaScript, so I hope someone's actively researching the problem: performant Whalesong perhaps, or an entirely different approach.
Whalesong is moribund for now. The Pyret intermediate language is actually a really good compilation target for functional languages. The problem is that Racket has a lot more stuff than Pyret (some of which are discussed in the paper, others are things like delimited continuations). There's certainly a Racket-lite that drops these features, is still a very full language, and would compile very nicely to Pyret. Anyone want to help us build that? (-:
That was my suspicion as well: there could be a very usable and rich subset of Racket that could target JS without significant performance degradation. Sidestepping the deeper darker corners like I think ClojureScript does with Clojure? Herculean effort already it becomes even more daunting when you start picking up features to drop only to discover just how much of Racket depends on say delimeted control machinery. After all Racketeers have been eating their dog food so most if not all their PL research found its way into the design. Bitten by their own success :) The manifesto takes admirably healthy stance here: problems offer opportunity for research. Alas, when u consider the time it takes to build smth like Pyret or Whalesong your pool of researchers and implementers narrows pretty much to academia. Unless of course there's some benefactor who's willing to assume the expense and allow the time
ClojureScript is pretty sophisticated since it is considered production ready for commercial work and leverages much of Clojure's ongoing library development directly.
https://github.com/clojure/clojurescript/wiki
Not to take anything away from Pyret.