hello rohan,
Post by r***@public.gmane.orgPost by Julian RohrhuberI think it isn't just a notational convenience, at least on the level of
a running program.
on the specific question of "variable arity", i still don't really
f = {arg ...l; l.size + 1};
g = {arg l; l.size + 1};
f.value(1,2,3) == 4
g.value([1,2,3]) == 4
it seems to me that f & g are both functions over lists (and in this
case total functions) and you just write the list differently.
I'm not sure I understand, but I try to remember what I meant.
So the idea of variable arity in the call (not in the definition) occurred where you have different, explicitly named arguments. You can bind values to these arguments by passing an array to valueArray (abbreviated by *), which may have fewer values (no problem), but also more.
The example would be:
x = [440,0,0.1,0,'too','many','arguments'];
SinOsc.ar(*x);
If the argument definitions are generic enough, this may make sense. In the above case, there may be reasons to be unhappy about this way of putting it (different *ar methods have different semantics).
Post by r***@public.gmane.orgPost by Julian RohrhuberAlso, some functions that pass both selector and argument don't know
about the arity of the selected method, so they need to use
valueArray.
yes. but you can write the "list apply" function without variadic
functions, it's a long function to write because you need to enumerate
all of the cases you're interested in, but you can do it, ie.
[] -> f.value()
[p] -> f.value(p)
[p,q] -> f.value(p,q)
[p,q,r] -> f.value(p,q,r)
...
i mean, this will cover the case of wanting to apply "plus" or
"sum-of-squares" to a list, etc. and it's enough to write an
arity-generic map (collect) etc. you don't need variadic functions
for this?
Well, I still sense that arity and type are somewhat related, and may be even treated on the same level - your example seems to support this: it looks just like pattern matching on type.
Post by r***@public.gmane.orgPost by Julian RohrhuberHere is what Alan Kay wrote and still puzzles me (I'd love to
understand things better from the side of development of
Lisps/Schemes).
i think that aligns with the felleisen comment? the
post-smalltalk/actors lisps (ie. scheme) are not the same as the
pre-smalltalk lisps. it's in the nature of scheme that you have to
write the "smalltalk" rules as a library...
of course felleisen doesn't say if actors is a good model of
smalltalk, or how well sussman & steele understood actors...
Ah yes, I see. So far I had assumed that Scheme was mainly a reduction of Lisp (http://c2.com/cgi/wiki?LispSchemeDifferences), but this seems not to be the core of it (http://en.wikipedia.org/wiki/History_of_the_Scheme_programming_language). Apparently it is the possibility of writing in continuation passing style that is the main addition?
Post by r***@public.gmane.organother nice 'history' of that period is olin shivers & jonathan rees
on T, ie: http://mumble.net/~jar/tproject/
it's neccesarily a narrow view, and knows it, ie. "The Europeans
working on early systems like ML in Edinburgh probably find all this
American early-80's thrashing & confusion over scoping discipline and
implementation strategy incredibly clueless. Sorry 'bout that."
A very interesting source, thank you!
Post by r***@public.gmane.orgPost by Julian RohrhuberUnfortunately, I implemented reduce only as a method for binary
functions or operators.
i'm not sure this is unfortunate! i think it's the nature of folds?
Well, for a moment I thought one could make the arity of fold depend on the selector you pass:
[1, 2, 3, 4, 5].reduce { |a, b, c| a * b - c };
1 * 2 - 3 => -1
-1 * 4 - 5 => -9
But, if you pass a selector instead of a function, the method's arity depends on the object it calls. Still, possible, but possibly confusing.
Post by r***@public.gmane.orgi'm afraid i still may not have been very clear.
there are functions that are properly list functions, such as size
(length) and collect (map) and reverse and reduce (foldl0) and reject
(filter) and sum etc. etc. (where a list is a variable length
sequence)
and then there are functions that are properly 'tuple' functions,
ie. +, round, absdif, etc. etc. (where a tuple is a fixed length
sequence).
variadic functions and "list apply" interchange the notations, but the
functions are still of one sort or the other.
"list apply" gives you generic map, but the reverse seems an odd thing
to do?
i figure there has to be some reason for all of this, but i don't
think i know what it is. (except, as mentioned before, that in lisp
the notational reasons in some few cases are compelling).
of course in ml etc. you can't write either of these.
the obvious "notational" cost is that you have, for instance, to write
out the map/zipWith family etc. or use an "Applicative" type infix
notation.
actually it's possible to avoid having to write out the family of
functions, but as far as i know you still need to write the arity into
the expression, ie. there is still a notational 'excess', see
http://www.seas.upenn.edu/~sweirich/papers/aritygen.pdf
Exactly, the abstract of the article is also a good way of putting it. As you know, in dynamically typed OOP, you avoid it by, well, by not having types in the signatures of the methods. Maybe AbstractFunction is a good place:
composeNAryOp { arg aSelector, anArgList;
^NAryOpFunction.new(aSelector, this, anArgList)
}
Post by r***@public.gmane.orgPost by Julian RohrhuberYes, so that was what I meant: there are two types of fundamental
entities here, functions and values.
i wrote poorly there, of course functions are values, and integers are
values, but integers are not functions...
Hm, I had suspected that integers are a function that return themselves or something like that. But that was thinking it too much from a mathematical angle I suppose.
Post by r***@public.gmane.orgPost by Julian RohrhuberThis is a distinction that (at least in principle) disappears with
object orientation, because everything is of one elementary typeless
"type".
actually, i recall rees also asked interesting questions about oo, and
http://www.eros-os.org/pipermail/e-lang/2001-October/005852.html
His points of critique of OOP are interesting and worth repeating here:
- It accounts poorly for symmetric interaction, such as chemical
reactions and gravity.
- It deals poorly with information-oriented phenomena such as
mathematical objects, copying, broadcast, encryption, caching, and
signing. E takes a step in the right direction by introducing the
"selfless" notion, but this isn't enough.
- It usually has a very imperative, operational flavor to it.
It begs you to write a recipe, not to describe the result that you
want as functional languages do. This isn't really inherent, and E
is much better on this count than C++/Java.
- It forces you to always decide who's on top in any interaction,
i.e. which object should define the method, a decision that's not
always easy and one that you often want to change.
- It's a poor match both syntactically and semantically with
natural language, making it awkward for expressing things that are
in people's minds.
Would make an interesting discussion!
Post by r***@public.gmane.orgi never really knew what to make of any of this, and retreated into
pure term rewriting, which i can follow well enough.
the typeless type is a mystery to me. it still seems to go wrong in
all the same ways as the typeful type.
3.reverse
"x".negate
oh yes, indeed, and the possibility of going wrong may be simply a consequence of logical incompleteness.
Practically, I often wonder if there is could be a way to improve the situation about polymorphic misunderstanding (or separate between the good and the bad cases).
Post by r***@public.gmane.orgPost by Julian RohrhuberThere are indeed advantages of reverse Polish notation, even if it
really looks strange.
i've often wondered about this. i'm not super averse to lisp
notation, and forth hardly seems worse. as a gift, and to
procrastinate, and to find out, i wrote a very simple forth
interpreter that only knows about supercollider unit generators and
translated various sc2 examples. i think, as a notation, it's not too
awful.
http://rd.slavepianos.org/?t=hsc3-forth
quite beautiful! A proper knitting-machine for signal-knots...
I still try to understand what it actually does :)
Post by r***@public.gmane.orgthere's a lisp in the same vein, hence the fahey "american primitive"
references. in relation to this thread, the lisp has strictly
unary/monadic lambda, & runs the exact same graph codes as the actual
scheme supercollider bindings, which is perhaps sort of interesting.
http://rd.slavepianos.org/?t=hsc3-lisp
Post by Julian RohrhuberIt is a bit like cooking, the eating is always at the end.
it also reminds of mark twain, "Whenever the literary German dives
into a sentence, that is the last you are going to see of him till he
emerges on the other side of his Atlantic with his verb in his mouth."
There are people here who can keep audiences busy exactly in this way, enjoyable and distressing at the same time!
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/