Re: [fonc] Fonc on Mac Snow Leopard?
Personally I was very excited about the Carl Hewitt's work on ActorScript [1] lately. IMHO something like Lively Kernel could provide the client infrastructure for this Client Cloud computing. What is your opinion on his work? I also liked the notation he uses in the paper. What I do not like about JS is its imperative verboseness. I also have mixed feelings about JSON. I like the idea of beeing able to express something more denotational, e.g. in ways that keeps focussing on the simplest solution, and then use something like equational reasoning to derive at more performant and complex systems. In the end syntax matters and maybe there is no syntax that works for every solution. So I see a high value in building Syntax understanding into libraries (This kind of homoiconicity is what I like from LISP-like langauges). Also Gilad Bracha did some work on parser combinators using a Self like language called Newspeak [2]. I found the IDE (I think it was called Hopscotch) very interesting in that it mirros the browser. Indeed the current version is running on top of Squeak. Maybe Lively and Newspeak could join forces? Taking the Idea of Hopscotch beyond a single language would be great. Mozilla Lab's Bespin Project focuses on a kind of Emacs for the Web. What I would really like to see is some kind of Worldwide live development environment where projects are really living things and people can take different views on them. With real semantic mappings between individual notations and syntax. -- Jakob [1] - http://arxiv.org/abs/0907.3330 [2] - http://newspeaklanguage.org/ Am 09.05.10 01:06, schrieb Alan Kay: By the way, people on this list should look at Dan Ingalls' Lively Kernel. (http://www.lively-kernel.org/) Dan is also one of original authors of the NSF proposal for STEPS and we claim successes in the Lively Kernel as STEPS successes as well. That said, LK is much more like the bootstrapping of Squeak was, in that a known architecture was adapted to the purpose of using JS as the machine code for a new operating system and live environment. Again, there was the small dedicated team at Sun under the direction of the master designer/builder (Dan). And once they got a few versions bootstrapped they opened it up to interested open sourcers, and there is a lively mailing list for Lively. We like Lively and pay a lot of attention to it because it covers some of the functional ground that needs to be covered for a complete system. The main difference is that they are not trying for really small really relational models. However, the adaptation of the Smalltalk architecture here is very efficient for building things (as it was almost 40 years ago). So this is worth looking at. And we could imagine this as what STEPS might be like to a community, except that we are trying to invent new more compact more powerful ways to express programmatic ideas. At best, something like this is several years in STEPS' future. Cheers, Alan *From:* Jakob Praher j...@hapra.at *To:* fonc@vpri.org *Sent:* Sat, May 8, 2010 12:25:12 PM *Subject:* Re: [fonc] Fonc on Mac Snow Leopard? Hi Alan, just out of curiosity: I am wondering why VPRI is not aiming at a more community oriented style of innovation. Do you think the communcation effort is not worth the cost since you do not gain enough or even loose some freedom and / or speed by discussing archictural concepts more publicly? Does this imply that in your opinion open (source) projects only work (good) if there is something to be build incrementally (like a bazaar). I am also asking since I am interested in innovation through open communities. I am wondering why there is not more discussions (which I am sure you have internally at the VPRI) brought onto lists. Maybe one could discuss not only the implementation but also concepts behind the design? Having a daytime job I know that sometimes catching up with a lively community is a challenge, on the other hand seeing where things are going and maybe also join forces in early stages might be interesting, no? For instance there could be other people doing PoC work. Thanks, Jakob Am 08.05.10 18:03, schrieb Alan Kay: Glad you are interested, but don't hold your breath. We've got quite a bit more to do this year. It's not an incremental project like many open source people are used to. We actually throw away much of our code and rewrite with new designs pretty often. Cheers, Alan *From:* DeNigris Sean s...@clipperadams.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Sat, May 8, 2010 8:55:29 AM *Subject:* Re: [fonc] Fonc on Mac Snow Leopard? We don't plan to wind up using any one else's GC so I wouldn't worry. Not worried - just excited to play with this stuff! Sean
Re: [fonc] Fonc on Mac Snow Leopard?
Regarding syntax understanding: Yes I am aware of OMeta as well as the original work on PEGs. (And also of PEG/LEG work by Ian). I see is that OMeta is used in the Lively Kernel also to understand Smalltalk Syntax. Is this just proof of concept or is there some attempt to be able to run Squeak programs on the browser through lively? Am 09.05.10 23:41, schrieb Jakob Praher: Personally I was very excited about the Carl Hewitt's work on ActorScript [1] lately. IMHO something like Lively Kernel could provide the client infrastructure for this Client Cloud computing. What is your opinion on his work? I also liked the notation he uses in the paper. What I do not like about JS is its imperative verboseness. I also have mixed feelings about JSON. I like the idea of beeing able to express something more denotational, e.g. in ways that keeps focussing on the simplest solution, and then use something like equational reasoning to derive at more performant and complex systems. In the end syntax matters and maybe there is no syntax that works for every solution. So I see a high value in building Syntax understanding into libraries (This kind of homoiconicity is what I like from LISP-like langauges). Also Gilad Bracha did some work on parser combinators using a Self like language called Newspeak [2]. I found the IDE (I think it was called Hopscotch) very interesting in that it mirros the browser. Indeed the current version is running on top of Squeak. Maybe Lively and Newspeak could join forces? Taking the Idea of Hopscotch beyond a single language would be great. Mozilla Lab's Bespin Project focuses on a kind of Emacs for the Web. What I would really like to see is some kind of Worldwide live development environment where projects are really living things and people can take different views on them. With real semantic mappings between individual notations and syntax. -- Jakob [1] - http://arxiv.org/abs/0907.3330 [2] - http://newspeaklanguage.org/ Am 09.05.10 01:06, schrieb Alan Kay: By the way, people on this list should look at Dan Ingalls' Lively Kernel. (http://www.lively-kernel.org/) Dan is also one of original authors of the NSF proposal for STEPS and we claim successes in the Lively Kernel as STEPS successes as well. That said, LK is much more like the bootstrapping of Squeak was, in that a known architecture was adapted to the purpose of using JS as the machine code for a new operating system and live environment. Again, there was the small dedicated team at Sun under the direction of the master designer/builder (Dan). And once they got a few versions bootstrapped they opened it up to interested open sourcers, and there is a lively mailing list for Lively. We like Lively and pay a lot of attention to it because it covers some of the functional ground that needs to be covered for a complete system. The main difference is that they are not trying for really small really relational models. However, the adaptation of the Smalltalk architecture here is very efficient for building things (as it was almost 40 years ago). So this is worth looking at. And we could imagine this as what STEPS might be like to a community, except that we are trying to invent new more compact more powerful ways to express programmatic ideas. At best, something like this is several years in STEPS' future. Cheers, Alan *From:* Jakob Praher j...@hapra.at *To:* fonc@vpri.org *Sent:* Sat, May 8, 2010 12:25:12 PM *Subject:* Re: [fonc] Fonc on Mac Snow Leopard? Hi Alan, just out of curiosity: I am wondering why VPRI is not aiming at a more community oriented style of innovation. Do you think the communcation effort is not worth the cost since you do not gain enough or even loose some freedom and / or speed by discussing archictural concepts more publicly? Does this imply that in your opinion open (source) projects only work (good) if there is something to be build incrementally (like a bazaar). I am also asking since I am interested in innovation through open communities. I am wondering why there is not more discussions (which I am sure you have internally at the VPRI) brought onto lists. Maybe one could discuss not only the implementation but also concepts behind the design? Having a daytime job I know that sometimes catching up with a lively community is a challenge, on the other hand seeing where things are going and maybe also join forces in early stages might be interesting, no? For instance there could be other people doing PoC work. Thanks, Jakob Am 08.05.10 18:03, schrieb Alan Kay: Glad you are interested, but don't hold your breath. We've got quite a bit more to do this year. It's not an incremental project like many open source people are used to. We actually throw away much of our code and rewrite with new designs pretty often. Cheers, Alan
Re: [fonc] An actor-based environment for prototyping
Congrats on sticking with your work Dale. I'm impressed. On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher dale.schumac...@gmail.com wrote: I've been following with great interest the FoNC developments at VPRI. I too am very interested in compact, simple and expressive representations of computer-based solutions. My focus for the last three years has been on the Actor model of computation [1][2]. It seems to me that actors are closer to Alan Kay's original concept of objects than the implementation of objects realized in Smalltalk and its derivatives. As Alan has said, the emphasis should be on the messages. In a concurrent environment, the asynchronous messaging of actors is a much better primitive than the synchronous call-return messaging typical in today's object-oriented languages (including those based on COLA). In order to explore these ideas, I've developed an actor-based environment for protoyping. Within this environment I've implemented; a solution to the same-fringe problem, an implementation of Joe Armstrong's Erlang Challenge, a fault-tree simulation, a dialect of FORTH, two dialects of Scheme, and a meta-circularly-defined actor language called Humus. Humus is a pure actor-based programming language that provides a foundation for software developers to build reliable concurrent computer systems. It features a referentially transparent pure-functional core for defining values. These values become the messages between (and specify the behavior of) dynamically configured actors. Actor behaviors are composed of concurrent, rather than sequential, primitive operations. Actor configurations may also be composed without affecting their operation. This allows implementation of systems with high scalability and low latency in both multi-core and distributed execution environments. The theoretical foundations of Humus have mathematically rigorous semantics [3]. Unlike Erlang or Scala, there are no blocking operations and all expressions are completely free of side-effects. Mutable state is entirely encapsulated within actors and may be affected only be sending asynchronous messages. Some of the implementation techniques used in both Humus and my actor-based environment (ABE) were inspired by COLA. OMeta also provided insight into the design of numerous parsers for the various languages built in ABE. I haven't implemented OMeta directly, but believe an implementation is possible. The biggest hurdle to that implementation is the specification of semantic actions. If I use the host language (Humus) to specify the semantic actions, then I can't take advantage of all the useful OMeta code written for COLA. It seems that I would have to implement COLA (Coke) as well. I would love to find a way to connect my work with that of VPRI, to the extent that we have shared goals. [1] G. Agha. Actors: A Model of Concurrent Computation in Distributed Systems. MIT Press, Cambridge, Mass., 1986. [2] C. Hewitt. Viewing Control Structures as Patterns of Passing Messages. Journal of Artificial Intelligence, 8(3):323-364, 1977. [3] G. Agha, I. Mason, S. Smith, and C. Talcott. A Foundation for Actor Computation. Journal of Functional Programming, Vol. 7, No. 1, January 1997. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher dale.schumac...@gmail.com wrote: Humus is a pure actor-based programming language Hi Dale, Are the messages that a Humus actor sends internally (calling methods on itself, etc) also asynchronous? And if so, does this mean that a given instance will never need more than one (potentially recyclable) locals context per method? Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
On Sun, May 9, 2010 at 8:39 PM, Steve Dekorte st...@dekorte.com wrote: On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher Are the messages that a Humus actor sends internally (calling methods on itself, etc) also asynchronous? And if so, does this mean that a given instance will never need more than one (potentially recyclable) locals context per method? All actor messages are sent asynchronously. Actors don't call methods, as that implies a return value. They only send immutable values as messages. When a message is received, the actor's behavior is invoked in a context including the message value and the actor's state. Messages are processed atomically, but this can't lead to dead-lock since an actor's behavior never blocks. In terms of resource usage, it would be more accurate to think of needing one (recyclable) context per concurrent message delivery. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Other interesting projects?
On 10/05/10 04:59, Alan Kay wrote: There are already quite a few Smalltalk elements in Factor (and the postfix language itself (for most things) could be used as the byte-code engine for a Smalltalk (looking backwards) and for more adventurous designs (looking forward)). Factor already has a Smalltalk implementation (a parser and compiler to Factor code) that Slava did a while back as a proof of concept. I'm not sure how performant or complete it is however. Dan Amelang has been moving Nile to a really nice place, and it would be relatively easy to retarget the OMeta compiler for this (particularly the JS grounded one) to ground in Factor. Is there a Nile grammar somewhere? I tried searching for it and didn't come up with anything. I see Dan's github repository but it doesn't seem to include the Ometa definition. Chris. -- http://bluishcoder.co.nz ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
