(def $ (x . lists)
(if lists
(apply map x lists)
(fn (lists) (apply map x lists))))
More or less does what you want, without special syntax.
($$car... would have to be written ($($ car)... though.
To me this looks like a specific case of wanting currying/partial application built in for functions of semi-fixed arity, rather than a need for new syntax.
You can even be cleaner: $car is $.car (though this doesn't work for $.$.car). But I don't think this is really a specific case of partial application (though I see where you're coming from). While partial application would be ((map car) '((1 2) (3 4) (5 6))) and this would be ($car '((1 2) (3 4) (5 6))), the biggest win (for me) is not the partial application aspect, but the conciseness of having just one character, as opposed to (currently) ([map car _] '((1 2) (3 4) (5 6))) or ([apply map car __] '((1 2) (3 4) (5 6))), or even the partial application version. And even so, this strikes me as more similar to a request for explicit partial application, which is already implementable, than implicit partial application.
Yes, it was the conciseness I was after. The syntax was inspired by K, where you can do this by putting a ' before a function name.
Of course, K often looks like line noise, but then K takes this technique to its logical conclusion and uses special syntax for everything. There's no need to go that far.
Leaving aside the issues of detecting a query, I think it's a really bad idea to have the compiler force (badly guessed) semantic knowledge on me.
It's my code, I wrote it, and I don't want any compiler telling me that a query that caches previous results must be imperative! and not end in a ? .
I also thing needlessly polluting a namespace with addition symbols is a bad idea. You only get one namespace in arc, try to preserve it for the future.
i have to most respectfully disagree friend. so far i like most everything i see in arc, but this ssyntax business does not resonate well with me. i thought it was only me (i'm getting old and all) but now i see some other people that are bothered by it so i feel i should say something. i think there is something to this.
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.
Pattern matching is completely orthogonal to hygiene.
You could add in another operator, %, that performs exactly the same as ` but hygienically.
Personally I'd settle for just being able embed procedures in code trees like you can in common lisp. Being able to write.
I'll add one more thing: static binding. It's the only functional language/LISP dialect I've ever seen developed after the 1970's (besides Emacs Lisp) that still does dynamic binding. I decided that this would be lots of trouble for programming in the large, which is why I never decided to pursue it.
This NewLisp fragment (which is also valid Scheme) illustrates this:
This form evaluates to 5 in NewLisp but 3 in Scheme. The equivalent in Arc:
(let x 1
(let f (fn (y) (+ x y))
(let g (fn (f y) (let x 3 (f y)))
(g f 2))))
as expected evaluates to 3, so Arc also does static binding. Dynamic binding makes safe use of free variables in different contexts that much harder, and essentially makes referential transparency all but impossible. I cannot for the life of me, especially after reading Steele and Sussman's "The Art of The Interpreter", imagine why the designers of NewLISP thought it would be a good idea to use dynamic binding in their language. Static binding had a reputation in the past as carrying with it a performance hit, which is why RMS didn't use it for Emacs Lisp, but research done afterwards has shown that there are ways of doing it properly that don't sacrifice performance.
Unless I'm not understanding something, and am not quite grokking this whole list/functional language thing (entirely possible I'm still learning).
newLisp appears to have the following from this list (by way of a quick look at the documentation on the site):
macros via define-macro and lamda-macro (and not autmatically hygenic ones...)
pass by reference.
And closures via let and lambda forms.
garbage collection
hash tables
Im really not for or against newLisp. It seems that since you last looked some of the stuff got implemented. The thing Im really not sure of is macros. It seems to me that the newLisp maros are very much the same as arc macros. If this is wrong, can someone please help me grok it?
One of the things I don't like about newlisp is that from their site, they appear intentionally misleading about what they can and can't do.
They don't have hash tables, this they openly admit and they make do with self balancing trees.
They don't have macros, they have f-expressions. F-exprs are strictly more powerful, but execute at run time not at definition time. This means every abstraction you use incurs a penalty fee each time it is executed, rather than just once when it is compiled. They call what them macros anyway.
They don't have garbage collection at all. The whole language is basically allocated on the stack, and objects are deleted or copied and returned when a function ends. This means they can't have true closures, or pass by reference with indefinite extent for the objects.
As far as I can tell, the hacks they suggest to get round the lack of closures won't work if you want to create and destroy many anonymous fns. bound to data with indefinite extent.
They still refer to these hacks as `closures'.
Their pass by reference work around, amounts to passing symbol names from different contexts and can't do the right thing when you(for example) want to merge existing lists and then rebind one the original symbols.
Having said all that, if one of the newLisp guys wants to prove me wrong, and show something like partial application code to demonstrate that it really does have true closures, it'd be great to see, and I'd probably go back to the language and have another go with it.
Qi is completely type inferring, so it proves the type correctness of the code at compile time from a minimum number of declarations, like the ML family of languages.
However, as this is optional, it can also be switched off in places to handle code that the type system can not prove correct.
To make a similar system work, you'd have to label the inputs and return type of each function, and enforce the consistency of this, all at compile time. There is a complete prolog system buried in QI allowing the types to self reference and be turing complete in terms of complexity.
Having said that, the whole of QI is only meant to be 4k lines of common lisp and under an MIT license, so it'd be quite easy to port the interesting bits of it once the core of arc has stabilised.
pg, I was referring to Jekyll's explanation of optional typing. The 'maybe' means that I don't know the value in it, I've just heard that some people like it.
Typically, people optimise for speed and not terseness in the shootout. If you look at how the languages perform in terms of terseness you find:
Dynamic languages with no possibility of optimal type declarations come first, followed by statically typed type inferring languages, then a ragbag of stuff including dynamic languages with optional type declarations like SBCL.
Then Java and Ada at the back.
You want the lisp to be shorter? Try taking out the type declarations. They're optional.
I'm new to lisp/scheme/arc so this may not be an issue in practice, but what if you want to add a new pair to the beginning of the list?
The only way to do this would be to insert a new pair after the first, then copy the car from the first to the second, then set the first car as desired.
Unfortunately this does not work if you have references to this first pair in particular, because of its car, rather than because it is the beginning of the list;
Now that I think of it, passing parameters by reference would not be useful in this case.
Passing lists (pairs) by reference simply means creating a level of indirection to where the address of the first pair is stored. However, in a running program, there can be an arbitrary number of such locations.
I think that the problem of lists, of which the sort order is significant and which may be modified in arbitrary ways, can only be solved by,
a) having a global binding, that is, a global level of indirection that everyone uses, or
b) using a pair, of which the cdr remains unused, or some other reference-object as a level of indirection.
My example wasn't exactly orthodox lisp style.
Normally, you should explicitly set any variables you are manipulating, so you'd be writing: (= a (f a)) rather than relying side effects to set it for you (This is especially important when calling functions like sort).
It's such a common idiom that in common lisp I have a ! macro to turn (! f a . b) into (setf a (f a . b)).
