were to evaluate to a list instead of evaluating to a function call?
That is, have it evaluate exactly like
(list 1 2 3 4)
And I mean if the first element is an atom, not a reference to an atom.
But I even think generally falling back to lists if the first element can't be coerced to fn might not be a bad idea at all.
Already we don't always know if (a b) is a function call, a macro, hash-table access, or what have you. Would it hurt if (a b) could also turn out to just be (list a b) if 'a' wasn't a function?
The best part about arc is that it is so easily hacked. If you have what you think is a cool idea, why don't you try it and see? Show us the code and resulting use cases. If you aren't sure how, try a bit and then ask for help. We try to be pretty friendly around here if possible.
After all, the arc forum is really a community of language hackers. What better way to start than by making your own modifications?
That being said, I'm not sure whether to like this or not. The analysis required to determine which case to coerce to is getting rather complicated. I like code simplifications, but saving a single character (namely, an apostrophe) is a rather small difference vs the possible risk of making the code more confusing. However, if you show me... ;)
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)
In Anarki, you can try out something similar really quickly.
(defcall int self-and-args
copy.self-and-args) ; The 'copy may be unnecessary....
This should cause (1 2 3) to evaluate to a list. You can do this for types other than 'int as desired.
I actually think your idea conflicts at a design level with 'defcall. With 'defcall, there's no real guarantee that custom types will use any given default behavior, so you can only rely on the default for built-in types, and at that point you might as well just 'defcall them all one by one rather than having a default.
How do you mean? Under certain implementations of defcall, you might be able to get away with (= call*!int idfn), but Anarki's current implementation is a shortcut for this kind of code instead:
(defcoerce fn int (self)
(fn args
(apply list self args))) ; might be able to use 'cons here...
My confusion about 'copy and 'cons is founded on this part of arc.arc:
; Can return to this def once Rtm gets ac to make all rest args
; nil-terminated lists.
; (def list args args)
(def copylist (xs)
(if (no xs)
nil
(cons (car xs) (copylist (cdr xs)))))
(def list args (copylist args))
I don't hold onto argument lists very often, but when I do, I occasionally wonder whether I should be copying them first. I think this is the first time I've actually let that concern change my code, though. What do you think?
In (fn args ...), args will be a MzScheme list terminated by Mzscheme's '() instead of Arc's nil. It's usually hard to tell the difference, since the Arc runtime treats '() like nil when it can. There are a few odd corner cases where you'll notice it, for example if you use args as a key in a table, it will be a different key value than if you construct the same list using list.
Ah, right. Part of me's trying to think of a way to use an extensible 'iso (like akkartik's or mine) so it could be used as a table key comparator, but without the burden of maintaining a corresponding extensible hash function. (That is, the hash function would be automatic somehow.) How feasible do you think that would be? Maybe we should have the extensible hash function, but have convenience macros that extend both functions at once?
My main motivation is to remove all traces of the non-extensible Racket 'equal?.
You tell me equality is extensible, and now I know that, and I go look at that page and scan it from top to bottom. I do the usual things I do to read stuff online, and I've been pretty successful with my reading, my reading comprehension scores were excellent in standardized tests, I have a phd that was about nothing if not reading opaque publications, and now I'm faced with this page and I still have no idea how to tell that equality is extensible, or how to go about extending it. If you hadn't told me I'd look at that page about booleans and have no reason to expect it to bear the slightest relationship to equality for complex user-defined data structures[1]. Search for 'extensible'. Nope. Oh, 'inspectable structures.' What the sam hill are those? It has to do with prop:equal+hash, which doesn't even look like a single token to my eyes. Is it a function? How do I use it? All this goes through my mind in a flash, and all I feel is stupid.
I keep waiting for the racket reference to gradually become clear, but it's been a year now of poring over it and I don't think it'll ever happen. It's a blind spot, platform nine and three quarters, just around the corner but at ninety degrees from all three dimensions that I can see. I would never ever have noticed that equality is extensible until you told me that was so.
[1] I scan back up and it's right there in the title: "Booleans and equality." See what I mean about feeling stupid? Why should booleans and equality be grouped together? Why should equality be in the section on datatypes and not say structures?
0. Note that the actual link is broken -- it's missing a ")" in the end
(it's there, but it wasn't included in the url for some reason (I
don't know about the local markdown language...))
1. Yes, some of these issues are known, and we're in a constant race
with improving the documentation in various ways. As always, emails
to the mailing list or bug reports -- or better: suggestions and
possibly patches -- all of these are always welcome.
2. In this particular case, I didn't need to guess -- I knew that it was
added, so I just needed to find that reference.
3. But if I were trying to find it, the first place I'd look would be
the documentation for `equal?' -- and it is indeed there, at the end
of the second paragraph.
4. As for how you use this property, the text that I referred to has a
link to "Structure Type Properties", which describes all of that.
5. Re the organization -- booleans and equality are grouped because
they're related... It also appears as the first subsection in the
datatypes chapter, which makes sense there. If you have an idea how
to organize it better, then see #1.
6. Yes, it would be nice to have some section that lists all of the
properties that could be used for structs. The main problem with
doing this is that it's an open system, so anyone can add more
properties, but it won't make sense for the core to list properties
from modules outside of it. This was discussed recently, and I don't
think that anyone had an idea what to do about it.
"if I were trying to find it, the first place I'd look would be the documentation for `equal?' -- and it is indeed there, at the end of the second paragraph."
Part of the problem is that I never tried finding it, because it didn't occur to me that racket would have extensible equal?
A few months ago I was flattened - absolutely flattened - to find out that PLT has optional args and keyword args. (http://arclanguage.org/item?id=12591)
I have no idea why this is. Perhaps the problem is that people expect scheme to be a small language.
Well, the optionals and keyword arguments have been in for a long time now... In fact, the current thing is a second iteration after a first facility that was more CL-like...
In any case, Racket is certainly not a small language...
Yes, as I was ranting I was feeling bad for not having contributed to improve things. I wasn't being rhetorical about feeling stupid and guilty. Lack of understanding is a barrier but no excuse. For me to say "I have a phd, but this I can't read" is akin to saying "I've learned spanish, but chinese is hard." Well, d'uh. Deal.
Perhaps PLT needs a user guide in addition to a reference, a level of redundancy with a kinda orthogonal organization (focusing on complex tasks involving multiple advanced concepts) that'll help people triangulate on understanding, or just use what works for them.
I'm going to withdraw my rant. It's something specific about my stupidity that's causing me these problems. Still investigating.
Ah, I think I see what's been happening. Since I started out with arc I've restricted myself to the mzscheme 'ghetto' and not paid as much attention to the racket language itself. My attitude was "who knows what works in mzscheme and what doesn't." This has been the root cause of my troubles, I think.
Thanks for the link to Guide: Racket. I've also had trouble getting into Racket's documentation, but this looks like a much more accessible starting point than Reference: Racket.
Given that prop:equal+hash exists, are there any commonly used convenience macros for implementing it for a structure? It's niftiest if they support cyclic structures too, since Racket's equality API makes that possible, but I'm not picky. ^_^ I'll probably just write something myself either way, but I'm on the lookout for inspiration.
Oh, I didn't think that much about it. I just tried this in anarki:
(defcall int self-and-args
idfn.self-and-args)
and it seems to work ^_^. I can't come up with a counterexample that requires copying. Can you? Otherwise let's just not copy until something breaks. Then we'll learn something.
You know I think I totally misunderstood your original code comment. When I read it now my response to use idfn seems kinda facetious (I was seriously suggesting it, don't know what I was thinking.)
Well, I don't hold it against you. :-p It gave me an excuse to elaborate about my confusion too. >.>
I think I agree with you that we shouldn't worry about holding onto the argument list as long as it isn't a tangible problem. I'm interested to hear if someone knows of a problem though. ^_^ (Edit: Oh, aw posted an example.)
