#stackless #python dis- #continuations

11.20: news.adda/stackless python/dis-continuations:
Christian Tismer 2000:

. this paper presents an implementation
of "Stackless Python" (a Python which
does not keep state on the C stack) .
By decoupling the frame stack from the C stack,
we now have the ability to keep references to frames
and to do non-local jumps.
This turns the frame stack into a tree,
and every leaf of the tree can now be a jump target.
While exploring this idea,
we will recognize ordinary function calls and returns
to be just special cases of so-called continuations, ... .

why should stackless be popular?

. the maximum recursion level would be a user option
and not a limit set by C's stack .
There would be pickleable execution states;
that means you can save your running program
and send it in a file to another computer
where it can continue running .

module permissions

adda/cstr/module/permits:
12.8: intro:
. just as corporations are composed of
people with various levels of trustability
and access to classified resources,
a program is composed of modules
that are trusted with various sensitive resources
by being being granted a permit to gain access .
. obvious things in need of permissions
include access to the file system, internet,
or the user's contact list .
. recently under consideration
is the idea that modules need to get permits
before they can access any other modules .

implicit parameters

10.4: adda/cstr/module/specification/implicit params:
. another dimension of the module's specification
is access to certain implicit parameters:
ie, it would expect every caller to have
certain locals having specific names,
as well as specific types .
. that's no different than a var param
except it's constant; ie the declaration is saying
I don't want just any local you care to assign,
I want a local with a certain name .
12.8:
. this is like what a nested subprogram can do;
but is trying to apply the same idea to
non-nested subprograms .
. the generic way to give a subprogram
an implicit parameter,
is have the subprogram packaged in a tuple,
and have the other fields of the tuple
be pointers that can linked to locals .
. the tuple is declared locally,
the links are set to locals,
and then, whenever the subprogram is called,
it uses the links as implicit parameters .

exceptions ok unless requirements preclude

1.30: adda/cstr/exceptions/ok unless requirements preclude them:
. I thought Parasail's author explained somewhere
how exceptions really messed up multi-threads;
review my blog of that ...
(parasail-is-big-win-for-reliable).
. I decided a thread hang was no big deal;
in critical applications
exceptions are absolutely useless;
but if our point is to encourage programming
we should cater to all styles of thinking .
. we just need to protect the coder's user too:

read-only and write-only params

8.14: adda/cstr/function/syntax/read-only and write-only params:
 if a parameter gets a pointer, (eg, /.int)
then it can be modifying both the pointer and the int,
so, shouldn't we have a syntax for expressing
what the algorithm intends to do with both?
. so, we still need a syntax for what is read-only .
. if a parameter expects a read-only,
then we can give it a modifiable
while expecting that it won't modify it .
. how about syntax for write-only?
maybe we should use (.typemark^) for that?
[11.11:
. the latest idea obviates a read-only syntax:
(inout param's)`f(x) -- in that example,
the x param is in-mode only (read-only)
that includes both the pointer and its target .
. notice that if the input is shared by any co.programs,
then we need to lock it as read-only or copy it,
unless we expect it to rely on the interactive value .]

signaling in gui systems

8.12: adda/cstr/signals/signaling in gui systems:
how is the gui related to the signal?
. as a summary of 2012/07/gui-notification-systems
I was thinking gui's should be impl'd with
gui-optimized signals,
rather than the general signal system,
but then I wondered if that idea was
keeping mvc in mind,
so that generally all IPC (interprocess communications)
would be seeing the same windows that a
human can see with the help of a gui agent .

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 .
[7.29:
. 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 .
[8.8:
. 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 .
ipc:
. 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 )
)-FileNotFound
) --end of block with a dialog handler .]

signals

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 .

IPC (interprocess communications)

7.1: adda/co/IPC (interprocess communications):
intro:
. 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 .

views:
. 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 .

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 .

libraries and namespaces

6.14: adda/library/authors include system, app, client:

