Hello, fellow Lispers!
From time to time I'm using a technique which I call "assembly line". What
I mean is that several functions operate one after the other on a list of
(named) items, every function adding, removing or modifying items on the
list. [*]
My question: I'm rather sure that this pattern is known. (For example,
every program works on global variables in this way.) Is there another
name for it? Can someone give some further information?
Thanks, Nicolas.
[*] More info about my implementation:
1. Even if the functions usually return an updated assembly line, it is
not really needed because the list is modified (as in reality).
2. I use property lists starting with (:assembly-line t ...) for my
assembly lines and I have a macro WITH-ITEMS which defines
symbol-macros expanding into getf expressions. I am not yet
completely happy with this macro, though...
Nicolas Neuss wrote:
> My question: I'm rather sure that this pattern is known. (For example,
If I understand your question correctly:
In Unix, it's called "pipes".
In compiler technology, it's called "passes".
In hardware, it's called "daisy chaining".
I would not be surprised if you don't find it in an oop cookbook of
patterns, since this pattern is inconvenient (but not impossible) to
imagine when you don't have processes (all of the above examples use
asynchronous components).
pt
Paul Tarvydas <········@attcanada.ca> writes:
> Nicolas Neuss wrote:
>
> > My question: I'm rather sure that this pattern is known. (For example,
>
> If I understand your question correctly:
>
> In Unix, it's called "pipes".
>
> In compiler technology, it's called "passes".
>
> In hardware, it's called "daisy chaining".
>
> I would not be surprised if you don't find it in an oop cookbook of
> patterns, since this pattern is inconvenient (but not impossible) to
> imagine when you don't have processes (all of the above examples use
> asynchronous components).
>
> pt
One thing I want to stress in this pattern is that the interface between
the functions is fuzzy. Some function may choose to compute something and
put it on the assembly line or not. It may also put data on the assembly
line, if there is only a slight possibility that it will be needed later
on. In contrast, for compilers the passes will usually have a rather
clear-cut interface (or so I guess).
Nicolas.
On 24 Jun 2003 16:37:04 +0200, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
>One thing I want to stress in this pattern is that the interface between
>the functions is fuzzy. Some function may choose to compute something and
>put it on the assembly line or not. It may also put data on the assembly
>line, if there is only a slight possibility that it will be needed later
>on. In contrast, for compilers the passes will usually have a rather
>clear-cut interface (or so I guess).
This sounds like a 'blackboard' approach.
Mark
Mark Dalgarno <·············@scientia.com> writes:
> On 24 Jun 2003 16:37:04 +0200, Nicolas Neuss
> <·············@iwr.uni-heidelberg.de> wrote:
>
> >One thing I want to stress in this pattern is that the interface between
> >the functions is fuzzy. Some function may choose to compute something and
> >put it on the assembly line or not. It may also put data on the assembly
> >line, if there is only a slight possibility that it will be needed later
> >on. In contrast, for compilers the passes will usually have a rather
> >clear-cut interface (or so I guess).
>
> This sounds like a 'blackboard' approach.
>
> Mark
I thought Google would have difficulties finding it, but no:
http://www.ecs.umass.edu/mie/labs/mda/fea/sankar/chap4.html
Thank you very much. I think this is the information I sought. My
"assembly line" is a simple form of blackboard approach.
Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Thank you very much. I think this is the information I sought. My
> "assembly line" is a simple form of blackboard approach.
>
> Nicolas.
And thanks also for all other info I got.
Nicolas.
Paul Tarvydas <········@attcanada.ca> writes:
> I would not be surprised if you don't find it in an oop cookbook of
> patterns, since this pattern is inconvenient (but not impossible) to
> imagine when you don't have processes (all of the above examples use
> asynchronous components).
I'm not sure I agree with this. It would seem that nested function
calls would be able to do this. That would be the way I would think of
it.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Paul Tarvydas <········@attcanada.ca> writes:
>
>
>> I would not be surprised if you don't find it in an oop cookbook of
>> patterns, since this pattern is inconvenient (but not impossible) to
>> imagine when you don't have processes (all of the above examples use
>> asynchronous components).
>
> I'm not sure I agree with this. It would seem that nested function
> calls would be able to do this. That would be the way I would think of
> it.
Prolog is, in my opinion, another example of this paradigm. It fires rules
in a way that appears concurrent, and it appears to operate on a global
database.
To prove your point, all you have to do is macro-expand the output of a
prolog-in-lisp compiler.
To prove my point, all you have to do is look at the emitted code.
I find that one does not *tend* to write code in this paradigm when one is
using a sequential language (i.e. one based intimately on CALL/RETURN
(which includes most common oop languages)). Yet, I find that when I write
code using 100's of concurrent components (think CSP, Occam, etc.) that
send (real) messages to each other, one of the first thoughts is to set up
daisy chains, etc. Likewise UNIX. Likewise hardware design.
pt
Paul Tarvydas <········@attcanada.ca> writes:
> Thomas A. Russ wrote:
>
> > Paul Tarvydas <········@attcanada.ca> writes:
> >
> >> I would not be surprised if you don't find it in an oop cookbook of
> >> patterns, since this pattern is inconvenient (but not impossible) to
> >> imagine when you don't have processes (all of the above examples use
> >> asynchronous components).
> >
> > I'm not sure I agree with this. It would seem that nested function
> > calls would be able to do this. That would be the way I would think of
> > it.
>
> Prolog is, in my opinion, another example of this paradigm. It fires rules
> in a way that appears concurrent, and it appears to operate on a global
> database.
Oh, I don't think these are the same at all. Now, I am no expert in
Prolog, but it seems to me that deductive and rule-based systems do not
have a sequential control structure that is apparent to the user. In
fact, one of the appeals of the rule-based paradigm is that the
programmer is no longer required (or often even able) to specify the
order of application of the rules. The system takes care of deciding in
which order operations are performed, based on the applicability
conditions.
While there is chaining of results in rule-based systems, it is not
nearly as controlled as something like a Unix pipe, where the flow of
data is clearly and explicitly specified.
Blackboard architectures have a similar characteristic, in that each
knowledge element looks for applicable situations and processes them.
They do not have the sense of sequential application of a set of
operations onto every object passing through them.
--
Thomas A. Russ, USC/Information Sciences Institute
Paul Tarvydas <········@attcanada.ca> writes:
> Thomas A. Russ wrote:
>
> > Paul Tarvydas <········@attcanada.ca> writes:
> >
> >> I would not be surprised if you don't find it in an oop cookbook of
> >> patterns, since this pattern is inconvenient (but not impossible) to
> >> imagine when you don't have processes (all of the above examples use
> >> asynchronous components).
> >
> > I'm not sure I agree with this. It would seem that nested function
> > calls would be able to do this. That would be the way I would think of
> > it.
>
> Prolog is, in my opinion, another example of this paradigm. It fires rules
> in a way that appears concurrent, and it appears to operate on a global
> database.
Oh, I don't think these are the same at all. Now, I am no expert in
Prolog, but it seems to me that deductive and rule-based systems do not
have a sequential control structure that is apparent to the user. In
fact, one of the appeals of the rule-based paradigm is that the
programmer is no longer required (or often even able) to specify the
order of application of the rules. The system takes care of deciding in
which order operations are performed, based on the applicability
conditions.
While there is chaining of results in rule-based systems, it is not
nearly as controlled as something like a Unix pipe, where the flow of
data is clearly and explicitly specified.
Blackboard architectures have a similar characteristic, in that each
knowledge element looks for applicable situations and processes them.
They do not have the sense of sequential application of a set of
operations onto every object passing through them.
--
Thomas A. Russ, USC/Information Sciences Institute
Nicolas Neuss wrote:
> Hello, fellow Lispers!
>
> From time to time I'm using a technique which I call "assembly line". What
> I mean is that several functions operate one after the other on a list of
> (named) items, every function adding, removing or modifying items on the
> list.
I recall reading an actual paper that describes this or a similar
pattern, but I don't remember the details. It might be worthwhile to ask
in the patterns discussion mailing list. See
http://hillside.net/patterns/mailing.htm#patterns
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Nicolas Neuss <·············@iwr.uni-heidelberg.de> wrote in message news:<··············@ortler.iwr.uni-heidelberg.de>...
> Hello, fellow Lispers!
>
> From time to time I'm using a technique which I call "assembly line". What
> I mean is that several functions operate one after the other on a list of
> (named) items, every function adding, removing or modifying items on the
> list. [*]
[snip]
You are talking about Coroutines. See section 1.4.2 of the first Knuth volume.
······@pobox.com (Kumade Khawi) writes:
> Nicolas Neuss <·············@iwr.uni-heidelberg.de> wrote in message news:<··············@ortler.iwr.uni-heidelberg.de>...
> > Hello, fellow Lispers!
> >
> > From time to time I'm using a technique which I call "assembly line". What
> > I mean is that several functions operate one after the other on a list of
> > (named) items, every function adding, removing or modifying items on the
> > list. [*]
> [snip]
>
> You are talking about Coroutines. See section 1.4.2 of the first Knuth volume.
I think coroutines are an even larger pattern. Maybe "multipass algorithms
with flexible interfaces" is the right denotation for my assembly lines.
Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> My question: I'm rather sure that this pattern is known. (For example,
> every program works on global variables in this way.) Is there another
> name for it? Can someone give some further information?
i'm not really sure what you're asking, but maybe this will interest you:
http://groups.google.com/groups?q=group:comp.lang.lisp+filter&hl=en&lr=&ie=UTF-8&selm=ahnk8t%247d5%241%40luna.vcn.bc.ca&rnum=3
--
Marco Baringer
Baringer Electronics and Software Engineering
www.bese.it
Nicolas Neuss wrote:
> Hello, fellow Lispers!
>
> From time to time I'm using a technique which I call "assembly line". What
> I mean is that several functions operate one after the other on a list of
> (named) items, every function adding, removing or modifying items on the
> list.
You could try the Pipes and Filters pattern in Buschmann, Meunier,
Rohnert, Sommerlad, Stal, "Pattern-Oriented Software Architecture".
Isn't this somehow related to series and generators/gatherers as
explained in CLtL2?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Nicolas Neuss <·············@iwr.uni-heidelberg.de> wrote in message news:<··············@ortler.iwr.uni-heidelberg.de>...
I utilized a similar pattern as the organizing architectural pattern
when I wrote a CORBA ORB in Lisp. I called the pattern "staging" in an
unpublished paper on the ORB some years ago; at the time I was not
able to find it in the literature.
The idea is that there are a set of functional stages and each object
in a series of objects must pass through various of these stages.
In debugging it can be useful to have a slot in the object that holds
the name of the current stage in which the object lies, since then one
can instantly know where in the staging process the object is when
inspecting it in the debugger.
In the case of the ORB, the ORB received various types of messages,
each of which is assigned a class. There are, let us say, 14 total
possible stages although a particular message class only goes through
at most 7 of the stages. Each stage corresponded to a single method on
the main message class, and the message class had an abstract dispatch
method which was specialized for each message subclass; each message
subclass dispatch method invoked sequentially the methods
corresponding to the stages appropriate to its message type.
The pattern also comes up in compilers, where each stage represents a
pass, as was mentioned in another article in this thread.
> Hello, fellow Lispers!
>
> From time to time I'm using a technique which I call "assembly line". What
> I mean is that several functions operate one after the other on a list of
> (named) items, every function adding, removing or modifying items on the
> list. [*]
>
> My question: I'm rather sure that this pattern is known. (For example,
> every program works on global variables in this way.) Is there another
> name for it? Can someone give some further information?
>
> Thanks, Nicolas.
>
> [*] More info about my implementation:
>
> 1. Even if the functions usually return an updated assembly line, it is
> not really needed because the list is modified (as in reality).
>
> 2. I use property lists starting with (:assembly-line t ...) for my
> assembly lines and I have a macro WITH-ITEMS which defines
> symbol-macros expanding into getf expressions. I am not yet
> completely happy with this macro, though...
In article <····························@posting.google.com>,
············@yahoo.com says...
> The pattern also comes up in compilers, where each stage represents a
> pass, as was mentioned in another article in this thread.
As an architecture this is often referred to as data-flow.
Colin