Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
Simplify make-br-fn and permit 0-arg br-fns
- Loading branch information
957501d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a huge fan of this change. I've been using [do t], for example, to get a unary function that returned t.
It's not like I haven't been working around Anarki's spin on the square bracket syntax already though--in the same file, no less. If this kind of change is useful for the greater good, I don't mind it. :-p
957501d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your use case of [do t], it could easily be changed to [do _ t], or replaced by defining a standard function that always returns true. Personally, I prefer having more control over the arguments, and I've been frustrated by having to use (fn nil (thunk-body)) when I could just do [thunk-body]. This reformulation seems more consistent, and the definition itself is simpler and clearer as well.
It's disappointing that bracket fns don't support dotted lists... if we could fix that then 95% of anonymous functions could probably be replaced with br-fns. The only ones that might be a bit tricky after that are nested fns.
957501d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually prefer the idea of using just one kind of brackets all the time. Who needs square brackets? If we have...
...then
(fn () (thunk-body))
can become(thunk:thunk-body)
--with just one pair of brackets--thanks toa:b
ssyntax. In certain cases like(ccc:thunk:thunk-body)
, it can cost less than one pair of brackets, since it reuses the surrounding ones. Similarly,a.b
ssyntax would let my[do t]
becomeitfn.t
.I'd also prefer to remove all need for dotted lists, using something else for rest arg destructuring--perhaps
&
. This complicates destructuring, so it's probably not a net benefit for everyone.Also, I strongly prefer not to settle for "most of the time" when it comes to semantics. The
-mbf-argsyms
check forquote
is a hack. It doesn't account for macro uses like[obj _ t]
that expand intoquote
, not to mention uses of_
that are confined to inner functions (as in[do [_] t]
). If 'make-br-fn needs to determine its argument list by inspecting the free variables of its body, what I think it should do is compile its body into an AST, then explicitly get the AST's free variables using the same tool the compiler uses.However, refactoring the compiler to work like I've just implied would be a drastic departure from Arc, so I don't seriously recommend it for Anarki. As a second option, Anarki's square brackets could settle on a policy of "we WILL crawl over all the code looking for symbols for the argument list, regardless of whether they're quoted." Since the semantic madness lives inside a clear lexical boundary (the function body), the programmer can be aware of the meta-influence of the symbols they use in their code.
These are the kinds of things I'd contribute to Anarki myself, if only I didn't expect to get carried away and turn the whole language into Penknife. ^_^
957501d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, this is what it took to tweak Lathe to work on Anarki again: lathe/lathe@2d4cfb3
It's not too bad, though I was unable to do a reasonably tight grep to find places I needed to fix, and my unit test coverage is poor, so there are probably other tweaks I've missed.
Edit: Oh, found some more:
lathe/lathe@a5c0ad5
lathe/lathe@5cb063e
Edit: I just finished a thorough check, and this was all I found.
957501d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I just fixed seven occurrences of [...] that became nullary in news.arc: f311b38
There's also one usage in util.arc and two in arc.arc that would be affected, but since those files are loaded before make-br-fn.arc, I haven't changed them.