You should see a little green box in the upper-right panel. If you click on it, it should pop up a dialog box that says "Hi!"
---
At this point it's already a nicer experience than entering stuff into the REPL. But I can do better. I plan to add in CodeMirror[1] support for the textarea on the left side, and add some more polish and such.
Awesome, now there's line numbers! Later on I'll write up a mode that will add syntax highlighting and auto-indent to CodeMirror for Nulan, but for now this will do.
Firstly, there's now an interactive tutorial. Just open up "nulan.html", and if you don't see the tutorial, click the "Reset Tutorial" button at the top. Be careful, it'll clobber any changes you've made.
Secondly, you might have noticed that the editor has syntax highlighting now. But it's actually really cool. First, try inputting this:
$mac foo -> a b c
a + b + c
foo 1 2 3
def foo -> a b c
a + b + c
foo 1 2 3
Notice that it colored the first "foo" green because it's a macro, and the second "foo" orange because it's a function. It also colored local variables blue.
Now try inputting this:
# Array comprehensions
box in
$mac for -> x {('in) n y}
'y.map -> n x
$syntax-infix for 0 [ order "right" ]
$syntax-infix in 0 [ order "right" ]
(x + 2) for x in {1 2 3}
Notice that syntax is colored grey. Not just the built-in syntax, but user-created syntax is colored grey as well! It also understands delimiters:
$mac ^ -> a b
a + b
$syntax-infix ^ 0 [ delimiter %t ]
prn 1^2
Lastly, you can use "Debug mode" to toggle whether additional information is displayed in the lower-right panel or not.
You'll have to use the "Reset Tutorial" button to see all the changes.
The biggest change is that you can now click on an expression to highlight it. To see what I mean, try clicking on stuff in the tutorial.
But the coolest part is that the highlighting understands boxes. Try inputting this:
box foo = 5
foo + 10
box foo = 20
foo + 30
Now try clicking on the 1st or 2nd "foo". Then try clicking on the 3rd or 4th "foo". And it's so smart, it can even differentiate local variables (which is non-trivial because Nulan compiles top-level forms, like Arc):
Once again, try clicking the 1st or 2nd "foo", then the 3rd or 4th "foo".
It's also smart enough to know that the "." syntax is a string, even though it looks like a symbol:
box foo = []
foo.bar <= 5
foo.bar
So, obviously this isn't just a simple name search. The nice thing about this is, because Nulan uses boxes, it will only highlight the symbols that evaluate to the same box.
Imagine a search/replace function that operates on boxes rather than symbols: you'll be able to find/rename exactly the right symbols, rather than symbols that happen to have the same name.
"if-box is a kinda contrived example. Perhaps we can find something better?"
If you have a better suggestion, I'm all ears. But I settled on that because A) it's simple, B) it's short, C) it's something that does actually come up in practice, so it's not too contrived.
---
"What's the difference between w/uniq and w/box? Both seem to create boxes."
Well, to explain this... unique variables are actually implemented as anonymous boxes. So implementation-wise, there's not much difference.
The difference is in the actual macros "w/box" and "w/uniq". Here's the definition for them:
$mac w/box -> @args body
'w/new-scope
| var ,@args
| body
$mac w/uniq -> @args body
'w/box ,@(args.map -> x 'x = make-uniq;)
body
The answer is that "quote" inserts boxes for global symbols, but values for local symbols. That is, this macro...
$mac foo ->
w/box bar = 5
'bar + 2
...returns "5 + 2", not "#<box bar> + 2". This is an unfortunate inconsistency which happens because I'm using JavaScript variables for the sake of speed.
I thought about having it throw an error for local symbols, which would have required you to write the macro like this:
$mac foo ->
w/box bar = 5
',bar + 2
But I decided that it wasn't worth it. Now that I think about it, I wonder if it would be possible to hack something up so you no longer need w/uniq...
---
"I tried running this and got the following"
It works fine for me. And in fact, the code snippet you posted seems exactly the same as what is already in the tutorial. Maybe you intended to paste something else?
As for the error... yeah, there are still some cryptic errors. I plan to make them more meaningful later.
"Now that I think about it, I wonder if it would be possible to hack something up so you no longer need w/uniq..."
After thinking about it some more, I realized it won't work very well. It would require me to make all variables global, which would slow things down and be more verbose.
I pasted your DOM demo code twice, and then I was able to access both window.x and window.x2 from within Nulan. Is this intentional?
I also appended some DOM elements to the parent frame using "window.parent.document.append-child x", and they didn't get cleared on each update, but that's my own fault I guess. :-p
"I pasted your DOM demo code twice, and then I was able to access both window.x and window.x2 from within Nulan. Is this intentional?"
Yes, absolutely. It's how Nulan ensures that every variable is bound to a single "box". This also has the nice property that all the different "versions" of a variable can be accessed from the JavaScript side.
Ordinarily you can't access the different versions from within Nulan, but "window" is one of the ways you can do so. Another way would be the "&" macro which bypasses the Nulan compiler.
---
"I also appended some DOM elements to the parent frame using "window.parent.document.append-child x", and they didn't get cleared on each update, but that's my own fault I guess. :-p"
Yeah, only the <iframe> is sandboxed. Of course you can refresh the page to clear it out. Don't worry, it'll save the text you typed in the textarea.
