Arc Forumnew | comments | leaders | submitlogin
Rainbow.js and Rocketnia's Arc libraries are now on npm
4 points by rocketnia 1060 days ago | 2 comments
I've been spending a bunch of time polishing up old projects in the past couple of months. I've been adding CI scripts to things that didn't have them before and publishing some repos on npm.

I'll write a follow-up comment to post links to the various repos I'm talking about.

.

== Rainbow.js ==

One of those is Rainbow.js.

  $ npm install --global rainbow-js-arc
  $ rainbow-js-arc init-arc my-arc-host-dir/
  $ cd my-arc-host-dir/
  $ rainbow-js-arc run-compat -e '(prn "Hello, world!")'
One of the first things I did was to simplify the license boilerplate back to a simpler Artistic License 2.0 declaration. What I had there before was a sort of tangle of Artistic License 2.0 licenses, which probably made the license look even more fearsome than it should have.

Once I got to running the code, it turned out Rainbow.js needed a lot of TLC before it was in the right shape to install and invoke from a CI script. In fact, I think I had never properly run it on the Rainbow unit tests before.

It's up and running them in a CI script now, and the readme's usage instructions are up to date with the new npm-based installation approach, which I've also shown off above.

.

== Framewarc ==

Another repo I spruced up is Framewarc. Framewarc is the new name for the Arc libraries I used to refer to simply as Lathe. (Lathe is a much more extensive set of repositories now. Forking the Arc parts out into their own repository has been overdue.)

I've actually put Framewarc on npm, despite having little to nothing to do with JavaScript, if only so it can be installed together with Rainbow.js:

  $ npm install --global rainbow-js-arc framewarc
  $ rainbow-js-arc init-arc my-arc-host-dir/
  $ framewarc copy-into my-arc-host-dir/lib/framewarc/
  $ cd my-arc-host-dir/
  $ rainbow-js-arc run-compat -e \
      '(= fwarc-dir* "lib/framewarc/")' \
      '(load:+ fwarc-dir* "loadfirst.arc")' \
      '(loadfromwd:+ fwarc-dir* "examples/multirule-demo.arc")'
As far as package managers go, I like npm. I know my way around it, it makes it easy to install CLI tools like these (which is particularly nice for publishing language implementations like Rainbow.js), it's feasible in many cases to bundle npm packages to run them in the browser, and its versioning makes it easy for users to pin against certain versions.

Version pinning has pros and cons. There's a lot that can be said about how wise it is to build ecosystems full of breaking change treadmills, or on the other hand how feasible it is to disallow breaking changes altogether. But this is Arc we're talking about, and experimentation with breaking changes is part of the point, isn't it? :) Version pinning and lockfiles are tools that make things somewhat more manageable when breaking changes occur.

While Framewarc was home to several experiments that are interesting in their own right, I always felt Framewarc's most successful aspect was its portability across Arc implementations and its resulting suitability as a test suite for new ones. On the other hand, I also count this as its biggest failure.

Portability is an ironic thing to pursue in a language as experimental, as fun, as as unencapsulated as Arc is. Portability isn't everyone's idea of fun, and typically even I don't have fun with it so much as I find it a necessary precondition for everything else I want to do.

So was Framewarc a good or bad thing to build for Arc? I think about that a lot. I didn't see people using it, which in hindsight is probably because it was a pile of code that I threw over the wall and didn't provide any tutorials for. To a large extent it felt like a way for me to say "gotcha" when someone had an Arc implementation that was slightly off, and it varied whether people appreciated hearing that kind of feedback. I felt like I was providing stop energy for a certain kind of experimentation-oriented Arc and start energy for a more compatibility-oriented kind.

But whether it's good or bad, it can probably be said that Framewarc is a more beaurocratic approach to Arc. So I've named it Framewarc. It's a framework like jQuery, facilitating portability between browsers. It's a few other kinds of framework too, especially in the way its module system invades the way Arc programs are constructed. All the ideas I've had for Arc module systems are at least a little bit invasive of the programming style, so even though Framewarc has been stagnant for some time now, I think it'll be a natural home for iterating upon new module system ideas that raise up the whole ecosystem of Arc implementations.

At any rate, if anyone's looking to use or to build frameworks in Arc, they might find Framewarc interesting. :) It can be good for the people who like it, without defining the Arc experience for everyone else.

Currently, Framewarc is a repository on my GitHub account. I'd like to dedicate it to the arclanguage organization if that's all right.



