On 7/19/2022 6:25 PM, Douglas Eagleson wrote:
> On Monday, July 4, 2022 at 2:50:51 PM UTC+8, Jeff Barnett wrote:
>> On 7/3/2022 10:29 PM, Douglas Eagleson wrote:
>>> On Friday, June 10, 2022 at 10:48:49 AM UTC+8, Jeff Barnett wrote:
>>>> On 6/9/2022 8:19 PM, Douglas Eagleson wrote:
>>>>> On Friday, June 10, 2022 at 6:45:59 AM UTC+8, Jeff Barnett wrote:
>>>>>> On 6/9/2022 3:32 PM, Douglas Eagleson wrote:
>>>>>>> On Thursday, June 9, 2022 at 1:21:36 AM UTC+8, Jeff Barnett wrote:
>>>>>>>> On 6/6/2022 3:11 PM, Jeff Barnett wrote:
>>>>>>>>> On 6/6/2022 2:10 PM, Douglas Eagleson wrote:
>>>>>>>>>> I am working on a project. How does a synchronous system get to be
>>>>>>>>>> stated in my version of AI, old Greek theory. These have two or more
>>>>>>>>>> systems with a common state. Synchronous can be random/coincidental
>>>>>>>>>> caused or caused by a variable/human action. These point to an AI
>>>>>>>>>> relation inferable.
>>>>>>>>>>
>>>>>>>>>> Two clocks can be made synchronous by a simple relative time. Actions
>>>>>>>>>> at times can make this relative solvable. Making synchronous an
>>>>>>>>>> abstract relation.
>>>>>>>>> Warning: my spelling of names is probably not accurate.
>>>>>>>>>
>>>>>>>>> In the mid 1960s, Alan Perlis then at CMU, was dissertation advisor to
>>>>>>>>> two PhD students working in foundations of Computer Science vis à vis
>>>>>>>>> program language semantics.
>>>>>>>>>
>>>>>>>>> One student was Tim Standish who wrote about data structure definition
>>>>>>>>> primitives. One could use the proposed set of primitives to explain data
>>>>>>>>> structure definition in your favorite languages. In other words, his
>>>>>>>>> primitives could be used as a macro language to define the intent of
>>>>>>>>> data declarations. This dissertation was noted by a big chunk of the CS
>>>>>>>>> community who was, at the time, trying develop better tools for
>>>>>>>>> inventing and implementing new languages. Last I knew, Tim was at
>>>>>>>>> University of California at Irvine.
>>>>>>>>>
>>>>>>>>> The other student was Bob(?) Fisher(?) and he did something that on the
>>>>>>>>> surface sounded as similar to Tim's work. The difference was that he
>>>>>>>>> wanted primitives to define the meaning of/control/ structures. Not
>>>>>>>>> only did he handle the usual (sequence, parallel, conditional, etc.) he
>>>>>>>>> also dealt with sexier things such as atomic-with-respect-to,
>>>>>>>>> wait-for-condition (join), indivisible-with-respect-to, priorities
>>>>>>>>> (e.g., to model interrupts), and more. I think Bob(?) was at DARPA soon
>>>>>>>>> after school and then disappeared into the wood work.
>>>>>>>>>
>>>>>>>>> I don't know how you might get a copy of Bob's dissertation but, if you
>>>>>>>>> could, a whole panorama of interesting possibilities might be made
>>>>>>>>> apparent to you and your endeavor.
>>>>>>>>>
>>>>>>>>> I'm sorry that I can't be more specific with references and citations
>>>>>>>>> but by encounters with the individuals mentioned happened 50+ years ago.
>>>>>>>> I did a little poking around and found a correct name: "Dave A. Fisher".
>>>>>>>> His dissertation is also available online. Google "Fisher, Control
>>>>>>>> Structures" and the first hit is a PDF at the pseudo URL
>>>>>>>> "https://citeseers.ist.psu.edu>viewdoc>download". Just click on this
>>>>>>>> item in the Google output and whatever your setup does for PDF will happen.
>>>>>>>> --
>>>>>>>> Jeff Barnett
>>>>>>> I downloaded Fisher's dissertation. I need a while to read it.
>>>>>>> Basically, my first look is to be understanding the general/abstract
>>>>>>> control structure.
>>>>>>>
>>>>>>> Is there a control structure definable using object theory?
>>>>>>> Generalizing the meaning of it's primitive.
>>>>>> A short answer to your question is probably no but maybe. The issue is
>>>>>> that control cliches define behavior, not "static" relations among data.
>>>>>> The "maybe" comes from local nests of related behaviors as abstract
>>>>>> objects then defining relations among these sorts of objects.
>>>>>>
>>>>>> It's been a longtime since I read it so I can't rely on my memory for
>>>>>> any real details. What I do remember is that it was a thrill to see a
>>>>>> thesis take on such a difficult, abstract problem and get some of it
>>>>>> right (IMO). There was nothing like it in the literature so it was a
>>>>>> first hack at nailing down one of the most important aspects of
>>>>>> computational systems and the whole notion of a computation.
>>>>>> Unfortunately, this work was not followed by a second tier of research.
>>>>>> --
>>>>>> Jeff Barnett
>>>>> I did a google search and found some later work of Fisher.
>>>>> I believe he went to help with DOD on the foundations of
>>>>> the ADA language.
>>>> That sounds right. I bumped into him once after he was done at CMU. We
>>>> talked for a while - he was amazed that anyone had read his
>>>> dissertation. I can't recall where this happened but he mentioned having
>>>> been at DARPA and I assumed that he was there in the Information
>>>> Technology Office as a Program Manager (PM). In the 1960s and most of
>>>> the 70s, most of that office's PMs were recent PhD graduates. Later on,
>>>> PMs were either military or civilians who were comfortable in suits
>>>> and ties. Big change.
>>>>
>>>> As I said above, I was disappointed that nobody picked up and continued
>>>> his line of research. If taken to the next step it would have an impact
>>>> on hardware design, compiling programs with tons of parallelism, and
>>>> make it possible to better reason about covert channels when trying to
>>>> determine security properties of systems.
>>>>
>>>> Good luck with your endeavor.
>>>> --
>>>> Jeff Barnett
>>> well I read the first 50 pages and it turned into Einstein level logic.
>>> He calls a control structure as defining an Interpreter for an Interpreter.
>>> This creator Interpreter does not need to compile itself as per Turing
>>> advice. It can be implemented in a language such as C using subroutines
>>> and functions and other C structures.
>>>
>>> He goes into great detail designing a syntax for his language Sol.
>>>
>>> I did have difficulty reading which "Interpreter" he was writing about.
>>>
>>> He introduced the operation of a process "monitor". Basically
>>> a list of objects held in a main process. He stated quite nicely the
>>> idea of only exercising a list item when an input variable has a state change.
>>> Maybe a poorman's object monitor can implement object process?
>>>
>>> I am still looking at the synchronous issue. Basically I need to make
>>> a blackbox the checks for this state. The issue of clock error occurs.
>>> So a class of input must be a degree of accuracy, maybe as a percentage.
>>>
>>> I got lost in the realm of math. Does a function simply define
>>> a synchronous path? I need some advice.
>>>
>>> I do believe two numbers always existing together can be called
>>> synchronous
>> I'll start with the last questions first: You ask what he meant by a
>> function and that is not so easy to answer. Mathematically a function is
>> an entity that maps some values to other values, where the input values
>> are always mapped to the same output values. In the world of software we
>> don't mean that at all. Take a similar question: What's a structure? The
>> answer is that it's the thing defined by your language's primitive with
>> a name like DEFSTRUCT. Similarly a function, subroutine, etc., is that
>> thing defined by the primitive your language provides to define such
>> things. Does a function define a synchronous path? Depends on the
>> language in which it is defined.
>>
>> I don't know what it means for two numbers to always exist together so I
>> couldn't determine if they were synchronous.
>>
>> It's been (quite) a while since I read this thesis but I might be able
>> to add some to what you have got out of it so far. The things said about
>> multiple interpreters was the following: In order to interpret a control
>> structure, the interpreter must "do" the control structure. Let's take
>> an example: PARALLEL(x, y, z), where x, y, and z are program pieces. In
>> order to really get the effect of parallel execution, the interpreter
>> must, in general, start Ix, Iy, and Iz; three interpreter routines, one
>> to interpret x, one to interpret y, and one to interpret z and they must
>> execute in parallel. And the same thing needs to happen when each of the
>> other control primitives are encountered. (There are, of course,
>> optimizations such as subsume a sequential element that appears in a
>> sequential, etc.) One may think that you could simulate PARALLEL by some
>> sort of interleaving on sequential hardware but when you mix in other
>> control relations the interpreter can't be faithful to the implied
>> semantics.
>>
>> The synchronization issue is that, for example, a monitor must
>> instantaneously spot that its condition has been satisfied so that a
>> declared reaction will occur. This is a hell of a burden on any
>> interpretation scheme. Let's look at an example: Let the variable X be a
>> sixteen bit integer; let the variable H be the high order 8 bits of X
>> and L be the low order 8 bits of X. Assume that there is a monitor on
>> the value of X, then that monitor must actively take a peek when either
>> H or L is modified. Similarly if there is a monitor on either H or L,
>> it must take a peek any time X is modified. This example may seem quite
>> artificial but it isn't. Consider interrupt structures of your favorite
>> computer. Bits are flipped in registers and interpreted as signals to
>> and by the OS. Describing and simulating such capabilities as they
>> actually work is quite difficult.
>>
>> For a moment, set aside the issue of interpreting programs written in
>> the control structure language and consider using the language to write
>> a detailed spec for a modern CPU with multiple cores and multiple
>> threads per core. You want to specify what the range of behaviors are
>> allowed. If you think about this for a while, I believe that you will
>> appreciate why the dissertation seems so convoluted. It's too bad that a
>> second dissertation on the same topic did not follow and clarify all of
>> these issues.
>>
>> At one point in the 1970s, I wanted to abstract the control flow and
>> data flow within a speech understanding system so I invented a language
>> called CSL (Control Structure Language) in which modules did not know
>> about each other. Data communications was over a set of software buses
>> (think pipes) and common data stores. CSL provided the primitives to
>> move data from module to module and enforce sequential execution among
>> threads, an I don't care what order they run in (pseudo parallel), and
>> condition monitors. There were some tokens pushed around to simulate
>> control signals, etc., something like Petri nets. The point of this
>> exercise was to put together a problem solver that did not commit order
>> of computation constraints when there was no reason to do so. As we
>> learned more, we could modify the CSL to exhibit more directed behavior.
>> By the way, the pseudo parallel directive assigned random numbers
>> dynamically to parallel threads as priorities so that running the system
>> on the same data multiple times could exhibit multiple behaviors and
>> generate different answers.
>>
>> I don't necessarily recommend reading another obscure paper (on CSL) but
>> if you are interested, a pdf copy is at
>> https://notatt.com/large-systems.pdf
>> --
>> Jeff Barnett
> hello
> I am just an average guy. It will take longer to to reply.
>
> Synchronous is a huge topic.. It can be thought of as a relation
> in time domain. I give up, but will get value from your reply.
Good luck exploring this topic. I always found it interesting.
--
Jeff Barnett