. Python has 2 libraries to choose from:
standard and local .
. Ada has one library with any number of modules,
including standard.package .
. instead of ada's one library,
there should be 3 libraries, one for each author:
system-authored -- the standard modules;
app-authored -- the software developer;
client-authored -- the user of the app .

. libraries can be specified by the app author,
(system is adda/aModule, local is ~/aModule )
but specifying this is not necessary because
the app's local library is always checked first;
ie, if an app author wants to use a system module
they simply abstain from giving any local modules
the same name as the needed system module .

. module providers can define
what other authors they want used
and in what order .
. notice that while many commercial wares
are arranged by author,
many openwares are arranged by project;
ie, each project represents an author collective;
but these collectives then have branches
which might represent either author subsets
or target-specific variations;
so, the typical explicit local path will be:
~/myProject/myBranch/myModule .

6.15:
. the client's library can have subfolders for
each of the authors: system and each app .
. the compiler always gives the client the final say,
so that if the users want to modify (system/x.pkg)
they write their own in (client/system/x.pkg).
. if the author requires that they not be modified
then a commercial version of the compiler
would alert the user that their modification
is being ignored due to contractual obligations .
. in the open-only version of the compiler,
the user would be unable to install commercial wares .

6.18: adda/library/hierarchical librarians:
. we could also have the idea of hierarchical librarians;
ie, just as the typical librarian is local to the file system,
rather than applying to the entire local network
or to the entire internet,
so also, a librarian could be local to a folder .
6.19:
x : dir-name/type-name
. what was the library structure defined by ? ...

6.14: adda/type/record expressions vs literals:

