If by "atom" you mean non-conses that aren't tables, strings, or functions:
$ diff -u old-ac.scm new-ac.scm
--- old-ac.scm 2010-12-01 10:18:36.961984734 -0800
+++ new-ac.scm 2010-12-01 10:27:02.058606152 -0800
@@ -647,7 +647,7 @@
; ((or (number? fn) (symbol? fn)) fn)
; another possibility: constant in functional pos means it gets
; passed to the first arg, i.e. ('kids item) means (item 'kids).
- (#t (err "Function call on inappropriate object" fn args))))
+ (#t (ac-niltree (apply list fn (ar-nil-terminate args))))))
(xdef apply (lambda (fn . args)
(ar-apply fn (ar-apply-args args))))
arc> (1 2 3)
(1 2 3)
arc> (+ (1 2 3) (4 5 6))
(1 2 3 4 5 6)
arc> ('a 'b 'c)
(a b c)
arc> (map [1] ('a 'b 'c))
((1) (1) (1))
You could, of course, have another conditional (e.g., only do it for numbers instead of numbers, exceptions, quoted symbols, sockets, etc.). The catch-all seems dangerous. The special-casing hardly seems worthwhile. It saves you, what, a quote character for list literals (or otherwise a call to list, which isn't that much to type and makes the code clear that there's a literal list happening there)? Versus the other ideas kicking around in the comments of ac.scm, as seen in the diff.
> a call to list, which isn't that much to type and makes the code clear that there's a literal list happening there
So far most macro-intensive lisp code isn't really clear until you know what the macro is doing, you could see (function arg1 arg2 arg3) inside an expression and you'd think it's a function call, but it could be passed to a macro and that macro would transform it into something else.
The advantage I'm hoping for is simplifying building lists (or trees) without resorting to macros.
Here's an explicit alist
((a b) (b c))
which otherwise would be a bit more cumbersome:
(list (list a b) (list b c))
And this is not the same thing as
'((a b) (b c))
tryarc:
arc> (= a "w1" b "w2" c "w3")
"w3"
arc> '((a b) (b c))
((a b) (b c))
arc> (list (list a b) (list b c))
(("w1" "w2") ("w2" "w3"))
I have to admit this is all somewhat theoretical at this point. For all I know, this pattern never occurs in lisp programs.
I have to admit this is all somewhat theoretical at this point. For all I know, this pattern never occurs in lisp programs.
Not enough that ambiguities wouldn't still need to be resolved with list anyway. Most of the time, you're not building up a literal tree of elements that you know will be atoms -- you're using variables. E.g.,
(def enq (obj q)
(atomic
(++ (q 2))
(if (no (car q))
(= (cadr q) (= (car q) (list obj))) ; call to list here
(= (cdr (cadr q)) (list obj) ; call to list here
(cadr q) (cdr (cadr q))))
(car q)))
You couldn't change (list obj) into just (obj), since (a) Arc doesn't like lexical bindings replacing macros, so (obj) would eval to an empty hash table; (b) even if that was fixed (it's easy to do, but vanilla Arc's still bugged), what if you're enqueuing a function, list, string, or hash table? (obj) would eval either to an error (not enough arguments) or would call your function, which is surely a bug. Thus, you need list.
(def pair (xs (o f list))
(if (no xs)
nil
(no (cdr xs))
(list (list (car xs))) ; calls to list here
(cons (f (car xs) (cadr xs))
(pair (cddr xs) f))))
could only be changed to
(def pair (xs (o f list))
(if (no xs)
nil
(no (cdr xs))
(list ((car xs))) ; since ((car xs)) would be a list
(cons (f (car xs) (cadr xs))
(pair (cddr xs) f))))
which isn't really clearer, and runs into the same problems if (car xs) happens to be a string, list, function, or hash table.
Even
(def split (seq pos)
(list (cut seq 0 pos) (cut seq pos))) ; call to list here
couldn't be changed, since seq should be a list or string.
See also the definitions in arc.arc of insert-sorted, reinsert-sorted, defsets of car/cdr/caar/cadr/cddr, setforms, a lot of macro expansions (like obj, though that's arguably replaceable under the proposed scheme), and commonest. That was my point about list making the presence of literal lists explicit.
Places where you could safely use this scheme aren't really big wins anyways. You get to change
(def queue () (list nil nil 0))
to
(def queue () (nil nil 0))
or
(let record (list (seconds) ip user)
in app.arc to
(let record ((seconds) ip user)
It's rare you'll have to type out a big enough tree literally (i.e., without variables that will cause the problems we've seen) to make it worthwhile, and it doesn't simplify much code that currently uses list anyway.
;(pmul-deg m) returns a function that multiplies polynomials
; and throws out all terms with degree > m
;xs is a list of polynomials
((pmul-deg 5) (car xs) (cadr xs))
I do not want this to be interpreted as an assoc-list.
if x doesn't evaluate to a function, hash table, macro, (or whatever else is allowed as a first element), then as a last resort, we interpret the expression as a plain list
In your example, the first expression evaluates to a function, so the normal rules would apply as usual.
I see. I'll mention first that I wouldn't find this feature useful myself, and would likely be irritated that certain things didn't turn out to be errors. However, here's something I see as a problem that you can probably appreciate:
(1 2 3). Arc evaluates this expression. The car is a number. Therefore, this is interpreted as the literal list (1 2 3).
((1 2 3) 1). By the above, the car of this expression evaluates to the list (1 2 3). This, applied to the argument 1, should give us the second element (the 1th element with zero-origin indexing) of the list (1 2 3), which is 2.
(((1 2 3) 1) 6). Following the above method of evaluation, the car of this expression evaluates to 2, so we get (2 6), which you say should evaluate to the literal list (2 6). This is, of course, quite different from the list (((1 2 3) 1) 6), which is probably what someone who writes literal lists according to your system would expect. I don't think it's possible for (((1 2 3) 1) 6) to be interpreted as a literal list without throwing the Arc "data structure in functional position is interpreted as a lookup" model out the window.
For that matter, I think would already be pretty weird that, given that xs is (1 2 3), (xs u) will be either an element of xs (if u happens to be a number) or a literal list (if u isn't a number).
So, either you have a "literal lists" rule that works for nesting lists most of the time--just not when one of the lists happens to be length 2 and the cadr is a number--or you have to give up the "xs is a list --> (xs n) is the nth element of xs" rule. Perhaps you could restrict it to constructing lists of constant depth; that would be a consistent, easily understood rule that wouldn't infringe on list lookups, although it still would make (xs n) be a drastically different type of object depending on what n was, and I still wouldn't like it or find it useful.
Pedagogical digression:
You say this about using quasiquote in `((,a ,b) (,c ,d)):
> Too cumbersome and somewhat confusing. Actually I think subconsciously I want to get rid of these symbols when ever possible.
Then I think you are ignorant. My intent is not to insult you; I intend this as a statement of fact, and as implied advice (that you should learn more). Look at what quasiquote allows you to do:
`((,a ,b) (,c ,d)) ;evaluate keys and values in assoc-list
`((,a b) (,c d)) ;evaluate keys, not values, in assoc-list
`((a ,b) (c ,d)) ;evaluate values, not keys, in assoc-list
`(,(a b) ,(c d)) ;construct list of two function calls
By putting in a quasiquote and adding or not adding commas in various positions, you can specify any arbitrary pattern of evaluation for the list ((a b) (c d)). And I assure you, all of these are useful at times; above, I have merely listed ones that are common enough patterns for them to have names; attempting to define the language so that the compiler will always find the correct pattern and you'll never need to use quasiquote is a bad idea. And don't even try writing more than the most basic macros without quasiquote--it's like working without rlwrap, except that can be somewhat remedied by editing a file and defining (l) to load that file.
(Again, I don't intend to insult or flame you. I do intend to flame this idea, because I think it's bad.)
Philosophical digression:
Note, by the way, that the "data structures in functional position are interpreted as lookups" rule is pretty justifiable from a Lisp point of view. You could implement data structures as functions:
(def my-cons (a b)
(fn (x)
(case x
car a
cdr b
(if (isa x 'int)
(if (is x 0)
a
(b (- x 1)))
(err "Can't do this.")))))
(def my-car (x)
x!car)
(def my-cdr (x)
x!cdr)
arc> (= x (my-cons 1 (my-cons 2 (my-cons 3 nil))))
#<procedure: my-cons>
arc> (x 0)
1
arc> (my-car x)
1
arc> (my-car (my-cdr x))
2
arc> (x 1)
2
arc> (x 2)
3
The only issue is printing. Here's an example implementation:
It isn't perfect, because that 'print function will apply any function to the symbol 'type, which may cause errors. You need some access to the implementation of primitive operators to do this right. But, of course, the language designer has that power, and could quite plausibly have implemented conses and tables as functions, and given 'pr what it needs. So, it makes sense from a very-basic-Lisp point of view that "(the-list-xs 2)" could be a function call that yields the second element of the-list-xs.
I'll add that numbers and atoms are... atomic. Pure and indivisible, the building blocks that you can make everything else in Lisp with. I'm fine with compound data structures being functions, because they can be implemented with functions as featureful as you want, but I think atoms should be simple, basic pieces.
I was going to say something almost just like this, so kudos. ^_^ However, I cut myself off 'cause I realized that in someone's mind, 6 could primarily be a function that constructs lists that begin with 6, and only incidentally has useful behavior with '+, '-, etc. :-p To be fair, that's pretty silly, and you have other points that are good regardless.
I just noticed none of your alist examples work with the atoms-imply-lists thing -- unless you ditch list-indexing, like (xs 0). That is, even if a, b, c, and d are all atoms,
((a b) (c d))
would not be an explicit alist, since
(a b) == (list a b)
and
(c d) == (list c d)
Thus,
((a b) (c d)) == ((list a b) (list c d))
which throws an error since (list c d) isn't a proper index (i.e., isn't a number).
Even if you could write alists that way, you'd be restricted to only those with atom cars. Personally, I can't think of the last time I needed a literal alist. If I wanted to write them that much, couldn't use quote, and couldn't bare to use list, I'd probably just do
If [] wasn't already used for lambdas, I could've suggested using it as a raw-list literal. [1 2 3] wouldn't be that bad.
I don't think odd parentheses like [...] are substantially more convenient than operator applications like (list ...). In fact, when editing in a bare-bones text editor, it's a slight pain to have to figure out whether )))]))]))) is the right combination of brackets. :-p
That doesn't mean it's a bad idea altogether. I think Clojure probably has the best practical use of brackets. It uses [] for literal lists just like what you're talking about, but it also generally uses [] brackets wherever there's no operator-and-body format that needs highlighting and indenting. They're used for argument lists, for instance. I haven't heard of someone setting up an editor to take advantage of that consistency, but I'd be surprised if that wasn't the reason for it. ^_^
(Which is reason against PLT's use of [], but doesn't affect arc's chosen use.)
Incidentally [] has one major advantage over (): it doesn't require pressing the shift key every single time. In my vim and emacs I've swapped the two sets of keys in lisp mode.
Which is reason against PLT's use of [], but doesn't affect arc's chosen use.
Hmm? I don't provide any reasons against Racket's claim that "Using square brackets in a few key places makes Racket code even more readable." In fact, I think it does aid a bit in readability, but it doesn't help when my goal is to correct sloppy brackets. XD
What I am saying is that Arc's [+ 1 _] syntax is about as convenient as (f- + 1 _) or (f-:+ 1 _). Arc also shares the ))]))) issue, a little. It would be more noticeable if more operators accepted functions as their last argument rather than their first argument.
Incidentally [] has one major advantage over (): it doesn't require pressing the shift key every single time. In my vim and emacs I've swapped the two sets of keys in lisp mode.
You mentioned this a while ago, so I've been using only [] in my languages-in-progress. ^_^ It also helps that I begrudge () and {} for looking too similar to each other. :-p The one thing I'm worried about is that ] and [ might be less distinguishable from each other than ) and ( are.
It would be more noticeable if more operators accepted functions as their last argument rather than their first argument.
Yeah, but they don't. Lisp idiom tends to be to put the values being operated upon last, and with good reason: you want to put last the arg most likely to be a temporary. Otherwise you risk separating function calls from their args. Compare:
Since there's this major structural constraint I think any dispatch in lisp should be on the type of the last arg. (http://arclanguage.org/item?id=12646)
Hmm, it would involve reimplementing eval inside arc. So far the arc compiler simply converts arc expressions to scheme expressions. You can't evaluate anything then.
Guess I should've mentioned this in my first post. People shouldn't be getting hung up on it. The diff was in this function:
; call a function or perform an array ref, hash ref, &c
; Non-fn constants in functional position are valuable real estate, so
; should figure out the best way to exploit it. What could (1 foo) or
; ('a foo) mean? Maybe it should mean currying.
; For now the way to make the default val of a hash table be other than
; nil is to supply the val when doing the lookup. Later may also let
; defaults be supplied as an arg to table. To implement this, need: an
; eq table within scheme mapping tables to defaults, and to adapt the
; code in arc.arc that reads and writes tables to read and write their
; default vals with them. To make compatible with existing written tables,
; just use an atom or 3-elt list to keep the default.
(define (ar-apply fn args)
(cond ((procedure? fn)
(apply fn args))
((pair? fn)
(list-ref fn (car args)))
((string? fn)
(string-ref fn (car args)))
((hash-table? fn)
(ar-nill (hash-table-get fn
(car args)
(if (pair? (cdr args)) (cadr args) #f))))
; experiment: means e.g. [1] is a constant fn
; ((or (number? fn) (symbol? fn)) fn)
; another possibility: constant in functional pos means it gets
; passed to the first arg, i.e. ('kids item) means (item 'kids).
- (#t (err "Function call on inappropriate object" fn args))))
+ (#t (ac-niltree (apply list fn (ar-nil-terminate args))))))
It works the same as any other list/table/string referencing in Arc. Things that look like function calls are compiled to (ar-apply f args), generally speaking (see ac-call), so this logic happens at runtime. Thus,
arc> (let f [+ _ 1] (f 5)) ; evals as fn call
6
arc> (let xs '(a b c) (xs 0)) ; evals as cons ref
a
arc> (let xs "abc" (xs 0)) ; evals as string ref
#\a
arc> (let h (obj a 1 b 2) (h 'a)) ; evals as table ref
1
In standard Arc:
arc> (let x 'atom (x 5)) ; defaults to #t clause
Error: "Function call on inappropriate object atom (5)"
With the patch:
arc> (let x 'atom (x 5)) ; defaults to #t clause
(atom 5)
