Most OO languages don't just "implicitly bind" self; self (or this) is usually a reserved word. A conflict with another variable is made impossible because you can't say "int this = 4" in Java or C++. As pointed out, Python already makes the binding explicit.
Further, let us imagine for a moment that lambda closures and class instances are ... different things.
Perhaps modules should be valid containers. Thus instead of introducing a new syntax foo@a, we can use (foo 'a) and foo!a using sugar already in place. (I realize I am not the first person to say that.) I also would not like having to use mdef and m= within a module. Ideally, I should just use def, mac, and = as normal and export the symbols I want visible from outside.
(module foo (export a bar)
(= a 'in-top)
(def foo (x) (+ x 1))
(def bar (x) (+ x 1))
(pr a))
(prn foo!a)
(foo!bar 0)
(= bar foo!bar) ; an import.
(= a2 foo!a) ; a qualified import.
This could all be implemented as an optional library, except for those pesky macros. And of course, we do need a module system with adequate macro support.
What about something like what you are proposing, but where you have to explicitly state when you use the module namespace, since we obviously can't overwrite = without sad effects ?
For example, let's take the $ symbol (another ugly one :) to mean "the current module". The above could be written :
(module foo (export a bar)
(= $!a 'in-top)
(def $!foo (x) (+ x 1))
(def $!bar (x) (+ x 1))
(pr a))
(prn foo!a)
(foo!bar 0)
(= bar foo!bar) ; an import.
(= a2 foo!a) ; a qualified import.
Advantages :
- very simple
- written in pure Arc (thus candidate to the core language)
Here's a macro implementing part of that behavior :
(= $ nil)
(= $path* '()) ; Current module hierarchy
(mac module (name . body)
(w/uniq old-$
`(with (,old-$ $)
(= $ (table))
(push $ $path*)
,@body
(pop $path*)
(if $path*
(= (,old-$ ',name) $) ; Put it in the parent
(= ,name $)) ; Put it in global namespace
(= $ ,old-$))))
It supports imbricated modules. To import a module, or do a qualified import, the classical table manipulation functions work.
Question (dunno the answer, not on my hacking computer): how will a macro receive the expression (foo:bar foo)? As (foo (bar foo))? as ((compose foo bar) foo)? As (|foo:bar| foo)? (|| is used to enclose a literal in symbols)
There's a problem with using = and def. I tried it, but many parts of the core and libraries assume a unique namespace. As commands can have many side-effects, everything breaks easily.
Here's a different idea. Suppose that instead we build a basic modulesystem which transforms:
(modules-base
;name of module.
foo
;set of functions in this module
(bar)
;set of module variables
(nitz)
;set of functions from other modules
((module2 hmm niawniaw))
(def bar (x) (hmm) (niawniaw) (do1 nitz (= nitz x))))
(modules-base
foo
(bar)
(nitz)
;gotten by taking (keys module2)
((module2 hmm niawniaw))
(def bar (x) (do1 nitz (= nitz x))))
Weaknesses: (1) we can't make module-variables accessible outside. If we had access to environments, though, we could.
(2) macros are impossible as yet, whether shared or not. Possibly, we need macrolet, and adding some mechanism to store macros separately from the module table - possibly in a table-of-tables module-macros.
Implementation: simple scanning would be nice. However, modules-basic would be better implemented by a 'macrolet form.
That reminds me, I ended up reinventing Cells over the table in Arc because the real deal was so big it would have been a heckuva project, but I started on the actual code and... whoa! I have one chunk I found easiest to express as a very simple state machine using Common Lisp's tagbody/go and I had very little confidence in my conversion to a functional solution.
You gave `map' strings as input, so it attempts to return a string. That means it is trying to map the output of `is' into the characters of a string, but t and nil aren't charactors.
(def char-is (a b) (if (is a b) #\t #\f))
(map char-is "abba" "abab") => "ttff"
Common Lisp addresses this issue by having `map' take a result type as the first argument.
I'm not so sure about this. I think changes of the filling-up-namespace sort are reasonable, for the same reason being a Lisp-1 is reasonable: conflicts happen rarely in practice.
A better solution would be to try to ensure that only generally useful macros are added to arc.arc, and that they have names that are unlikely to be used as local variables. Or even better would be to make local variables shadow macros.
Consider this, though: "help" is defined as a macro. Some of the REPL-var code needs macros. The drop-into-scheme operator is a macro. I don't think we want to make people load a library file to use these.
I see the compatibility rule as more of a guideline - try not to break the functionality of stuff that already exists. But I don't think it should limit experimentation and exploration, including exploration of what's useful to have in arc.arc.
OK, I'll backpedal a bit here. The last thing I want is to have to require "lib/help.arc" :). It should be easy to find out what macros have been added though -- as much for curiosity as for compatibility. I'll try and whip up a script tonight, unless someone beats me to it.
Not yet, although I'm working on it. The main problem is that currently, destructuring splits on the (car ...) and (cdr ...) of each list node in the pattern, something like this:
;a is the variable that contains the current list node of the function input
;p is the pattern
`(and (acons ,a)
; this creates the test
(let ,a (car ,a) ,(self a (car p)))
(let ,a (cdr ,a) ,(self a (cdr p))))
Obviously, I'll need to resequence them - the cdr branch has to be physically located within the car branch, so that I can capture any variables in the created guards.
LOL. I didn't even realize this was legal code. But mind you, Arc will be the one destructuring the pattern within the first element of ,(... ...), meaning it won't count the number of elements and all that. Hmm. Note sure if going recursive here is a good idea. Hmm.
