Lambda the Ultimate

inactiveTopic Invocations as objects
started 7/15/2003; 10:50:26 AM - last post 10/16/2003; 5:32:54 PM
Andris Birkmanis - Invocations as objects  blueArrow
7/15/2003; 10:50:26 AM (reads: 532, responses: 10)
Disclaimer: My knowledge of programming languages is somewhat narrow, Java being my primary. Also, I believe this topic is not language specific.

It just occurred to me that an invocation (say, of a method in Java) is in fact an instance of a special, eh, type.

More precisely, each invocation creates a frame on a JVM stack, which contains all the data necessary for execution of the call. It just happens that the only references to these frames are located on the JVM stack. This fact allows simplifying garbage collection of the frames, namely they are discarded immediately after return from the call.

I tried to imagine what kind of a language (or VM) would result if there were no JVM stack, or rather if it were explicitly in the control of an application developer and/or compiler.

The first thing to come to mind are tail-call optimizations. Well, not optimizations at compile-time, but run-time possibility to garbage collect frames to which no-one will return.

The second: as thread-specific storage is deprived of the stack, it basically is left with pc (program counter?). Could it enable cheaper multi-threading?

The third: coroutines? If application can explicitly handle frames... Well, I cannot stop my fantazy :)

Could the honorable audience give me some pointers to close ideas in existing/hypothetical languages/run-times/formalisms? Am I just obsessed by some well-known and trivial notion? Words like 'closure' are buzzing in my mind, but I cannot grasp them.

Major thanks! :)

Matt Hellige - Re: Invocations as objects  blueArrow
7/15/2003; 11:28:52 AM (reads: 541, responses: 0)
Could the honorable audience give me some pointers to close ideas in existing/hypothetical languages/run-times/formalisms? Am I just obsessed by some well-known and trivial notion? Words like 'closure' are buzzing in my mind, but I cannot grasp them.

If I understand what you're suggesting (and I'm not sure I do), I think "first-class continuations" might be the magic phrase you're looking for. Even if that's not quite what you have in mind, reading some of the copious literature on the subject might help clarify your own idea...

I don't know of a good intro to continuations, but I imagine someone else here could provide a link. Scheme is maybe the most prominent language that features first-class continuations, and you could almost certainly find more info either at the readscheme.org continuations page (but note that "continuation-passing style" or CPS is a related but somewhat different topic) or in the docs for any of the big Scheme implementations (maybe look for call/cc or call-with-current-continuation).

Have fun!

Michael Vanier - Re: Invocations as objects  blueArrow
7/15/2003; 2:30:02 PM (reads: 533, responses: 0)
If you can find it, Scheme and the Art of Programming by Springer and Friedman has a very nice, gentle introduction to continuations. It's one of the trickiest programming concepts I've ever seen, so don't be dismayed if it takes some time to get used to. But Matt is right, first-class continuations are *definitely* the topic you want to learn about.

Darius Bacon - Re: Invocations as objects  blueArrow
7/16/2003; 12:34:32 AM (reads: 505, responses: 0)
See Carl Hewitt's paper "Control structures as patterns of passing messages", and Raph Levien's Io language designed around continuations.

Historically, objects were invented in Simula as a generalization of the activation records of BEGIN...END blocks.

sean - Re: Invocations as objects  blueArrow
7/16/2003; 5:53:06 AM (reads: 495, responses: 0)
Also see Dan Sugalski's "What the heck is" on continuations. As an implementation-centric (as opposed to theory-centric) description, it provides a perspective you don't get in most textbooks.

/s

Dan - Re: Invocations as objects  blueArrow
7/16/2003; 6:10:20 AM (reads: 479, responses: 0)
Yep, sounds like continuations are what you're working towards. They aren't, despite what other folks will tell you, that big a deal.

It may help if you draw pictures for yourself, since not everyone thinks in Scheme. ;)

Frank Atanassow - Re: Invocations as objects  blueArrow
7/16/2003; 9:17:20 AM (reads: 475, responses: 0)
Where activation frames are allocated is an implementation matter, not a property of the language. Nevertheless, allocating them on the heap is a common implementation technique for languages with first-class continuations, as Matt noted.

SML/NJ's implementation puts all its frames on the heap.

Andris Birkmanis - Re: Invocations as objects  blueArrow
7/17/2003; 3:48:04 AM (reads: 453, responses: 0)
Thank you all for such a benevolent attitude!

I happenned to find most of the papers mentioned even before I saw the posts - just directing me to Scheme was very productive :) Google is great, SiteSeer coming next to it (him? :))...

The only thing I could not find was "Viewing control structures as patterns of passing messages". And I really miss it after reading its abstract :( Darius, are you aware of its online version?

Ah, I also had a real fun reading Stackless Python mailing list archives - all the polytical/ideological/psychological intricacies being not less amusing than technological discussions. Looks like SLP 1.0 is (was) very close to what I had in mind several days ago... Could not find any SLP 3.0 papers - are these mystical tasklets somehow related to pi calculus family? Any experts?

Unfortunately, now I believe none of the magic I imagined can be effectively done on top of a standard JVM... That really precluding me from continuing this way full-time :( Business world is harsh...

But thank you all, it was real fun, keeping me long hours after midnight :)

Darius Bacon - Re: Invocations as objects  blueArrow
7/17/2003; 11:47:19 PM (reads: 433, responses: 0)
Sorry, I read the Hewitt paper in a book.

nish - Re: Invocations as objects  blueArrow
10/16/2003; 5:32:54 PM (reads: 213, responses: 0)
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-410.pdf

Hewitt paper.