Re: [fonc] Other interesting projects?

[Dan Amelang]

FYI, there are some "failed experiments" left over in this grammar.
Like the "[" exprs:xs "]" syntax for tuples and the whole idea of
tuple reductions (e.g., "∧[" expr:x "]).

Dan

On Sun, May 9, 2010 at 11:02 PM, Alessandro Warth  wrote:
> Hi Chris,
> Here's the nile parser that I wrote in OMeta/Squeak.
> Cheers,
> Alex
>
> On Sun, May 9, 2010 at 9:50 PM, Chris Double 
> wrote:
>>
>> 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
>
>
> ___
> 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] Other interesting projects?

[Dan Amelang]

Hi Chris, glad to have you around!

On Sun, May 9, 2010 at 9:50 PM, Chris Double  wrote:
> 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.

There is a preliminary version of the Nile grammar embedded in the
Ometa-based Nile-to-C compiler in my "nile" repository. I hope to
finalize (i.e., remove the ugly warts from) the Nile syntax in the
next couple weeks. In addition, Alex and I have been working on the
formal semantics of Nile. In the end, I hope to have both a small,
clean language and a small, clean compiler for others to play with. I
hope to pique your interest!

Dan

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

Re: [fonc] Other interesting projects?

[Alessandro Warth]

Hi Chris,

Here's the nile parser that I wrote in OMeta/Squeak.

Cheers,
Alex

On Sun, May 9, 2010 at 9:50 PM, Chris Double wrote:

> 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
>


NileParser.st
Description: Binary data


OffsideRuleParser.st
Description: Binary data
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Other interesting projects?

[Chris Double]

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

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

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

[Steve Dekorte]

> On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher
>  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

[Raul Murguia]

Congrats on sticking with your work Dale.  I'm impressed.


On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher
 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

[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] Fonc on Mac Snow Leopard?

[Jakob Praher]

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 
>> *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

Re: [fonc] Fonc on Mac Snow Leopard?

[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 
> *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 
>> *To:* Fundamentals of New Computing 
>> *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 excit

Re: [fonc] Fonc on Mac Snow Leopard?

[BGB]

yep.

seems an interesting way to do things, as then the emphasis can be kept on the 
design rather than on the implementation.

in general, I agree. we don't need "one true app X" or "one true implementation 
Y". there are already enough of these...

it is better then if technology can be kept open, with documented designs and 
modular implementations, such that even with a potentially large project one 
can still pursue better designs, cleaner and better implementation strategies, 
experiment with alternative ways of doing things, ...

so, if one wants to try something, they can write a new part and test it, and 
throw away parts later that don't work out so well.


I have tried this in the context of my efforts as well, although there is still 
a lot of emphasis on making everything work and be usable, and in many cases 
things have "settled" and become difficult to change.


this has led some to me implementing parts in ways which not everyone has 
agreed with, for example, I chose a textual assembler rather than using a 
binary-API for the assembler, or micro-crafting machine-code fragments in the 
codegen. however, as I see it, this really doesn't matter so much, and the 
textual assembler is easier to use and more general purpose (although if really 
needed, one can gain around a 5x speedup by bypassing the ASM preprocessor and 
parser and direct-driving the assembler internals). but, really, for most 
things, how likely is this to matter?...

as I see it, one can optimize things, but I tend to somewhat dislike optimizing 
things in ways which compromise the usability of their external interface.

I say this after having just gained a 40x speedup (for larger inputs) in a tool 
based on my C compiler, based on a few optimization tricks: copying over some 
code (from elsewhere in the project) which uses a tree-structure for the 
metadata database (vs linear lookups), and making use of hash-tables in a few 
places (to shortcut a few more linear searches).

nevermind the core of my compiler is still built around XML processing... as I 
see it, the merits are worth the costs...

I also have an x86 interpreter, with many core parts (such as the instruction 
decoder) based on string-processing, but it performs within 70x of native, so 
it is good enough... (many other interpreters are faster, but most other 
interpreters don't have to deal with segmentation or address-translation 
either, and this eats up a bit more of the time...).

I guess I am also odd in that I write most of my interpreters in plain C 
(typically not ASM), and use JIT and SMC more as a tool to opening up some 
doors, and not simply in some attempt to optimize things (although it can be 
used for this as well).

as I see it, the big thing in optimizing is not how to make doing an operation 
X times faster, but rather often how to not do it in the first place...


I guess a bit of a difference though is that I end up doing a lot of cloning, 
where I see designs elsewhere, and then implement my own version.


granted, there may often be a lot of variance between my implementation of 
something and the implied implementation of the thing.

like, me remembering a while ago when I ended up pointing out my BGBScript 
implementation to someone, and them being confused by a lot of what was being 
dumped out on the screen (mostly internal messages intended for debugging). a 
lot of the information was coming back using Scheme-style value formatting, 
since this is what my typesystem largely uses internally.

"x=[1,2,3];"
=>
"(set! x (array 1 2 3))"
"#(1 2 3)"
...

well, along with some messages showing the results of attempting to "reduce" 
expressions, showing a disassembly of the internal bytecode, ...

bytecode (written in a slightly different style): "mark push_1 push_2 push_3 
array dup store(x) ret".


note that a lot of stuff also uses a signature system, basically composed of 
strings with sequences of characters used to encode various value types, 
references into the metadata database, ...

(if anyone has seen the internals of the Java ".class" fileformat and the IA64 
ABI, this is a big part of the system, but there are many other details...).


  - Original Message - 
  From: Alan Kay 
  To: Fundamentals of New Computing 
  Sent: Saturday, May 08, 2010 9:03 AM
  Subject: Re: [fonc] Fonc on Mac Snow Leopard?


  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


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

Re: [fonc] Other interesting projects?

[Alan Kay]

Hi Murat,

My friend Joe Goguen's work has had a long time influence on my thinking, and I 
miss him quite a bit. 

OBJ has many really important ideas in it (and Maude is a reflection of Joe's 
seminal ideas over the years). I thought quite a bit about the tradeoffs with 
term-rewriting when I was writing the STEPS proposal (and there are references 
to this in the proposa), but decided in the end that it would be a good idea to 
see if there could be something a little more aimed at the intent of STEPS, 
since this was going to be a start from scratch set of designs.

Io is nice, but not as much in the spirit of STEPS as OBJ is.

Cheers,

Alan





From: Murat Girgin 
To: Fundamentals of New Computing 
Sent: Sun, May 9, 2010 11:54:32 AM
Subject: Re: [fonc] Other interesting projects?

A couple more projects to consider:

- OBJ family languages (mainly Maude and CafeOBJ but there are others):  I 
believe John Zabrowski brought these up before.   Especially Maude's 
"executable specification" concept sounds similar to "active mathematics" 
concept I've read in 2009 report.   There might be other interesting spec 
languages as well.

- Steve Dekorte's Io language: Really small, prototype based, 
Self/Smalltalk-like language with simple message-passing semantics.


Of course perf is a concern for both.

Thanks, Murat


On Sun, May 9, 2010 at 9:59 AM, Alan Kay  wrote:

Hi Dominikus,
>
>It's not a challenge but an invitation. It should be easy enough to do and it 
>would allow some nice cross experimentation. 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)).
>
>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. This would make for both nice demos, good 
>benchmarks, a more OS independent version of Factor, and a fair amount of 
>insight about the semantic and pragmatic tradeoffs in Factor.
>
>Another target that would be fun and enlightening
> here would be Erlang. (This would be a nice target for the Lively Kernel 
> stuff also)
>
>All of this would contribute greatly to "deep thoughts" about how the real 
>grounding of STEPS should be approached.
>
>Cheers,
>
>Alan
>
>
>
>
>
>

 From: Dominikus Herzberg 
