mem'mgt's array range checking

3.26: adda/mem'mgt/array range checking:

Java requires range checking on
every array access

. that must be a misunderstanding,
one reason you would set limits on
for-loop var manipulation
is so you could check the array access just once
during the first entry instead of every re-loop ?
. I was worried about how to
efficiently do range checking
but my segmented memory idea is not efficient anyway!
. it's an array of 256 ptrs to
data arrays of some small size like 4k,
the bits are divided so that the high 8bits
will address the ptr,
then the lower bits will address into the data array .
. perhaps this is a bit too low level to commit to;
instead,
you program to a higher interface,
and then let a mem module of the translator
try out various strategies for mixing ideas about
segmented mem with other ideas like
copy to allow array growth .
. either way, the lang' I'm mapping to is c,
and that requires me to explain
just how I avoid alloc'block bounds errors .
. modular arithmetic does seem the way to go;
eg, if the platform allows
unsigned rollovers of only certain ranges,
then that range is the size my
alloc'd blocks need to be .
023:
. another cool way is to give every process a 16bit range
from which all its blocks come from,
and then that process can
completely scramble its own space
but at least there will be interprocess modularity .

portable translation the pypy way

3.26: bk.adda/Self-Sustaining Systems:
Self-Sustaining Systems: First Workshop, S3 2008 By Robert Hirschfeld, Kim Rose

