On Fri, 27 Oct 2006 15:49:22 +0800, Manuel Simoni wrote:
> > That all sounds entirely workable, but has the practical problem that
> > you have to construct a new programming language based on an unusual
> > programming model.
>
> I'm ready to leave the current models behind, and a lot of
> Gedankenexperimente showed me that dynamic (re)evaluation is soo
> nice... Well, actually I started to design an interpreter for your
> abs() Bicicleta example...
It's very exciting to have someone else so interested!
> I've rewritten it in a Lispy syntax, and changed it a bit:
>
> (= abs
> (= x 3)
> (if (> x 0)
> (= result x)
> (= result (- 0 x))))
In the formalism I've been thinking of, that would be something like
(= abs
(= x 3)
(= result (if
(= condition (> x 0))
(= then x)
(= else (- 0 x)))))
Although it's still glossing over the distinction between abs and
abs.result, which I've been expressing with {} vs () (i.e. abs{x = 4}
is a structure with fields x and result; abs(x = 4) is rewritten as
abs{x = 4}.result.)
Were you able to read the Python code explaining all that? Maybe I
should rewrite it in some more concise language if the Python is too
hard to read.
I don't think I entirely understand the evaluation semantics you have
in mind. Is "if" a special form?
> >From this, a couple of things occurred to me... I see this as graph
> reduction/production:
>
> - Code is always executing in the context of a node.
> - There's an implicit root node at the top level, that's the first
> context for the program.
> - Whenever = is encountered, we move the context node one level down
> (e.g. at (= abs ...) we actually create a new edge from the root node
> to a new node, that then becomes the context node.)
> - However, like lexical scoping, we still need to access enclosing
> "environments" (= parent context nodes) from nested code.
Right. One of the tricky issues with scoping is that if you can
access "x" as above, that means you need to add all the names from
your lexical ancestors to your environment --- but unlike in Algols
and Scheme, those names may be inherited from somewhere else
altogether, which makes it a rather hard-to-read form of lexical
scoping, or even defined in some scope derived from the ancestor scope
you wrote them in, in which case the scoping is no longer even
lexical. The sigma-calculus avoids this by only adding the lexical
ancestors themselves to the environment, in the form of "self", and
you have to refer to everything else through them.
(The sigma-calculus in its original form also doesn't allow derived
nodes to add new methods/childnames, which is another way to avoid the
semi-dynamic-scoping issue, but I think that would be too
restrictive.)
The compromise I had in mind was to represent the names internally as
"someancestor.childname", but have an option to display only
"childname" when it was unique (i.e. when there was no possibility of
getting confused about which "childname" was meant).
> But in the above example, there's a slight logical problem: The =
> operator is used for two different purposes:
> a) (= abs ...) creates a new "abs"-labelled edge from the context and
> evaluates the remaining expressions in the new context
> b) (= x 3) creates a new "x"-labelled edge from the context and sets
> the target of the edge to the value 3.
>
> So, maybe a different operator is needed:
>
> (-> abs
> (= x 3)
> (if (> x 0)
> (= result x)
> (= result (- 0 x))))
Or you could just write it as
(= abs (
(= x 3)
...))
using another level of nesting to construct the new node, instead of
having = create both the edge and the node.
> Further thoughts:
>
> - I think you should go for the multi-valued fields, and have all
> operations be "array"-aware.
I was thinking that each field would have exactly one value,
> - Wear the hair-shirt and be non-strict. Side-effects can probably be
> added later like in Haskell. I think that users will build a lot of
> transformation programs (e.g. address book to web page) and then use
> the results of such programs as "Lego blocks" for side effects (e.g.
> write the resulting HTML to file.)
Absolutely. You wouldn't be able to display the current value of each
field in the editor if the program depended on side-effects hidden
down in expressions --- reinvoking the expression might cause unwanted
side-effects.
> - A cool stunt to pull off would be to let the dynamic
> evaluation/update notification happen through feeds, with one of the
> many internet scale event notification technologies.
Yes, I think that's a great idea. I don't know what the
implementation order will be, though, since I think I'll need to make
Bicicleta really good for one thing before I make it reasonably good
for other things, and I don't know whether Atom feeds will be useful
in whatever that one thing is. (I'm thinking screensavers might be a
good first thing to try.)
> (I guess you're aware of IM2000, BTW? It's by the creator of qmail,
> "IM2000 is a project to design a new Internet mail infrastructure
> around the following concept: Mail storage is the sender's
> responsibility", http://del.icio.us/manuel/im2000)
Yeah, although I haven't read the whole proposal.
> Re Decentralized-Slashdot, I have to think about this longer, but
> that I don't have a spam problem on del.icio.us is already quite
> reassuring that such a system could work, and it (your write-up) is
> actually exactly my vision for the future of internet publishing.
Either we're smoking the same kind of crack, or we're onto something
:)
I have occasionally seen del.icio.us spam, but:
a) spam generally only starts to become a problem when a system has a
lot of users (and del only has 300k);
b) I think Joshua stuck some subtle anti-spam stuff in early on that
prevented certain people's updates from making it to the front page
or other people's inboxes.
> In my model, users never have to merge if they don't want to: the
> system stores all variants of a document separately (at each device),
> and when I look at my laptop I can see:
> that this document has title "foo" on my laptop, but title "bar" on my
> server, and title "quux" on my cellphone. The GUI would show me all
> three values, but on each device the "local" value would displayed in
> a preferred style.
>
> Now, of course, this just defers the merging problem. As a next step,
> Simple Sharing Extensions could be added, so we can show the user only
> the real conflicts. I just hope that the real conflicts between a
> user's devices are rather small, and when the devices are synced e.g.
> daily, quite manageable.
I imagine that you are correct.
