Unfortunately, this is then deoptimized for the most common one-argument case, where you have to write [... _.0 ...]. We could have [...] expand to (fn __ (let _ (car _) ...)), so that you would have
(reduce [- (/ __.1 (* 2 __.0))] mylist)
but still have
(map [+ _ (* _ _)] myotherlist)
. I still prefer the _1, _2, ... syntax, though---unsurprisingly, as I contributed that implementation (though not the idea) :)
Actually, I do think the _1, _2 .. syntax makes the most sense, if you aren't wanting to name parameters. Though maybe (as was mentioned above) in some cases, the first three should be a b c, or x y z? I don't know how you would set that up to work well with what already exists though.
If that's the case, we have a much larger problem. From the "copyright" file:
This software is copyright (c) Paul Graham and Robert Morris. Permission
to use it is granted under the Perl Foundations's Artistic License 2.0.
This is from arc2.tar (and thus Anarki as well). Thus if that's true about the Artistic License, all of Anarki is in violation. According to Wikipedia (http://en.wikipedia.org/wiki/Artistic_License), however, the Artistic License 2.0 is both free and open source---in fact, it's GPL compatible, and perl itself is dual-licensed under both of said licenses. Thus, I would think we would be OK.
It's a bit late/early and IANAL, but my reading of the Artistic License is that we are OK given section 4. Section 4 says that we can distribute modified versions of the source provided we document the differences and either: (a) make the modified version available to the original creator under the original license; (b) ensure that one can install both the modified and original versions separately and that the modified one has a different name; or (c) allow redistribution of the source under either this license or another free license. We're definitely doing (a) and (c) and we're probably doing (b), so if I understand this correctly, we should be in the clear.
Thoughts on this interpretation? This is much bigger than just one library, after all...
Somewhat annoying, as doing a 'diff' is probably not enough.
It'll also become slightly messy if pg's statement from a month ago becomes true, and there will be new versions of arc coming out in october / november. If we pick up features from different versions of arc, would the changes compared to arc2, as well as the changes compared to arc3 need to be documented.
I guess the value of forcing good documentation of the changes is that it becomes easier for pg to distill a new arc version out of the mutants that the community is spawning, as they'll have their features well documented.
The deal with path separators has to do with the difference between the classic Mac OS (9 and lower) and Mac OS X. Classic Macs used their own path system, which used :s as the path separator (e.g., ":Macintosh HD:Documents:Arc:tut.txt"). When the switch to OS X came, suddenly everything was based on Unix, so file paths became sane (e.g., "/Users/username/Documents/Arc/tut.txt" or even "~/Documents/Arc/tut.txt"). Nevertheless, in the name of backwards compatibility, many things still display paths in the old format, the GUI pretends that :s in file names are actually /s, and AppleScript deals natively with old-style filenames.
There was some reason I didn't do it that way (I'm the author of ArcLite). IIRC, it was because the semantics of Arc forms differed in a way that would basically require an Arc interpreter anyway, even if you compiled them. For example,
(foo "bar" 1 2)
is only a function call if foo is a function object. If foo is an array, it's an array index; if it's a hash, it's a dictionary get (both ill-formed in this example). Other operations are similarly polymorphic, eg. overloading + for addition and concatenation. In order to translate that reliably to JavaScript, you'd need to turn every funcall form into a type-dispatch. At that point, you're basically writing an interpreter anyway.
(def >> args
; throw an error here so that user won't get
; mysterious errors in the 'reduce part
(if (no args)
(err "'>> requires at least one argument"))
(reduce (fn (a b) b.a) args))
If you are actually typing mzscheme-m-fas.scm (which is not what you wrote in your original comment), that's your problem: you need to write mzscheme -m -f as.scm . (If not, I don't know what to say.)
And a stylistic note: when replying to someone, click on the link to their comment and actually reply; it makes following the discussion more smooth :)
Turns out the error was even sillier: I had to switch to the arc2 directory and then execute mzscheme -m -f as.scm. (I was not lying when I told you I was new at this). Sorry for the stylistic annoyance. Thanks for your help!
For what it's worth, (PLT) Scheme can in fact do what you require. After all, there's an implementation of defmacro that ships with it (though it might be called something else)! And there's a way (if I recall correctly, a very long, verbose way, shoring up your second reason) to implement aif and the like in their system by "requesting a shadower" or something like that.
The biggest reason Arc has unhygienic macros is that they are conceptually simpler in terms of implementation: the code that the macro outputs is spliced right in, with no preprocessing/wrapping/whatever. If macros were hygienic, they would have to be preprocessed somehow before being substituted in.
Whether this simplicity is better than hygiene is, as you have probably noticed, argued about, but that's the rationale.
