Re: [fonc] Final STEP progress report?

[Dale Schumacher]

Kind of like "music starts at 9pm" :-)

We're all anxious to see the results of your work.  Thanks (in
advance) for sharing it.

On Fri, Jan 4, 2013 at 10:51 AM, Alan Kay  wrote:
> It turns out that the "due date" is actually a "due interval" that starts
> Jan 1st and extends for a few months ... so we are working on putting the
> report together amongst other activities ...
>
> Cheers,
>
> Alan
>
> 
> From: Mathnerd314 
> To: Fundamentals of New Computing 
> Sent: Friday, January 4, 2013 8:43 AM
> Subject: Re: [fonc] Final STEP progress report?
>
> On 11/7/2012 4:37 PM, Kim Rose wrote:
>> Hello,
>>
>> For those of you interested and waiting -- the NSF (National Science
>> Foundation) funding for the 5-year "STEPS" project has now finished (we
>> stretched that funding to last for 6 years).  The final report on this work
>> will be published and available on our website by the end of this calendar
>> year.
> It's four days past the end of the calendar year, and I don't see a final
> report: http://www.vpri.org/html/writings.php
>
> Am I looking in the wrong place? Or will it be a few more days until it's
> published?
>
> -- Mathnerd314
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Debugging Actor Systems

[Dale Schumacher]

A discussion of logging, testing and reasoning to establish confidence
in actor-based systems.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Producer/Consumer Rate-Matching

[Dale Schumacher]

Generalizing from the Sleeping Barber, we explore the operation of a
active Bounded-Buffer implementation.

http://www.dalnefre.com/wp/2012/05/producer-consumer-rate-matching/
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] “Sleeping Barber” in Humus

[Dale Schumacher]

Do a little yak shaving with an actor-based approach to the "Sleeping
Barber" problem.

http://www.dalnefre.com/wp/2012/04/sleeping-barber-in-humus/
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Kernel & Maru

[Dale Schumacher]

Hi Julian,

I heartily agree that building your own implementations is important.
Although I have also found it illuminating to read and study the
implementations of others, there is nothing that brings the issues
home like making the implementation choices yourself.  Then you can
see exactly what results from the interactions among those choices,
leading to a deeper understanding of the fundamental issues.  I
blogged about part of my own journey in a 4-part series starting with
http://www.dalnefre.com/wp/2011/11/fexpr-the-ultimate-lambda/ (where I
reference both Maru and Kernel).

One insight that I would like to share is that semantics should be
considered separately from syntax.  Not to say that syntax isn't
important, it is!  Only that, at least for me, considering the
different elements of meaning and how they interact is more important
than how they are expressed textually (or visually).  My approach to
this has been to build an object/actor model for each semantic
element, then consider their responsibilities and their protocols for
interacting with each other in order to achieve a computational
result.

I keep coming back to "minimal" sets of conceptual "primitives", where
"minimal" and "primitive" are relative to which model you choose.
Three of these sets keep recurring in my work: actors, functions and
patterns.  For actors, the primitives are "create", "send" and
"become".  For functions, the primitives are "variable", "abstraction"
and "application".  For patterns, the primitives are "predicate",
"sequence" and "alternative".  I continue to explore productive
combinations of these concepts.  I hope you enjoy your journey of
discovery as much as I am enjoying mine!

Take care,
Dale

