Well, I do not totally agree with you there. I have programmed in Arc both for fun and work, and have also coded in Scheme a little, and I really find the . and ! syntax is really a good thing for structure access, mainly when you have nested structures. You know, when you have 3 or 4 opening parentheses at the same time. Too sad you can't fully use it in these situations.
But it's not a problem of fear of parentheses ; actually I couldn't find other cases where . and ! could be used without feeling a bit ugly (i.e. in calling functions or macros). Yes, parentheses & s-exprs are great, but I don't believe they should be the only syntax for accessing structures.
Don't worry anyway, I don't think Paul would integrate suggestions he considers weak, even if many of us asked it.
One thing that it's not good at (as far as I could tell) but is generally useful for a wiki is file uploads through web. I'm planning to add this myself but it's about 3rd or 4th on my list so I won't be upset if someone else beats me to it. hint hint.
Very good idea. I think it would be better if it was done by pg on this site. Spreading Arc stuff all around the web is not the best way to have a united community. And the problem would remain the same : how could someone coming in a few weeks know where that wiki is ?
I agree- using dots/exclamations in multiparameter functions is definitely pretty scuzzy, so it makes sense to use this semantic space for something else, too...
The reader (I would argue) should always make the assumption that the dot/excl implies single-parameter functions. This would be particularly nice in nested tables... Imagine we had a table of tables of city populations:
You can use one hash table per type of shape (that would be called a class in many other languages :). For example, a hash called sphere and one called plane. Each of these hashes would have an entry whose key is the generic name of the function (intersect, etc.) and whose value would be the implementation of the function for that type.
Finally, if x is your object and (car x) gives you its type, you can call its intersect function this way :
(withs (type (car x)
class (classes type)
function (class 'intersect))
(function x))
If you have parameters, they must be added after x in the last line. Basically, that's it. But there are many other possibilities if you don't like this one for any reason. And anyway, maybe someone else will give you a better one.
I would like to emphasize the bit "once that is working"... it can be a bit much to get the whole mechanism working at the same time as developing the macro. So get the flow going from a text file being read in to the correct function being called for that shape and maybe do a few shapes until you are sure the beast is about right, then do the macrology. Especially if a macro is in a separate file (as it should be) and you are not reloading the whole shebang each time you run, you'll go nuts running old code even after changing the macro if you just reload the macro-defining file. Add to that the fact that the mechanism itself will be a moving target... well, I like to divide and conquer these deals.
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.
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.
This "array" support is really for an abstract sparse array (with a hashtable implementation). I think what's being referred to is a "real array" (with a sequential-cells-of-memory implementation.)
Do you think it is the right thing ? If so, I'll push it to the git. Nothing amazing there, just mzscheme vectors that can be called as hash tables, lists or string. It's got a constructor (vec) and responds to len. Any further function can (should) be written in Arc.
arc> (= v (vec 10))
#10(nil)
arc> (= (v 1) 0)
0
arc> (len v)
10
arc> (v 0)
nil
arc> (v 1)
0
arc> (v 10)
Error: "vector-ref: index 10 out of range [0, 9] for vector: #10(nil 0 nil)"
Edit: Although it might (?) be better in the lib/array.arc, unless of course it's already integrated into ac.scm...
Edit2: Also, I hope (vec ...) is a function, not a macro or special form, so that existing code that uses vec as a local variable for a collection, or as a function, can still work.
It can't be put in a .arc file, since it is pure scheme code. Further functions dealing with vectors should go in lib/array.arc, however. And yes, vec is a function.
