In tcl the syntax is build from strings and in tclisp the syntax is build from symbols and cons cells.
tclisp could have a better syntax checking and real macros.
This is part II of a series of blog posts, but I don't know if part I or part III is as immediately relevant to us.
One of the things this touches on is associating expressions with source code. That's something I tend to neglect to do, but this makes it look easy.
The other thing is it shows a way to normalize expressions to other expressions, just using HOAS (aka putting functions in your expression AST). This makes expressions the only run time data structures needed in the language.
Normalization of expressions is commonly needed in dependent type theories because it makes it possible to compare types by intensional (implementation) equality, even if those types contain program expressions. (Comparing types for equality is needed for instance when typechecking a funtcion application, since you might have used an argument of incorrect type.)
In general, worrying about compatibility in the arc/anarki neighborhood is a fool's errand. Not worth doing. Just do what makes sense, and don't be afraid to be different.
That arc-js looks very promising, though also somewhat incompatible with the existing libraries.
For instance, the basic fizzbuzz example provided on the main page looks very similar, but doesn't actually run in anarki. Maybe that's anarki's fault, but the syntax of the for loop is different.
I do like the idea of arc ported to js though; makes getting access to mongodb easier, at the very least :)
Thanks for sharing, rocketnia! I’ve been looking into ways of getting started, and Arc.js looks like the most novice-friendly implementation so far. Node.js and browser is what I use for hobby coding anyway. :)
I would look at the boot.js file. It's kind of like arc.arc is for arc, in that it is a lisp-based bootstrap of all of the basic functions made available in the default environment.
It should give you basic examples of how to write code in wat, as well as show you which functions are defined. Of course, most of them don't actually have examples in the file, as it's merely defining the standard library, but it's a start. There's also test.wat, and the authors blog: http://axisofeval.blogspot.com/search/label/wat (which unfortunately mostly uses the underlying json representation for most of its code).
And the 'killer feature' of wat.js is not that it has first class environments or fexpr, which are admittedly very cool, but that the core language implementation that supports all of these and more is only a few hundred lines of code. There's more in the repository of course, but all of that is to provide the standard library or add sexpression parsing, etc. This makes wat a very good minimal platform for building a custom language.
Thank you so much for this!! arc-js looks great. I'm able to define and run Arc macros with it.
This changes everything. With arc-js you can start writing client-side apps in the browser without dealing with Javascript. You can add libraries in arc-js that do that (are there any already?) The big advantage is you bypass HTML: you can make a browser and a server send sexps back and forth.
There I was thinking there was no hope with an Arc in Javascript and sure enough Arc is quietly thriving.
I tried them now and was able to get up a Wat VM. But I haven't been able to figure out how to run macros in there.
I wish there were examples. Snippets you can copy paste that do lots of useful stuff like http://ycombinator.com/arc/tut.txt. It shouldn't take anyone more than 10secs to find how to do things. It's disheartening to hear such good work remains unused only because there are no examples but I suspect it's the truth. That's what happened to me.
Language designers think some cool esoteric feature is the killer feature of a language but a more useful feature might be examples: an implementation of an application developers want, like Arc did by providing a webserver and a blog.arc. If you are writing a language, ship a useful app with it, like C did with UNIX.
The creator (smihica, Shin Aoyama) hasn't come to the forum yet, but their work is impressive. Just look at that REPL start up in under a second! On my machine anyway. :)
Thanks to svetlyak40wt for discovering this project 80 days ago (http://arclanguage.org/item?id=18355). It was in active development then, and it's still active now.
---
The primary spark that led me to make Rainbow.js was a desire to respond constructively to threads like this one.
Using Rainbow was a side effect because I wanted to wow people with the execution speed, which conanite had already meticulously worked on in Rainbow. This was still tied into the desire to help those forum threads along: Between speed and portability, what possible excuse could there be not to use it? ^_^
Once I committed to particular technical goals involving consistency with Rainbow, the 20,000 lines of code were basically predetermined. It's kind of unfortunate that it would fail to be helpful in threads like this one, but it's not all a loss.
The secondary spark that led me to make Rainbow.js was that I wanted to get the hang of using JavaScript, after having worked mostly in Arc for a few years. That goal was met. :)
I must have missed the macros then. The biggest problem I had with wat-js is that... I couldn't figure out how to run it. I wish it had a single shell script that you ran and brought up a repl. So one doesn't have to spent time copy-pasting stuff from a text file into an html file and firing up a browser, or typing their code within double quotes or doing anything else.
I'm pretty sure it has macros. Even if it didn't, their effects are easily duplicated with fexprs.
Rather, a macro can be described as an extension of the compiler, while a fexpr is an extension of the interpreter. In a compiled language, macros can be an optimization tool, because they can perform arbitrary computation at compile time.
In wat.js, which I believe is interpreted, macros provide relatively little value. They can still perform slightly better, because they only need to be expanded once. To quote directly from manuel:
"To fexprs I also add macros. When a macro is used as the operator of a form, the form's code gets changed to the macro's output when the macro is first called, a technique I learned from here. I like macros because they make syntactic abstraction cost-free - with fexprs alone there is always an interpretative overhead. Still, Wat macros, like fexprs, do not work with quoted identifiers, but with first-class values, so many hygiene problems are avoided."
So generating HTML with the same kind of dsl that arc uses should be fairly painless. Either that, or I misunderstood what you were saying entirely.
When I looked at wat.js it didn't have macros. That was a bigger drawback than speed, because then you can't generate any HTML. An Arc in Javascript could get away with implementing less, like ignoring continuations and garbage collection.
I haven't gotten that far yet, but I was thinking it would be neat to hack something on top of wat.js until it could support arc.arc. It may not be the right way to create a fully compatible arc implementation, but it is certainly one of the smaller bases to build a javascript based lisp on. It also has a lot of the fundamental language features I wish arc had, like first class environments and fexprs, right out of the box.
The only drawback would be speed; a more directly compiled lisp would probably have better performance.
Yeah, that's something I'm trying to think about with the current project that I'm working on. Part of why I brought up mongodb support. Maybe something like datomic would be better.
Starting with simple files is actually really convenient and takes very little effort. Only fixing things that need fixing is a good way to make progress quickly, but it is a little disconcerting not to have many options to switch to.
Maybe building a simple arc-based database would be a good idea, but that also distracts from solving the actual problems I'm working on. Which did not initially include making a new database, as much fun as that would be.
I was working on a simple git-based data storage system for arc as part of my 'metagame' project. Not exactly designed for multi-server use though.
It's probably not. Restarts (and similar) just seemed like a really useful tool for use in production environments. Anything that makes error handling more powerful, flexible, or understandable is a good thing. But changing arc to support it might be a bit much, at least at this point.
I do think it would be good if we could improve arc's error handling though. Or at least error reporting on the repl.
Arc doesn't have hierarchical dynamic typing like that...
I had created a hierarchical typing system for arc once, by just changing the tagged symbol to a list of symbols that is treated as the type hierarchy, but I think I lost the code... I'll have to see if I can find it.
The news.arc code writes to files. It doesn't use an SQL database.
---
Even without SQL, code injection is something to worry about. The Arc codebase is a breeding ground for exactly this kind of issue, since it rarely does string escaping. Let's see...
HTML injection (XSS attacks): This is the kind of injection news.arc primarily needs to worry about. Almost every string it passes around is used directly as an HTML code snippet. Fortunately, every user input is sanitized thanks to the form-generating utilities in app.arc.
Shell injection: Make sure that any directory paths passed to (ensure-dir ...) are already shell-escaped. (Arc also invokes the shell in a few other places, but those don't need any extra escaping.)
Format string injection: Be careful about file paths passed to (tofile ...). Everything after the last slash must be a valid 0-argument format string. The format string syntax is described at http://docs.racket-lang.org/reference/Writing.html.
Arc injection: The prompt.arc webapp is explicitly designed to let admin users evaluate their own Arc code on the server. If an attacker gained access to this page, it would be worse than any other kind of code injection. Because of this, I don't recommend running prompt.arc on a production site. (If it can't be helped, I recommend at least using HTTPS so admin login credentials and commands can't be intercepted by a man-in-the-middle attack.)
"So, are there anything like restarts available for Racket/arc?"
I'm pretty sure the answer is no, for now.
With the right use of Racket's 'parameterize and 'current-parameterization, we could build a system that works like Common Lisp's conditions and restarts. (Global variables are an alternative to 'parameterize, but they'll have more awkward interactions with continuations and threads.)
I've only played with CL once or twice, but I seem to recall one of the nicest parts about conditions and restarts is that when a condition isn't caught at the REPL, the user gets a sub-prompt they can use to invoke a restart. Threads might give us something close to this behavior, if we make the REPL's catch-all condition handler block the thread while the user chooses a restart.
Unfortunately, all preexisting Racket/Arc errors will still use the exception system rather than this homemade condition system. In order to make conditions the main error mechanism, we might have to modify the way Arc compiles to Racket so that it traps exceptions and turns them into conditions.
Finally, CL's condition handlers use its subclassing system to find the most specific handler. Arc doesn't have hierarchical dynamic typing like that, or at least not in the main language, so it might not make sense to handle conditions that way.
Altogether this is quite a few feature interactions that would need to be considered, and we'd end up with quite a different REPL experience--maybe even a qualitatively different language. How do we know if it's worth it?
Well, arc has delimited continuations from racket, and I gather you can do anything with them. But if you figure out how, you come tell us :)
I think the CL implementations must have happened when I was away from the forum. Wart started out as a common lisp implementation of arc: http://arclanguage.org/item?id=12814; https://github.com/akkartik/wart/tree/sbcl. But again, I did this without ever grokking conditions and restarts. The OP was actually quite illuminating for me.
news.arc is one of the libraries that comes with arc, and is a branch of the source for Hacker News and the Arc Forum. It defines all of the functions related specifically to the news site, and is what allows you to run a clone of the forum. It's located in the lib folder of the anarki repo.
main.arc is the launch script I included in my arc-openshift repository. It just sets a few variables, and then launches the news server with the right parameters. It's located in the root directory of the arc-openshift repo.
Other files of interest are the arc libraries srv.arc and app.arc. srv.arc sets up a web server, and app.arc adds extra utilities for things like user management, etc.
