Development of an IL

Discuss all aspects of application development in COSA, including the use of graphical tools, the component repository and an intermediate COSA description language (CDL).

Development of an IL

Postby sparky » Fri Jul 23, 2010 1:37 am

All,

With my latest version, my goal was to start development of applications via an external interface. I pulled ahead the application file code so I could keep things clean.

The file uses the following structure:
<!-- start of file -->
[init]
{initialization such as data values and components}

[start]
{initial set of effectors to run}

[sensor]
{sensors used}

[stop]
{effectors run on exit}
<!-- end of file -->

I have attached four test applications (plain text files) I use. While I have not implemented the ability for custom components, I envision an entry in the [init] section to define them and a "run <component name>" would be used to execute them.

Any thoughts?
Attachments
SampleApps.zip
Sample applications
(1.49 KiB) Downloaded 627 times
sparky
 
Posts: 22
Joined: Sat May 22, 2010 12:34 pm

Re: Development of an IL

Postby harry666t » Sat Sep 04, 2010 6:37 am

Sorry for a very late reply, I've been mostly offline for a while ^^'

Well, I've got lots of thoughts. Sorry, but this format is ugly. It's underpowered, inflexible, contains redundant sections, and can't even fully describe a moderately complex component (an application is just a special case of a high-level component).

I'll step through your examples and point out all of my objections. Starting with IncrementValue:

Code: Select all
[init]
int x 0;
int maxValue 10;


This is almost ok - I'd call this section "data". You can't have both other components and data&cells in a single component (it's either high-level or low-level), so you simply can't list components here.

Code: Select all
[start]
outputLine "Current value of x is $[x].";


The "start" section is unnecessary, and even wrong. Since every application is a component, it's always running, and just waiting for a "start" signal to arrive. Instead of a dedicated "start" section, it would be sufficient to connect that "outputLine" cell to the component's start connector.

Another objection is the "outputLine" as a cell. It's perfectly OK for debugging, but for real apps... I believe that the string constant should be stored in the data section, and the operation should be performed as a call to the operating system (through signal&data connectors). The format shouldn't strive to be friendly for human readers, that's a job for the graphical tools.

Code: Select all
[sensor]
lessThan $[x] $[maxValue] increment x;
equals $[x] $[maxValue] stop;


Hier liegt der Hund begraben. The only possible kind of relationship (connection) between cells in this format is one-to-one. Look at Louis's examples, almost everything is at least one-to-many, often many-to-many. Also, a cell often has inputs and outputs doing different things (white and black female connectors), so it is necessary to specify not only the cell, but also the connector.

Also, remember that usually the data effectors are self-activating - once started, they keep performing their action on every cycle, until stopped.

The "stop" effector could be replaced by sending a signal to the component's "done" connector, but I guess it's ok for tests.

Code: Select all
[stop]
outputLine "Counted to $[maxValue]!";


Again, just like the "start" section - this is redundant. This specific "outputLine" cell should just be connected to the "equals" sensor (that also sends the "done" or "stop" signal).

I'm not sure what to think about "VarType" and "Math" examples. You've listed a crapload of cells in the "start" section. This looks like it's meant to be run in sequence, otherwise the results would be unpredictable. These two examples make the format look like Unix's "bc" calculator, but with a funnier syntax. It doesn't "feel" like COSA.

--

So, a more useful format for a LLC would need to specify stuff like:

* data - all data cells, with types, initial values, and either name or address;
* cells - all sensors, effectors, etc. Everything that has inputs, outputs, and acts on data or signals. Every cell should either be named or have a locally unique ID (address) assigned;
* external connectors - at least "start" and "done", possibly data connectors, etc. All connectors need either to be labelled or have an ID;
* relationships, aka connections - the relationships would usually be formed between a male and a female connector, or between a sensor or effector and data. Connectors could be addressed with cell IDs or individual names. A simple list of lines like "x_lessthan_maxvalue.male => increment_x.start" would do the job.

As of the high-level components, by definition, they consist solely of other components, their own external connectors, and connections between these. A HLC with appropriate connector sets ("application started", "application is to be closed", input from the user, etc) would automatically qualify as an application.
harry666t
 
Posts: 48
Joined: Thu Mar 11, 2010 7:38 am

Re: Development of an IL

Postby sparky » Sat Sep 04, 2010 9:33 pm

Harry666t,

I posted a new way of looking at the COSA virtual machine in the other topic, so much of this will be revamped. Right now, an application in code would look like the following:

--- start of file ---
{data object initialization}

start with (state name);

state (state name) {
{list of effectors}
{list of sensors}
}

state (state name) { ...}
--- end of file ---

I'll keep your thoughts in mind while I'm fixing this portion up.
sparky
 
Posts: 22
Joined: Sat May 22, 2010 12:34 pm

Re: Development of an IL

Postby sparky » Sun Sep 19, 2010 5:07 pm

This is based on my post in the VM forum dated today.

I have tentatively chosen to use an XML-based format. I envision using a GUI to develop the file, but I'll leave that exercise to someone else.

I'm still undecided on if a pure sensory application will work. So I've also created (albiet a placeholder) for a Flowchart-based process, one that you would model in Visio or PowerPoint. I suppose a StateProcess would also work, modeled like a UML State diagram.

Main tag: SensoryProcess
------------------------------
This contains a name attribute, so when looking at list of running processes one can identify which process is which. If you wanted to use a PID, that's okay too.

Section: DataValues
-----------------------
This lists all the data values within the scope of the process. If the process contains sub-components, those components would have a data value section as well.

DataValue: Type (data type, such as integer or byte array); name (referenced by effectors and sensors); value (initial value, optional). Byte arrays need an encoding parameter so when strings are input or output the correct encoding is used.

Section: Effectors
---------------------
This lists all the effectors within the scope of the process. If the process contains sub-components, those components would have an effector section as well.

Effector: Type (what kind of effect is desired); name (referenced by sensors and tests); one or more data value names. I implemented it such that constants are allowed, but I think to prevent the dreaded constant everywhere issue this should be a data value name (from above).

Section: Sensors
---------------------
This lists all the sensors within the scope of the process. If the process contains sub-components, those components would have an sensor section as well.

Sensor: Type (what kind of effect is desired); name (referenced by tests); one or more data value names. I implemented it such that constants are allowed, but I think to prevent the dreaded constant everywhere issue this should be a data value name (from above).

Section: Tests
---------------------
This lists all the tests within the scope of the process. If the process contains sub-components, those components would have an test section as well.

Test: Sensor (name of sensor to evaluate); ActionOn (evaluation criteria, such as less than, equals, greater than or equals); list of effector name and action to take (start or stop).

Section OnStart
-------------------
This lists all the effectors that should be run on the first tick when the internal process's first executes.

I'm not an expert on parsing, but what I would like is something that is readable enough so applications can be developed without a GUI.

Any thoughts?
Attachments
CosaSamples.zip
Hello world and Hello loop sample files
(1.04 KiB) Downloaded 624 times
sparky
 
Posts: 22
Joined: Sat May 22, 2010 12:34 pm

Re: Development of an IL

Postby sparky » Tue Sep 21, 2010 5:33 pm

Updates to the files above, that incorporate components in the main process.
Attachments
SensorLoop.zip
(989 Bytes) Downloaded 613 times
sparky
 
Posts: 22
Joined: Sat May 22, 2010 12:34 pm

Re: Development of an IL

Postby harry666t » Sat Sep 25, 2010 1:21 pm

I have tentatively chosen to use an XML-based format. I envision using a GUI to develop the file, but I'll leave that exercise to someone else.


Oh really? I thought COSA was all about composing programs through drag'n'drop...

I'm still undecided on if a pure sensory application will work.


Show me a real-world example of something that couldn't be done in a "pure-sensory" environment.

Byte arrays need an encoding parameter so when strings are input or output the correct encoding is used.


I recall that Guido van Rossum (of Python fame) was criticizing Ruby designers' decision to store encoding per-string (vs. globally). I can't remember the actual argument against this, but maybe it's worth looking for the post in question.

By the way, is this the correct abstraction layer to worry about string encoding? Shouldn't it be the job of the library that handles text IO?

This lists all the effectors that should be run on the first tick when the internal process's first executes.


This list is IMHO unnecessary. If there is no user input (in the form of external signals), what is there to do?

I'm not an expert on parsing, but what I would like is something that is readable enough so applications can be developed without a GUI.


Not going to happen. I've already brought to your attention that a COSA component is essentially a set of objects with lots of many-to-many relationships between each other. If you really want your programming experience to feel like doing SQL JOINs with intermediate hashing tables, all in your head, while the rest of us is doing drag'n'drop development, go on, I can help you create the least unpleasant syntax we could come up with, and even work on a parser.

Sometimes to proceed, you need to unlearn what has been the meaning of your life so far. If you want to be a productive COSA developer, you will need to embrace visual programming, or you will stay far, far behind.
harry666t
 
Posts: 48
Joined: Thu Mar 11, 2010 7:38 am


Return to COSA Application Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron