[Pipet Users] Command Compilation in Piper: A Discourse

[Nicolas Chauvat]

> I'd like to comment on your use of "processor", "flag" and "filemane"
> type of nodes. For Overflow (PL), a Node is a Node and there's no such
> discrimination.

I read the page about command-compilation Jeff posted. My experience (with
Narval and other systems) is that "a Node is a Node" is nice in theory,
but becomes a problem when you want to enhance the user interface and
facilitate the writing of programs. If "processor", "flag" and "filename"
are different things of different types, used for different purposes, make
it so. Maybe they're all Nodes from a graph/network point of view, in
which case the solution would be to make them inherit from a common base
class. But if you don't put into your model the capacity to discriminate
between a string that is actually a flag and a string that is actually a
filename, you'll have troubles when you'll want to add things such as "put
all your nodes in the workspace and I'll help you link them, or tell me
what you want to do and I'll try to build a network that does it". Yes,
I'm trying to bring in my AI background :-)

To continue on the same topic, I've read all the docs I could find on the
Piper website and Wiki and have a couple comments regarding the relations
between Piper and Narval.

The Piper introduction and slides say that "Everything is a
component. Component have I/O. You can connect components I/O the same way
you use pipes in a shell. Components have a location."

For Narval I'd say "Everything is an element. Recipes are sequences of
steps linked by transitions. Recipes are elements. Steps have I/O with
prototypes and can be actions or transforms. Actions and transforms I/O
are elements. Transitions have conditions on elements. Plans are
executable instances of recipes and are elements."

Similar isn't it? Yes and No. I'll focus on the differences.

Narval manipulates high-level data: e-mails, calendar events, web pages,
search results, tasks and projects, etc. whereas, if I understand
correctly, Piper currently pipes data streams from a process to another
and does not really care for the meaning of the data that's exchanged and
Piper has higher speed requirements for data transfer. That's a sufficient
difference to legitimate many design decision differences between the two.

Narval uses typing extensively. Elements are trees currently represented
in XML. XPath is used to express conditions on those trees. Those
conditions are used in the step prototypes and in the transitions, as in
"to run, this action needs an email Element such that the following xpath
is true: email/headers[begins-with(string(subject),'[Pipet Users]'))."

This provides a way to express simply a lot of constraints later used to
verify things and predict problems before they happen (both as a compiler
would do for source code and as a language like Eiffel does with pre/post
conditions at run-time).

Second, transitions let you control the data flow in your network/graph.
With the added capability to map an action on a sequence of input
elements, you get most of what the usual branch/loop of other languages
would give you.

Using trees as a basic structure and xpath to express contraints and
conditions is a true benefit in our case and let us build other features
(planning, etc.). We couldn't find a simpler way to do it.

I've more to say about Narval, but could this experience be of any use to
Piper? What do you guys think?

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)