Contracts for Processors

[Ged Byrne]

Paul,

Here I believe we could benefit from the thinking behind design by contract: 

I think it would be useful to have the concept of a contract for a component.

The central idea of DbC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" which defines for example that:

• The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit).
• The client must pay the fee (obligation) and is entitled to get the product (benefit).
• Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts

http://en.wikipedia.org/wiki/Design_by_contract

This would allow for the mutation of IPs in a controlled manner.  Any language could be used to describe the contract between the IP on receipt and send from a component.

The logical language of Eiffel could be adapted:

feature -- Element change
 
    deposit (sum: INTEGER)
            -- Add `sum' to account.
        require
            non_negative: sum >= 0
        do
            ... As before ...
        ensure
            one_more_deposit: deposit_count = old deposit_count + 1
            updated: balance = old balance + sum
        end

http://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions

Alternative a specification by example style might be used, adapting the style of BDD tools like Cucumber

Feature: Daily car maintenance
  Cars need maintenance


Scenario: Fuelling
    Given a car with 10 litres of fuel in the tank
    When you fill it with 50 litres of fuel
    Then the tank contains 60 litres

http://thomassundberg.wordpress.com/2011/09/16/test-drive-an-implementation-using-an-executable-specification/

The important thing is that the relationship between the IP on input and output must be expressible using a regular expression or state machine.  That is to say in formal terms, the contract must specify the relationship between input and output using a type 3 regular grammer.

If a process is to alter the state of an IP, then it must declare a contract bounding the output to the input in a contract.  Destroying an IP should also be treated as change of state, and should therefore by specified in a contract.   The fact that a process may create a new IP could also be specified in a contract.

He would have to be proven by somebody much cleverer than me, but I believe that this would ensure that all processes are Markov Processes, so that the state of an IP on the output is entirely dependant upon the state on input.  The history of the process or the IP is not necessary.

A type 3 regular expression is equivalent to a finite state machine, which is equivalent to the gate logic of an IC, so this could help formally define the levels of granularity in Brad's gate, chip and card model.

What do you think?

Regards, 

Ged

On 11 April 2012 03:46, Paul Morrison <paul.m...@rogers.com> wrote:

Now suppose I have incoming IPs, and we have a process which modifies a particular field in each IP (e.g. the Assign component), is it better to destroy the incoming IP and create a new one  with the same structure as the incoming one - or can we just modify the incoming one and send it on?  Or doesn't it matter?  From my point of view, I find the [im]mutability issue confusing :-)  Does this have a bearing on the dataflow vs. (?) FBP issue?

If each process is a separate microprocessor, does this change the answer?

[Paul Morrison]

Hi Ged,

Yes, I like the Eiffel contract idea - it seems a good fit with FBP concepts.  In the 2nd edition of my book, you will find references to Joe Armstrong's ideas about contracts (Chap. 27) and Mike Beckerle's use of the term in describing type-checking (Chap. 11).  It has also seemed to me that the output of Collate could be described as a regular expression (Chap. 23)  - is that similar to what you have in mind when you refer to regular grammars?

My only quibble is that I feel making components Markov processes is too restrictive - even a simple counter component has to have memory.  Unless you are picturing putting _all_ memory into IPs, and feeding them back into the process as each incoming IP is processed...?

Regards,

Paul

--
http://jpaulmorrison.blogspot.com/

[Ged Byrne]

Hi Paul,

Thanks for the pointer to Joe Armstrong's ideas.  That is exactly what I was thinking.  Give me some time to write up something.

Regarding  Markov processes I see your point.  However, introducing state like this probably needs to be somehow made explicit.

Take the simplest example: the counter.  As soon as you introduce a counter you introduce a bottle neck.  If that single counter is to work then every IP of the type you want to count must pass through that specific instance of the component.  You cannot process the IPs in parallel unless some way of aggregating their state is introduced. 

I don't think putting all state into IPs is such a good idea.  We do have stacks and chains.  Could these be used to store and share data?

Regards, 

Ged 

[Brad Cox]

How about map/reduce. The map component divides the stream to multiple counter processes, the reduce component sums the counts?

[Paul Morrison]

Hi Brad, that's what I was thinking!  If people don't mind showing that explicitly in the network, in JavaFBP and C#FBP we can even gear the number of paths to the number of processors on the machine, using some ratio - a possible advantage of defining the network using procedural code?!   If OTOH people want to somehow split up the Counter process automagically, that's a whole 'nother bag of snakes.  We'll leave that for FBP 2.0... :-)

Re stacks, I have been visualizing each process having its own stack, so I don't really see how that helps...    Chains are an extension of IPs and are subject to the same ownership rules (except that here some IPs are owned by other IPs, rather than by a process).

[Brad Cox]

Paul, does JavaFBP have a REST interface I could use for configuring/assembling components? RestEasy's kickin' my butt. Would be nice to avoid all that by adopting something that "just works".

--
Cell: 703-594-1883
Blog: http://bradjcox.blogspot.com
Web: http://virtualschool.edu
Manassas VA 20111

[Paul Morrison]

On 12/04/2012 1:00 PM, Brad Cox wrote:
> Paul, does JavaFBP have a REST interface I could use for
> configuring/assembling components? RestEasy's kickin' my butt. Would
> be nice to avoid all that by adopting something that "just works".

Don't know anything about REST! Is it anything like the (rather basic)
socket support I built for JavaFBP and C#FBP? You could take a look at

http://flow-based-pgmg.svn.sourceforge.net/viewvc/flow-based-pgmg/javaengine/trunk/JavaFBP/src/com/jpmorrsn/fbp/components/ReadFromSocket.java
http://flow-based-pgmg.svn.sourceforge.net/viewvc/flow-based-pgmg/javaengine/trunk/JavaFBP/src/com/jpmorrsn/fbp/components/WriteToSocket.java

I would be happy to cook up some more components if you can send me some
specs... :-)

[Raoul Duke]

On Thu, Apr 12, 2012 at 10:43 AM, Paul Morrison
<paul.m...@rogers.com> wrote:
> Don't know anything about REST!  Is it anything like the (rather basic)

> I would be happy to cook up some more components if you can send me some
> specs... :-)

i guess we all live in our own caves, like i'm learning about fbp :-) :-)
http://en.wikipedia.org/wiki/Representational_state_transfer

[Brad Cox]

Google Roy Fielding REST. Its not involved in component to component pipelines (runtime). Its for configuring and assembling components from a browser-based GUI (config time).

[Raoul Duke]

On Thu, Apr 12, 2012 at 10:51 AM, Brad Cox <brad...@gmail.com> wrote:
> Google Roy Fielding REST. Its not involved in component to component
> pipelines (runtime). Its for configuring and assembling components from a
> browser-based GUI (config time).

by the way, especially for those new-to-rest, i read that in the sense
of "How Brad wants to use REST with JavaFBP" rather than "REST is only
about config time wherever it is used" ja wohl?

sincerely.

[Brad Cox]

Ja.

[Dan]

REST is too scatter-brained for me. It does not contain strong aspects / paradigms, something basic you can not do without.
REST-style architectures consist of clients and servers. In FBP it does not make too much sense to discuss about sever and clients because this is just a matter of components deployment. Deployment is important but not essential in the logic of the program. There are a lot of things to discuss about it but in the end REST does not look to me as something fundamental and it is not a paradigm.

Regards,
Dan

[Brad Cox]

That's fine. Never claimed it was a paradigm (tho some would argue about that; that word paradigm's real debate bait). I want it for configuring components from browsers. Period.

[John Cowan]

Paul Morrison scripsit:

> Don't know anything about REST!

It is an architectural style reverse engineered from HTTP, but it is not
necessarily connected with HTTP or even sockets. Rather, it is a pattern
for interacting with key-value stores like file systems or HTTP servers,
that don't maintain session state but just keep the value associated
with each key.

Here's the essence of the REST pattern:

1) Given a key, the store returns the corresponding value. It may
compute the value in an arbitrarily complex way; the pattern does not
require dumb stores.

2) Given the key, a client of the store can read, modify, or delete the
key-value pair, provided it has permissions to do so.

3) Each request contains enough information to determine how the store
should process it.

4) Stores should support the following requests, and as few others as
possible, so as to make blind interaction with a store possible.

* Get, a safe operation that returns a value given the key. This
operation produces no side effects chargeable to the client (the store
may log something). It can be repeated and will produce the same
result, modulo changes on the store side (timestamps may differ, e.g.)

* Put, a safe operation that changes the value associated with a key.
This operation is repeatable with the same effect. When a Put is
complete, a Get will receive the same result, modulo changes on the
store side.

* Post, an operation that creates a new key-value pair given a value.
The client may suggest a key, but the server is always free to create
the key, which is returned to the client.

* Delete, an operation that removes a key-value pair given th ekey.
This operation can be repeated with the same effect.

5) Except for trivial entry points, the client should not assume anything
about keys; keys should be retrieved from parts of values that the client
has already fetched. (This is usually stated as "hyperlinking is the
engine of application state.")

--
John Cowan co...@ccil.org http://ccil.org/~cowan
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer

[Paul Morrison]

On 12/04/2012 2:02 PM, Brad Cox wrote:
> That's fine. Never claimed it was a paradigm (tho some would argue
> about that; that word paradigm's real debate bait). I want it for
> configuring components from browsers. Period.
>
>

Brad and Raoul, I'm lost in my cave! Do I understand that you want to
configure a JavaFBP network using one of the browsers? Assuming you
don't want to use DrawFBP (which uses Java and Swing), we could just
have you edit a file, e.g. Wayne Stevens' notation (arrows and commas),
which could be converted to a JavaFBP network specification. I also
think this Group has several other examples of text-based network
specification techniques, e.g. Henri Bergius' NoFlo. When I Google
REST I just get all this stuff about constraints - is there a
diagramming tool? I tend to think visually, so text doesn't cut it for me!

Thanks, guys!

[Paul Morrison]

Thanks John,

That helps a lot! Now I am really curious how REST and [Java]FBP go
together - that should be interesting! I could guess, but I want to
hear from the Group!

--
http://jpaulmorrison.blogspot.com/

[Brad Cox]

That's OK Paul. Probably a bridge to far if you've not on that trail already. This is for a suit demo whose whole point is we can do browser glitz with the best of them. Nobody but me will even know FBP is in there under the covers. Sigh.

[Raoul Duke]

On Thu, Apr 12, 2012 at 11:44 AM, John Cowan <co...@mercury.ccil.org> wrote:
> Here's the essence of the REST pattern:

wow. that was more cogent than anything else i've ever read about REST :-)

> 5) Except for trivial entry points, the client should not assume anything
> about keys; keys should be retrieved from parts of values that the client
> has already fetched.  (This is usually stated as "hyperlinking is the
> engine of application state.")

this is apparently to some people a very important win.
http://java.dzone.com/articles/domain-model-rest-anti-pattern

[John Cowan]

Raoul Duke scripsit:

> http://java.dzone.com/articles/domain-model-rest-anti-pattern

That article has substantial problems, but it does correct
the "just expose your data" anti-pattern. Hypertext as
application state is what makes the difference between *just*
being a key-value store and being a REST application. See
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
(which is linked from the above article), including particularly Roy's
comments.

--
John Cowan co...@ccil.org http://www.ccil.org/~cowan
C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant
le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux,
de rapport nyait pas. --Jacques Lacan, "L'Etourdit"

[Paul Morrison]

On 12/04/2012 3:07 PM, John Cowan wrote:
> s'y conjuguant
> le nyania qui bruit des sexes en compagnie,

Is that the Nyania in Ghana?
http://www.indexmundi.com/z/?lat=10.95&lon=-1.0833333&t=p&r=7540&p=nyania&cc=gh&c=ghana
- and I thought my French was pretty good :-)

--
http://jpaulmorrison.blogspot.com/

[Paul Morrison]

Anyway let me know if there is anything I can do to help!

P.

--
http://jpaulmorrison.blogspot.com/

[John Cowan]

Paul Morrison scripsit:

> On 12/04/2012 3:07 PM, John Cowan wrote:
> >s'y conjuguant
> >le nyania qui bruit des sexes en compagnie,
> Is that the Nyania in Ghana? http://www.indexmundi.com/z/?lat=10.95&lon=-1.0833333&t=p&r=7540&p=nyania&cc=gh&c=ghana
> - and I thought my French was pretty good :-)

Nobody really knows. My best guess is that "nyait" means "goes 'nyah-nyah'"
and "le nyania" is "the condition of everyone going 'nyah-nyah'."

--
John Cowan <co...@ccil.org> http://www.ccil.org/~cowan

The peculiar excellence of comedy is its excellent fooling, and Aristophanes's
claim to immortality is based upon one title only: he was a master maker
of comedy, he could fool excellently. Here Gilbert stands side by side
with him. He, too, could write the most admirable nonsense. There has
never been better fooling than his, and a comparison with him carries
nothing derogatory to the great Athenian. --Edith Hamilton, The Greek Way

[Paul Morrison]

On 12/04/2012 4:02 PM, John Cowan wrote:
> Nobody really knows. My best guess is that "nyait" means "goes
> 'nyah-nyah'" and "le nyania" is "the condition of everyone going
> 'nyah-nyah'."

"the impenetrability of Lacan's prose... [is] too often regarded as
profundity precisely because it cannot be understood" (Richard
Stevens). I don't feel so bad now :-)

[Paul Morrison]

John, as a curator of the RetroComputing Museum, and Henri B., as one
who is interested in computing archaeology, and of course anyone else in
this Google Group, this may interest you. An old friend, Nate Edwards
(http://en.wikipedia.org/wiki/Nate_Edwards ), has sent me some stuff on
a marvelous machine and system design that he and some colleagues have
been trying to generate interest in for a number of years. ALTOPS is
not only massively parallel, but its approach to system design relies
heavily on manufacturing and accounting practices. If I understand it
correctly, the internal architecture is component- and bus-oriented. It
occurred to me that some of you might be intrigued by the ideas, and
might either want to explore them more deeply - or might know people who
would.

I have uploaded some presentations to my web site, and I hope at least a
few of you will find them intriguing enough to pursue more deeply! Here
are a few of the files:

http://www.jpaulmorrison.com/npedwards/ALTOPS1.pptx
http://www.jpaulmorrison.com/npedwards/ALTPSUM1.pptx

He also sent me an old paper on program verifiability which may interest
a number of you - if you haven't already seen it:

http://www.jpaulmorrison.com/npedwards/PROOFS OF PROCESSES.pdf

and a presentation on the security advantages of the architecture -
ALTOPS believes in complete separation of data and code:

http://www.jpaulmorrison.com/npedwards/SECURITYSYS5.pptx

Hope some of you find this stimulating - and perhaps have suggestions as
to how Nate should proceed going forward. He feels that the
capabilities and challenges of the new hardware might make this timely
(a bit like FBP!).

Brad, maybe you remember Nate...?

--
http://jpaulmorrison.blogspot.com/

[Paul Morrison]

Sorry, I seem to have changed the thread title by mistake... Hopefully
it will change back!

[Paul Morrison]

Happened again! This weird! Sorry!

--
http://jpaulmorrison.blogspot.com/

[Paul Morrison]

Can we move the ALTOPS stuff to a new thread? I don't seem to have
the authority...

[Paul Morrison]

[Brad Cox]

That's one helluva coincidence! It was Nate that gave me the spare byte I mentioned earlier today. Paul, could you send me his email address privately? Thanks!

On Thu, Apr 12, 2012 at 7:50 PM, Paul Morrison <paul.m...@rogers.com> wrote:

An old friend...

[Paul Morrison]

Could someone please clean up this mess!!! I clicked on start new
discussion- and it didn't! :-[

On 12/04/2012 7:48 PM, Paul Morrison wrote:

[Brad Cox]

Yep. Just like paint is not "fundamental" to a house. Its "merely" about curb appeal which real engineers don't bother with. :(

[Paul Morrison]

On 27/08/2012 10:19 AM, Brad Cox wrote:
> Yep. Just like paint is not "fundamental" to a house. Its "merely" about curb appeal which real engineers don't bother with. :(
>

Sorry, Brad, which post is this in answer to? Thanks!