>
>To: Fundamentals of New Computing 
>Sent: Sun, May 9, 2010 9:46:17 AM
>
>Subject: Re: [fonc] Other interesting projects?
>
>
>>Dear Alan,
>
>
>there already is a PEG parser in Factor, which is influenced by OMeta. The 
>parser is implemented by Chris Double, see
>
>
>http://www.bluishcoder.co.nz/2008/04/factor-parsing-dsl.html
>http://docs.factorcode.org/content/vocab-peg.html
>
>
>And yes: I can imagine something simpler and more comprehensive than Factor as 
>a foundation, but it would be quite close. One can reduce the foundation of 
>concatenative languages to a bare minimum (the mythical single-page 
>specification) including a sound mechanism for refinement and abstraction. 
>Right now I'm in the process of doing exactly this.
>
>
>I would be happy to see the Factor community accept your challenge! 
>
>
>Cheers,
>
>
>Dominikus
>
>
>2010/5/9 Alan Kay 
>
>One way to make progress here (and is a good "five finger exercise" for people 
>who are interesting in learning) would be for someone (or several) from this 
>list doing a bootstrap of OMeta to Factor. This should be quite easy from any 
>of the current versions of OMeta, including the JS version that Alex did for 
>UCLA students. I think we would make the time to give a little advice on this 
>if needed.
>>
>>This would give the list a way to make many different languages whose 
>>semantics would be grounded in Factor. One test that would reveal a lot about 
>>Factor and the Factor approach, would be to use your Factor OMeta to 
>>implement Dan Amelang's Nile language and his Gezira graphics system written 
>>in it. Could you make it run fast enough within the Factor development tools? 
>>Or would you have to
>> devolve to using something like C? Could you get OMeta (etc) to really make 
>> use of the Factor compiler?
>>
>>There's a lot to like about Factor, but  Could you imagine something 
>>simpler better and more comprehensive than Factor as a foundation?
>>
>>Cheers,
>>
>>Alan
>>
>>
>>