On Tue, Apr 10, 2012 at 12:04 PM, Alan Kay  wrote:
> Hi Julian
>
> (Adding to Ian's comments)
>
> Doing as Ian suggests and trying out variants can be an extremely
> illuminating experience (for example, BBN Lisp (1.85) had three or four
> choices for what was meant by a "lambda closure" -- three of the options I
> remember were (a) "do Algol" -- this is essentially what Scheme wound up
> doing 15 years later, (b) make a private a-list for free variables, (c) lock
> the private a-list to the values of the free variables at the time of the
> closure).
>
> I  suggest not trying to write your eval in the style that McCarthy used
> (it's too convoluted and intertwined). The first thing to do is to identify
> and isolate separate cases that have to be taken care of -- e.g. what does
> it mean to eval the "function position" of an expression (LISP keeps on
> evaling until a lambda is found ...). Write these separate cases as
> separately as possible.
>
> Dave Fisher's thesis "A Control Definition Language" CMU 1970 is a very
> clean approach to thinking about environments for LISP like languages. He
> separates the "control" path, from the "environment" path, etc.
>
> You have to think about whether "special forms" are a worthwhile idea (other
> ploys can be used to control when and if arguments are evaled).
>
> You will need to think about the tradeoffs between a pure applicative style
> vs. being able to set values imperatively. For example, you could use
> "Strachey's device" to write "loops" as clean single assignment structures
> which are actually tail recursions. Couple this with "fluents" (McCarthy's
> "time management") and you get a very clean non-assignment language that can
> nonetheless traverse through "time". Variants of this idea were used in
> Lucid (Ashcroft and Wadge).
>
> Even if you use a recursive language to write your eval in, you might also
> consider taking a second pass and writing the eval just in terms of loops --
> this is also very illuminating.
>
> What one gets from doing these exercises is a visceral feel for "great power
> with very little mechanics" -- this is obtained via "mathematical thinking"
> and it is obscured almost completely by the standard approaches to
> characterizing programming languages (as "things in themselves" rather than
> a simple powerful kernel "with decorations").
>
> Cheers,
>
> Alan
>
>
>
> 
> From: Ian Piumarta 
> To: Julian Leviston 
> Cc: Fundamentals of New Computing 
> Sent: Monday, April 9, 2012 8:58 PM
> Subject: Re: [fonc] Kernel & Maru
>
> Dear Julian,
>
> On Apr 9, 2012, at 19:40 , Julian Leviston wrote:
>
>> Also, simply, what are the "semantic inadequacies" of LISP that the "Maru
>> paper" refers to (http://piumarta.com/freeco11/freeco11-piumarta-oecm.pdf)?
>> I read the footnoted article (The Influence of the Designer on the Design—J.
>> McCarthy and Lisp), but it didn't elucidate things very much for me.
>
> Here is a list that remains commented in my TeX file but which was never
> expanded with justifications and inserted into the final version.  (The ACM
> insisted that a paper published online, for download only, be strictly
> limited to five pages -- go figure!)
>
> %%  Difficulties and omissions arise
> %%  inv

[fonc] Futures and Capabilities

[Dale Schumacher]

Exploring explicit Futures and using Object Capability Security to
control access

http://www.dalnefre.com/wp/2012/03/futures-and-capabilities/
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Error trying to compile COLA

[Dale Schumacher]

On Mon, Feb 27, 2012 at 5:23 PM, Charles Perkins  wrote:
> I think of the code size reduction like this:
>
> A book of logarithm tables may be hundreds of pages in length and yet the 
> equation producing the numbers can fit on one line.
>
> VPRI is exploring "runnable math" and is seeking key equations from which the 
> functionality of those 1MLOC, 10MLOC, 14MLOC can be automatically produced.
>
> It's not about code compression, its about functionality expansion.

This reminds me of Gregory Chaitin's concept of algorithmic
complexity, leading to his results relating to compression, logical
irreducibility and "understanding" [1].

[1] G. Chaitin.  Meta Math! The Quest for Omega, Vintage Books 2006.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Implementing Actors in Kernel

[Dale Schumacher]

Hi Viktor,

I haven't given much thought to using Iteratees.  I'll be interested
to see your results.

Take care,
Dale

On Fri, Feb 17, 2012 at 5:40 AM, √iktor Ҡlang  wrote:
> Hey Dale,
>
> really interesting post, thanks for writing it up.
>
> I've been experimenting implementing actor behaviors as Iteratees, is
> that something you've explored as well?
>
> Cheers,
> √
>
> On Fri, Feb 17, 2012 at 5:29 AM, Dale Schumacher
>  wrote:
>> When Steele and Sussman wanted to explore Actors, they built an
>> evaluator in LISP.  Their work eventually resulted in Scheme, which
>> moved us from dynamic to static/lexical scoping, but is _not_ an actor
>> language.  Since then there has been ongoing confusion about the
>> relationship, if any, between Actors and Lambda Calculus.
>>
>> Kernel is a modern Scheme variant based on explicit, rather than
>> implicit evaluation.  It is on this foundation, in about a page of
>> code, that I demonstrate how a simple Actor system can be implemented.
>>  It is my hope that this show that Actors are not simply functions,
>> but rather are simple powerful building-blocks for managing
>> concurrency in the presence of mutable state.
>>
>> <http://www.dalnefre.com/wp/2012/02/implementing-actors-in-kernel/>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - The software stack for applications that scale
>
> Twitter: @viktorklang
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Implementing Actors in Kernel

[Dale Schumacher]

When Steele and Sussman wanted to explore Actors, they built an
evaluator in LISP.  Their work eventually resulted in Scheme, which
moved us from dynamic to static/lexical scoping, but is _not_ an actor
language.  Since then there has been ongoing confusion about the
relationship, if any, between Actors and Lambda Calculus.

Kernel is a modern Scheme variant based on explicit, rather than
implicit evaluation.  It is on this foundation, in about a page of
code, that I demonstrate how a simple Actor system can be implemented.
 It is my hope that this show that Actors are not simply functions,
but rather are simple powerful building-blocks for managing
concurrency in the presence of mutable state.


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fexpr the Ultimate Lambda

[Dale Schumacher]

Actually, I hope to cite the Smalltalk work when I write about
extensible syntax, rather than just extensible semantics.

On Fri, Nov 25, 2011 at 1:53 PM, Dale Schumacher
 wrote:
> Yes, absolutely!  I've read that paper numerous times.  Unfortunately,
> I wasn't able to cite all of the branches of the LISP family tree.
>
> I _did_ cite Piumarta's work on Maru.  His extensible base is much
> smaller Shutt's, but Kernel provided a better illustration of
> actor-based evaluation techniques.
>
> On Fri, Nov 25, 2011 at 1:19 PM, Alan Kay  wrote:
>> Hi Dale
>> Check out "The Early History of Smalltalk" to see the same insight about
>> Lisp and how it was used to think about and define and implement
>> Smalltalk-72.
>> Cheers,
>> Alan
>>
>> 
>> From: Dale Schumacher 
>> To: Fundamentals of New Computing ; CAG
>> ; Programming Language Design
>> ; The Friday Morning Applied Complexity Coffee Group
>> 
>> Sent: Friday, November 25, 2011 10:05 AM
>> Subject: [fonc] Fexpr the Ultimate Lambda
>>
>> Fexpr the Ultimate Lambda (http://bit.ly/v6yTju) a treatise on
>> evaluation, in honor of John McCarthy.
>>
>> John Shutt’s Kernel language, and its underlying Vau-calculus, is a
>> simplified reformulation of the foundations of the LISP/Scheme family
>> of languages. It is based on the notion that evaluation should be
>> explicit, patterned after Fexprs, rather than implicit, using Lambda.
>> The results is a powerful well-behaved platform for building
>> extensible languages. Not extensible in syntax, but in semantics. We
>> have implemented the key mechanisms of Vau-calculus using actors. The
>> actor-based evaluation strategy introduces inherent concurrency
>> prevasively throughout the evaluation process.
>>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
>>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
>

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Fibonacci Machine

[Dale Schumacher]

Thanks for disseminating the latest report.  It is, as always, an
inspiration to see all the fine work being done.  I can hardly wait to
play with the "final" system, and perhaps extend and build on it.

One of the first things I did was re-create (in Humus) the Fibonacci
Machine from the Nile data-flow model.  I think that the "start-0" and
"start-1" processes in the upper branch ("b1", "b2", "b3") should be
reversed.  It seems that the "add" process should first receive 0
(from "b3") and 1 (from "b5"), then the 1 from "b2" can be forwarded
and combined with the 1 from the feedback loop ("b7").  I like how the
pair of forwarders in the upper branch form a kind of delay-line
effect to stagger the previous and next results.

I appreciate the opportunity to explore and experiment with the ideas
here.  It will be even better when I can do it in the same environment
that you do, rather than translating into my own system.

On Mon, Nov 7, 2011 at 5:08 PM, karl ramberg  wrote:
> http://www.vpri.org/pdf/tr2011004_steps11.pdf
>
> Karl
>
> ___
> 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] The Language Barrier

[Dale Schumacher]

You might also find David Harel's article "Can Programming Be
Liberated, Period?"
(http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.3837)
interesting.  He takes quite a different approach to "specification"
of system behavior, as well as programming in general.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Richard Gabriel & Guy Steele, "50 in 50" talk

[Dale Schumacher]

On Sat, Jun 25, 2011 at 6:00 AM, BGB  wrote:
> ... the more a language moves towards being
> practical and useful, the more it will likely tend to resemble more
> mainstream languages. which I suspect more work through a sort of long-term
> distilation/refinement process, where useful features tend to be added
> eventually, and non-useful features tend to be dropped, leading to
> incremental improvement.

The fact that "successful" languages tends to resemble each other is a
kind of self-fulfilling prophecy.  One of the things I enjoyed about
the presentation was the reminder of the potential diversity in both
meaning and mode of expression in computer languages.

A healthy amount of diversity makes an eco-system more resilient.  It
seems to me that we were, until the last few years, converging on a
dangerously unstable mono-culture of languages.  I'm encouraged to see
that we may be heading into a new period of expansion and
experimentation, which I expect will eventually lead to another period
of consolidation, as the cycle proceeds.

Richard Gabriel had some interesting things to say about this
http://dreamsongs.com/Files/PatternOfLanguageEvolution.pdf

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))