3 points by rocketnia 1060 days ago | link

Links:

- Rainbow.js on GitHub: https://github.com/arclanguage/rainbow-js

- Rainbow.js on GitHub (current snapshot link): https://github.com/arclanguage/rainbow-js/tree/655c4e493c417...

- Rainbow.js on npm (currently version 0.2.1): https://www.npmjs.com/package/rainbow-js-arc

- Framewarc on GitHub: https://github.com/rocketnia/framewarc

- Framewarc on GitHub (current snapshot link): https://github.com/rocketnia/framewarc/tree/12b6962fc3b7fb93...

- Framewarc on npm (currently version 0.1.2): https://www.npmjs.com/package/framewarc

- The original Lathe repo (old link): https://github.com/rocketnia/lathe

- The original Lathe repo (new link): https://github.com/lathe/lathe

- The original Lathe repo (current snapshot link): https://github.com/lathe/lathe/tree/79302086a5a6876d8e282d8f...

Another repo that I just forked off of the original Lathe repo is Lathe Comforts for JS:

- Lathe Comforts for JS: https://github.com/lathe/lathe-comforts-for-js

- Lathe Comforts for JS (current snapshot link): https://github.com/lathe/lathe-comforts-for-js/tree/165d3844...

-----

2 points by rocketnia 1059 days ago | link

Tonight I did the same thing for the last of my Arc repos, Penknife.

  $ npm install --global rainbow-js-arc framewarc penknife-lang
  $ rainbow-js-arc init-arc my-arc-host-dir/
  $ framewarc copy-into my-arc-host-dir/lib/framewarc/
  $ penknife-lang copy-into my-arc-host-dir/lib/penknife/
  $ cd my-arc-host-dir/
  $ rainbow-js-arc run-compat -e \
      '(= fwarc-dir* "lib/framewarc/")' \
      '(load:+ fwarc-dir* "loadfirst.arc")' \
      '(= penknife-dir* "lib/penknife/")' \
      '(load:+ penknife-dir* "penknife.arc")' \
      '(pkrepl)' \
      -q
  pk> [+ arc["Hello, "] arc["world!"]]
  "Hello, world!"
Penknife really was just a pile of code before now. I originally wrote it on my commute using an Android phone. Now I've finally gotten around to giving it a readme, a .gitignore, and all that. Whew. :)

There was another language I called Penknife a couple of years later because I thought of it as having the same set of design goals, so technically this one's more like Penknife Mk. I. That's what I think I'll call it.

Something about Penknife Mk. I that I often think back to is its approach to macro hygiene.

Its syntax is primarily string-based, but with the ability for other values to be embedded inside the strings. It has a kind of quasiquotaton that surrounds the quoted section with an object wrapper that the macroexpander recognizes. When the macroexpander expands that expression, it switches over to using the scope at the macro's definition site. Interpolations in the quasiquotation are surrounded with another wrapper that causes the macroexpander to switch back to the caller's scope.

When the macro is defined, its lexical scope is captured and carried on the macro's binding. That way, it's the namespace that holds other namespaces inside it. The syntax trees don't have to hold namespaces; they can just hold paths to traverse the namespace hierarchy.

I still think of this as a nice sweet spot; the code has a context-independent enough identity to be compiled, while the namespaces are mutable enough to allow REPL interaction.

Racket's sets-of-scopes approach to hygiene is mature and supports advanced features like local macros and local definition blocks, but I think of it as kind of sloppy. It spray paints one piece of information over the whole syntax tree just to mark that a variable is in scope. This approach could be handy in cases where variable scopes overlap with each other in non-hierarchical ways -- where sometimes one variable is in scope, sometimes the other, and sometimes both -- but I feel like Penknife's wrapper objects are a much tidier model of the typical hierarchical structure. There've been many moments in my Racket programming when I would have liked Racket to have Penknife Mk. I's approach to hygiene instead.

- Penknife Mk. I on GitHub: https://github.com/rocketnia/penknife

- Penknife Mk. I on GitHub (current snapshot link): https://github.com/rocketnia/penknife/commit/509a7c21d750a24...

- Penknife Mk. I on npm (currently version 0.1.0): https://www.npmjs.com/package/penknife-lang

- The Era repo on GitHub, home of Penknife Mk. II and a few other things: https://github.com/era-platform/era

- The Era repo (current snapshot link): https://github.com/era-platform/era/commit/7f6751cb4d15f8c8c...

-----