. pypy offers a model-driven approach
to language implementation:
unlike jython, which diverges from cpython,
pypy is providing a pil (pythonic intermediate lang')
which can then have a backend to every other lang;
ie, the compiler is translating as if
that lang were a cpu intstruction set .
. pypy doesn't try be the intermed'lang for all back ends .
. it has versions for
high level (oop'ish) langs -- eg, {cli, jvm, js} --
and low level langs: eg, {llvm, c} .
. by coding your translator in pypy (Rpython)
you can debug it on the batteries-included cPython system
and then have all these back ends it will run on
-- including c .

. great, now if I could only love python!
3.31:
. this presentation assumes jython diverges
simply because it's rendered in a
different code base;
but jython differs for a deliberate reason:
it didn't want to just be another python
that happened to be runnable on a jvm,
it wanted a lang customized to complement the jvm;
whereas, cpython wants a lang that is
basically customized to complement ms`windows .

xml modeling

3.26: adda/xml modeling:
. the basics of xml started with
putting "(br) -- line break -- in angle-brackets;
because, angle brackets classically mean
a formal parameter,
as seen in language syntax diagrams .
. this formalism was required because
-- despite their being a standard for text --
there was no unambiguous representation for
line structure: { cr, lf, cr-lf, line's char count } .
. another (incidental) property was that
angle brackets were separating text that was
not meant to be taken literally;
and, this was the basis for
extending the use of angle brackets
for any text that was not to be taken literally .
. the basic structure of {sgml, html, xml}
is to have a pair of angle brackets for
each opening and closing element .
. using that way, there's a restriction on
literal text containing angle brackets;
whereas,
with a parenthetical method (described next)
there's a restriction only on
un-paired parentheses, and the use of the
code-starting symbol: [!]
which can be chosen to be both
very rare in literal text
and easy to write, read, and find .
. the math-english way would have made use
of parenthetical symbols:
{literal text ...}
[!]
block-name( parameters,,, ):
(
{literal text ...}
)-block-name
[!]
non-block ( parameters,,,)
{literal text ...}
3.31:
. the lisp way is slightly more compact:
{literal text ...}
[!]
(block-name parameters,,, :
{literal text ...}
)-block-name
[!]
(non-block-name parameters,,,)
{literal text ...} .

syntax for sets, powersets, bags, lists, hypermatrix

3.25: adda/dstr/literals:
. when a var is of type set,
it really means its values are a
powerset of some given enum type.
. another approach is using {a | b | c | ...}
to mean a value space,
while {,,,} means a set that involves multiple values .
. let dots do hyper-matrix structuring:
( ,,,; ,,,; . ,,,; . ...)
while in set braces, dots delimit items in a bag:
items in a bag are not ordered but duplicates are allowed;
eg, { 2 . 2 . 3 } is the bag of primes for 12 .
vs list { ;;; } which has duplicates but is ordered .

an interface's value literals

3.25: adda/type literals:
. a full adt description needs both a
set of operations
and a set of value literals .
. definitions of type enum are listing
just the values
because the set of operations are from
the scalar.class,
which by definition include certain operations:
relationals (equality, inequality),
assignment, and functions for expressing values as
an integer or string:
ord is the value's place in scalar order;
val is the numeric encoding of the state;
image is the graphic view of state
-- typically a character string
but can also be an icon:
. every graphic icon has a title (a filename),
and many images have nothing but a title;
eg, to describe the state of color,
you'd use the name of the color without necessarily
mapping it also to a colored block image .
[3.31:
. perhaps the most natural way to show in an interface
that a set of symbols are the type's value literals,
is to express them as the return values of the function:
image()
-- understood to return the type's value literals:
`image.{ v1, v2, ...} .
`val.{ n1, n2, ... } could then show
by correspondence with image,
the mapping of images to codes (assuming val was
contracted to be part of the interface) .]

typedef syntax vs terminology trade-offs

3.25: adda/oop/classes vs types:

. if using 2 keywords for defining class vs type,
the class could mean a type that is an
adt (abstract data type),
so then one could replace the type`def's
angle brackets (used for an interface literal)
with a simple enclosure
since a class`def would always be an interface,
and would therefore no longer need a variety
of enclosures; eg, t.class: (,,,) .
3.30: adda/dstr/nominally typed structs:
. another way to avoid various enclosure types,
is to use typing of parentheses:
(.braces ,,,), (.set ,,,) .

. any reason to reserve the terms"{class, classwide}
for the way ada uses the concept of class-wide ?
[3.31: adda uses class-wide semantics universally ]
. notice the english meanings of
"(what type) vs "(what class),
or "(typical) vs "(classical) .
...
. a good reserved meaning for "(class) vs "(type),
is when dealing with generics,
eg, the class of scalars
includes many enum.types .
3.27:
. generally, the meaning of "(class) within the
field of logic -- the origins of oop nomenclature --
is a set defined by a predicate .
. a class can include many types,
and for many reasons .
. the type.classes of interest to oop and generics
are those where membership is defined by
shared interfaces .

multi-interfaces

3.24: adda/multi-interfaces:
. just as oop classes have different interfaces for
clients vs subclassers,
adda needs a sublanguage for describing
multiple interfaces
and the various actors that can access them .
. dimensions for having separate faces include:
roles, security levels, priorities,
business arrangements (eg, cripple.ware vs full-service),
and partner name (where the degree of allowed reuse
depends on which partner is doing the reusing ).

high-level uses of pointer and possessive

3.22: adda/dstr/high-level uses of pointer and possessive:
. both pointers (as seen in subdirectory syntax)
and possessives (as seen as component selection by structs)
can be seen as different ways to express the same thing;
but one way they express different things
is that ptr's don't imply ownership
as they often implement sharing .
. shouldn't adda use the {pointer, possessive} symbols
for the model views?
ie, ownerships can be impl'd with pointers,
but if the understood relation is ownership,
then the pointer should be written as a possessive mark .
that idea may be the same as this:
the important thing in design is to follow an interface .
3.31:
. indeed, this was really an empty debate,
since these operators do have different interfaces,
and it's the writer -- not the lang designer --
who has control of which relation to make structures with .

arrays and structs compared

3.21: adda/dstr/array vs record:

. a remaining problem is how rec's and arrays
are the same yet demand differing syntax?
ie, why not rec#field?
instead of rec`field
or use array`item
instead of array#item ?
. during use, rec's and arrays are
not the same:
refering to them both as functions: domain -> codomain;
only arrays can leave some of their domain undefined
according to limits set by the attributes:
array`length
or array`last .
. also, the arg for #()
is expected to be an expression returning enum
while the x in rec`x
is expected to be a symbol literal .

. if you want an array treated as record
you can define it like one: a.(e1.t, e2, ...)
-- e2 has same type as e1
since the default typing in a list
is the same type as was last defined .

. you could also treat record like an array
by keeping type info in a tag field:
rec#.tagged
where tagged is:
( val.tall --. ptr to any type .
, typeis.symbol --. indicator of val's current type .
) .

degrees of freedom in function typing

3.20: adda/oop/degrees of freedom in function typing:

. a valuable freedom of expression I first saw in Python
is what might be called the anonymous protocols .

. is there some way to minimize syntax declarations?
the most general form is something like
{-, /}
where it can be either unary or binary,
and you know when it's binary because
either it will have an infix position
or it will be a prefix to a binary list .
. then the way you could sort out ambiguities
is to leave it up to the implementation
to be precise about
what arg arrangements it expects .
. just as in lisp,
every syntax in {uniop, biop, multiop}
can be reduced to a single arg
that is a list of various sizes .
. the default function signature is for an operation
(ie, a function where all param's have the same supertype)
then every operation is expected to support
a list of any size .
. this would work for num.type
if /x would mean 1/x
just as -x means 0-x;
and, if any list was greater than 2 args,
it could be recursively evaluated as a
list of binary operations .

. the oop paradigm I've had in mind
has assumed there's some efficiency
in the convention that
supertypes were declared by name,
so that then param's could be typed by name,
and finally there were 2 ways to find
matching function calls:
(1) eg, int+real:
. the operands will all have the same supertype,
so the compiler can search that supertype
for a matching operator .
(2) lib`fn(num); ... fn(int):
. the function may be in a nearby library,
and the call's arg will be compatible with
the function's declared arg .

. but does that work as a contract?
if I'm not mentioning the arg length,
then can't the caller and server
disagree on that ?
. isn't there generally a problem with
parameters sometimes being misplaced?
and don't we solve that by declaring our
parameter structures?
. there should be language for
both cases:
when needing the freedom of genericity,
and when needing help with conforming to
efficient, picky param' formats .

syntax for picky functions in an adt:
. say arg x needs to support an operation f,
where x is not just any place in f's arg list,
but is the 2nd arg,
and the 1st arg is of t.type .

eg, x.< f(first.t, x) > .

3.22: web.adda/cs/generics:
. generic programming is defined as when
all obj's are typed exclusively with
abstract data types .

syntax designed around url

3.20: adda/cstr/syntax:
. if adda is supposed to follow url syntax
how would you explain # as a multiplicity?
. I was concerned that book#2 is confused with
book having a chapter#2 .
. an url is about an address,
and when a file is being adressed,
it usually means enter the files beginning
-- so the file represents one address
rather than a number of them .
. there's no denying that adda's #-sign
has a meaning similar to url's;
the problem is when extending that
to english names:
what english really does with book names
is make the enumeration part of the name .
. books might use a colon to separate the series.name
from the issue.name .

anonymous and literal adt's

3.19: adda/oop/anonymous types:
. abstract typing means a symbol's useage
is declared in terms of operations;
eg,

( num.type: <+, -,  /, *>;
, x.num .
)

. that example could instead be
written with an anonymous type as:

x.<+, -,  /, *>

. despite that being harder to read,
a benefit is that a simpler syntax
with fewer exceptions;
the alternative is disallowing all type literals;
ie, having to name all types !

3.19: todo.adda/oop/abstract literals:
. adda still needs a way to express
literal abstract types symbolically
rather than as a list of operator literals .
... that gets back to question of
how to express a union of types:
ie, I'm not listing the available operations
I'm listing the names of types
that will list available operations .

3.21: adda/oop/abstract type literals:
. how is adda allowing new types in terms of old
without assuming the old and new are
assignment compatable ?
eg, does it impl' type color with number
yet still warn of type mismatch when
number is used as a color?
--. actually,
that wouldn't be a good example since
the system should support physics' way of
typing numeric obj's with dimensions;
ie, (x color) returns a color defined by
the numeric value of x .

. adda still needs a way to say
a type's interface is the same as a given type
but also say they are not compatable types;
eg,
my.type: another.type`face;
--. here,
a type's face returns an interface literal;
eg,
the literal face of numbers is

<+,-,/,*, abs(), sign(), ...> .

. to merge many faces, use union:
(face u face ...)
--. if a face is a set
are you calling the face literal a set notation ?
a set is any unordered list in which
duplicates can be tossed .

review of aggregate-type`literals:

record var with anonymous type: rec.(v.t, ..)
record type: (v.t, ...)
array var with anonymous type: array#(v.t, ..).t
array type: #(v.t, ...).t .
-- array type literals can also symbolic:
#enum-range-symbol.t,
or enum range literal:
#{e1, e2, ...}.t .

. notice functions are sets {,,,}
but arrays are structs (,,,)
according to the design of their literals;
there were 2 issues to juggle:
have all struct's literals indicate type uniquely,
but also keep things making sense without special rules .

. for types' literals
the combination of enclosure and content syntax
are what identify which type they are:

enum: {symbol, ..}
record: (v.t, ...)
function: (x).t
adt: < symbol, ...>

. in the adt,
symbols are assumed to be any number of args
unless the arg is specified;
an operator listed without a parenthetical
means 1,2, or more args, with infix accepted .
. abs() means one or more args
but as prefix only, not infix .

. for functions with multiple param's
of various types: f(x.T1, y.T2, ...)
when an param's type is not given
that means its the same type as
the adt's name;

eg, G: < f(x, y.t), ...>

-- x is type G like so: f(x.G, y.t) .
. if num.type has this function:
image().#.char
it means:
image(x.num).#.char .

fundamentalist engineering

3.18: adda/fundamentalist engineering:

. seems portable lang's always have a
problem with not really being that portable
due to diff's between platforms
in services or features .
. the worst cases are when most platforms
support a feature
so then the lang binds to it directly:
eg, environment var's (en'vars)
then on a platform like ppc,
that doesn't support en'vars,
the lang's manual must explain
that any code using en'vars will not work!?
. the way to handle cross-platform variation
is to always be using
thick rather than thin bindings .
. the thick binding would make sure that
some reusable set of lang features
could be doing the same job as
a dedicated en'var binding .

. en'vars are differing from other files
how?
. their format is a dictionary(string->sting);
one per user acct .
. if you'd never heard of en'vars before
you could be clued into their existence by
the lang's platform resources file
which dynamically lists
what is currently available
(special files, mounted volumes,
service api's, gui's, etc) .
. in terms of the lang's fundamental features,
en'vars would be globals
shared among all app's
that are acting as implicit param's .
. every platform can have an en'var
because when a platform doesn't natively provide them,
the lang already has the generic tools
that can implement and declare them .
. the key to portability then
is lisp's way of
using symbolics fundamentally:
finding the elements or atoms
from which all molecules can be defined .

mail is high-priority

adda/concurrency/mail is high-priority:
3.16:
. process`mailboxes can be used for impl'ing
the notifications system .
. notice that sched'priorities can change
when the mailbox is updated;
because,
any mailbox could include commands that when run,
will change the mailed agent's priorities .
. so all mail reading should be high priority ?
3.17:
. the mail could work like we have ours,
where the sender can know in some cases
that sent mail has a certain priority;
also,
a service could declare that its priority
could never depend on its mail
due simply to the nature of the service .
. of course,
any of those self-declared priorities
are all relative to priorities known by the system:
eg, the highest priority is always
giving prompt service to the real-time user,
and that induces a high priority in all dependencies .

notifications support

3.16: adda/notifications:

. after reading about dev.mac's notification system
I'm wondering how adda, too,
can provide this service .
. existing parts of adda should be reused
when possible;
eg, all coprograms having mailboxes .
[3.29: coprograms include all concurrent processes:
coroutines, tasks, type-mgt's,
and other background services .]

multi-level interfaces:
. you can see notifications in action
during a debug watch-point command:
that makes execution stop at
any code that modifies a given obj .
. this is economically possible because of
the multiple levels of interface
where all the high-level entries
use just one low level write function;
so, then an obj's write function
can be replaced with a
(call me instead of writing);
likewise, in the same way that
classes can be subclassed,
objects within the same class can be
individually customized
so as to facilitate notifications .

3.17:
. this can be done while still
reusing class functions
by having every object include
along with a tag
a watched bit for impl'ing notifications .
. the way to identify an object
is that every object
-- even when on the stack rather than heap --
is part of a process with an id#
and then part of a call path:
eg, process#2/sub1/sub2
. or,
every object is part of an act'rec ...
(this needs a proof,
but the future looks bright);
anyway,
the run-time exec' is checking the watched.bit
during each object access,
and if it's set,
then it's got that obj's id,
which is used to look up the object
in a notification database
to see what about the object is customized .
. the db can provide
the conditions under which
notifications need to be sent out,
and can also keep the list of
which mailboxes should be notified,
or what actions need to occur
if a certain trigger is set .

3.16: addm/notifications:
. assuming every obj has a watched bit
for impl'ing notifications:
. a problem with letting arbitrary obj's be watched
is it brings down performance across the entire system
regardless of how little
the watching feature is used ?
. for obj watching to be efficient,
have 2 versions of addm:
one will be checking the watch bit,
while the other version will ignore it .
. every process has a pointer indicating
which virtual processor it's being run on .

comment's terminator shouldn't be a period

3.15: adda/comment/terminator shouldn't be a period:
. if using the period to end a comment,
then it's messy to use periods for
segmenting parentheticals;
conversely, it's not user-friendly either to
impose syntax on users' comments,
or make additional arbitrary rules .
. better to have syntax reusing other rules;
eg, use the [this is one lexical unit].enclosure
along with a comment operator:
--[here is a fine comment]
and then not use double dash
for any other operator .

key to concurrency support

3.14: adda/translation/concurrency
. the recently found scripting lang, falcon,
has good support for concurrency
-- very impressive .
. might be good code to reuse for adda;
but c++ code and with multiple authors
might be quite frustrating for a
beginner of the lang .
. it doesn't take a lot of coding
with an elegant design;
the key to concurrency
is the recent idea for coroutine translation:
every sub is converted to a coroutine
and a yield placed in every recurrence
(loops, upward goto's ...).

act'rec as implicit parameter to coroutine

3.11: adda/translation/coroutines/act'rec as implicit parameter:
. after seeing coroutines for c
I saw a way that uses
another implicit parameter:
the param is a record of
all the routine's needed locals,
along with a yield pointer .
. it returns that record,
and then is called with the same record .
. when called again with the same record,
it uses the yield pointer to jump to where it left off .
. this gets a bit messy when
the yield is inside loops:
this is not really a problem with c,
where loops are very primitive:
a for-loop is just a while-loop is just a
combination goto and conditional
-- you can goto anywhere .

complex apply syntax

3.11: adda/complex apply syntax:
. if functions can return functions,
eg f x x = f(x)(x) = g(x) = y,
what about prefix functions returning biops? eg:
x f(x) y = x g y = g(x,y) .
. need to be careful about where to draw the line between
writer's expressiveness,
and reader's sanity .

macro -- compilation needs context

3.9: adda/macro/compilation needs context:

. when defining macro's that are etrees
rather than text substitutions,
a complication is the context needed:
. a macro is modular, yet it assumes
enough context to be compilable .

. but when does it need compilation?
it could instead have delayed compilation?
. for simplicity, for those reading the code,
you want it to be compilable
at least to the point so that
the etrees being formed are like those that
the reader gets when doing a mental parsing .
. back-end compilation and type-checking
can be done dynamically, at run time .

SOP (subject-oriented prog'ing)

10.3.16: adda/sop (subj'oriented prog'ing)

. exploring falcon's "(mop) (msg'oriented prog'ing),
the mop interface is this:

VMSlot: VM Interface for mop operations.
getSlot: Retreives a MOP Message slot.
subscribe: Registers a callback to a message slot.
unsubscribe(a callback): Unregisters from a slot.
assert(on a msg`slot): Creates assertion .
retract: Removes a previous assertion on a message.
getAssert: an assertion.
consume: use the currently broadcasted signal .
broadcast: to every callable item subscribed to a message.

--. this reminds me of Minsky's frames .

. ibm might have a slightly different meaning for mop;
they talk about mop being the cure for
component-fragility or
component-structure fragility
-- this is referring to the silliness that comes from
implementing oop as structs containing
pointers to function pointers .
. the example they give is:
register_sale(item, store, customer)
which a silly-oop Java call would have to express
as one of these:
item.register_sale(store, customer)
store.register_sale(item, customer)
customer.register_sale(item, store) .

"(. the essence of component-fragility.
is when calls for a service
are dependent on which of the data involved
happen to carry the implementation.
. in mop, the msg broker knows
which object carries the function .)

. that example is similar to the problem I had
with conventional understandings of oop:
for binary operations like addition,
conventional oop was doing this: x.+(y)
when what was really going on
was this:
num's-add( destination.num, x.num, y.num)
where num is a supertype or
class of types sharing an interface:
{real, integer, complex, rational, ...}

. in the example of registering a sale,
there are 2 objects: {store, customer}
--
it doesn't need to involve the item;
because,
an object interface is primarily needed
only for controlling modifications
not mere accesses .
[3.29: or, a good reason in this case is that
none of the operations on an item are binary .
... still no clarity during double-check ... .
]
. after a sale,
the store has more money and less item,
while the customer has the opposite .
. in this transaction,
the item was just a constant id number .
. the abstraction of the transaction
is this:

    [register a sale](store, customer):
(
store`mailbox`+
  customer`[ask for sale](payment);
store`agrees?
 store`[locates item];
 ok`= store`[request transfer](payment);
 ok?
   customer`pocket`+
     store`[receipt and item] .
)

. so, registering a sale is simply
a classic example of the need to
mix oop with procedural programming;
ie, it's actor transaction directing,
where the purpose is to orchestrate objects .

. perhaps ibm's mop is merely saying the same:
that there really is no place
for a system where "(everything is an object) .

ibm's Message Central project

. at ibm's Message Central project
the goal is to enable widespread use of
component-based software,
[3.29: the way hardware is engineered? ]

. ibm`mop tools include:
SAGE (Scalable [inter-component] Adapter GEnerator),
and the
Continuum programming language
[translates oop'ish designs into]
reconnectable components.
. sage is based on tools for
sop (subj-oriented programming),
which is a type of aop (aspect-oriented prog'ing) ...

. ibm`Hyperslices are generalizations of subjects from sop .

sop at ccs.neu.edu:

"(Subject-oriented programming focuses on
operations as join points
(vs statement-level join points)
and functional aspects.
Some examples of functional aspects being
best described in terms of operation join points
are:
Persistence, error detection and handling,
fault tolerance, logging, tracing
and metrics-gathering.)

. sop was first defined here: (pdf)
ibm` Harrison & Ossher`
Subject-oriented programming: a critique of pure objects
Proceedings of the Conference on
oop, Systems, Languages, and Applications, 1993

. here we've seen that sop's gist is basically
the same as ibm's mop?
[3.29: or at least ibm`mop's motivation
is the same as sop's .]

Subject-oriented design: towards improved
alignment of requirements, design, and code
Conference on
oop Systems Languages and Applications
Proceedings of the 14th ACM SIGPLAN conference on
oop, systems, languages, and applications 1999

go! prog'lang is not google's go!

10.3.27: news.adda/lang/go!

[3.29: . Go is google's exciting new systems lang;
and, by following the go forums,
I learned of yet another exciting lang,
for higher level programming .
. go! is a multi-paradigm lang that's concerned with
agents, concurrency, and ontology-oriented programming .
(. fans of [go!].lang were complaining about
google's "(go) ripping off their [go!] name .) ]

. since go! borrows from L&O (logic and objects).
the name might come from G being
the icon of a flipping L .

. Go! for multi-threaded deliberative agents:

"( Go! is a multi-paradigm programming language
that is oriented to the needs of programming
secure, production quality, agent based applications.
It is multi-threaded, strongly typed
and higher order (in the functional programming sense).
It has relation, function and action procedure definitions.
Threads execute action procedures,
calling functions and querying relations as need be.
Threads in different agents communicate and coordinate
using asynchronous messages.
An agent's reactive and deliberative components
are concurrently executing threads
which communicate and coordinate using
belief, desire and intention memory stores.)

. go! is included in networkagent @ sourceforge

"(. networkagent is a group of systems for
building network-oriented intelligent agents,
consisting of
an agent communications infrastructure,
April - an agent construction programming language,
Go! - a logic programming language
and DialoX - an XML-based user interface engine) .

Falcon prog'lang features support concurrency

3.11: adda/lang/falcon:


choice of Falcon-ada over Python-c:

Falcon supports many programming paradigms,
including those supported by Python,
but additionally message oriented and tabular.
Finally, it seems to have builtin in concurrency support,
rather than supporting it as an after-thought
like Python
- and concurrency was one of AuroraUX's stated goals.

[3.29: AuroraUX Operating system:
AuroraUX operating system is robust via
Ada-coded Unix Shell Interpreter,
and OpenGL library toolkit .
. user can access software from
DragonFly BSD, Solaris, GNU/Linux 2.6
via ABI system call emulation .
. scripting with FalconPL, Perl and Lua
. user space coding with Clang/LLVM tool chain .]

Falcon's creator Giancarlo Niccolai 2009:

. went open source in 2009;
falcon is based on C++, whose Virtual Calls
are actually more efficient than
the switches [needed by objectified c coding] .
[3.29: supported by Kross?
Kross is the scripting framework for KDE 4;
a scripting framework allows binding of
arbitrary scripting languages
to the object system .
. kde's currently available scripting engines
include Python, Ruby, JavaScript and Falcon PL .]
BlastWave's Dennis Clarke is Falcon-coding the
BlastWave open source package repository Web interface
and is helping in porting all the Falcon codebase
to Sun platforms – the AuroraUX SunOS distro
has adopted Falcon as its official scripting language .

. many no-way-back points in the design,
[and at least one reversal:]
. dropped support for stateful functions,
(for building stateful machines)
because every function's {enter, exit}
was spending time checking whether
its instance was stateful .

a brief tutorial:
. comprehensive overview .

Falcon applauds AuroraUX:
. try out AuroraUX, an emerging Open Solaris
distribution that comes with Falcon .

falcon vs python, lua, ...:

. like php it supports [Document Templates]:
ie, embeds scripts into text document.
(basis for server-side dynamic page generation) .
. like lua it has coroutines,
and prototype-orientation .
. uniquely provides "compile-time metaprogramming",
full multi-threading,
native internationalization,
{functional, tabular, message} programming

--[ . they wouldn't call python even partially functional?
. the facts page calls coroutines
lightweight parallelism -- where the vm provides
time slicing and context switches;
I thought that was what threads were .
. according to lua, coroutines are
cooperative multitasking featuring yields,
where it yields control to a particular sub:
instead of calling that sub,
it is resuming where that sub last yielded .]

3.16: bk,web:
. wikipedia.org's Falcon concurrency .

explore falcon's groups:
. includes interfaces supporting various orientations:
. the mop ( message-oriented programming) interface
is this:

VMSlot: VM Interface for mop operations.
getSlot: Retreives a MOP Message slot.
subscribe: Registers a callback to a message slot.
unsubscribe(a callback): Unregisters from a slot.
assert(on a msg`slot): Creates assertion .
retract: Removes a previous assertion on a message.
getAssert: an assertion.
consume: use the currently broadcasted signal .
broadcast: to every callable item subscribed to a message.

iConsume confused with iDevour

3.23: pol/openware/
iConsume gear won't endanger iProduce gear:
. Cory Doctorow, makezine 2006.11 p16
says that because pc's are potential hdtv tuners,
the drm requirements placed on receiver parts
would spread to all pc parts .
. that wouldn't make sense because
drm is esp'ly for iConsume gear;
whereas, there will also be a market for
computers used as iProduce gear
-- to produce what is being consumed;
and, design of computer parts will be
most efficient when confining tuner req's to
tuner modules,
so there will always be cheap parts for
building pc's that are useful to open source
and the sampling of open content .
. the same hysteria is being applied to
Apple's iConsume line (ipad, iphone, etc)
which are seen as a dangerous precident
having even open content
controlled by the unit's drm
-- why would ipad ever mean the end of iProducers
like the imac and macbook?

3.22: news.addn`gear/mac/ipad is drm happy:

. DRM is used by Apple to control
installation of software
and to regulate every use of movies
downloaded from iTunes.
Apple furthermore claims that
circumventing these restrictions
is a criminal offense, even for purposes
that are permitted by copyright law.
. critics of DRM have asserted that
publishers are insisting on the restrictions.
However, on the iPhone, iPad, ...
Apple does not provide open content publishers
with any way to opt out of the restrictions

robotics (cyber-physical systems) gets gov funding

news.adds/robotics (cyber-physical systems) gets gov funding

When Robots Invaded the Senate

At the heart of “Robots” are resilient mixed-criticality systems
called cyber-physical systems (CPSs) .
. the National Science Foundation
discusses the basics of these systems
and details a recent luncheon briefing and open house
on CPSs for members of the U.S. Senate.

. Cyber-Physical Systems (CPS) Solicitation Frequently Asked Questions .
. CPS Summit site .

CPS Summit Report (pdf):

Despite the 70-year history of computing
and the 200+- year history of engineering physical control systems
the fields of computer science and control theory
have remained largely separate, both technically and culturally.
This separation extends to virtually all domains where
computers interact with the physical world.
Methods for designing computer systems and physical systems
are based on simplifying assumptions about each other
that limit the range of systems that we can build.
On the one hand, computer engineering cannot translate
requirements for physical systems, such as stability,
into computational requirements on performance, power consumption, etc.
On the other hand,
control and signal processing theory
has abstracted computers largely as
infallible numerical devices.
This simplification ignores many important aspects of computing,
such as increasingly larger timing variance
due to caches and energy management
and increasingly higher software error rates caused by complexity.
The viability of future CPS must also address
noise in measurements,
inaccuracies in actuation,
disturbances from the environment,
and faults and failures in the computational process
in a coherent, unified framework.