True, although the final (rev a) (rev b) loses some of the speed benefit in the tail-recursion. If we didn't care about order (which happens quite often) we can drop the (rev ...) things. Otherwise, we can use a modulo-cons form, but this exceedingly complicated.
accums seems good... I suggest pushing it on nex-3's arc-wiki.
What I would like to see is a proper order-preserving accum. Here's a try at a "reasonably efficient" implementation:
(mac accumf (accfn . body)
" Collects or accumulates the values given to all calls to `accfn' within
`body' and returns a list of those values. The returned list
is in the same order as calls to `accfn'.
See also [[accum]] [[summing]] "
(w/uniq (hd tl)
`(let (,hd ,tl ,accfn) nil
(= ,accfn
(fn (s)
(if ,hd
(do (= ,hd (cons s nil)) (= ,tl ,hd))
(do (= (cdr ,tl) (cons s nil)) (= ,tl (cdr ,tl))))))
,@body
hd))))
Thanks for your answers ! I think that might be an interesting functionnality to add in the core functions. I used it a few times, in quite different contexts. Partitioning a list from a given criteria looks like a frequent action...
Doesn't work in Arc2, but works in Anarki. Also doesn't work with macros, as you say. Macros aren't as big a deal however, because they cannot be shadowed by let or def, only by other macros with the same name.
Personally I think this is a pretty good answer to the hygiene issue. Probably not necessary in every single macro you write, but good if you intend lots of other people's code to use it.
Looks like my code when it's a three-liner and it really is a bit much to be coding (in my Algebra program):
(loop for denominator in denominators...
You are right (guessing at the implicit): "list" is a terrible name for a variable unless someone really is writing a general purpose list manipulation function, but we do see "lst" quite a bit over on c.l.lisp.
btw, the real question is whether you see "list" as a variable name in the Scheme source.
While we're on the subject, I know a number of people have been saying that Arc's unhygenic macros problems are a problem, because things like this break in a lisp-1:
(mac break (a b) `(list ,a ,b))
(let list nil (break 1 2)) => Error
However, you can simply unquote the function values in the macro.
(mac dont-break (a b) `(,list ,a ,b))
(let list nil (dont-break 1 2)) => (1 2)
To make this work for functions, you need to add ((procedure? s) s) to 'ac. Otherwise with arc2.tar:
arc> (mac dont-break (a b) `(,list ,a ,b))
#3(tagged mac #<procedure>)
arc> (let list nil (dont-break 1 2))
Error: "Bad object in expression #<procedure: list>"
Macros still remain a problem:
(mac list-macro parms `(,list ,@parms))
(mac break (a b) `(,list-macro ,a ,b))
(break 1 2) => Error
A problem with unquoting the function value is that if you redefine the function, any code that uses the macro will hold on to the original function as a literal. This means the solution doesn't lend itself well to exploratory programming.
Well, one could create a module system so that the macro would always see the function the way it was seen in the module where the macro was defined. Then, when the function name is rebound where the macro is applied, it doesn't affect the macro, but if the function is recompiled in its original module, it does affect the code produced by the macro. I'm not saying it's straight forward, but I do believe it's possible.
I guess I found my motivation for finally installing and learning git :) Did Eric or Nathan submit a post or comment about this? I'd like to give those boys some points.
Here's a suggestion: add the following bracket-detector stuff (untested):
(let bracket-sample '[a.highly-unlikely!symbol]
(def is-bracket (a)
(is (car a) (car bracket-sample)))
(def bracket-list (a)
((afn (a sample)
(if
(iso sample '(a.highly-unlikely!symbol))
a
(acons a)
(or
(self (car a) (car sample))
(self (cdr a) (cdr sample)))))
a bracket-sample)))
^^ again... code please! Seems pretty nice. Just wondering, does this use the parse combinator library on arc-wiki or is this something else? Haven't studied the parsec lib very well yet. If different, would it be possible to merge it into the arc-wiki lib/parsec.arc?
Here ya go, lib/treeparse.arc. Unlike the sloppy proof of concept hcase, this one might actually be useful.
This is different from parsecomb.arc in a number of ways, one being that it operates on lists and trees while parsecomb takes strings. Parsecomb also appears to be broken...
Incidentally, pg would like to conflate strings as a list of characters, so possibly with a "correct" implementation of treeparse we can still parse strings as well.
Possibly the brokenness in parsecomb currently is from the merge with arc1 and/or arc2
Edit: Hmm. Possibly you think this can be encapsulated using one of the module systems? Most of the components are functions anyway, and the existing macros end up evaluating to functions, so it may be possible to transform them to higher-level functions instead.
It would be nice to put it in a module, seeing as it binds allot of useful words. I like your module1plus, but without macro support it is hard to contain this library.
The macros seq, alt, cant-see, many, and many1 may appear to be expressible as functions, but they need to be macros to reference parsers not yet created.
(= a (alt 'y (many b)))
;; `b' is not bound yet, but will be by the time `a' is used.
(= b (alt 'x (many a)))
(parse a '(x y))
Oh, bummer. I guess I got too used to lazy evaluation in Haskell.
Macro support... dang. It's kind hard to scan through the code looking for macro definitions, and then you need to have them exportable, meaning you need the original list - and exportable macros will not be able to refer to the exporting environment (bummer).
Macros in packages are a hard problem, no doubt. I still wonder if some degree of macrolet hackery might do the trick.
On a brighter note, I decided to make the lazy semantics of "lib/treeparse.arc" a special case, not the default. That way, there only needs to be one macro, delay-parser. Apart from making the code cleaner, this also makes a module more feasible.
Hmm. Maybe export the macros as functions. Hmm. This also means that everything within the module has to be macro-expanded, in case macroexpansion creates a reference to a module-based macro. Aargh.
Minimizing the number axioms is good. Minimize the number of convenience macros is a different proposition. Most conditionals and closures don't need anaphora, so when I see the plain if or fn I know not there's nothing funny going on. The anaphoric versions tell me I need to look for the it/self references before I'll understand what I'm reading.
Other things we shouldn't do include eliminating let in favour of the more general with, and then eliminating with in favour of the more general withs.
Of course, (withs (a (foo) b (bar a) c (baz b)) ... ) is really just:
