See also: https://github.com/vsedach/Parenscript TLDR: s-expression syntax for javascript, macros are written in common lisp.
Macros can actually be written in Parenscript as well, AFAIR. But the language blends itself very naturally with CL code.
LispyScript
21–30 of 43 posts
Re: LispyScript
#22Doesn't look like Lisp, more like Clojure. Basically none of the functions, macros or syntax is from Lisp. The documentation says: http://lispyscript.com/docs/ > LispyScript is not a dialect of Lisp. There is no list processing in LispyScript . LispyScript is Javascript using a Lispy syntax (a tree syntax). That's about right. It actually uses some kind of s-expressions, but not Lisp syntax.
This is why I called my version of this "Loosp", because it required a very loose (so probably incorrect) definition of Lisp to call it a Lisp: https://github.com/capnmidnight/betty-boop/blob/master/pong....
Re: LispyScript
#23Earlier quoted context omitted.
Some inaccuracies here. ClojureScript does not have to be compiled by Google Closure. That pass is an optional one for production builds. There is no "bridging" when using the Closure Compiler with non-Closure compatible code. The issue is that in production mode the Closure Compiler will make aggressive assumptions about what it can rename. So it's not about bridging it's about preventing renaming - again this is on…
> "again this is only relevant for advanced production builds" So, all real-life builds that anyone would care about.
Not really. Advanced optimizations doesn't matter for server-side JS whether Node.js or Nashorn.
Re: LispyScript
#24Nice! reminded me of http://ympbyc.github.io/LittleSmallscript/
Re: LispyScript
#25There is no shortage of JavaScript-Lisps, that’s for sure!
Re: LispyScript
#26Earlier quoted context omitted.
Not that you're wrong -- you're correct -- but I want to bring up that this was likely true at the time this was written. LispyScript has been around for a while.
First commit for lispy - march 5, 2012 First commit for sweet.js - August 1, 2012 im actually pretty shocked they are that close together.
I bet they both started around the time CoffeeScript started to get big -- it showed there was a market for compile-to-js-but-almost-js langs.
Re: LispyScript
#27Doesn't look like Lisp, more like Clojure. Basically none of the functions, macros or syntax is from Lisp. The documentation says: http://lispyscript.com/docs/ > LispyScript is not a dialect of Lisp. There is no list processing in LispyScript . LispyScript is Javascript using a Lispy syntax (a tree syntax). That's about right. It actually uses some kind of s-expressions, but not Lisp syntax.
> Basically none of the functions, macros or syntax is from Lisp.
Sounds like it's extremely well named, then. LispyScript is to Lisp as Javascript is to Java: an entirely different language with different syntax, semantics, standard library and performance characteristics, but with just enough superficial similarity to provide plausible deniability for the name.
Re: LispyScript
#28Earlier quoted context omitted.
Some inaccuracies here. ClojureScript does not have to be compiled by Google Closure. That pass is an optional one for production builds. There is no "bridging" when using the Closure Compiler with non-Closure compatible code. The issue is that in production mode the Closure Compiler will make aggressive assumptions about what it can rename. So it's not about bridging it's about preventing renaming - again this is on…
> "again this is only relevant for advanced production builds" So, all real-life builds that anyone would care about.
Think about where you would use CLJS - my use cases would not have an issue with extra 100kb of code - you don't use CLJS to do jQuery animations on your web page - you would use it to build complex single page apps or write server side code/scripts.
You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefits with immutability that's not my point - you're still going trough a lot more memory and stressing GC) - you use it to help you deal with your code because of it's semantics.
But in reality last time I tried CLJS I didn't really feel like it delivers on the productivity part and it's mostly because of implementation issues. IMO the decision to implement CLJS on top of Closure compiler and in Clojure (instead of going for a self hosting compiler) was a mistake - you can't overstate the value of REPL and fast iteration in a language like Clojure - and my last attempt to use CLJS the compiler/REPL environment far from what I would consider fast iteration : compiler took forever to start because of JVM and while it could run as a service it needed to be restarted frequently enough that it mattered, REPL was very unstable it would just die randomly - sometimes you'd need to refresh the page, sometimes you'd need to restart the server process. Oh and don't even get me started on the voodoo needed to get the damn thing running - install piggieback, then install austin and then add this weasel thingy then configure the server process all so you can get a halfworking repl and pray it doesn't break because good luck figuring out what's actually going on. Compare this to JS where I just go in to the devtools panel and test my code.
Re: LispyScript
#29I wouldn't say Lisp-like syntax is necessary for a macro system. It helps a bit... but all things considered, I believe pattern matching is a bigger boon to macro writing than syntax per se.
For those it may interest, I have made a language with mostly conventional syntax which supports macros: http://breuleux.github.io/earl-grey/
The macro system is modular, so you can easily write and publish macro libraries. I have written some for testing, gulp, and react. It's not super mature but it's getting there.
Re: LispyScript
#30Earlier quoted context omitted.
> "again this is only relevant for advanced production builds" So, all real-life builds that anyone would care about.
Think about where you would use CLJS - my use cases would not have an issue with extra 100kb of code - you don't use CLJS to do jQuery animations on your web page - you would use it to build complex single page apps or write server side code/scripts. You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefit…
Things are progressing and I encourage you to have another look.
$ lein new figwheel myproject
$ cd myproject
$ rlwrap lein figwheel
Browse to http://localhost:3449