[Dale Schumacher]

On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza  wrote:
> In fact, I'm interested enough in the block structure visualization that I've 
> been porting just the blocks, without the Scratch semantics and runtime, to 
> the web. You can use scratch-like blocks to write and output any language, 
> provided a language plugin. As a demonstration, I'm writing a language plugin 
> for Javascript (plus Raphael, for graphics) and Martyn Eggleton is working on 
> a plugin for writing Arduino code. It is still early days, very alpha, but if 
> anyone is interested there is more here:
>
> https://github.com/dethe/waterbear/wiki [info]
> https://github.com/dethe/waterbear/ [code]
> https://waterbearlang.com/ [Javascript demo]
> http://stretch.deedah.org/waterbear/ [Arduino demo]
>
> I've been meaning to share this with the group here, but wanting to get it 
> roughed in a bit more, but here it is in all its half-baked glory. Feedback 
> highly appreciated.
>
> --Dethe

Very cool project.  I'd like to see how easy it would be to use it for
Humus programs.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

[Dale Schumacher]

Perhaps I can help you avoid talking past each other.

On Mon, Jun 13, 2011 at 11:35 PM, Julian Leviston  wrote:
> On 14/06/2011, at 1:50 PM, C. Scott Ananian wrote:
>
>>> When you're about to type the next "tile", you're given options... anything 
>>> outside of those options is impossible, so the computer doesn't put it in, 
>>> because syntactically it wouldn't make sense.
>>
>> There's nothing specific to tiles in what you wrote.  You could do the
>> same just as easily with a keyboard-based system.
>> This is what I mean when I say that "tiles prevent syntax errors" is
>> not accurate; it's confusing two separate things.
>> Again: more accurately you could say, "strong typing can prevent
>> syntax errors"...  tiles have nothing to do with it, really.
>
> Assuming a "compile after composing" type of system. If it's a running, live, 
> system, then "type" is irrelevant because an "object" at the point of being 
> "talked to" will provide its own semantic and therefore 
> syntactic-appropriateness context (ie duck typing for want of a better term). 
> Do you see why I think text-stream based systems are outmoded crappy systems 
> yet?

The "strong typing" Scott is talking about is the equivalent of the
snap-together shapes on the tile edges.  Another equivalence is the
choice-list of options you may be presented in an IDE.  Both constrain
(or guide, in the case of code-completion) your options based on the
"type" of the interaction.  Without some kind of type information
there is no meaningful way to constrain the options, graphical or
otherwise.

Hopefully, I haven't misrepresented either of you, or added my own
confusion to the conversation.

[snip]
> Instead of having actual one-level-linked instantiated objects AT THE POINT 
> of programming, we use multi-layered deferred referencing (ie text-stream 
> based "codes" which are later processed and further decoded into computer 
> codes by another computer program many times).

One perspective on designing in solution-space is to visualize the
object (or actor) instances and their interactions during the
evolution of a computation.  For me, syntax follows structure.  That
is, I first think about the objects and their connections, both static
and dynamic, in a sort of general nodes-and-edges graph structure.
Then I try to map the graph into a linear textual representation.  The
result is often frustrating, since linear streams of characters make
some graph structures awkward to express.  I expect that direct
visualization of the object graph would be helpful here.  On the other
hand, I find that the behavior of the objects (actors) is easier to
grasp in a compact textual representation, even though the behavior
description has its own (fractal?) graph structure.

In any case, the graph structure carries no type information.  It is
just a reference/reachability graph, constraining potential
communication (a reference is required for interaction).  The content
(type) of the communication is not constrained.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Persistence and the Great Horse Trade (was Re: [fonc] Alternative Web programming models?)

[Dale Schumacher]

On Mon, Jun 13, 2011 at 2:21 PM, Casey Ransberger
 wrote:
> Comments below.
> On Jun 13, 2011, at 6:00 AM, Dale Schumacher 
> wrote:
>
> On Mon, Jun 13, 2011 at 4:50 AM, BGB  wrote:
>
> however, unlike full image-based development, the app will generally
> "forget" everything that was going on once it is exited and restarted.
>
>
> I think this is one of the most annoying "features" of our current
> computer systems.  If I have a project (or 10 or 20 projects) spread
> out on my workbench, and I leave to have something to eat, or go to
> sleep, when I return everything is still (more or less) in the state I
> left it.
>
> Dale, when read this it wasn't clear to me what you meant to convey. Are you
> saying "it's annoying that when I come back to my bench, I have to swim all
> the way back to the context I was in before" or are you saying "when I
> return to my bench, it's annoying to have to close all of that stuff because
> what I usually want is a new context anyway"?

I'm most definitely saying that I prefer the "eternal" (as Alan said)
system, with persistent state.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

[Dale Schumacher]

