Awesome! I've been looking forward to seeing some development on ar. ^_^ I like what you're doing with the argument lists. Have you found your arc2js progress useful for this? (Part of me wonders how Racket's local (define ...) forms compare against its other options in terms of performance. If they're faster, that could pose the same compilation annoyances as arc2js deals with. ;) )
As far as the name "Nu" goes, it's actually been taken by another lisp (and I'm not even talking about NewLISP :-p ): https://github.com/timburks/nu. Early this year I did a couple of months of Objective-C programming for work, and I GitHub-followed Nu in envy. XD
"I like what you're doing with the argument lists."
You mean the "destructuring is just lambdas" thing?
---
"Have you found your arc2js progress useful for this?"
No, except insofar as writing arc2js taught me some useful compiler things. For the most part, it's been pretty simple and easy, so I don't think arc2js helped much, if at all.
---
"Part of me wonders how Racket's local (define ...) forms compare against its other options in terms of performance."
(let a nil (%nocompile (racket-define a 5)) a)
(let a nil (= a 5) a)
Time: 1500-1600 ms
(let a nil (%nocompile (racket-let* ((a 5)) a)))
(let a nil (%nocompile (racket-let ((a 5)) a)))
(let a nil (let a 5 a))
(let a nil a)
Time: 1400-1500 ms
It would seem Racket optimizes lambdas very heavily.
---
"As far as the name "Nu" goes, it's actually been taken by another lisp (and I'm not even talking about NewLISP :-p )"
Darn. I still like the name "Nu" enough that I want to keep it, though.
It took me a while to reply because I was planning to do some of my own testing before posting, but I haven't found the time.
---
"You mean the "destructuring is just lambdas" thing?"
No, I don't know what to think about that yet. I like it if and only if this works:
(let (a . b) '(1 . 2)
...)
Even if that works, I almost expect Racket to copy a mutable argument list into an immutable one for use inside the lambda, so here's a second test case:
(withs (foo (list 1 2 3)
(a . b) foo)
(= b.0 4)
(is foo.1 4))
What I definitely do like is the use of Racket's optional arg syntax where possible. ^_^
---
"It would seem Racket optimizes lambdas very heavily."
IMO, those examples aren't normal uses of (define ...), since they're contexts where the variable is already defined. I'd like to test these cases:
; Racket code
(let ((a 5)) a)
((lambda (a) a) 5)
(begin (define a 5) a)
; NOTE: Make sure this (begin ...) isn't at the top level, or the
; definition will be global.
(let () (define a 5) a)
((lambda () (define a 5) a))
* Internal-definition expansion has changed to use `let*' semantics
for sequences that contain no back references. This change
removes a performance penalty for using internal definitions
instead of `let' in common cases, and it only changes the meaning
of programs that capture continuations in internal definitions.
Internal definitions are now considered preferable in style to
`let'.
Then again, if they're going to make more semantic changes like this one, it might be better to avoid compiling to an internal-definition style. :-p
Anyway, from the phrasing in the changelog, it sounds like internal definitions are implemented in ways the programmer can already control at a lower level with things like 'let*, so you'll probably continue to find that internal definitions are at least as slow as other options.
The reason is because racket-mlist->list expects a proper list. I can fix that easily.
Update: I fixed racket-mlist->list, but Racket's apply absolutely positively requires a proper list, so it looks like I can't use nested lambdas if I want to fix that: I'll have to use a Racket let*
---
"I almost expect Racket to copy a mutable argument list into an immutable one for use inside the lambda"
It's true, it does copy the list, so that returns nil. I wonder if I can work around that...
---
"One reason it's on my mind is the Racket 5.2 changelog"
I'm not using Racket 5.2. And even if I were, the reason for the speed tests was to see how it would perform within the (fn ...) expansion, where it does indeed overwrite an already-existing variable. (Though I could change it to use a gensym...)
