parasail is big win for reliable concurrency

12.7.2: news.adda/co/ParaSail
(Parallel Spec and Impl Lang) is by Ada's Tucker Taft:

first siting of parasail:
11/09/11 Language Lessons: Where New
Parallel Developments Fit Into Your Toolkit

By John Moore for Intelligence In Software
The rise of multicore processors and programmable GPUs
has sparked a wave of developments in
parallel programming languages.
Developers seeking to exploit multicore and manycore systems
-- potentially thousands of processors --
now have more options at their disposal.
Parallel languages making moves of late
include the SEJITS of University of California, Berkeley;
The Khronos Group’s OpenCL;
the recently open-sourced Cilk Plus;
and the newly created ParaSail language.
Developers may encounter these languages directly,
though the wider community will most likely find them
embedded within higher-level languages.

. ParaSail incorporates formal methods such as
preconditions and post-conditions,
which are enforced by the compiler.
In another nod to secure, safety-critical systems,


explorations of virtual memory

7.1: adda/vmem'mgt/intro:

. in our virtual memory stack system
we are replacing each of the stack's
subprogram activation records (act'rec's)
with a pointer to a resizable object
(ie, it points to an expandable array in the heap );
thus, the stack [8.29:
-- if we didn't have a stackless architecture -- ]
becomes an array of pairs:
( return address
, pointer to act'rec
) . if our allotted ram is getting full,
we can file the obj's attached to earlier parts of the stack
or even file earlier segments of a very long stack .


dialogging exceptions

7.28: adda/cstr/dialogging exceptions/
syntax and fleshing out semantics:

. in adda, dialogging exceptions are
the kind of exceptions which are not call-killing:
they simply give the caller a chance to
fix things in the event of a missing resource:
eg, if a service finds a parameter missing
such as when a file is found to be unreachable,
it will give the caller's file-missing handler
a chance to assign a new file url to an address .
. dialogging exceptions are basically like
implicit parameters that accept a procedure for
what to do in the case of an exceptional situation;
ie, in the usual exception,
the service is quitting and that kills
the whole block that called that service;
so control jumps to the block's exception handlers;
whereas, in the case of dialogging exceptions,
the service is not quitting;
it merely calls an exception handler .]

. for dialogging exceptions,
the handler is expected to return a resource;
so we need syntax for an exception's
returning a value;
it's like a signal but you need a
pointer or inout param because
it's not just reading but writing to the param .
. what if the handler can't help?
if the param is a pointer
it can return nil to indicate failure
indicating the handler is of no help,
so the service then knows to
clean up and throw a returning exception
or give some other indication of failure .
. it's just like a dialog is to the user;
and in that situation,
the user can either find the resourse
and ok the dialog, or cancel it .
. for our example, the service declares:
FileNotFound( f/.filename ).dialog;
-- notice the arg is a pointer type;
and then the handler responds like this:
# a return would be ( f/`= $the/find.txt; );
-- the "(/) is dereferencing the pointer;
and, the target is assigned a literal filename .
# a cancel would be ( f`= none )
-- the pointer itself is assigned no address .
. how are we dealing with
pointers that are sent across processes
(ie, how is an arbitrary pointer being thread safe?);
well, in the case of exceptions there are no surprises;
because, it's by invitation only:
the exception raiser is providing an address
for the caller to put a patch into .

