Scheme (lambda args ...) is equivalent to Arc (fn args ...).
It allows to get the raw list of arguments, which may be empty (i.e: no arguments are passed).
So (if (pair? args) ((car args) h)) h) tests if args is a non-empty list (with pair?). If so, it uses the car of this
list as the initialiser. It calls it (((car args) h)) with the freshly created table, h, as parameter.
(An example of the "raw arguments list" behaviour in Arc:
arc> (def prnargs args ; /!\ no parents around "args"
(forlen i args (prn "arg n°" i ": " (args i))))
arc> (prnargs)
nil
arc> (prnargs 'a 'b)
arg n°0: a
arg n°1: b
nil
)
> ... removing table / obj > table ...
I believe 'obj is less used than 'table. 'table is more simple in that everyone knows what a (hash)table is, but an "object" is a fuzzy concept, as you pointed it out.
> but all kind of things are objects
Yep, and what most people call objects are more/less just a more/less "special" hashtable. That's why, I suppose, obj is called like that: just a synonym for table (although the function 'obj is != from 'table).
You can do a lot with an hashtable, and it's cool. Where is the problem?
(For info, Arc's templates also uses hashtables behind the hood, if I remember well. See also: Javascript objects.)
> I suppose what I'm saying is that it doesn't seem very useful to have table visible in Arc and in general
I agree with you that maybe having both 'obj and 'table is a bit confusing, and maybe too much. People may expect they are totally different things. And they are in a way redundant.
My quick idea would be to make 'table takes 0, 1 or more args. If 0, empty hash. If 1, it's an initialiser fn. If more it uses the args like 'obj does.
As I observed above (http://arclanguage.org/item?id=10528), table can't do this (unless we rotate names around, which would be a perfectly valid option), but here's a lightly-tested macro (with a terrible name) which exhibits your DWIMmy behaviour:
> I like your suggestion about changing to 'table to take variable numbers of arguments.
Then let's do it :-)
In ac.scm, we change the xdef of 'table, and the def of 'fill-table (which doesn't seem to be used anymore) to work with a normal list (and not an alist).
> Thanks much for your detailed and informative reply.
Thanks go to you for having a fresh view on the data structures of Arc, and questioning them. I was just "quoting the manual" and this is not hard.
----
To absz: thanks for mentioning "DWIM", I didn't know this acronym but this is exactly what I expect from a (programming) language. It is what differenciates a language from a (formal) notation IMO. Funny point, the (french) wikipedia article uses Perl as a DWIM-oriented language example :-)
Interesting that Thaddeus (http://www.arclanguage.org/item?id=10533) makes a mistake using 'obj / wants 'inst to work w/ 'obj. This comforts me in the idea that 'obj is confusing. People expects an "object" to do magic (inheritance, instanciation, etc), to be high-level, where they just expect an (hash)"table" to be a simple key/value store.
The DWIM definition of 'table given above would be even better if it could also take an alist as single argument, and use it to init the table (it's easily doable, but I'm tired now).
But maybe this DWIM stuff is crap because we're writing everything in Scheme and not in Arc.
Maybe (xdef new-table (lambda () (make-hash-table 'equal)), and then use the raw 'new-table and 'fill-table, 'listtab, 'tablist and co. to define a DWIM 'table in Arc.
Or maybe it's crap because DWIM is crap by nature and it's better to have (to know) 'table, 'obj, 'fill-table, etc.
What is sure is that it makes the "design work" easier, you can keep the 'table/etc. definitions shorter and cleaner in arc.arc/etc. What is less sure is if doing so (making the designer have the good life) is the way to have a pratical language for actual programmers.
I like your definition of table. The only advantage of 'obj is that keys don't need to be quoted. (Although sometimes that's a disadvantage too; the macro quotes them, so keys can't be determined at run-time)