"Bazar" proposal

[Armin Rigo]

Hello Lee,

On Fri, 27 Oct 2000, Lee Salzman wrote:
> I would argue that Slate is even more simplistic than Bazar (making
> Bazar the intrinsicly richer of the two).

Due to this summer's moves of information on the Tunes web site I cannot
seem to find any documentation about Slate other than
http://slate.tunes.org/doc/semantics.html, which still discusses Slate in
message-passing style. The graph reduction aspect as you describe it makes
Bazar close to Slate, indeed, so I am sorry if I missed more recent docs
about Slate.

In the light of your comments, I would compare Slate and Bazar as follows
: Slate has a more general "named terminals" connection model, while
Bazar's is limited to "one-input-two-outputs" terminals. Reduction in
Bazar is performed by the "operator" nodes, which have no output
terminal. The way reduction is performed is defined by the operator in a
"non-well-founded" manner : the operator's operations are given as an
expression in the Bazar style too. Typically, you describe these
operations by writing a Lambda expression that performs as the operator
does. This is "non-well-founded" because you can describe all operators
like this, even "Lambda" itself. There is no atomic operator. This is
similar to Slate's idea that MO's have a MO themselves, and so on.

In the light of all this, Bazar can be seen as a special graph reduction
model, whose reduction functions are written "inside of" one special kind
of node, the "operator" nodes. As I understand your description, Slate is
very close, only more general.

Can you please point me to some recent docs and test-code of Slate ?

> As for message-passing, there is no set way to provide for this in
> Slate (as subject that me and Brian have grappled with a great deal),
> but OTOH, this allows for great flexibility for extending what exactly
> a message is by changing the objects that implement such. It doesn't
> necessarily seem that Bazar avoids these issues to me, though.

Yes, you are right. In fact I was implementing Slate's multiple attributes
per object by replacing it with just one attribute (i.e. one input
terminal) as follows : for any object on which you would need more than
one attribute, define a list of objects, one per attribute; then to query
some specific attribute of the object, stick the corresponding "attribute
object" to its input terminal.

In this sense, Bazar is more simplistic than Slate. This extra simplicitly
made it possible for a uniform way to specify graph reduction rules as a
single Bazar expression associated with the operator (actually a big
Lambda with If-Then-Else subexpressions to check which attribute was stick
to the object). It would then be possible to define inside of the language
itself (and not externally) what an attribute means.

Whether this extra simplicity pays or just comes in the way is however not
clear to me yet :-)


Armin