But in other languages you don't even have to bother with that. Accessing the third element of the stack is easily feasible and you can even guess how to do it.
And the fact that my variables have no name (they're all called "first element on the stack", "second element", etc.) reminds me assembly code, but without the efficiency : I can understand that in a low-level language as Forth, but it doesn't look like Factor is one.
But I can be wrong, and anyway Factor is on my "try it again later" list.
On the one hand, factor -does- have named variables.
On the other hand, once you start experimenting with stack stuff there's a moment where you go "aha" and it actually starts to make a lot of sense for temporary variables.
There are probably other aha moments further in that I haven't got to yet; I've not spent as much time with factor as I want to.
I dunno if I'll ever use it for "real stuff", but I think it's worth fighting your way through to the aha moments just like lisp and haskell are even if you never expect to use -them- for "real stuff".
It seems that required arguments after optional ones makes it hard for callers to think about what they are passing to the procedure. Keyword arguments solve this problem.
I may be mistaken, but isn't this destructuring already done by function definitions. I mean you can write:
(def bob args progn)
and args is properly bound to the list of arguments. Or you can choose to do
(def bob (a b c . rest) progn)
and it's bound that way.
arc> (def bob (a b (c d . rest1 ) . rest2) ( prn a b c d rest1 rest2))
*** redefining bob
#<procedure: bob>
arc> (bob 1 2 '(3 4) 5 6 7)
1234nil(5 6 7)
1
arc> (bob 1 2 '(3 4 5 6) 7 8 9)
1234(5 6)(7 8 9)
You see it's already doing the destructuring you want, without some complex syntax for it. The above code is arc0 I make no claims for it's functioning in arc1.
I disagree with 2. An official module system will be much more effective at using libraries once they are created. Without some module system, there won't be a way to create a standard directory for external dependencies to be found through a standard module system. If someone did make a system and it was adopted by a lot of people, I believe that it should be made standard so as to prevent splinter module systems.
A proper module system which works well with non-hygienic macros seems to be difficult to make. I don't know whether it would be better if macros are made first-class.
I disagree. Recall that macros in Arc have precedence in expressions over non-macros; that is, if obj in (obj x) is globally a macro, even if it is used as a variable name, all (obj x) will be replaced by the macroexpansion. Note that this applies for all x.
Suppose we have nested macro expressions. The inner macro will not see the expression until the outer macro processes that value; the outer macro might even decide to completely bollix the inner macroexpression.
(macro ....
(sub-macro ...))
Now suppose we declare a "using" macro, which replaces all symbols inside its expressions for other symbols, i.e.
arc> (using
(
foo bar
nitz koo)
'(foo bar nitz koo))
(bar bar koo koo)
Obviously, if we postulate another macro 'foo, the replacement done by using will prevent the macro 'foo from transforming any part of the (using ...) form.
The benefit of this using macro is as a basis for module systems. Suppose we have a module system such that:
Rewriting all symbols is what the CL package system does. Of course, the CL package system does not really rewrite symbols after parsing, it chooses different symbols for the same string in different packages when parsing.
A true module system just rewrites all identifiers that are globally referenced, without touching local identifiers and quoted symbols.
Why not local identifiers? It won't hurt anyway, since:
(fn (x) x) == (fn (y) y)
Quoted symbols are more problematic. The problem is that you can't determine how macros will bash quoted symbols. For example, (tag (x) ...) implicitly creates 'x. And prior to replacement, you can't be sure if the 'tag here is pg:arc1's tag or some other module's 'tag macro.
An alternative is to make the (pr ...) versions of similarly-named symbols in different modules the same; this probably involves hacking (coerce ... 'string) to cut out the module name for symbols.
Hmm, probably means we need a separate macro namespace. Heck, stuff like (let obj (table) (obj 1)) doesn't do as you expect, because of the mixing of macros in the same namespace as functions and values.
