Hi,
> --- Keith Hopper <[EMAIL PROTECTED]> wrote:
> > > 1. All processors have at least one output.
> > > 2. There is a syntactical construct to "ground" outputs.
> >
> > What you both seem to be discussing is an extension of three-valued
> > logic as used in the formal methods world. Here, however, we have a
> > 'value' result from some processing and at the same time a
> > 'status' result - which is how POSIX interfaces are defined - there
> > is a result status and a result value (or an empty value) - have
> > a look at the language-independent POSIX
> > specs. In practice this is often implemented at the CPU level by a
> > 'flags word' and a result.
> You seem to have an interesting perspective here, but I am afraid I am not
> completely getting your analogy. How do you see the concepts of "value"
> and "result" apply to the case of processors in a pipeline? How is this
> related to Three-Valued Logic?
Ah! Sorry! I should have explained that the three values are
true/false/not-yet-known - the latter value is 'outside' the Boolean logic
domain - which models the behaviour of actual library implementations of
POSIX interface - the status is ignored unless not OK. In this case no
value can be returned and the program receives an all bit set pattern (eg
0xffffffff) and must then make a specific query to the 'error mechanism' -
outside the value domain too!. That methodology was adopted on the basis
that errors occurred only rarely.
Here, at a much higher conceptual level, we have the ability to
provide the status information on another (virtual) channel - which is the
way things are defined in the language-independent POSIX documents. These
specify that if an error or other status reply occurs it can occur
alongside a returned value - for example reading from a file returns not
only the content but also an indication of how much was read - and indeed
possibly also having an error status which caused less than requested to be
read.
May I suggest, therefore, that a 'control channel' is in accordance
with this kind of thinking - which is eminently sound in theory - a channel
which may always be accessed, whether any 'value' response is
present/wanted or not. This leaves the question of what to do with the
value if it is not wanted. Being myself an electrical engineer too, I think
the analogy with a ground plane is sensible - but only if the program (in
xpl) specifically indicates that such a 'connection' be made - to that
glorious bit bucket in the sky - /dev/null!!
I hope that helps explain my thinking.
Keith
--
City Desk
Waikato University
[PGP key available if desired]
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
orbeon-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