From: Max OrHai 
>>To: Fundamentals of New Computing 
>>Sent: Sat, May 8, 2010 5:54:01 PM
>>Subject: Re: [fonc] Other interesting projects?
>>
>>
Thanks for asking. I don't really have much first hand experience here 
(which is why I asked in the first place), and that phrase doesn't 
immediately ring a bell.
>>
>>
>>Factor has reflection, continuations, optional typing, and meta-programming 
>>features. It supports funct

Re: [fonc] Other interesting projects?

[Murat Girgin]

A couple more projects to consider:

- OBJ family languages (mainly Maude and
CafeOBJbut there are others):  I
believe John Zabrowski brought these up before.
Especially Maude's "executable specification" concept sounds similar to
"active mathematics" concept I've read in 2009 report.   There might be
other interesting spec languages as well.

- Steve Dekorte's Io language : Really small,
prototype based, Self/Smalltalk-like language with simple message-passing
semantics.

Of course perf is a concern for both.

Thanks, Murat

On Sun, May 9, 2010 at 9:59 AM, Alan Kay  wrote:

> Hi Dominikus,
>
> It's not a challenge but an invitation. It should be easy enough to do and
> it would allow some nice cross experimentation. 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)).
>
> 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. This would make for both nice demos, good
> benchmarks, a more OS independent version of Factor, and a fair amount of
> insight about the semantic and pragmatic tradeoffs in Factor.
>
> Another target that would be fun and enlightening here would be Erlang.
> (This would be a nice target for the Lively Kernel stuff also)
>
> All of this would contribute greatly to "deep thoughts" about how the real
> grounding of STEPS should be approached.
>
> Cheers,
>
> Alan
>
>
> --
> *From:* Dominikus Herzberg 
>
> *To:* Fundamentals of New Computing 
> *Sent:* Sun, May 9, 2010 9:46:17 AM
>
> *Subject:* Re: [fonc] Other interesting projects?
>
> Dear Alan,
>
> there already is a PEG parser in Factor, which is influenced by OMeta. The
> parser is implemented by Chris Double, see
>
> http://www.bluishcoder.co.nz/2008/04/factor-parsing-dsl.html
>  
> http://docs.factorcode.org/content/vocab-peg.html
>
> And yes: I can imagine
> something simpler and more comprehensive than Factor as a foundation, but it
> would be quite close. One can reduce the foundation of concatenative
> languages to a bare minimum (the mythical single-page specification)
> including a sound mechanism for refinement and abstraction. Right now I'm in
> the process of doing exactly this.
>
> I would be happy to see the Factor community accept your challenge!
>
> Cheers,
>
> Dominikus
>
> 2010/5/9 Alan Kay 
>
>> One way to make progress here (and is a good "five finger exercise" for
>> people who are interesting in learning) would be for someone (or several)
>> from this list doing a bootstrap of OMeta to Factor. This should be quite
>> easy from any of the current versions of OMeta, including the JS version
>> that Alex did for UCLA students. I think we would make the time to give a
>> little advice on this if needed.
>>
>> This would give the list a way to make many different languages whose
>> semantics would be grounded in Factor. One test that would reveal a lot
>> about Factor and the Factor approach, would be to use your Factor OMeta to
>> implement Dan Amelang's Nile language and his Gezira graphics system written
>> in it. Could you make it run fast enough within the Factor development
>> tools? Or would you have to devolve to using something like C? Could you get
>> OMeta (etc) to really make use of the Factor compiler?
>>
>> There's a lot to like about Factor, but  Could you imagine something
>> simpler better and more comprehensive than Factor as a foundation?
>>
>> Cheers,
>>
>> Alan
>>
>> --
>> *From:* Max OrHai 
>> *To:* Fundamentals of New Computing 
>> *Sent:* Sat, May 8, 2010 5:54:01 PM
>> *Subject:* Re: [fonc] Other interesting projects?
>>
>> Thanks for asking. I don't really have much first hand experience here
>> (which is why I asked in the first place), and that phrase doesn't
>> immediately ring a bell.
>>
>> Factor has reflection, continuations, optional typing, and
>> meta-programming features. It supports functional, OO, and dataflow
>> programming; it can do concurrency in a few different ways, it has excellent
>> support for lazy lists and PEGs, and yes it even has named variables if one
>> really wants them. The full image (including IDE and some quite featureful
>> libraries like a relational DB, XML parser, and http server/client) is about
>> 30K lines of code I believe, and unlike Squeak it's quite easy to trim it
>> down for release as a standalone application if so desired.
>>
>> I don't use it everyday, but I haven't yet found anything enormously
>> problematic about it. I'd be happy to admit that my perspective is proba

Re: [fonc] Other interesting projects?

[Alan Kay]

Hi Dominikus,

It's not a challenge but an invitation. It should be easy enough to do and it 
would allow some nice cross experimentation. 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)).

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. This would make for both nice demos, good 
benchmarks, a more OS independent version of Factor, and a fair amount of 
insight about the semantic and pragmatic tradeoffs in Factor.