. being required to statically type vars
is not a loss of freedom because
we can declare a var to be tall.type,
which means it may include any type
(tall typings are like tall tales,
leading t'all sorts of things ...).

. what should the import syntax be?
my first idea was that explicit importing was mostly unneeded,
because by typing var's,
we implicitly import that type's module;
but there are other types of modules to reuse .

. think of the orthogality:
when defining var's in a name space,
these are actually fields in a record literal;
. just as data types may define both literal values
and expressions that return values;
so too we should be able to define record structures
with either literals or expressions .
. ada uses {with, use} for expressing this .

. a situation similar to importing is inheritance
so importing should have the same syntax .
. a recent proposal for such syntax was
(3.23: adda/oop/syntax/sections for use, is, has).
. it suggested 3 new keywords:
# use:
. for an interface to import a module;
they may refer to types other than self
that are not in the top-level library .
[6.15:
. here's all the places a type's name can get reused:
app's pkg, pkg's of other authors being imported
wanting a system type
even though app has redefined that type name
in one of its own local modules .]
# is:
. for supertypes,
establishing type compatibility .
# has:
. for listing the type's known subtypes;
eg, number.type has all of these subtypes:
int, real, quotient, complex, modular .

. I thought a good word for "(import) was "(has),
but if possible I should make sure that
the keywords have similar meanings
when used by inheritance and namespace definition .

7.2: todo:
. I need to show the diff's and similarities
of inheritance to namespace definitions .

6.15: adda/library/anonymous record declarations:

. why not do imports by declaring records globally,
and then instantiating records?
and instead of (with; use),
do an anonymous instantiation;
ie, instead of (x.myrec), say  (.myrec)?
but if we have multiple anonymous record declarations
with conflicting component names,
we have no way to resolve the conflict
because we have no root name to specify .
[6.19:
. we could use the type name as a root,
and use either record instances or rec'types .
. rename is done like this (x: mypkg)
while using original name is (: mypkg)
and if conflict use (mypkg.component).
. anything on the right side of colon must be a
library item, either an instance or a type .
. might be easier on the reader's eye if we
always required renaming when importing rec'instance .

. should we always have an implicit ada'use in force
for if a naming contention exists ?
here's the reason ada'use is optional:
it is filling the name space;
and, these included names can't be redefined now;
better to use ada'use the way ada uses it .]

. Ada's packages are like record instances
-- in contrast to record types;
Ada'with(package) allows the instance to be
visible to the current scope .
. packages in the Ada library may include variables
(this is how Ada can define global variables).
. by being instances instead of record types,
the included variables are being shared by
every process that includes such a package,
ie, a global record instance .

. subrograms are types not instances;
when we have a pointer to a function
what we have is a constant template
which can be shared by numerous
function activation records,
just as numerous record instances
share the metadata of a record type
that is in control of record instance formatting .
. thus, a function activation requires a pair:
(the name of the subprogram providing the template,
and the address of an activation record);
when we speak of a process,
this pair is what we're refering to;
(6.17:
but when concurrency is considered,
then a process implies a triple:
the 3rd component of this triple is a
thread of execution:
either the id of the processor it is using,
or a task mgt record
for controlling a slice of the processor's time ).

. global variable instances can be confusingly shared by
many authors' processes;
so, a global variable should be registering
which processes are using it,
and be able to tell us which processes have been involved;
likewise, any subprogram that can
spawn tasks which can share its local var's,
creates a situation where processes share a var
but this is not so confusing because
it doesn't involve sharing among various authors .
[6.16:
. the way globals are shared by various authors
can also be happening locally,
if we can import a package that expects
the eviron to provide a sharable var .
[6.18:
. but maybe this should not be happening;
if you want an import to use your locals
it should exist as parameterized record type,
so then a parameter used during record instantiation
is passed the address of locals it can use .
... or how about this:
. when a type is instantiated by a client,
in addition to allocating an instance,
it also gets some sharing space in client
which the type mgt can use for keeping
meta info or parameters
that are relevant to just a particular client's set of
a particular type's instances .
. this new space would be similar to class var's,
except that instead of being shared by all members of the class,
they would be shared only by those members
that were owned by a particular client
ie, contained in a particular subprogram activation record
or a declare block .
. so then, if type mgt's can do this,
instantiated records could also .]

. other confusions with what's global include
# the internet is the top-most global,
# one's local network is global to a file system .

. we can think of global var's as
implicitely inheriting from registering
(no process can access the registering type
without getting registered).
. if we want registering behavior for a local
we must explicitly have it inherit from registering .

. my initial concern with vars being shared
could only happen because the author put the var there,
but there could still be surprises among an author's subprograms
because the author's client can choose to
run more than one of the author's sub's at a time .
. an imported sub' should be able to
declare a non-local var as a dependency
in order to have symmetry with the idea that
subs can access non-local vars;
and,
that feature should be orthogonal to
the feature of a sub being reusable .]

pre- and post-conditions

4.18: adda/cstr/function/pre- and post-conditions:
. we need a syntax that extends a function's type expression
to include the function's pre- and post-conditions
which are predicates that reduce the function's space
by testing both the input and output for certain conditions .
. math syntax sometimes uses the (|) operator for such work .
. perhaps the new syntax for a function type literal could be:
(x.t).t | (pre-condition; post-condition) .

defining returns out of declare blocks

4.10: adda/cstr/declare blocks/defining returns:
. ideas for what declare blocks can do to return:
idea#1:
. it has its own return y so if it wants the parent to return,
it has to do a (parent `return).
idea#2:
. it can't use the return stmt for itself,
instead the return is the final stmt's return .
[4.30:
. later I had the idea of using (be ...)
as the declare block's return statement .]

implicit declare block complication

4.6: adda/cstr/declare block/
complication of being implicit:
. the problem with not needing a
special symbol for declare block,
is that if I happen to be in a parenthetical
but I was declaring a var meant to belong to the enclosing body,
then under the current system,
the fact that I've made a var declaration in a parenthetical
has converted that a declare .
. the way out of this is to use a path name
to show where the declaration is being made:
( ../belongsToEnvirons.t;  ).
4.29:
. there was also the idea of typing the parenthetical
in order to declare it to be a namespace,
so then untyped parentheticals would not be
deallocating what was declared within them .

(be) is return statement for declare blocks

3.20: adda/cstr/declare expression/be stmt:
. adda's declare blocks can be expressions,
so they should have their own return stmt
that means what the declare block is returning
rather than what the enclosing function is returning .

signals are another dimension of interfaces

3.5: adda/cstr/signals/another dimension of interfaces:
. pyqt's connector lets an object's method
emit a message to a notification center,
which then relays the signal by launching an instance of
"(on signal do call this list of functions
which can include emitting an object's signal;
use qobject`connect to add to the todo list
of a signal of some object ).
. signals are like gui's mousedown(coords) event,
which means it emits a signal to the eventqueue,
and you can respond to events by connecting the signal
to your subprogram named:
[what I do when a mousedown happens].
this works like a framework class
where it has methods for you to define
so it knows what to do for you .
. they are a new control system
more similar to exceptions than to object functions .
in fact an exception is a special kind of signal
just as a task type is a special kind of datatype .
. I like to think of object communications in human terms
like telephones and mailboxes;
emitting a signal is like publishing a newsletter;
people can subscribe to your newsletter
by naming a mailbox .
. then that address will be just for that newsletter,
and you have one of your staff there (a subprogram)
waiting to respond to what that newsletter says .
. this responder subprogram is called a slot .
. a list of publishings can be seen as a
dimension of a type's interface
except that rather than being a type member's requirement,
it explains what is expected of clients of the type's members;
ie, part of the type's service is
keeping you uptodate with these newsletters .

3.23: adda/cstr/unify exceptions, dialogs, and signals:
. a dialog is like a gui dialog:
the caller provides a callback
and if the callback comes back before a timeout error
then the server continues
else it does a dialog-failed exception .
. the exception works like ada's:
it signals a failure (type, details), and then terminates .
so the block's exception catching part
should look like the signal catcher parts :
they are both interrupt handlers .

set generator syntax

2.23: adda/cstr/set generator:
(^ x,y,z: int . f(x,y,z) )  -- this is the set generator;
see how the power param is terminated by a period?
the reason that can't be the usual math operators {: | }
is due to (:) being confused with the label declaration
and with other math uses for (| ) .
. (x.t, y.t) can also be defined by ( x,y: t ).
2.29:
. even if it was ok to overload (| ),
the form of it is opposite of what I need:
math puts the control var to the right of (|):
{ f(x) | x in t }
when I want the control var as the head:
{^ x in t .
 f(x)
} -- that way var's are declared before they are used,
and it's easier to read generally,
when the body of the generator is getting large
(I have to admit that for math's one-liner's,
the math way looks neater ).

dynamic module import

2.18: adda/cstr/dynamic module import:

. dynamic module import?
at first I was perplexed at how to parse functions
if you can't be sure what's active,
conflicting with each other in the namespace .
. but this does work out; and,
it's essential for the mandate to have
complete lisp-like control over your machine .
. lisp can treat any control structure (live or template)
as if it were also data:
inspecting its space, and then using what it finds .
. this could be called having 1st-class plug-in's .

parsing for conditional imports:
. this will be like generics, but instead of
the programmer specifying the type of instance,
the run-time is checking parameter types,
to figure out which of several subprograms to run .

. after an explicit import,
rather than just a situation where a program
looks around the file system on its own,
some of the imported names may be overloaded .
. if multiple imports are conditional,
then we must assume that any combination
of imports will happen .
. the programmer may have it arranged such that
in practice no overloading ever occurs;
but generally this can't be known at compile time .
. therefore,
we should be responding to every import
without regard to the condition intended;
and, if there is then overloading,
we should tell the compiler user
that a run-time binding has been used,
so they have the option of specifying a particular module
rather than slow things down by
testing the run-time param'type in order to
find the suitable subprogram from among
the multiplicity of modules currently in effect .

. a run-time binding works like this:
the function to call is dynamicCall,
which is given the intended subprogram's param's,
along with a link to the intended subprogram's symbol
(found in the caller's run-time symbol table);
and, that symbol has a list of pointers to
the subprograms of the same name
in the various imported modules .
. in summary,
the symbol table needs 2 listings:
one for the types it finds,
and another for the other (instance) symbols .
. in a simple example with no run-time binding,
the symbol table's list of instance symbols is temporary
(not of use after the compiler is done);
but, in the case of needing dynamic calls,
the symbol table needs a permanent list of instance symbols  .

addm's case instruction

addm/cstr/case/large domain space issues:
[1.8: intro:
. for a classic case stmt, one ensuring that
no more than one exec'path was activated,
the primary purpose of the variables (and arithmetic)
is to dynamically set the guard ranges .]

if case ranges can be variable expressions,
how does that work at the machine level?
. the alternative execution paths are numbered: 0...n,
so the case stmt is an array 0..n of
pointer to subroutine .
. the pointer could be an offset of the program counter,
so they can be word sized or even byte sized .

[1.8: case method depends on domain size:
. typically for each exec'path,
there is either a list of literals,
or else a pair of possibly variable expressions
delimiting a range .
. next there are 2 cases of domain space:

# small:
. the expression being cased is less than a byte,
or certainly not more than a 16bit word .
. in this case there is a direct mapping
from enum to exec'path number .
. we sort the literal cases,
thus allowing for a binary search during run-time .
. for the case ranges, a..b, c..d, ...,
we need the if/else if ... list:
case => a and case <= b ?
  goto ...
else case => c and case <= d ?
  goto ...
else ... .

# huge: ... ]
large domain space issues:
. how do the cases map to 0..n
when not enum literals?
that's when it loses the efficiency
that case stmt's are known for:
. it's eval'ing every exec'path guard expression
as well as the expression being cased,
then it might be reduced to crawling through
a huge {if/else if ...} list;
what it checks first might depend on profiling:
in the past eval's of this case stmt,
what percentage of time was each case chosen?

1.8: hashing intro:
. the expression is larger than small;
in this case, hashing might work?
in a hash the typical problem is
associating a name with an id# .
. when you find the name,
then you need to replace it with the id#;
you could place the string in a sorted container
in which the insertion operation was cheap;
and then do a binary search to find it,
or you could use the hash method:
. if you expect n strings,
then use an algorithm to turn the string into
a number that can range of n values;
eg, if there are less than 2*^16  values,
then your hash function should return 16bit ints .
. if 2 strings result in the same number
then they both go in the same bucket,
so when your search finds a bucket,
it has to crawl as with the binary search .

1.8: back to the casing problem:
. if the expression being cased is a huge number or string,
then with the literals used in the guard
we build a hash table,
and then hash the value being cased .
. when we find the match,
it's associated with the exec'path number we need .

wild vs proper goto's vs informal looping

1.6: adda/cstr/goto:
. if goto's are jumping high in same the block
the place they jump to need only be typed .loop,
but wild jumps need to be typed .<<>>
. when used at the end to break from a nested cstr,
the goto is a clean jump to bottom,
these are typed .exit? [1.31:
no:
. this is the proper use of goto;
so, it doesn't need a special type,
but every thing should have a type,
and the default type for labels could be .label .]

. to enter wrapup.label
use the syntax (enter wrapup) ? [1.31:
yes .]
. don't use the syntax (exit);
because, it may not be to exit self*
and (exit (current enclosure)) should be reserved for
situations that actually involve
jumping out of some enclosing container .
*:
. the other exits are  {main, parent, thread}
as well as named cstr's {case, loop }.

. at each cstr (any structure that may contain stmts)
there can be a wrapup section named [on exit];
on().proc can also concurrently check
any number of conditions that implicitely
call the given responder routine when the guard is true . [1.31:
eg, on mem-out: (save work; log error) .]