8.9: ok,cancel as dialog-local keywords:
. another idea is that the handler's parameter
needs to be an out-mode not a pointer;
and, to handle the dialog
it assigns to the parameter and calls ok;
if the handler has nothing to return,
then it calls cancel to
allow for the service to clean up,
and then it can either propagate an exception
or make a change in strategy,
and then exit from the enclosing block,
or enter some tagged block; eg,
( --. begin a block containing a dialog handler .
[service that needs a file](f)
-- call the service that may dialog later .
on FileNotFound( out f.filename ).dialog:
( f`= [find a new file];
[file was found] ? ok
else: ( cancel; raise MissingResource )
) --end of block with a dialog handler .]

ways of referring to non-locals

7.28: adda/function/ways of referring to non-locals:
[8.8: intro:
. when namespaces are nested
such as when a program contains subprograms,
the usual situation is called shadowing
which means, for example, that if
subsub is within sub is within main,
and they each declare a symbol, x;
then each scope sees only its own x .
. if subsub wanted to see main's x,
it might specify a pathname;
eg, global/main/x .
. we might also require this for all globals
just to make it easy on the reader;
because if symbol y were not defined in subsub
yet subsub was using it,
then  we have to look in every superscope,
(sub, and main, in this example).
whereas, if we require pathnames for globals,
then the reader instantly knows the meaning of
global/main/sub/y .]

. instead of refering to a scope's ancestors
to reach globals,
we could use "(global) treated as root of fs
to reach non-locals .
. "(parent) is useful as a namespace root,
but if you're going to have a parent.keyword,
users will expect a grandparent as well
(gparent, ggparent, gggparent, etc) [8.8:
so that instead of writing global/main/sub/y
it can be compacted to gparent/y .]
. of ways to identify globals,
it was suggested that we could recognize
such roots as {global, parent, gparent, etc};
but in our case,
the global namespace will be static
(no symbols are added after compile time);
so that gives us an advantage
that will make it easier on the writers:
all they need to do is find
some unique subset of the url,
and then we can identify the full url
by doing a bottom-up search
comparing the leaf first . [8.8:
... however, chances are,
that is hardly reader-friendly;
if the name seems long, and it's used much,
then use renaming: ( x: gparent/x; ); 8.9:
nevertheless, we can have the compiler
use this system for helping both readers and writers,
by letting writers abbreviate, and then
expanding abbreviations to help readers .]

obj' messaging to clarify what's functional

7.28: adda/function/
oop's obj' messaging as a syntax for inout params:

[8.8: 8.16: intro:
. the usual way to manage objects is to
define their interface with a datatype declaration;
eg, t.type: ( ... ) -- that interface can include
both subprograms ( f( x.t ) )
and obj'messages  ( x'f ).
. up to now, that interface declaration
was the only place where we could
define obj'messages;
whereas, subprogram could be defined anywhere:
. there are various declare blocks
( package, record, subprogram, etc).
that can instantiate objects of type t;
eg, (.int:  ... )
-- that's a block that returns an integer;
and, anywhere an object can be declared,
we can also declare subprograms that are
local to the current declare block .]

declare blocks can declare obj'messaging:
. obj'messaging can be seen as
a special style of parameter,
where f(inout x) is instead written as ( x`f ).
. in the context of a type declaration,
( x`f ) is declared simply as ( `f );
because, x is assumed to be
any of the datatype's instantiations;
so, we know what x's type is,
but in a subprogram's declaration of ( x`f )
x's type would not be known;
so, the sub's declaration
would look like this: ( (x.type)`f );
and, a generalization of this would be
(x.type1, y.type2, etc)`f
which is useful for making it obvious that
x,y,etc are all inout parameters;
then we can reserve the syntax ( f(x) )
for functional uses of x,
ie, where ( f ) is not modifying x
nor modifying anything x can access;
ie, if you want to pass a pointer, p,
for the purposes of modifying p's target,
then the needed syntax is p`f, not f(p).


lang's should document pragmatics

7.21: adda/doc's/intended use as related to resources used:
. here is part of Python's Recommendations
for a library's coding style:
"( Code should be written in a way that
does not disadvantage an implementation of Python
For example, CPython's a += b or a = a + b
is an efficient implementation of
in-place string concatenation;
but in Jython,
the ''.join() form should be used instead.
This will ensure that concatenation occurs in
linear time across various implementations.)
[ie, jython is about java is about oop;
and if you have something like
( a = a op x ) to say in {oop, java, jython}
the oop way to do that is a.op(x)
and if you're a big oop fan and said
( a = b op x )
it's assumed you would never do so for
the case where (a) is the same as (b) .]
. this reminded me that part of
documenting a language
should be not only what the resource usage is,
but also the intended application;
ie, it should warn you if it's
not the most efficient way to do something
and point you to what is .

mixing strings and numbers

7.17: adda/type/mixing strings and numbers:
. suppose the (+)-opererator can be used for
both addition and concatenation;
if we have to eval (string + number),
then the coercion should be to string,
since every number has a string image,
but not every string can eval to a number;
therefore, we should have it so that

nested subprogram pathnaming

7.17: adda/syntax/nested namespaces of various impl's:
. what is the path delimiter for nested name spaces,
main/sub or
. notice if a file system were
pre-declared and const,
then pointers are not needed;
so, the path is x.y.z not x/y/z .
. nested subprograms need not be const's;
they can be redefined at any time
without having to recompile the superprogram;
but the question is moot; because,

folder naming like internet subdomains

7.12: adda/dstr/folder naming like internet subdomains:

. in the naming system for subsystems,
the naming of a folder can have a special meaning
because the folder represents
something like a website;
so, just as the top domains
(.com, .org, .net ...)
indicate a website's role type,
these folder types ( .pkg, .type )
can indicate top level domains in our
network of modules .
. later that system would change so that
(.pkg) was the implicit datatype
of any untyped folder
if it was within adda's path .]

. a module can be divided into several folders
by using subdomains; eg,
given these top-level modules:
( int.num.type
, real.num.type )
we can see that both int and real
belong to the same datatype, num;
so, when importing num.type
we're reaching all the folders named *.num.type .

8.8: on the other hand:

atoms equivalent to tuple singletons

7.7: adda/syntax/atoms equivalent to tuple singletons:
. does a function's arg need a parenthetical?
ie, can we say( f x ), instead of( f(x) )?
if (f x) can be the same as f(x),
then all atoms (such as x)
can be seen as singleton tuples (ie, x=(x) );
so, then there's no need for adda to copy
Python's singleton tuple syntax: ( (x,) ).


one call for trees of operations

7.22: addm/one call for trees of operations:

. the key to efficiency will be
providing support for integrated use of
both oop and concrete types;
ie, if the tree needs to be done fast
or in a tight space,
then the compiler uses native types;
but if it needs to handle polymorphism,
then it uses the type-tags,
and sends it to an oop type .

biop* oop:
*: (binary operations)
. the problem with the popular oop model
is that it is not helping much for biop's;
so, we should consider the binary parameter
to be one obj;
and, we again have oop working .
. this has always been implicit in my design;
biop oop works by featuring
2 type tags per arg: (supertype, subtype);
eg, (number, integer);
and then we don't have to worry about
where to send a (float, integer)
because they both have
the same supertype: number .
. this note was just pointing out
that I was realizing the syntax x`f -- vs f(x) --
was ok; whereas, previously
I had howled that oop was absurd because
it turned (x * y) into x`*(y)
as shorthand for asking x's type mgt
to apply the *-operation to (x,y);
what oop needs to be doing is (x,y)`*
as a shorthand for calling the type mgt that is
the nearest supertype shared by both x and y,
and asking it to apply the *-operation to (x,y).
8.15: and of coure,
oop langs like c++ need to get their own lang
and stop trying to fit within C,
so then we can go back to (x*y)
as a way to write (x,y)`* .]

dynamic linking to video driver

7.11: bk.addm/Gordon Letwin`Inside OS#2:
[8.13: intro:
os/2 was microsoft's next big thing for 1998,
but it never happened despite being
a leap forward in security .
. in this reading session,
I was wondering how it dealt with the issue of
unstable drivers . intro's dynamic linking .]
p89: the familiar static linking:
. the linker handles static links by
noting which symbols are marked external
and hooking those up with similar symbols
to be found in accompanying .obj files .
p29: the new dynamic linking:
. dynamic linking is how operating systems can be
extended or patched by the user or the apps;
just like hardware can accept new circuit boards .
. because drivers needed protected mode
there would need to be a mode transition
with every write to the display
but we avoid this by having apps
not access device drivers directly;
rather they do so through dynamic linking .
[. how does that explain it?
is dyna'linking facilitating our ability to
run device drivers in user mode?]
. dyna'linking to the video display driver
is possible because it doesn't require
hardware interrupts;
drivers are generally located in the kernel
only because some are needing access to
hardware interrupts .


7.27: adda/cstr/signals:
7.30: intro:
. pyqt signals are a system of inter-object communication;
any object can emit a signal
to convey that some event has occurred;
and, any other object may connect a signal handler
to be launched whenever a particular object
raises a particular signal .
. signals can return any sort of record,
and the corresponding signal handlers
are expected to declare their parameter's type
to be the same type as the signal's returned record .
. pyqt sees signals as launching slots
and then the act of connecting a signal handler
is filling such a slot with a subprogram .
. there can be multiple connections to a slot,
so the slot is often filled with multiple handlers .


first-class cocoa scripting

7.3: web.adda/the ruby lang like nu
has a scriptable interface to cocoa:
. nu and macruby have a scriptable interface to cocoa
that is direct, not like macpython
which merely embeds a portable engine .
. hello, MacRuby!
MacRuby's source, and dev' Resources;
motivation for the project,
and, how it works:
The Libffi library is used
to create closures at runtime
and inject them, either in
the Objective-C runtime or YARV,
but also to perform C or Objective-C calls.
. Libffi is also used by CPython's
standard ctypes library.

IPC (interprocess communications)

7.1: adda/co/IPC (interprocess communications):
. the mvc pattern means that
programs don't use a gui directly;
rather, programs are designed to be
used by other programs,
and if a human user needs access to a program
then we pair it with a gui-producing agent
-- that's the controller in my definition of
mvc's model-view-controller .

. keeping the mvc pattern in mind,
the parts we see from the gui
are the program's exported obj's
or the content of IPC* channels .
*: (IPC: interprocess communications).

. just as human users of a program have a
view window for seeing an exported obj's state,
programs as users of other programs
have a view that consists of a buffer,
like what is offered by a file server
(rather than loading the whole file in memory,
it places the first unread chunk into a buffer)
. what buffers have in common with
user view windows
is an indication of which segment is being buffered
(the starting offset, and the buffer size).

. while subprograms typically communicate with
one or more out-mode params
(including the return value
which is actually an implicit out-mode param),
subprocesses communicate via IPC channels,
which are generally equivalent to
gui windows and menu systems
that are being used by a program instead of a human .

. each process can see its channels in a list;
and, just like the file browser's detail view
is showing the attributes of files,
attributes of a channel include:
content type, obj size,
buffer size, buffer's current location,
and process being communicated with .
. such a list of channels is a matrix:
channels are the rows,
and attributes are the columns . [8.8:
. in addition to showing a process's channels,
we might also want to see the system's channels:
the columns of that matrix would include
all the processes a channel could be connecting;
and, the matrix cells would indicate the mode:
does a process just read from the channel,
or also write to it? ]

compared to parameter modes:
. just as parameters can have modes {in, out, inout},
channels can be {readonly,  writeonly, read&write}.
. if both ends can read&write to the channel,
which one is the {importer, exporter}?
importers have access to menus and dialogs,
exporters have access call entry queues
which are storing the service requests
that resulted from clients' menu selections
(these requests include any records
that have been generated by dialogs).

. in order to have channel users being equals,
instead of having a client-server relationship,
they should both be importing the same channel
from a 3rd-party server .


gui notification systems

5.18: adde/gui/notification systems:

. all processes can inter-communicate;
but, processes are also hierarchical,
eg, apps represent root processes,
while owning a set of subprocesses;
so, intercommunication happens only between
siblings and ancestors (parents, grandparents, etc).

. the gui display is seen by apps
as a list of pointers to obj's that draw images .
. making an obj gui-visible means
adding a link to this gui list .
. since most app windows are a
tree-like arrangement of objects,
the gui list items are usually trees (lists of lists).
. the first on this list corresponds to
the front-most window;
apps can change the order of this window list
unless barred by the user;
but, of course, the user controls
only the top level of this list,
since the trees underneath belong to
particular apps not the user .
. in either case, it is the owner who decides
who can see or modify their possessions .

. if x.app (an app named x)
gives embedding rights to y.app,
then x.app accepts offers to
list a given item in its own gui sublist;
this allows apps to work together on
generating parts for the same window .
. the default capability is to allow nothing
(no reading and no modification);
so, by default, when reading the gui list,
non-self sublists appear to have no parts,
just a link for contacting the owner .

. the system is following an mvc pattern;
so, when putting an obj in a gui sublist,
what is actually posted there
is an image (view of mvc)
of the obj (model of mvc);
ie, each datatype can draw an image;
and, each time a gui'd object is modified,
this must cause the object to emit a signal
that will result in the obj's gui image being updated .
. finally, a gui image update must
signal to the gui mgt
to recopy that image to the screen buffer
and recopy every overlapping image,
or somehow avoid overwriting overlapping images .
todo: need ideas from QT how to arrange it  .


dialogs generated from type declarations

3.16: adda/type"gui/
dialogs generated from record.type decl's:

. the pyqt dialogs can be automated;
they are just like records
with a name of a field by a field value .
. the field`type determines the field value's widget type:
# short enum's can be a radio button;
# long enum types can be pull-down menu
or combo dial and value box .
. to validate a widget's input from the user,
we can run the adda compiler on it .

(x as type) conversion syntax

3.23: adda/type/syntax/conversion:
. adda conversions should be like python:
because try doing it the other way:
if the type needs param's,
then it's not obvious whether this is a param'd type
or a type converting a value .

3.14: adda/syntax/conversions look like dimensions:
. in some situations, we may need to
specify the literal's datatype
with a conversion syntax;
conversion should work like dimensions,
as factors: a value is followed by its dimension .

. I'm wondering if that starts to look messy
for general expressions vs literals ...
we'll have a full expression
and then be expecting either a
terminator or a binary operator,
so then finding a typemark means a
conversion of the previous subexpression
(an atom, or a parenthetical).
. does ( f(x) type ) apply to f or x?
. maybe just as there is (x: type)
there could be (x:: type -- conversion)?
but that is counter to most popular uses of [::].
. ada may have had the best idea:
typemark( ... ) would tell you
that typemark was converting (...) .
. a compromise might be ( x(typemark) )
but that could be confused with
function application
-- and the same applies to ada's syntax
since we may want a conversion by
a parameterized type:
typemark(arg)(thing to convert)
-- lots for a reader to remember .
. the keyword "(as) would be memorable:
x as typemark
-- although people coming from Visual Basic
might be confused .
. using english is literally too wordy,
but conversions are mostly automatic,
and shouldn't be seen too often .]

 3.23: adda/type/syntax/context specification:
. perhaps the best syntax for specifying a value's type
(in contrast to converting a value to some type)
is to use the possessive syntax:
where x can be any symbol defined by the type,
or be an parenthetical expression that is
returning a value of that type .

Python's generators and coroutines

2.16: adda/cstr/1st-class functions/
generators and coroutines:

. a generator in python
is a function identified by it's body:
it's calling yield instead of return .
. the easier way to view this
in a typed lang, like adda,
is to set the return type as a stream ?
. streams are conceptually like files
so they should work like files;
eg, to restart sequence do an
f.open(name of generator instead of file) .
. streams are like sequences, in that
seek(n) can be done by restarting the generator
and asking for an nth item .
. the coroutine in python is like a generator;
but instead of streaming output,
it has a streaming input:
f`open mycoroutine(init);
f`put (some data to send to it) .
. it could do put's to output, and get's to input;
being both a generator and a coroutine .

generic parser

2.23: adda/translate/generic parser:

. if there is a generic parser,
then it has to record spaces(n) and new lines,
because the meaning of symbol sequences
will often depend on whether a space
is separating them .
. this may not help me anyway since my interpretation
can depend on whether a name is a type id or not?

. one thing that does simplify things
is a parser that does find and tree
the enclosures and delimiters
-- {} () [] , ; : .  --
along with some other un-redefinables .

. it also supports implicit enclosures
(the use of indentation to indicate a grouping)
so it needs to translate ( newline & (some spaces) )
into the beginning or continuation of an enclosure;
and, there needs to be a parameter for
what the currently expected indenting level is .

. if it can find (symbol.type) as being a type def,
then it can also find ( .symbol ) as being a type; [2.29:
but, types shouldn't require a preceding dot .]

. strings of alphanum's that start with alphabet
are always names .
. enclosures include set generators .