Another target that would be fun and enlightening here would be Erlang. (This 
would be a nice target for the Lively Kernel stuff also)

All of this would contribute greatly to "deep thoughts" about how the real 
grounding of STEPS should be approached.

Cheers,

Alan






From: Dominikus Herzberg 
To: Fundamentals of New Computing 
Sent: Sun, May 9, 2010 9:46:17 AM
Subject: Re: [fonc] Other interesting projects?

Dear Alan,

there already is a PEG parser in Factor, which is influenced by OMeta. The 
parser is implemented by Chris Double, see

http://www.bluishcoder.co.nz/2008/04/factor-parsing-dsl.html
http://docs.factorcode.org/content/vocab-peg.html

And yes: I can imagine something simpler and more comprehensive than Factor as 
a foundation, but it would be quite close. One can reduce the foundation of 
concatenative languages to a bare minimum (the mythical single-page 
specification) including a sound mechanism for refinement and abstraction. 
Right now I'm in the process of doing exactly this.

I would be happy to see the Factor community accept your challenge! 

Cheers,

Dominikus


2010/5/9 Alan Kay 

One way to make progress here (and is a good "five finger exercise" for people 
who are interesting in learning) would be for someone (or several) from this 
list doing a bootstrap of OMeta to Factor. This should be quite easy from any 
of the current versions of OMeta, including the JS version that Alex did for 
UCLA students. I think we would make the time to give a little advice on this 
if needed.
>
>This would give the list a way to make many different languages whose 
>semantics would be grounded in Factor. One test that would reveal a lot about 
>Factor and the Factor approach, would be to use your Factor OMeta to implement 
>Dan Amelang's Nile language and his Gezira graphics system written in it. 
>Could you make it run fast enough within the Factor development tools? Or 
>would you have to
> devolve to using something like C? Could you get OMeta (etc) to really make 
> use of the Factor compiler?
>
>There's a lot to like about Factor, but  Could you imagine something 
>simpler better and more comprehensive than Factor as a foundation?
>
>Cheers,
>
>Alan
>
>
>
>

From: Max OrHai 
>To: Fundamentals of New Computing 
>Sent: Sat, May 8, 2010 5:54:01 PM
>Subject: Re: [fonc] Other interesting projects?
>
>
>>Thanks for asking. I don't really have much first hand experience here (which 
>>is why I asked in the first place), and that phrase doesn't immediately ring 
>>a bell.
>
>
>Factor has reflection, continuations, optional typing, and meta-programming 
>features. It supports functional, OO, and dataflow programming; it can do 
>concurrency in a few different ways, it has excellent support for lazy lists 
>and PEGs, and yes it even has named variables if one really wants them. The 
>full image (including IDE and some quite featureful libraries like a 
>relational DB, XML parser, and http server/client) is about 30K lines of code 
>I believe, and unlike Squeak it's quite easy to trim it down for release as a 
>standalone application if so desired.
>
>
>
>I don't use it everyday, but I haven't yet found anything enormously 
>problematic about it. I'd be happy to admit that my perspective is probably 
>narrower than it could be, though: I'll defer to the more experienced.
>
>
>- Max
>
>
>On Sat, May 8, 2010 at 5:03 PM, Alan Kay  wrote:
>
>Hi Max,
>>
>>Well, what properties do you think might be "enormously problematic" with 
>>stack languages ?
>>
>>Cheers,
>>
>>Alan
>>
>>
>>

From: Max OrHai 

>>To: Fundamentals of New Computing 
>>Sent: Sat, May 8, 2010 4:49:14 PM
>>Subject: [fonc] Other interesting projects?
>>
>>
Hello all.
>>
>>I'm an undergraduate student (formerly CS, now math) and I've been
>>reading this list since the beginning of the STEPS project: this is
>>one of the most promising things I'm aware of going on in  computing

>>right now. (I'm a big fan of Haskell's rising popularity, although
>>it's more of a case of gradual improvement, building on the traditions
>>of Lisp and ML etc..) Still, I'm puzzled how I've never seen anyone

Re: [fonc] Fonc on Mac Snow Leopard?

[Pascal J. Bourguignon]

On 2010/05/09, at 10:21 , Christopher Bratlien wrote:


Just dipping my toe into this conversation.

I think it's cool that Javascript has protoype inheritence of Self,  
and Lively Kernel gives Javascript its Morphic back. Also, LK is  
spawning ideas such as Lively Fabrik http://www.lively-kernel.org/repository/lively-wiki/Fabrik.xhtml


I would love to interact with a visual (and lively, steppable) model  
of the metacircular evaluator from Scheme/SICP done in Javascript.  
Page 13 of the Lisp 1.5

allows a reader to contemplate evaluating:

(LAMBDA (X Y) (CONS (CAR X) Y)); ((A B) (C D))

Has somebody already modeled this exercise visually? I would like to  
see a running, in my face, in the browser, model of this.




There's the Alligator-and-egg stuff:

http://visual-languages.blogspot.com/2009/07/alligator-eggs-revisited.html
http://visual-languages.blogspot.com/2009/07/alligator-eggs-for-last-time.html
http://worrydream.com/AlligatorEggs/

--
__Pascal Bourguignon__
http://www.informatimago.com




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

Re: [fonc] Other interesting projects?

[Dominikus Herzberg]

Dear Alan,

there already is a PEG parser in Factor, which is influenced by OMeta. The
parser is implemented by Chris Double, see

http://www.bluishcoder.co.nz/2008/04/factor-parsing-dsl.html

http://docs.factorcode.org/content/vocab-peg.html

And yes: I can imagine
something simpler and more comprehensive than Factor as a foundation, but it
would be quite close. One can reduce the foundation of concatenative
languages to a bare minimum (the mythical single-page specification)
including a sound mechanism for refinement and abstraction. Right now I'm in
the process of doing exactly this.

I would be happy to see the Factor community accept your challenge!

Cheers,

Dominikus

2010/5/9 Alan Kay 

> One way to make progress here (and is a good "five finger exercise" for
> people who are interesting in learning) would be for someone (or several)
> from this list doing a bootstrap of OMeta to Factor. This should be quite
> easy from any of the current versions of OMeta, including the JS version
> that Alex did for UCLA students. I think we would make the time to give a
> little advice on this if needed.
>
> This would give the list a way to make many different languages whose
> semantics would be grounded in Factor. One test that would reveal a lot
> about Factor and the Factor approach, would be to use your Factor OMeta to
> implement Dan Amelang's Nile language and his Gezira graphics system written
> in it. Could you make it run fast enough within the Factor development
> tools? Or would you have to devolve to using something like C? Could you get
> OMeta (etc) to really make use of the Factor compiler?
>
> There's a lot to like about Factor, but  Could you imagine something
> simpler better and more comprehensive than Factor as a foundation?
>
> Cheers,
>
> Alan
>
> --
> *From:* Max OrHai 
> *To:* Fundamentals of New Computing 
> *Sent:* Sat, May 8, 2010 5:54:01 PM
> *Subject:* Re: [fonc] Other interesting projects?
>
> Thanks for asking. I don't really have much first hand experience here
> (which is why I asked in the first place), and that phrase doesn't
> immediately ring a bell.
>
> Factor has reflection, continuations, optional typing, and meta-programming
> features. It supports functional, OO, and dataflow programming; it can do
> concurrency in a few different ways, it has excellent support for lazy lists
> and PEGs, and yes it even has named variables if one really wants them. The
> full image (including IDE and some quite featureful libraries like a
> relational DB, XML parser, and http server/client) is about 30K lines of
> code I believe, and unlike Squeak it's quite easy to trim it down for
> release as a standalone application if so desired.
>
> I don't use it everyday, but I haven't yet found anything enormously
> problematic about it. I'd be happy to admit that my perspective is probably
> narrower than it could be, though: I'll defer to the more experienced.
>
> - Max
>
> On Sat, May 8, 2010 at 5:03 PM, Alan Kay  wrote:
>
>> Hi Max,
>>
>> Well, what properties do you think might be "enormously problematic" with
>> stack languages ?
>>
>> Cheers,
>>
>> Alan
>>
>> --
>> *From:* Max OrHai 
>>
>> *To:* Fundamentals of New Computing 
>> *Sent:* Sat, May 8, 2010 4:49:14 PM
>> *Subject:* [fonc] Other interesting projects?
>>
>> Hello all.
>>
>> I'm an undergraduate student (formerly CS, now math) and I've been
>> reading this list since the beginning of the STEPS project: this is
>> one of the most promising things I'm aware of going on in  computing
>> right now. (I'm a big fan of Haskell's rising popularity, although
>> it's more of a case of gradual improvement, building on the traditions
>> of Lisp and ML etc..) Still, I'm puzzled how I've never seen anyone
>> here mention the "other" famously compact, dynamic, self-contained
>> system: Forth. There's been a recent resurgence of interest in stack
>> languages, mostly around Slava Pestov's Factor
>> (http://factorcode.org), which seems to me to share many themes with
>> the STEPS/FoNC work, although it's certainly more pragmatic in
>> orientation and less earth-shaking. Does anyone here have any
>> experience with Forth or Factor that they'd care to comment on?
>>
>> Here's a Google Tech Talks video of Pestov introducing Factor:
>> http://www.youtube.com/watch?v=f_0QlhYlS8g
>>
>> - Max OrHai
>>
>> ___
>> 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 mailing list
fonc@vpri.or

Re: [fonc] Other interesting projects?

[BGB]

this reminds me of a number of years ago...

I had my own custom Scheme implementation, but this effort imploded due to a 
number of factors (in large part, the code had become unworkable and 
unmaintainable...). but, hell, this was my first non-trivial forray into 
interpreter and compiler technology (it had a compiler, as well as an 
interpreter, but this was several years before I started messing with JIT and 
SMC). (this was around 2001-2003).


but, after its demise, I tried at that point developing a new scripting 
language, derived primarily from PostScript...

attempts to actually use it: "OMG this is horrible...".
yes, it was terribly awkward to write in, and worse yet was trying to make 
sense of it again later;
seemingly, there was no way to format it by which to address this issue.


however, the later development was to build another language on top of it, in 
my case a language inspired largely by JavaScript (I called it BGBScript). 
(relevant later: this one used XML AST's, also note that this is the "1st 
incarnation", or also BS/0).

soon enough, I ended up switching from using blocks to using jumps, since 
blocks were very problematic WRT implementing many constructions: goto, break, 
continue, ... jumps were, however, a much cleaner strategy for these.


this language was used for a while, but was rewritten in 2006 (BS/1, or 2nd 
incarnation), but this incarnation was short-lived (its own success was its 
downfall). this was also the first time I started making use of JIT. it had 
re-incorporated many parts of the original Scheme implementation, such as the 
MM/GC, and at the AST level there is much overlap (the AST's are S-Expressions, 
and many of the operations have the same names and syntax as in Scheme...).

in 2007, I started on a C compiler, which was based on a heavily mutilated 
version of the second incarnation of the prior language, which kept to a 
similar architecture. however, things deformed steadily (the stack machine used 
as the IL has been made horrible due to technical limitations in my original 
implementation, mostly WRT use of the C ABI and how I was managing the stack).

many of the C compiler components have been rewritten several times, including 
both the upper end (which migrated to XML-based ASTs, originally derived from 
BS/0), and the lower-end has been in continuous internal flux (although the 
original IL remains...).

in 2008/2009, I started trying to add Java and C# support to this compiler, but 
this turned into a mess (neither my C upper-end nor my lower-end could deal 
with all of the issues which came up).

this was motivated mostly by the thought that Java and C# could allow faster 
compilers and work better as a scripting language than C.

basically, C is too slow to compile, and generally too awkward and error-prone 
to use for many scripting tasks (such as taking arbitrary fragments and 
eval'ing them). although the C implementation does have a few hacks to 
facilitate faster compilation (it is possible to use a pp-directive to turn off 
the need for headers, ...).


several efforts had also been made to migrate to a more "proper" compiler 
architecture: an AST-based model (where a tree-model is used all along), with 
the lower-end being driven by SSA (and a Three-Address-Code style notation). 
however, such efforts have failed (although many SSA-like elements now exist 
within the lower-end).

I have since come to the opinion that I am better off sticking to stack 
machines for the IL (I understand them and they work), although there is some 
hope for a newer (and less horrid) IL (a cleaner stack model, with less 
x86'isms and ugly hacks). however, I have not settled on a design or started 
implementation.


far more recently, several things lead me to re-start my BGBScript effort (over 
the past several months), which is now on its 3rd incarnation (based mostly on 
a rewrite of the 2nd incarnation to use a different MM/GC system, namely the 
one used in my C effort, which is a descendant of the same GC as used in the 
1st incarnation).

the IL is mostly the same as the one used in the 2nd impl (which was also the 
original form of the IL used by my C compiler, although they have since 
diverged somewhat...).

I may call this BS/2 (but, BS/2 was the name of a died-off effort between BS/0 
and BS/1 which had been mostly based on Java...).


newer features are that I am putting a lot of effort into making the thing 
closer to ECMAScript (trying to get the thing more standards-conformant, in my 
case going off of the ES5 spec), but have also been incorporating some features 
from ActionScript as well (as well as some more subtle features inspired by 
Java and C#...).

OTOH, I have also basically largely bridged the gap with C (it can 
transparently make use of much of the C toplevel, and directly call C 
functions, ...). note that the mechanisms are mostly automatic, so there is no 
need to manually wrap or declare much of anything.

however, it d

Re: [fonc] Other interesting projects?

[Alan Kay]

One way to make progress here (and is a good "five finger exercise" for people 
who are interesting in learning) would be for someone (or several) from this 
list doing a bootstrap of OMeta to Factor. This should be quite easy from any 
of the current versions of OMeta, including the JS version that Alex did for 
UCLA students. I think we would make the time to give a little advice on this 
if needed.

This would give the list a way to make many different languages whose semantics 
would be grounded in Factor. One test that would reveal a lot about Factor and 
the Factor approach, would be to use your Factor OMeta to implement Dan 
Amelang's Nile language and his Gezira graphics system written in it. Could you 
make it run fast enough within the Factor development tools? Or would you have 
to devolve to using something like C? Could you get OMeta (etc) to really make 
use of the Factor compiler?

There's a lot to like about Factor, but  Could you imagine something 
simpler better and more comprehensive than Factor as a foundation?

Cheers,

Alan





From: Max OrHai 
To: Fundamentals of New Computing 
Sent: Sat, May 8, 2010 5:54:01 PM
Subject: Re: [fonc] Other interesting projects?

Thanks for asking. I don't really have much first hand experience here (which 
is why I asked in the first place), and that phrase doesn't immediately ring a 
bell.

Factor has reflection, continuations, optional typing, and meta-programming 
features. It supports functional, OO, and dataflow programming; it can do 
concurrency in a few different ways, it has excellent support for lazy lists 
and PEGs, and yes it even has named variables if one really wants them. The 
full image (including IDE and some quite featureful libraries like a relational 
DB, XML parser, and http server/client) is about 30K lines of code I believe, 
and unlike Squeak it's quite easy to trim it down for release as a standalone 
application if so desired.


I don't use it everyday, but I haven't yet found anything enormously 
problematic about it. I'd be happy to admit that my perspective is probably 
narrower than it could be, though: I'll defer to the more experienced.

- Max


On Sat, May 8, 2010 at 5:03 PM, Alan Kay  wrote:

Hi Max,
>
>Well, what properties do you think might be "enormously problematic" with 
>stack languages ?
>
>Cheers,
>
>Alan
>
>
>

From: Max OrHai 
>
>To: Fundamentals of New Computing 
>Sent: Sat, May 8, 2010 4:49:14 PM
>Subject: [fonc] Other interesting projects?
>
>
>>Hello all.
>
>I'm an undergraduate student (formerly CS, now math) and I've been
>reading this list since the beginning of the STEPS project: this is
>one of the most promising things I'm aware of going on in  computing
>>right now. (I'm a big fan of Haskell's rising popularity, although
>it's more of a case of gradual improvement, building on the traditions
>of Lisp and ML etc..) Still, I'm puzzled how I've never seen anyone
>>here mention the "other" famously compact, dynamic, self-contained
>system: Forth. There's been a recent resurgence of interest in stack
>languages, mostly around Slava Pestov's Factor
>(http://factorcode.org), which seems to me to share many themes with
>>the STEPS/FoNC work, although it's certainly more pragmatic in
>orientation and less earth-shaking. Does anyone here have any
>experience with Forth or Factor that they'd care to
> comment on?
>
>Here's a Google Tech Talks video of Pestov introducing Factor:
>http://www.youtube.com/watch?v=f_0QlhYlS8g
>
>- Max OrHai
>
>
>___
>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] Other interesting projects?

[Dominikus Herzberg]

Hello Max!

almost exactly two years ago, I asked Ian Piumarta from VPRI a similar
question on the S3 (Self-Sustaining Systems) workshop in Potsdam, Germany:
Aren't Forth and especially Factor interesting candidates for FONC? He
definitely agreed, but admitted not having so much experience with
stack-based or concatenative languages.

Today, two years later, I would say that Slava Pestov and his development
team on Factor have convincingly demonstrated that stack-based and
concatenative languages are the most promising candidates supporting the
STEPS approach. Since I'm also doing research on concatenative languages, I
might be biased. However, my argumentation is a bit different. For me,
concatenative languages distill the techniques used for almost four decades
in building the most complex systems mankind has ever built:
telecommunication systems and the Internet. These kind of systems are
message-based, scale extremely well, they are roboust, concise (see the
TCP/IP example discussed elsewhere on this mailing list), flexible and
extremely adaptable. That's why I'm a bit surprised that the VPRI teams does
not seem to pay so much attention to Forth, Factor and related languages.

Gruß,

Dominikus

2010/5/9 Max OrHai 

> Hello all.
>
> I'm an undergraduate student (formerly CS, now math) and I've been
> reading this list since the beginning of the STEPS project: this is
> one of the most promising things I'm aware of going on in  computing
> right now. (I'm a big fan of Haskell's rising popularity, although
> it's more of a case of gradual improvement, building on the traditions
> of Lisp and ML etc..) Still, I'm puzzled how I've never seen anyone
> here mention the "other" famously compact, dynamic, self-contained
> system: Forth. There's been a recent resurgence of interest in stack
> languages, mostly around Slava Pestov's Factor
> (http://factorcode.org), which seems to me to share many themes with
> the STEPS/FoNC work, although it's certainly more pragmatic in
> orientation and less earth-shaking. Does anyone here have any
> experience with Forth or Factor that they'd care to comment on?
>
> Here's a Google Tech Talks video of Pestov introducing Factor:
> http://www.youtube.com/watch?v=f_0QlhYlS8g
>
> - Max OrHai
>
> ___
> 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] Fonc on Mac Snow Leopard?

[Jakob Praher]

Dear Alan,

thank you for your reply. Below you find my humble propositions.

First of all I would like to stress that I owe you and the work done by
VPRI already some very important view points (which are worth some IQ
points), so I do not intend to aim at impairing the achievements of the
VPRI. I also think your public controversy against
shortsighted/established axioms of (commercial) computer science also
boosts a climate of innovation.

Am 08.05.10 22:32, schrieb Alan Kay:
> In a subsequent email to the one below I mentioned some of the things
> that interested parties could do to participate.
Ok. I have to admit that this was not pure ignorance but also due to the
fact that some mails of this list hit the junk folder. I will read them.
>
> Let me ask you what kinds of projects do you think are done best by
> "community oriented styles of innovation", and just how much actual
> innovation happens (and has happened in the last 30 years)?
I am not sure I am hitting the nail on the head, but I when I wrote
"community oriented sytles of innovation" I meant that not only the
outcome of innovation should be open, but also its process. It did not
impose that this means a lot of people, it might still be a small group
of interested and devoted people.

Tools are (still) not good for visualizing dialectic discourses. Putting
challenges (challenges are not merely big questsions but constrainted
pieces of the puzzle which also guides the ) not only published answers.
Moderated reading lists and discussion of these materials I think also
raises the level of interested lurkers.

This is something that is not only the duty of a group of bright people
like you but is surely as much a duty of participants like me. And
granted, further work sections in papers might be a way to hook up. And
sure often less is more in dicussions, since also individual thought
processes (which in the end is the atomic unit) need time.
>
> Or whether the Linux kernel or the Smalltalk kernel or etc., were done
> by a community? Even Eric Raymond admits that what really goes on even
> for moderately innovative stuff in "open source" is that there is a
> small dedicated group from 1 to usually less than 10 people who work
> hard together to make a kernel, and this then empowers many people to
> contribute using its powers and styles.
IMHO one thing is that Unix and Smalltalk where kids of a different time
and both were also done in closed labs. (Xerox PARC and Bell labs) This
brings me to a second aspect, that of full time (funded) work - I could
imagine that if people are dislocated but have all their time for
pursuing a common goal this would work. Sure one would have to meet
occasionally. I think culture is not purely something that takes place
at certain locations/buildings/labs but it something that can also be
transported over the Net.

And let me stress that it is not a question of the amount of people - it
still be only 20 people - but it is a matter of transparency, right? And
if people like me join a list like this this means that there is a
potential from around the world.
> And the aims of STEPS are not "innovative" but "inventive". Increments
> on previous stuff are not barred, but what is required generally is
> careful design thinking. This is somewhat analogous to the difference
> between painting a picture or composing music and building a building.
Thank you for this distinction. If I understand you right is that to
invent you "create something new" and with innovate you imply "making
adaptions". Maybe it is also in a away that you are trying to define a
new way of painting - like impressionism vs expressionism? Otherwise I
guess that also the act of painting or composing reuses a lot of
existing. One interesting (underestimated) aspect of software is its
livelyness. I know that is not what you inteded in drawing an analogy
between software and these creative processes. I dislike them because
IMHO software is not DONE like a painting or a piece of music or a
finished building. There are dependencies though. For instance when
changing fundamental pieces of software you have to take care to still
be able to work with existing.
> So I would suggest simply reading all of the STEPS related documents,
> then pick some part that seems interesting (whether we are already
> working on it or not), and come up with an "idea memo" such as this
> one (http://www.vpri.org/pdf/m2009014_membrane.pdf) by Ted Kaehler.
> (Since you are interested in "innovation", it might be a good idea to
> look at the processes of some of the great inventors of our field --
> this is a technique that Ivan Sutherland (the inventor of computer
> graphics itself and much much more) used when working on hard
> projects.) We write quite a few of them, and post some of them on the
> website.
I will do so. I like the idea of an idea memo.
>
> One of the reasons we work this way is that brainstorming has proved
> to be very weak for difficult projects. But idea mem

Re: [fonc] Fonc on Mac Snow Leopard?

[Christopher Bratlien]

Just dipping my toe into this conversation.

I think it's cool that Javascript has protoype inheritence of Self, and
Lively Kernel gives Javascript its Morphic back. Also, LK is spawning ideas
such as Lively Fabrik
http://www.lively-kernel.org/repository/lively-wiki/Fabrik.xhtml

I would love to interact with a visual (and lively, steppable) model of the
metacircular evaluator from Scheme/SICP done in Javascript. Page 13 of the
Lisp 1.5
allows a reader to contemplate evaluating:

(LAMBDA (X Y) (CONS (CAR X) Y)); ((A B) (C D))

Has somebody already modeled this exercise visually? I would like to see a
running, in my face, in the browser, model of this.

Ok, I'm pulling my toe back out of the water now...

Best wishes,
Chris

On Sat, May 8, 2010 at 6:06 PM, Alan Kay  wrote:

> 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 
> *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  
> *To:* Fundamentals of New Computing  
> *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
>
>
> ___
> fonc mailing listf...@vpri.orghttp://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