On Mon, Jun 13, 2011 at 4:50 AM, BGB  wrote:
>
> however, unlike full image-based development, the app will generally
> "forget" everything that was going on once it is exited and restarted.
>

I think this is one of the most annoying "features" of our current
computer systems.  If I have a project (or 10 or 20 projects) spread
out on my workbench, and I leave to have something to eat, or go to
sleep, when I return everything is still (more or less) in the state I
left it.

>
> by analogy, it is like running programs in Windows:
> one can open/close/run programs, edit things, ... in Windows, and so long as
> it is running, it will remember all this;
> but, if/when Windows is rebooted, it will forget, and one starts again with
> a "clean slate" of sorts (an empty desktop with only their icons and
> start-up programs to greet them...).
>
> but, the merit of rebooting Windows is that it keeps the system "clean", as
> running Windows continuously is prone to cause it to degrade over time, and
> without an occasional reboot will begin to manifest lots of buggy behavior
> and eventually crash (IME, much worse in Vista and Win7 than in XP...).
>

Long-running stability and continuous upgrading (WITHOUT "rebooting")
should be the norm.  There should be no such thing as a "boot"
process.  A system should remain stable (and running) throughout a
lifetime of gradual evolution/mutation.  Of course, we also need a way
to branch/fork/clone/version and even start-from-embryo, to build new
systems.  The next step is to consider how the "system" (or parts of
it) can migrate, or become mobile, among hosts.

>
>> and essentially, that's what text-file coding (ie editing "offline" code)
>> does for us... because things are in files, it's easy to "include" a file as
>> one packaged unit, or a group of file, or a "package"... and then that
>> "package" can be referred to... separately, and even maintained by someone
>> else, and it's not a COPY of the package, it's a reference to it...  you
>> know? This is incredibly powerful.
>
> yep.
>
> I am generally mostly in favor of using files.
>

Naming is certainly important, as is contextual reference, but I'm not
convinced that "files" are a necessary part of providing that
mechanism.  Consider, as a possible alternative, the idea of
parametrizing a module with its dependencies.  This is just the
principle of applying abstractions to allow local naming (aliasing) of
"externally" provided objects.

my_module(something_i_need, ...) = ... module specification using
something_i_need ...

create my_module(provider_of_service, ...)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Re: Electrical Actors?

[Dale Schumacher]

On Sun, Jun 5, 2011 at 8:13 PM, Casey Ransberger
 wrote:
> On Jun 5, 2011, at 4:25 PM, Dale Schumacher  wrote:
>> If someone has, I would sure like to hear about it!  There was the
>> Apiary machine, but I don't think that was ever physically built, only
>> simulated.
>
> Googling...
>

"Tradeoffs in Designing a Parallel Architecture for the Apiary" is a
good place to start
(http://dspace.mit.edu/handle/1721.1/41221?show=full).  It seems that
many of the related papers are not freely available.

> Maybe to deal with concurrency I should really start thinking of them as 
> "actor animators".
>
> I'm sure there's a way to pull this off. Even if it's by having a lot of 
> FPGAs on the logic board so that I can compensate for reconfiguration latency 
> by switching between them, but I don't think that idea fits any goal around a 
> parsimonious architecture, which is one thing that I'm after. The 
> synchronization problems I'd expect also seem awful, unless someone out there 
> has thought a bunch about doing a low-level TeaTime (or what have you.)

Actually, I think the parsimony principle is pretty well supported by
low-level actors.  I've built several actor run-time environments in
software.  The low-level machinery is quite small and simple.  Its
primary responsibilities are memory management and message dispatch.
CREATE is memory allocation, BECOME is "assignment" and SEND is
message construction (allocation) and queuing for dispatch.

The rest of Humus was implemented on this simple core
(http://www.dalnefre.com/wp/2010/08/evaluating-expressions-part-1-core-lambda-calculus/).
 The meta-circular description provides a semantic guide for direct
machine-level implementation of the language components.  Parsers and
translators can also be built from low-level actors
(http://www.dalnefre.com/wp/2011/02/parsing-expression-grammars-part-1/),
allowing expression of actor scripts in textual form.

Even the Humus simulator
(http://www.dalnefre.com/humus/sim/humus.html) is built on a very
small actor run-time core (http://www.dalnefre.com/humus/sim/actor.js)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Re: Electrical Actors?

[Dale Schumacher]

On Sun, Jun 5, 2011 at 5:23 PM, Casey Ransberger
 wrote:
>
> Has anyone taken the actor model down to the metal?

If someone has, I would sure like to hear about it!  There was the
Apiary machine, but I don't think that was ever physically built, only
simulated.

This is a concept that has been kicked around several times over the
last couple of years among some of my collaborators.  It is one of the
reasons why I ported the actor core runtime to the Arduino, to get a
step closer to the metal.

The SEND and BECOME primitives seem fairly straight-forward to
translate to hardware.  It is the CREATE primitive that I struggle
with.  Since we can't actually "create" new hardware elements, it
seems like it would have to be virtualized in some way.  Perhaps it
would be sufficient to virtualize it the same way we virtualize
processes, simulating multi-processing on a smaller number of cores.

Maybe there would be some way to activate latent nodes of processing
power, injecting them with their initial behavior as a way of
breathing life into them.  It could be just a matter of "allocating"
new actors the way we allocate memory.  Each hardware node could have
a capacity of available actors who only need a script to become alive.

I would love to explore this idea further and hear how you would
consider approaching the problem.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Parsing Expression Grammars, part 4 (Left-recursion considered harmful)

[Dale Schumacher]

Parsing Expression Grammars, part 4 (http://bit.ly/iVXPEJ) addresses
the issue of left-recursive grammars, often used for left-associative
arithmetic operators.  Accumulating a value via iteration is proposed
as an appropriate solution for recursive-descent parsers like PEGs.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Re: Parsing Expression Grammars, part 2

[Dale Schumacher]

Parsing Expression Grammars, part 3 (http://bit.ly/h9HoW1) extends the
parser toolkit to support pipelines of tree-transforming parsers,
bringing our capabilities to the level of OMeta [1].

[1] A. Warth and I. Piumarta. OMeta: an Object-Oriented Language for
Pattern Matching. TR–2007–003,
http://www.vpri.org/pdf/tr2007003_ometa.pdf, Viewpoints Research
Institute, 2007.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Parsing Expression Grammars, part 2

[Dale Schumacher]

Parsing Expression Grammars, part 2 (http://bit.ly/gDrbmi) goes beyond
simple matching with semantic values, predicates and actions.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Parsing Expression Grammars, part 1

[Dale Schumacher]

Parsing Expression Grammars, part 1 (http://bit.ly/gR9Xdu) describes
an actor-based PEG implementation that illustrates the use of multiple
"continuations" to manage flow control.  It also shows several
examples of lazy-initialized executable specifications.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Playing the Stooge with Humus

[Dale Schumacher]

After many requests, I've finally built an online simulator/debugger
to let people experiment with Humus.  I've just published a brief
tutorial "Playing the Stooge with Humus" (http://bit.ly/gYL4cm) to
showcase the new simulator environment.  Here's your chance to try
some hands-on examples.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Evaluating Expressions, part 7 – Tra nsactions and Exceptions

[Dale Schumacher]

I just posted the final piece of the meta-circular Humus evaluator.
"Evaluating Expressions, part 7 – Transactions and Exceptions"
(http://bit.ly/fl6Z3O)

Throughout the series, I've had the opportunity to present a wide
variety of powerful language constructs.  Of course, concurrent
evaluation/execution has been an ongoing theme.  Pattern matching as
part of the resolution of equations is one of my favorites.
Single-assignment data-flow variables played an important role in
automatic resolution of data dependencies.  The lambda-abstraction
mechanism is applied universally to support parameterization of not
only expressions, but statement blocks too.  I hope this series can
serve as an interesting and informative reference.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Describing Semantics

[Dale Schumacher]

The versions of Humus I have running implement earlier versions of the
language syntax. In addition, they exist in a proof-of-concept
prototyping environment, so graceful handling of errors was not a
priority. I’m making progress on a version that is appropriate for
public consumption, but it’s not ready yet. If you’re interested in
working with the prototype, and willing to work around the sharp
edges, contact me via email. Thanks for your interest.

On Wed, Nov 24, 2010 at 11:43 PM, Yanqiu Chen  wrote:
> On Tue, Nov 23, 2010 at 10:38 PM, Dale Schumacher
>  wrote:
>>
>> My Humus language [2] is a sort of "kernel language" based on a pure
>> implementation of the Actor model.
>>
> so how can i get an runnable Humus?

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Describing Semantics

[Dale Schumacher]

Another way to define semantics is the "kernel language" approach
where the kernel language has a formal (possibly Operational)
semantics.  Van Roy and Haridi used this in CTM [1] for Oz/Mozart.

My Humus language [2] is a sort of "kernel language" based on a pure
implementation of the Actor model.  This language has been used to
explore the semantics of a variety of other computational models
including Object-Oriented Method Invocation (ala COLA) [3] and
pure-functional Lambda Calculus [4].

My strategy in using Humus has been to create "live" objects (actors,
really) which represent various software constructs (variables,
patterns, expressions, statements, etc.).  These actors respond to
events which initiate computation.  They generate events with cause
effects, modeling the "state" of the system.

A prototype implementation of Humus generates a graph of actors from
the AST resulting from parsing language text.  The graph of actors
represents the "program".  Execution occurs when an "eval/exec"
message (which carries the context/environment for execution) is sent
to the entry-point of the actor graph.

[1] http://c2.com/cgi/wiki?ConceptsTechniquesAndModelsOfComputerProgramming
[2] http://www.dalnefre.com/wp/humus/
[3] 
http://www.dalnefre.com/wp/2010/07/message-passing-part-2-object-oriented-method-invocation/
[4] 
http://www.dalnefre.com/wp/2010/08/evaluating-expressions-part-1-core-lambda-calculus/

On Mon, Nov 22, 2010 at 8:33 AM, Alan Kay  wrote:
> Actually, I think it would be a good exercise for you to ask "what is
> semantics?", especially with regard to computing, and some of the ways it
> might be useful. and report back to this list. It will make a good topic
> for discussion.
>
> This is easier than it was 50 years ago because there are more examples and
> more formalisms. So, in what ways are e.g. "operational semantics" and
> "denotational semantics similar, and how are they different? What do you
> lose or gain going from one to the other?
>
> Cheers,
>
> Alan
>
>
> 
> From: Ondřej Bílka 
> To: Fundamentals of New Computing 
> Sent: Mon, November 22, 2010 6:21:30 AM
> Subject: Re: [fonc] Describing Semantics
>
> Hello
> Can you explain benefits of operational semantics.
> I skimmed through few papers  and it looks that they define yet another
> language with its abstract syntax tree.
> On Sun, Nov 21, 2010 at 04:55:45PM -0800, Alan Kay wrote:
>>    Hi Casey,
>>
>>    You might enjoy looking at "operational semantics" -- whose idea has
>> been
>>    around longer than the term. There is also "denotational semantics",
>> which
>>    goes back to Christopher Strachey in the 60s.
>>
>>    The latter is more amenable to automated reasoning processes, and the
>>    former is more amenable to lower level translations that create working
>>    machinery.
>>
>>    We are more interested in the former, and doing something about it is
>> on
>>    our list, but this is not likely to happen for quite a few months.
>>
>>    So it would be great for folks on the fonc list to weigh in. For
>> example,
>>    Nile is currently translated by OMeta into a variety of targets,
>> including
>>    Javascript, Squeak, and C -- and soon into a STEPS lower level language
>>    (which could be thought of as a kind of "operational semantics").
>>
>>    It would be nice to have more schemes for semantics which allow both
>>    reasoning and translation into efficient lower level code.
>>
>>    Cheers,
>>
>>    Alan
>>
>>
>> --
>>
>>    From: Casey Ransberger 
>>    To: Fundamentals of New Computing ; "om...@vpri.org"
>>    
>>    Sent: Sun, November 21, 2010 3:40:31 PM
>>    Subject: [fonc] Describing Semantics
>>    So I was in a heated debate with a good friend about Ometa. He pointed
>>    out, inadvertently, that matters of syntax and grammar are only the
>> easy
>>    part of the problem.
>>
>>    Ometa, I think, is the most elegant language we've seen for binding
>>    syntactic/grammatical constructs to semantics implemented in a host
>>    language, but the host language, as cool as it's gotten (e.g.,
>> JavaScript
>>    has some decent semantics, once one can work around the syntax) is
>> still
>>    resistant, and Ometa leaves it up to us to express the semantics we
>> want
>>    in whatever host language we've chosen.
>>
>>    How many hoops do we want to jump through in order to express our
>>    semantics? Obviously JavaScript isn't ideal for that.
>>
>>    I imagine I'm not the only person thinking about this. Ometa seems to
>>    *want* to be embedded in a language that expresses diverse semantics
>>    compactly.
>>
>>    What language is that?
>>
>>    My friend presented me with a construct that looked very much like a
>>    dictionary but where the keys and values could be only of certain types
>> in
>>    the target language (this in an argument about the value of source to
>>    source transl

[fonc] Evaluating Expressions, part 6 – Act or Primitives

[Dale Schumacher]

Implementing language features using Actors has reached the point
where the actor primitives themselves can be described
meta-circularly.

http://bit.ly/9KfHLI

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Evaluating Expressions, part 5 – Rec ursion

[Dale Schumacher]

Evaluating Expressions, part 5 – Recursion (http://bit.ly/cVPMHk)
explores the relationship between multiple recursive references,
mutable environments, and incremental developing using a REPL.

If you are planning to attend QCon/SF next week, stop by and say
"Hello" (http://qconsf.com/sf2010/presentation/Actor+Thinking)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Evaluating Expressions, part 4 – Pat tern Equations

[Dale Schumacher]

Pattern equations extend the use of pattern matching to the realm of
definitions.  These are true equations which establish equality
relationships, sometimes in a conditional context.  Unlike most
computer languages, these equations exhibit symmetric treatment of
both sides of the equation.  (http://bit.ly/a4Vnuz)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Evaluating Expressions, part 3 – Pai rs and Parallelism

[Dale Schumacher]

Concurrent evaluation of sub-expressions.  Extension of
single-argument/single-return lambda calculus to
multi-argument/multi-return without Currying. Fork/join pattern
captured as a behavior.  (http://bit.ly/9eEafl)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Evaluating Expressions, part 2 – Con ditional Special Form

[Dale Schumacher]

Conditional special forms implemented via pattern matching rather than
Boolean predicates and lambda abstractions defined in terms of pattern
matching (http://bit.ly/9VZtIH)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Evaluating Expressions, part 1 – Cor e Lambda Calculus

[Dale Schumacher]

Evaluating Expressions, part 1 – Core Lambda Calculus http://bit.ly/cImxrf
(http://www.dalnefre.com/wp/2010/08/evaluating-expressions-part-1-core-lambda-calculus/)

With only a handful of actor behaviors, this article shows how to
create a behavior-driven evaluator for pure lambda calculus
expression.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Re: [PiLuD] “Dining Philosophers” in Humus

[Dale Schumacher]

Nice!  Only there are two issues.

First, my algorithm should never deadlock, so the philosophers would
starve :-)

And second, it would require invocation of a nested runtime.  Now
_this_ is the interesting part.  I will be posting about this soon.
It is also the basis for instrumentation and debugging tools.

On Mon, Aug 16, 2010 at 2:26 PM, John Zabroski  wrote:
> Bonus points if you extend it to the Russian Dining Philosopher's Problem
> [1] (each Philosoper is recursively thinking about the DP Problem).
>
> [1] http://www.cs.adelaide.edu.au/~charles/OPN.html
>
> On Fri, Aug 6, 2010 at 5:01 PM, Dale Schumacher 
> wrote:
>>
>> Just published:  An incremental exploration of the Dining Philosophers
>> problem.  This actor-based solution is a little different in that I
>> give active state-dependent behavior to the chopsticks as wells as the
>> philosophers.
>>
>> http://www.dalnefre.com/wp/2010/08/dining-philosophers-in-humus/
>>
>> --
>> send mail      : pi...@googlegroups.com
>> subscribe      : pilud+subscr...@googlegroups.com
>> unsubscribe  : pilud+unsubscr...@googlegroups.com
>> home page   : http://groups.google.com/group/pilud
>> Note: reply address is set to the list -- no need to "reply all"
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] “Dining Philosophers” in Humus

[Dale Schumacher]

Just published:  An incremental exploration of the Dining Philosophers
problem.  This actor-based solution is a little different in that I
give active state-dependent behavior to the chopsticks as wells as the
philosophers.

http://www.dalnefre.com/wp/2010/08/dining-philosophers-in-humus/

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] What is "message-passing"?

[Dale Schumacher]

I've just published the second part of a two-part article exploring
what we mean when we say "message-passing" (http://bit.ly/9y0NkV).
Specifically, I illustrate implementations of Synchronous Rendezvous
[1] and Object-Oriented Method Invocation [2] in terms of asynchronous
actor messaging.

[1] 
http://www.dalnefre.com/wp/2010/07/message-passing-part-1-synchronous-rendezvous/
[2] 
http://www.dalnefre.com/wp/2010/07/message-passing-part-2-object-oriented-method-invocation/

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Re: [PiLuD] Actors in Clojure — Why Not ?

[Dale Schumacher]

Thanks for sharing your insights and experience, David.  Regardless of
our approaches, it is clear that meaningful software systems are at
least "complicated", and in many cases "complex".  Some of my
larger-scale experiments (such as meta-circular Humus) have led me to
some very interesting patterns for manging this inherent complexity.
I'll certainly be publishing more, and I look forward to ongoing
collaborative discussions.

Although I can't say that I have ready answers for some of the
challenge you describe, I do have confidence that appropriate
actor-based solutions do exist.  Since the actor model has close
analogs with the interactions among groups of people, I often look for
solution-patterns among the social and commercial interactions of
communities.  The history of civilization provides a rich set of
tried-and-true interaction patterns--much richer than the relatively
impoverished history of computing :-)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Re: [FRIAM] Actors in Clojure — Why Not?

[Dale Schumacher]

On Sun, Jun 20, 2010 at 12:44 AM, Saul Caganoff  wrote:
> It strikes me that the actor model is very closely related to a lot of the
> principles I have used with MOM and I'm keen to get hands-on with an
> actor-based programming language to try it out and explore the parallels.
> What would you recommend as a good place to start? Specifically in terms of
> language I'm briefly aware of Erlang and Clojure...until your blog post I
> was unaware of Humus.

Gul Agha, his students and colleagues have done a lot of work in
applying the actor model to distributed (and even mobile) systems.
You might want to look into Salsa for some interesting examples.
Erlang, of course, has a long history and proven track-record, so
there are lots of lessons to be learned there too.  I started
developing Humus because I couldn't find an accessible pure-actor
implementation.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Re: [PiLuD] Actors in Clojure — Why Not ?

[Dale Schumacher]

The example of implementing a queue (using a serializer) is definitely
part of a meta-circular definition of actor behavior.  Serializers are
one of the critical mechanisms identified by Hewitt, et. al. long ago.
 I believe that maintaining multiple virtual configurations of actors
provides another important way to partition actor systems.

In either case, I don't see the problem in composing actors,
especially if they have limited interactions.  Since concurrency is
mediated by message delivery, and message handling generally
represents small finite amounts of computation, independent actor
behaviors are interleaved at a very fine granularity.  And they can't
interfere with each other because they don't have shared mutable
state.

Of course, when working with traditional threaded systems, the cost of
context switching encourages us to do a lot more work between context
switches.  I think the key to effective actor implementations is a
dramatically lower context switching cost, which I have achieved in my
prototype.

The big mental shift in working with actors is to think in terms of
concurrent, rather than sequential, composition.  When I start
describing the meta-circular definition of Humus, in terms of actors,
the inherent pervasive fine-grained concurrency will be more clearly
exposed.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Re: [PiLuD] Actors in Clojure — Why Not ?

[Dale Schumacher]

Hi David,

I've actually read quite a bit of your actor-related material and I'm
aware of your criticisms.  I respect the fact that your opinion has
grown out of experience, rather than just thought-experiments.
However, my own experimentation has led me to different conclusions.

To be clear, the context of my exploration has been what I call
actors-in-the-small rather than actors-in-the-large.  While the issues
of multi-core shared-memory-multiprocessing significantly overlap the
issues of open distributed systems, certain problems (like message
loss) are less important, and other problems (like latency) are more
important for actors-in-the-small.

When I say that the actor model is flexible enough to model the
mechanisms of other computational models, I _do not_ mean simply in
the "Turing tar-pit" sense.  For me, the actor model places the
emphasis on message protocols and behavior, rather than mutable state
and global consistency.  In that sense, I find that describing other
computational models with actors helps me to understand the event
interactions that are hidden within the primitives of each model.
This leads me to a better understand of how each mechanism works, and
provides a basis for comparison between models.  I will be publishing
further articles illustrating exactly what I mean by this.

Thanks for your thoughtful response.  I look forward to continued
productive debate on these fascinating subjects.

Dale

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Actors in Clojure — Why Not?

[Dale Schumacher]

Thanks for the encouragement.  I agree that this article skims the
surface of a number of deeper issues.  That's been part of my
challenge in blogging.  I want to pack too much into each article.
Friends have been advising me to publish shorter pieces more
frequently.  The result is that I have to explore these off-shoots in
subsequent articles, which I definitely plan to do.

Type systems are certainly an area of strong debate.  I should point
out that some actors will not "reply" _at all_, so the issue of reply
type is moot.  You could say that a _message_ has a type, but it is
not always clear what type(s) an actor will understand.  This is
especially problematic because an actor can replace its own behavior.
The new behavior may understand a very different set of messages,
effectively changing the "type" of the interface.

I prefer to focus on "protocol" rather than "type".  Protocol accounts
for changing behaviors over time, based on interactions (messages).
For an example of this, take a look at the state-dependent protocol
involved in implementing a "queue"
(http://www.dalnefre.com/wp/2010/05/composing-actors/#queues).  The
actors involved in implementing the queue change their protocol to
coordinate their updates and thus must be protected by a serializer so
they don't receive "outside" requests when they are in the wrong
state.

On Sat, Jun 19, 2010 at 12:53 AM, John Zabroski  wrote:
> Towards the end, it seems like you also suffer from some hand-waviness.
>
> Perhaps you could flesh out the hand wavy portions in some future posts.
>
> In particular, I would focus on how to transitively handle messages.  For
> example, a common error I see by some academics who are overly zealous about
> functional programming and Hindley-Milner type systems is that they believe
> if an actor cannot handle a message directly, then we cannot say anything
> meaningful about the return type of the reply.  This is not true, of course,
> it is simply that we need a way to model the union of all reply
> possibilities.
>
> Stuff like partial failure is hard to do elegantly, but does not excuse
> hand-wavy explanations.
>
> Looking forward to your future blogging!
>
> Cheers,
> Z-Bo
>
> On Fri, Jun 18, 2010 at 10:58 PM, Dale Schumacher
>  wrote:
>>
>> Published:
>> "Actors in Clojure — Why Not?" (http://bit.ly/9ZUXaQ)
>> http://www.dalnefre.com/wp/2010/06/actors-in-clojure-why-not/
>>
>> This article provides a counterpoint to Rich Hickey's rationale for
>> not including actor-based concurrency in Clojure.
>>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Actors in Clojure — Why Not?

[Dale Schumacher]

Published:
"Actors in Clojure — Why Not?" (http://bit.ly/9ZUXaQ)
http://www.dalnefre.com/wp/2010/06/actors-in-clojure-why-not/

This article provides a counterpoint to Rich Hickey's rationale for
not including actor-based concurrency in Clojure.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Solving “Same Fringe” with Stream Ge nerators

[Dale Schumacher]

Published:
Solving “Same Fringe” with Stream Generators
http://www.dalnefre.com/wp/2010/06/solving-same-fringe-with-stream-generators

This article explores mutable and immutable streams on the way to
building a solution to the same-fringe problem based on incremental
fringe generation and incremental pair-wise stream comparison.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Composing Actors

[Dale Schumacher]

Groups of collaborating actors can be treated as a single actor with
the help of a serializer. My new article "Composing Actors"
(http://www.dalnefre.com/wp/2010/05/composing-actors/) describes a
generic transparent serializer for request-response services built
from actors.  Code samples are written in the pure-actor language
"Humus".

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] An actor-based environment for prototyping

[Dale Schumacher]

On Tue, May 11, 2010 at 3:16 AM, Michael FIG  wrote:
> Hi,
>
> Dale Schumacher  writes:
>
>> I'll have to give some thought to the larger-scale blackboard
>> mechanism.  It seems like it will take a few combined abstractions to
>> get there.
>
> I have a relatively simple model in mind that's probably a cheap
> ripoff of Prolog, LINDA, and term-rewriting systems.
>
> Let me know if you see merit in it:
>
> http://michael.fig.org/first.html

It looks very interesting, especially the example of locating "sine".
I'd like to learn more about this.  Do you have more information
online somewhere?

I've just launched a new blog to start publishing thoughts about the
design and implementation of reliable, scalable, massively-concurrent
actor-based systems.  If you're interested, you can subscribe at
http://www.dalnefre.com/

I'm aiming for a bi-weekly publication schedule and have just put up
the first post.  Comments are always welcome!

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] An actor-based environment for prototyping

[Dale Schumacher]

Yes.  I cited the reference with more bibliographic information, but
I actually downloaded the paper from the CSAIL link that John quoted.
I just wanted to be sure it was the right paper :-)

On Tue, May 11, 2010 at 9:20 AM, Alan Kay  wrote:
> But in this case, Dave's thesis would have been an LCS TR, so should be
> findable (and free) via the CSAIL "historic collections".
>
> Cheers,
>
> Alan
>
> 
> From: John Zabroski 
> To: Fundamentals of New Computing 
> Sent: Tue, May 11, 2010 6:42:50 AM
> Subject: Re: [fonc] An actor-based environment for prototyping
>
> http://publications.csail.mit.edu/lcs/specpub.php?id=773
>
> MIT has catalogued for free basically all their CS papers ever. -- Most
> Ph.D.'s require going through a clearinghouse to acquire and will set you
> back a chunk of monies.
>
> On Mon, May 10, 2010 at 11:37 PM, Dale Schumacher
>  wrote:
>>
>> Hi Alan,
>>
>> Thanks for the encouragement.  After a little searching I found
>> "Naming and Synchronization in a Decentralized Computer System", D. P.
>> Reed, 1978 [1].  Is that the paper you had in mind?  It looks
>> interesting, but I haven't had a chance to absorb it yet.
...
>> On Mon, May 10, 2010 at 7:28 AM, Alan Kay  wrote:
>> > Hi Dale et al.
>> >
>> > This sounds like a great project, and I'd like to find out more. (Have
>> > you
>> > looked at David Reed's 1978 MIT thesis on "distributed transactional
>> > object
>> > operating systems". In my opinion this was one of the very best next
>> > steps
>> > wrt objects (and it was influenced by Actors)).
...

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] An actor-based environment for prototyping

[Dale Schumacher]

d the other has
> characterizations of resources made available by the object. These bulletin
> boards are now all put into a LINDA-like matching space which does the
> (considerable) work of brokering. If one could come up with a great way to
> express the characterizations, then one would have removed one of the
> difficulties of scaling a message sending system, by removing the need to
> know the name or IDs of the receivers. In effect, one would not send
> messages, but only receive them.
>
> I think the big power here would be in finally getting more strongly to a
> more independent but highly practical way to provide semantics. (One of our
> favorite examples over the years is the question "if you don't know the name
> of the sine function, then how could you still invoke it?" ... APL has a
> very funny completely non-intuitive way of naming sine, etc.) This question
> is a very good question when you are trying to find powerful and useful
> resources on a large network 
>
> People who have taken the trouble to really understand and build Actor
> systems (like you!) are well set up to ponder and design and criticize one
> of the next logical qualitative leaps in object design and communication.
>
> Cheers,
>
> Alan
>
>
>
>
> [1] http://www.iam.unibe.ch/~ducasse/FreeBooks/SmalltalkHistoryHOPL.pdf
>
> 
> From: Dale Schumacher 
> To: Fundamentals of New Computing 
> Cc: Tristan Slominski ; Steven Teleki
> ; Dion Stewart ; John Heintz
> ; Ian Buchanan ; David West
> 
> Sent: Sun, May 9, 2010 4:38:20 PM
> Subject: [fonc] An actor-based environment for prototyping
>
> 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
>
>

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] An actor-based environment for prototyping

[Dale Schumacher]

On Sun, May 9, 2010 at 8:39 PM, Steve Dekorte  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

[fonc] An actor-based environment for prototyping

[Dale Schumacher]

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

Re: [fonc] Parameterized Word Tagging: Any interest?

[Dale Schumacher]

>> Adrian correctly pointed out that tagging is a time/space trade-off.  I did
>> demonstrate that different processors did perform differently by varying
>> tagging schemes.
>
> Yes, the current tagging scheme (with 0 as nil) seemed to perform best
> in your benchmark. But will it make a difference for more typical usage
> (such as idc compiling itself)?
>
>>  There is an interest in porting FoNC to smaller and larger
>> architectures.  If tagging schemes have limited benefit then why decide on 
>> any
>> tagging scheme?  There are valid reasons modern systems do not use high-bit
>> tags; I propose there are valid reasons to not hard-code a particular tagging
>> scheme into a flexible system like FoNC.

I'm new to this list, so pardon me if this is off-topic.

I'm working on a prototype micro-kernel (in C) that currently runs on
x86 but is ultimately targeted to run on an ARM processor as well.  On
the ARM, it is possible to include a shift into any data access opcode
without incurring additional execution cycles.  This creates a
different set of interesting trade-offs WRT performant type tagging.

I've experimented with a couple of different tagging schemes, some
intended to leave bits available for marking by the garbage collector.
 I've isolated all the tagging policies into a small set of macros.
This allowed me to switch from using 3-MSB to 2-LSB without changing
anything except the macro definitions.

The meta-question I have is: Is this an appropriate place to discuss
micro-kernel design issues in general, or is it VPRI/COLA specific?
It seems to me that we have a lot in common.  I have certainly enjoyed
learning from your published experiences.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc