7.1: adda/go.lang/defer:
. go.lang has a defer
that is like a type mgt's finalization routine
only it's used by a function
for things that should happen on return .
. ideas I got from that are:
# on return: ... [7.30:
. "(on *condition*) would generally mean
rule-based vs imperative programming;
so (on return: s) would add (s) to
the list of things to do before returning .]
# self`end`+ ... [7.30:
. this is modeled after i`+ 1
which is shorthand for i= i+1 .
. the self is the current subprogram;
it already has an "(end)
listing things to do before ending;
and a (`+) would add to that list .]
2011-07-30
Ousterhout's dichotomy
7.1: news.adda/Ousterhout's dichotomy:
. John Ousterhout, designer of Tcl,
noticed that high-level programming languages
tend to fall into two groups,
"system programming languages"
and "scripting languages".
[ie you can't have a language that is
optimal for both .
. in defence of that claim,
pypy tried to have a system language Rpython
that was as much as possible like
Python, the scripting lang;
because they wanted
a self-hosting python compiler
ie, one written in python instead of c .
[7.30: like adda,
Rpython is designed to translate into c
for the purpose of avoiding c:
system programmers can use Rpython
yet still take advantage of c compilers .]
. the closest Rpython could get to python
is a subset of it that added static typing;
because, some features that support
coder productivity
are antithetical to features that support
algorithm efficiency .
. Ousterhout was likely pointing out that
scripting lang efficiency was not so important;
because, scripts are glue for
subprograms of sufficient size,
such that most of the run time
is spent in the parts defined by the system lang .
7.30: web:
D. Ancona, M. Ancona, A Cuni, and N. Matsakis.
RPython: a Step Towards Reconciling
Dynamically and Statically Typed OO Languages.
In OOPSLA 2007 Proceedings and Companion, DLS'07:
Proceedings of the 2007 Symposium on
Dynamic Languages, pages 53-64. ACM, 2007(pdf)
. John Ousterhout, designer of Tcl,
noticed that high-level programming languages
tend to fall into two groups,
"system programming languages"
and "scripting languages".
[ie you can't have a language that is
optimal for both .
. in defence of that claim,
pypy tried to have a system language Rpython
that was as much as possible like
Python, the scripting lang;
because they wanted
a self-hosting python compiler
ie, one written in python instead of c .
[7.30: like adda,
Rpython is designed to translate into c
for the purpose of avoiding c:
system programmers can use Rpython
yet still take advantage of c compilers .]
. the closest Rpython could get to python
is a subset of it that added static typing;
because, some features that support
coder productivity
are antithetical to features that support
algorithm efficiency .
. Ousterhout was likely pointing out that
scripting lang efficiency was not so important;
because, scripts are glue for
subprograms of sufficient size,
such that most of the run time
is spent in the parts defined by the system lang .
7.30: web:
D. Ancona, M. Ancona, A Cuni, and N. Matsakis.
RPython: a Step Towards Reconciling
Dynamically and Statically Typed OO Languages.
In OOPSLA 2007 Proceedings and Companion, DLS'07:
Proceedings of the 2007 Symposium on
Dynamic Languages, pages 53-64. ACM, 2007(pdf)
. an approach that attempts to preserve
the flexibility of Python,
while still allowing for efficient execution
is limiting the use of
the more dynamic features of Python
to an initial, bootstrapping phase.
This phase is used to construct
a final RPython (Restricted Python) program
that is actually executed.
RPython is a proper subset of Python,
is statically typed,
and does not allow dynamic modification
of class or method definitions;
however, it can still take advantage of
Python features such as mixins and
first-class methods and classes.
This paper presents an overview of RPython,
including its design and its translation to
both CLI and JVM bytecode.
We show how the bootstrapping phase can be
used to implement advanced features,
like extensible classes and generative programming.
2011-06-30
enum.typed record domains
6.20: adda/dstr/enum.typed record domains:
. in classic lang's like c,
arrays had very different properties
than records .
. in a polymorphic languages however,
records can be more like arrays;
because, although their components vary in type,
the various types often have the same base type;
eg, all types can print their value, etc .
. and any time a record has at least
2 components of the same type,
it could make sense to specify components with
an expression rather than a literal name,
just as is done for arrays .
today's issue is this:
. in trying to unify the concepts of
arrays and records,
there needs to be a way for records to
express their component names as being
some enumeration-type's subrange;
and then, conversely,
any time a record r declares its components' names,
that should induce an enumeration type:
r`domain
-- I'm using the term "(domain) because
arrays and records are like functions;
and, functions in math are known to
input values from a domain type
and output values from a codomain type;
ie, f: domain -> codomain;
or, in adda:
function f(x.domain).codomain,
array A#(domain).codomain
record R.(r1.co1, r2.co2, r3.co3);
R`domain = {r1, r2, r3};
R`codomain = {co1.type, co2.type, co3.type},
. assume there's the enumeration
e.type: {r1, r2, r3};
how should a record say its domain = e ?
R.(r1.co1, r2.co2, r3.co3);
R`domain`= e ?
[6.23: yes,
that lets the record be defined in the usual way,
and then also say that the domain is
not a new declaration,
but rather a reuse of some existing enum.type .]
mis:
. one thing that wouldn't work is this:
R#(e).{co1.type, co2.type, co3.type} ?
-- that would instead be saying
R is an array of enum;
and each var's possible values
are in the set:
{co1.type, co2.type, co3.type}.
--. this could be useful for when
writing programs that write programs:
many of the values they're concerned about
are parts of languages, including types .
. in classic lang's like c,
arrays had very different properties
than records .
. in a polymorphic languages however,
records can be more like arrays;
because, although their components vary in type,
the various types often have the same base type;
eg, all types can print their value, etc .
. and any time a record has at least
2 components of the same type,
it could make sense to specify components with
an expression rather than a literal name,
just as is done for arrays .
today's issue is this:
. in trying to unify the concepts of
arrays and records,
there needs to be a way for records to
express their component names as being
some enumeration-type's subrange;
and then, conversely,
any time a record r declares its components' names,
that should induce an enumeration type:
r`domain
-- I'm using the term "(domain) because
arrays and records are like functions;
and, functions in math are known to
input values from a domain type
and output values from a codomain type;
ie, f: domain -> codomain;
or, in adda:
function f(x.domain).codomain,
array A#(domain).codomain
record R.(r1.co1, r2.co2, r3.co3);
R`domain = {r1, r2, r3};
R`codomain = {co1.type, co2.type, co3.type},
. assume there's the enumeration
e.type: {r1, r2, r3};
how should a record say its domain = e ?
R.(r1.co1, r2.co2, r3.co3);
R`domain`= e ?
[6.23: yes,
that lets the record be defined in the usual way,
and then also say that the domain is
not a new declaration,
but rather a reuse of some existing enum.type .]
mis:
. one thing that wouldn't work is this:
R#(e).{co1.type, co2.type, co3.type} ?
-- that would instead be saying
R is an array of enum;
and each var's possible values
are in the set:
{co1.type, co2.type, co3.type}.
--. this could be useful for when
writing programs that write programs:
many of the values they're concerned about
are parts of languages, including types .
preventing insecure inputs
6.11: adda/abi/insuring security:
[6.13: intro:
. many app's are a security threat because
they are trusted not to smash the stack or heap,
yet will do so if given mal-formed input;
the primary security defense provided by adda
is that all interactions with the stack or heap
are handled by robust system app's .]
. an app may be expecting ascii
and get unicode instead,
but adda typetags would document what was there,
and then the app could take steps to
convert to the prefered type .
[6.24:
. non-native types can have novel structures;
but they are always compositions of
native elemental type;
and, the addx system is helping app's
to read and write the data they exchange .]
[6.13: intro:
. many app's are a security threat because
they are trusted not to smash the stack or heap,
yet will do so if given mal-formed input;
the primary security defense provided by adda
is that all interactions with the stack or heap
are handled by robust system app's .]
. an app may be expecting ascii
and get unicode instead,
but adda typetags would document what was there,
and then the app could take steps to
convert to the prefered type .
[6.24:
. non-native types can have novel structures;
but they are always compositions of
native elemental type;
and, the addx system is helping app's
to read and write the data they exchange .]
oop's multi-dispatch
6.5: adda/oop/multi-dispatch/ working with obj'c:
[6.17: intro:
. according to the wiki,
the term"multi-dispatch refers to
something other than what I assumed it to be
so, I will now explain the diff's .
. everybody agrees on how polymorphism happens
when there is only one argument:
when you write f(x) you mean
x can be any type as long as
x's type defines a function f .
. you don't really know which procedure or method
is being used to define the function f
until you ask x what its type is,
then you use the f-procedure defined by that type .
. that is called dynamic dispatch;
the term "(dispatch) is being used in the same way
as "(taxi dispatcher),
whose decision of which taxi to send
depends on which taxi is free and closest;
likewise, a function call dispatcher
determines which procedure to send the arg to,
and bases its decision on
both the function name,
and the argument's type .
. if the arg is binary,
then a multi-dispatch system has to find
a procedure that is typed for that particular
combination of arg types;
and most such systems use function overloading;
ie, they overload a function's meaning;
eg,
there are many types of cars and motorcycles;
and how a collision turns out
depends on both types;
so then, for each type combination,
you have to define a new procedure
for the car-motorcycle collision function;
that means, for example,
that every time you create a new type of motorcycle,
you have to define as many new collision procedures
as there are types of cars .
. the multi-dispatch system I have in mind
does not use overloading;
rather it expects multiple args to share some supertype;
so, for the cars and motorcycles example,
they could simply share the physics type;
which defines its members as having
a mass and a velocity;
the collision procedure asks both arg's
for their mass and velocity
and then calculates new velocities for each .
. it then sends each arg a message
to change itself to the new velocity,
which each can do with its own version of
a velocitychange(x) procedure .
. that was a simple case because the multi-arg function
could be reduced to a multiple of single-arg functions;
a more complicated case can be found in numerics,
where a binary operation doesn't resolve into
2 unary operations;
. for example, say you had a numeric supertype
that includes only reals and ints;
# it can be overloading the addition function:
+(int, int),
+(real, real)
+(real, int),
+(int, real) .
# or it can use coercion:
it checks to see if types differ,
and then converts one
so both are the same type:
+(int,real) then means a call to
+(real,real);
it then checks whether the destination
is able to accept a real,
or if the destination has a function for
converting a real to its own type .
. now lets say another type, Rational,
is declared to be a subtype of numerics;
this means the supertype procedure for
handling binary operations
has to be updated:
# overloaders then have many more cases to deal with:
{int,real,rational}
x {int,real,rational}.
= 9 cases instead of 4 .
# coercers have another rule to add:
if types differ, then convert ... to ...:
{int,real} to real
{int,rational} to rational
{real, rational} to real .
. in the case of numerics there is a limit to this:
every imaginable subtype of numeric
can be expressed as subtypes of
just these subtypes:
{int, real, rational, complex}
x size-{1,2,4,8byte, huge};
so, for example,
we can declare rainbow to be a subtype of real,
and then the numeric supertype can
-- without ever knowing about rainbows --
see from its type declaration
that it must have a
convert rainbow to real procedure;
and, if a destination is type rainbow,
it again knows from the rainbow declaration
that this destination
has a real assignment procedure .
]-intro
[6.8: 6.17:
. as part of developing for mac,
obj'c features the usual dynamic dispatch .
. the sort of multi-dispatch I have in mind
would fit within mac's type-tagging system;
so for instance,
numerics would have 2 type tags:
# one says it's a subtype of mac's NSobject,
# another is private and indicates
which subtype of numeric it currently is .]
[6.17: intro:
. according to the wiki,
the term"multi-dispatch refers to
something other than what I assumed it to be
so, I will now explain the diff's .
. everybody agrees on how polymorphism happens
when there is only one argument:
when you write f(x) you mean
x can be any type as long as
x's type defines a function f .
. you don't really know which procedure or method
is being used to define the function f
until you ask x what its type is,
then you use the f-procedure defined by that type .
. that is called dynamic dispatch;
the term "(dispatch) is being used in the same way
as "(taxi dispatcher),
whose decision of which taxi to send
depends on which taxi is free and closest;
likewise, a function call dispatcher
determines which procedure to send the arg to,
and bases its decision on
both the function name,
and the argument's type .
. if the arg is binary,
then a multi-dispatch system has to find
a procedure that is typed for that particular
combination of arg types;
and most such systems use function overloading;
ie, they overload a function's meaning;
eg,
there are many types of cars and motorcycles;
and how a collision turns out
depends on both types;
so then, for each type combination,
you have to define a new procedure
for the car-motorcycle collision function;
that means, for example,
that every time you create a new type of motorcycle,
you have to define as many new collision procedures
as there are types of cars .
. the multi-dispatch system I have in mind
does not use overloading;
rather it expects multiple args to share some supertype;
so, for the cars and motorcycles example,
they could simply share the physics type;
which defines its members as having
a mass and a velocity;
the collision procedure asks both arg's
for their mass and velocity
and then calculates new velocities for each .
. it then sends each arg a message
to change itself to the new velocity,
which each can do with its own version of
a velocitychange(x) procedure .
. that was a simple case because the multi-arg function
could be reduced to a multiple of single-arg functions;
a more complicated case can be found in numerics,
where a binary operation doesn't resolve into
2 unary operations;
. for example, say you had a numeric supertype
that includes only reals and ints;
# it can be overloading the addition function:
+(int, int),
+(real, real)
+(real, int),
+(int, real) .
# or it can use coercion:
it checks to see if types differ,
and then converts one
so both are the same type:
+(int,real) then means a call to
+(real,real);
it then checks whether the destination
is able to accept a real,
or if the destination has a function for
converting a real to its own type .
. now lets say another type, Rational,
is declared to be a subtype of numerics;
this means the supertype procedure for
handling binary operations
has to be updated:
# overloaders then have many more cases to deal with:
{int,real,rational}
x {int,real,rational}.
= 9 cases instead of 4 .
# coercers have another rule to add:
if types differ, then convert ... to ...:
{int,real} to real
{int,rational} to rational
{real, rational} to real .
. in the case of numerics there is a limit to this:
every imaginable subtype of numeric
can be expressed as subtypes of
just these subtypes:
{int, real, rational, complex}
x size-{1,2,4,8byte, huge};
so, for example,
we can declare rainbow to be a subtype of real,
and then the numeric supertype can
-- without ever knowing about rainbows --
see from its type declaration
that it must have a
convert rainbow to real procedure;
and, if a destination is type rainbow,
it again knows from the rainbow declaration
that this destination
has a real assignment procedure .
]-intro
[6.8: 6.17:
. as part of developing for mac,
obj'c features the usual dynamic dispatch .
. the sort of multi-dispatch I have in mind
would fit within mac's type-tagging system;
so for instance,
numerics would have 2 type tags:
# one says it's a subtype of mac's NSobject,
# another is private and indicates
which subtype of numeric it currently is .]
alloc'order and size
6.2: adda/mem'mgt/alloc'order and size:
. when using the c lang's dynamic mem'allocator (malloc)
the c`runtime assumes you will be
returning mem in mostly the same order as
when you obtained them .
. if this is not the case,
then there could be heap fragmentation problems .
[6.3:
. use of malloc order may be less complicated
because in modern systems there is v.mem,
so the parts of heap that are
in the way of compacting it
can simply be paged out .]
. the less mem you use at any one time,
the better chance buggy programs around you
don't blow up from exceeding mem limits .
. if needing to alloc mem in a way that could
cause heap fragmentation,
consider how much mem your program is using at once,
and whether you can break it into pieces
that do inout on temp files .
6.17: other strategies:
# at the app level:
. it's easier to find mem even in a fragmented heap
if you're decomposing your mem needs into smaller parts;
eg, instead of alloc'ing 100 contiguous words
for a 10x10 matrix,
you could do 10 alloc's of 10 words each
arranged as an array of pointer to arrays .
# at the os level:
. just as logical files are strings of
many non-contiguous physical mem blocks;
malloc could be impl'ing large mem requests
as strings of smaller mem blocks .
. when using the c lang's dynamic mem'allocator (malloc)
the c`runtime assumes you will be
returning mem in mostly the same order as
when you obtained them .
. if this is not the case,
then there could be heap fragmentation problems .
[6.3:
. use of malloc order may be less complicated
because in modern systems there is v.mem,
so the parts of heap that are
in the way of compacting it
can simply be paged out .]
. the less mem you use at any one time,
the better chance buggy programs around you
don't blow up from exceeding mem limits .
. if needing to alloc mem in a way that could
cause heap fragmentation,
consider how much mem your program is using at once,
and whether you can break it into pieces
that do inout on temp files .
6.17: other strategies:
# at the app level:
. it's easier to find mem even in a fragmented heap
if you're decomposing your mem needs into smaller parts;
eg, instead of alloc'ing 100 contiguous words
for a 10x10 matrix,
you could do 10 alloc's of 10 words each
arranged as an array of pointer to arrays .
# at the os level:
. just as logical files are strings of
many non-contiguous physical mem blocks;
malloc could be impl'ing large mem requests
as strings of smaller mem blocks .
oop storage classes
6.1: adda/type/storage classes:
. recently it was seen how oop's class var's
can be modeled by having vars declared in
the interface type mgt's body
(the implementation module of the interface).
. the same idea can apply to declaring agg' types
(aggregates include the arrays, and records)
which can be just like an interface type
except that an agg's specification can't
declare new operators; [6.20:
ie, the definition of an interface type
is a type that declares
what operations and components
can be applied to obj's of this type;
an agg type is one that need declare only
components .]
. both the {agg', interface} type def's
can declare these 3 storage classes:
# public instance components:
in the typedef's face .
# private instance var's:
in the optional initialization function,
within the typedef's body .
# private class var's:
in the typedef's optional body .
efficiency concerns:
. if the type's face (ada`specification)
doesn't have to declare privates,
then the compiler can never know
what the actual size of an object will be;
whereas, if the face can include
something like: '(privates:0),
then the compiler can potentially know its size .
. however, given the trailer idea
(dynamically extending local mem),
knowing the size is not important anyway:
all act'rec's would have a discriminant bit
indicating the primary record variant:
the one {with, without} a pointer to trailer .
. if with trailer, then any private instance var's
would be on the trailer at that index .
6.1: adda/{begin, end} rename {init,fini}callbacks:
. what I've been calling the {init, fini} routines
should be named {begin, end}
since they mean the same thing in plain english .
. recently it was seen how oop's class var's
can be modeled by having vars declared in
the interface type mgt's body
(the implementation module of the interface).
. the same idea can apply to declaring agg' types
(aggregates include the arrays, and records)
which can be just like an interface type
except that an agg's specification can't
declare new operators; [6.20:
ie, the definition of an interface type
is a type that declares
what operations and components
can be applied to obj's of this type;
an agg type is one that need declare only
components .]
. both the {agg', interface} type def's
can declare these 3 storage classes:
# public instance components:
in the typedef's face .
# private instance var's:
in the optional initialization function,
within the typedef's body .
# private class var's:
in the typedef's optional body .
efficiency concerns:
. if the type's face (ada`specification)
doesn't have to declare privates,
then the compiler can never know
what the actual size of an object will be;
whereas, if the face can include
something like: '(privates:0),
then the compiler can potentially know its size .
. however, given the trailer idea
(dynamically extending local mem),
knowing the size is not important anyway:
all act'rec's would have a discriminant bit
indicating the primary record variant:
the one {with, without} a pointer to trailer .
. if with trailer, then any private instance var's
would be on the trailer at that index .
6.1: adda/{begin, end} rename {init,fini}callbacks:
. what I've been calling the {init, fini} routines
should be named {begin, end}
since they mean the same thing in plain english .
2011-06-28
a brief history of compound documents
5.7: web.adde/compound doc/problems:
. the compound doc is a really simple idea;
it works just like the way that your mac's gui
displays a window of various apps,
except that window arrangments can be
saved as documents, and windows can be borderless
as if they are part of the same document .
. but from reading opendoc's history
you'd think it was a plague .
"(. compound documents are said to be
an oversold concept:
there just aren't that many examples
beyond mixing graphics with text .)
--
. tell that to the html`object tag:
we routinely see combinations of
movies, photo's, text, script images,
and anything you have an app for .
. something about the plague again:
other compound doc specifications
had the same problem!
. the specification should have included
a manifest that listed what app's you need
in order to open a given document .
more compound doc' technology is history:
OLE, OLE Automation, ActiveX, COM+ and DCOM .
[ com is oop++ ]
COM's architect"Anthony Williams:
so, COM must additionally specify:
. the compound doc is a really simple idea;
it works just like the way that your mac's gui
displays a window of various apps,
except that window arrangments can be
saved as documents, and windows can be borderless
as if they are part of the same document .
. but from reading opendoc's history
you'd think it was a plague .
"(. compound documents are said to be
an oversold concept:
there just aren't that many examples
beyond mixing graphics with text .)
--
. tell that to the html`object tag:
we routinely see combinations of
movies, photo's, text, script images,
and anything you have an app for .
. an amazingly bad specification or implementation--
was opendoc's biggest problem:
it was very common to find
apps that could not even
open a document created by another app .
. OpenDoc attempted to solve this problem by
allowing developers to store multiple formats
to represent the same document object.
For instance, it was both possible and encouraged
to store a common format like JPEG
along with an editable binary format,
but in practice few developers
followed this recommendation.
. something about the plague again:
other compound doc specifications
had the same problem!
. the specification should have included
a manifest that listed what app's you need
in order to open a given document .
more compound doc' technology is history:
Dynamic Data Exchange (DDE, 1987),. ms`COM is often an umbrella term for
allowed "conversations" between applications.
OLE(1991, (Object Linking and Embedding).)
was Microsoft's first object-based framework,
and MS`Office's first compound doc' technology;
it was built on top of DDE .
. While OLE 1 was focused on compound documents,
COM and OLE 2 (1992-93) were designed to address
software components (oop++) in general.
. OLE custom controls (OCXs, 1994)
. Internet is a new use for
OLE Custom Controls (ActiveX, 1996),
-- gradually renamed all OLE technologies to ActiveX,
except the compound document technology
that was used in Microsoft Office.
DCOM (Distributed COM, 1996)
competed with CORBA as the model for
code and service-reuse over the Internet.
difficulties getting either of these
over Internet firewalls .
MTS run-time increased scalability, robustness,
and simplified system management.
OLE, OLE Automation, ActiveX, COM+ and DCOM .
[ com is oop++ ]
COM's architect"Anthony Williams:
Object ArchitectureCharlie Kindel 1997:
is concerned with Dealing With the Unknown
and ensuring Type Safety in a
Dynamically Extensible Class Library;
also significant to com
was clarifying what oop`Inheritance is,
and knowing How To Use It .
(popular) oop =C++ supports only oop not cop
Polymorphism + (Some) Late Binding
+ (Some) Encapsulation
+ Inheritance
Component Oriented Programming (cop) =
Polymorphism + (Really) Late Binding
+ (Real, Enforced) Encapsulation
+ Interface Inheritance
+ Binary Reuse” .
so, COM must additionally specify:
* Execution environment options
(so-called Apartments)
* Inter-process Marshalling
* Remote Object Activation mechanism and protocols
* Threading models
. the C++ linkage model impedescom provides what c++ is missing:
binary distribution and reuse .
. by using shared object linking,
the lack of binary standardisation
means there is an interoperability problem .
C++ lacks binary encapsulation:
ie, while it supports separation of
interface and implementation,
it's only at the syntax level
– not at the binary level.
implementation changes are “seen” by clients.
A “substrate” for building re-usable components.
. Interfaces are defined in COM IDL
(IDL + COM extensions for inheritance and polymorphism)
OS Neutral and (nearly) Language neutral:
. can be used from any language that can
generate/grok vtbl’s and vptrs.
. a packed bit field is returned
with every COM access .
categories define
an implementation of a given interface
that meets some set of constraints .
cross-platform task mgt survey
5.4: adde/universal view of task mgt:
. compare the various ways provided by
{mac, pc, linux} to see what's running:
# mac:
. a dock contains your favorite and active apps;
the dock marks currently active apps;
so, it might be called an app.bar .
. the [all windows].key shows all windows
in a non-overlapping arrangement;
the [current app's windows].key shows a similar
non-overlapping arrangement of
just those windows owned by the current app .
. mission control combines the
[all windows].key with the
[current app's windows]`function
by not only showing all windows in a
non-overlapping arrangement
but also grouping windows together
according to which app they're owned by .
# pc, linux:
. a taskbar has icons for each window;
press an icon to bring its window to the front .
# pc (group similar taskbar buttons):
. the taskbar has an icon for each app
and the effect of pressing on one
depends on how many windows that app has open:
if just 1 window, it brings that window to the front;
for many windows,
it shows a menu of that app's current windows;
the user selects one, and that window comes forward .
tabbing:
. all systems use the tab key for
(with ctrl or command) to select a window .
# mac:
show what's active in the dock;
# pc, linux:
list what's in the taskbar .
projectbar:
. usually there's been one desktop
containing all your windows;
if there were more than one desktop
then they could each hold
project-specific windows .
. for this I coined the term projectbar
to match how taskbar is literally
a bar of tasks .
. mac's name for projectbar is Spaces,
and its Dashboard involves the same idea .
. Dashboard uses a key for popping up
a 2nd desktop whose project is
the use of widgets
which are lightweight utilities
like calculators and clocks,
or data displays like weather,
calender, and ticker tape .
. another use of the Dashboard Space
could be task mgt;
where both {dock, taskbar}
are kept on the 2nd desktop .
. compare the various ways provided by
{mac, pc, linux} to see what's running:
# mac:
. a dock contains your favorite and active apps;
the dock marks currently active apps;
so, it might be called an app.bar .
. the [all windows].key shows all windows
in a non-overlapping arrangement;
the [current app's windows].key shows a similar
non-overlapping arrangement of
just those windows owned by the current app .
. mission control combines the
[all windows].key with the
[current app's windows]`function
by not only showing all windows in a
non-overlapping arrangement
but also grouping windows together
according to which app they're owned by .
# pc, linux:
. a taskbar has icons for each window;
press an icon to bring its window to the front .
# pc (group similar taskbar buttons):
. the taskbar has an icon for each app
and the effect of pressing on one
depends on how many windows that app has open:
if just 1 window, it brings that window to the front;
for many windows,
it shows a menu of that app's current windows;
the user selects one, and that window comes forward .
tabbing:
. all systems use the tab key for
(with ctrl or command) to select a window .
# mac:
show what's active in the dock;
# pc, linux:
list what's in the taskbar .
projectbar:
. usually there's been one desktop
containing all your windows;
if there were more than one desktop
then they could each hold
project-specific windows .
. for this I coined the term projectbar
to match how taskbar is literally
a bar of tasks .
. mac's name for projectbar is Spaces,
and its Dashboard involves the same idea .
. Dashboard uses a key for popping up
a 2nd desktop whose project is
the use of widgets
which are lightweight utilities
like calculators and clocks,
or data displays like weather,
calender, and ticker tape .
. another use of the Dashboard Space
could be task mgt;
where both {dock, taskbar}
are kept on the 2nd desktop .
documents as folder trees
5.11: adde/documents as folder trees:
[4.21:
. just as trees of folders can be merged,
the same should apply to documents as well,
with each subtitle being like a subfolder .]
. that introduces a 3rd dimension of merging
(volume, folder path, file);
and,
many merge styles:
# mac style:
. don't merge anything .
# pc style:
. merge folders, replace files .
# versioned merge:
. merge folders and avoid replacing files
by renaming them instead
with appended version numbers .
. the versions numbers rotate through 0...n;
so eventually data is lost .
# subfile merge:
. merge folders and files;
paragraphs are combined rather than replaced
(default is new subsections are appended
to older subsections).
# journaled merge:
. this is like the subfile merge (above)
except that there are instructions such as
delete the nth paragraph of a subsection;
or run a patch over it .
[4.21:
. the journal's files would pay attention to
subtitle pathname
and only then consider character position .
. this is in contrast to the typical
{revision, version}* control system
which measure all changes in terms of
character position .]
--
. intra-document structuring is
necessarily language-specific,
except at the level of characters,
whereas the unix way is tool reuse,
and so the patch tool must be
language-agnostic .
*:
revisions vs versions (terminology proposal):
# revisions are corrections or
efficiency enhancements;
# versions are parameterized configurations
for adapting to various situations
or new design ideas .
[4.21:
. just as trees of folders can be merged,
the same should apply to documents as well,
with each subtitle being like a subfolder .]
. that introduces a 3rd dimension of merging
(volume, folder path, file);
and,
many merge styles:
# mac style:
. don't merge anything .
# pc style:
. merge folders, replace files .
# versioned merge:
. merge folders and avoid replacing files
by renaming them instead
with appended version numbers .
. the versions numbers rotate through 0...n;
so eventually data is lost .
# subfile merge:
. merge folders and files;
paragraphs are combined rather than replaced
(default is new subsections are appended
to older subsections).
# journaled merge:
. this is like the subfile merge (above)
except that there are instructions such as
delete the nth paragraph of a subsection;
or run a patch over it .
[4.21:
. the journal's files would pay attention to
subtitle pathname
and only then consider character position .
. this is in contrast to the typical
{revision, version}* control system
which measure all changes in terms of
character position .]
--
. intra-document structuring is
necessarily language-specific,
except at the level of characters,
whereas the unix way is tool reuse,
and so the patch tool must be
language-agnostic .
*:
revisions vs versions (terminology proposal):
# revisions are corrections or
efficiency enhancements;
# versions are parameterized configurations
for adapting to various situations
or new design ideas .
avoiding freezes with real concurrency
5.21: 6.2: adda/translate/co
there were 2 cases of multi-tasking:
# gui reactor:
. the multi-tasking done for gui response
could really be done by
frequent subroutine calls to the gui handler
instead of swapping threads with it;
because, its endless event loop is equivent to
an endless number of brief loop body calls .
# time-slicing:
. when a program is composed of threads (co.programs),
it expects them to be time-sliced,
so that, for instance,
if there are several things to animate,
each refresh of the screen is showing
what appears to be concurrent activity .
. unlike the gui-reactor case,
there is no way to use a subroutine call for
sharing cpu time with anonymous threads;
because, generally they cannot be decomposed into
an endless number of brief loop body calls .
. a similar case is anonymous co.programming,
where the user runs several programs at once;
this situation is significantly unlike
app-orchestrated co.programming because
user-launched co.programs aren't aware of each other;
so, even if c did support coroutines,
they would not be of use in time-slicing here .
5.22:
. another place where programs can hang
besides infinite looping and recursion,
is waiting for devices to respond;
the addx library designer needs to know
where these hangups are,
and not give tasks direct access to them .
. instead,
the sub is suspended until the wait is over;
and control is given instead to gui reactions .
[6.2:
. it may be the case that
only hardware-based concurrency could provide
the needed protection from device freezes;
that means the base language can't be just c,
but involve c+posix, obj-c + gcd, or qt .]
5.29: web.adda/translate/co/open concurrency api's:
. unix is a std open platform now,
isn't there some concurrency api defined in posix?
. an overview of user-level vs kernel-level
and threads vs processes:
. processes communicate via sockets
pos:
. addx's primary use for threads is that
the main thread is adde dishing up the gui,
and it sends messages to a side thread
for housing the apps that do the actual work .
. while getting bogged down in posix idioms
it occured to me that since my first target is mac,
I should follow what they suggest
in the way of concurrency primitives .
...
there's also qt:
both open, cross-platform and easier than posix .
there were 2 cases of multi-tasking:
# gui reactor:
. the multi-tasking done for gui response
could really be done by
frequent subroutine calls to the gui handler
instead of swapping threads with it;
because, its endless event loop is equivent to
an endless number of brief loop body calls .
# time-slicing:
. when a program is composed of threads (co.programs),
it expects them to be time-sliced,
so that, for instance,
if there are several things to animate,
each refresh of the screen is showing
what appears to be concurrent activity .
. unlike the gui-reactor case,
there is no way to use a subroutine call for
sharing cpu time with anonymous threads;
because, generally they cannot be decomposed into
an endless number of brief loop body calls .
. a similar case is anonymous co.programming,
where the user runs several programs at once;
this situation is significantly unlike
app-orchestrated co.programming because
user-launched co.programs aren't aware of each other;
so, even if c did support coroutines,
they would not be of use in time-slicing here .
5.22:
. another place where programs can hang
besides infinite looping and recursion,
is waiting for devices to respond;
the addx library designer needs to know
where these hangups are,
and not give tasks direct access to them .
. instead,
the sub is suspended until the wait is over;
and control is given instead to gui reactions .
[6.2:
. it may be the case that
only hardware-based concurrency could provide
the needed protection from device freezes;
that means the base language can't be just c,
but involve c+posix, obj-c + gcd, or qt .]
5.29: web.adda/translate/co/open concurrency api's:
. unix is a std open platform now,
isn't there some concurrency api defined in posix?
. an overview of user-level vs kernel-level
and threads vs processes:
. processes communicate via sockets
pos:
. addx's primary use for threads is that
the main thread is adde dishing up the gui,
and it sends messages to a side thread
for housing the apps that do the actual work .
. while getting bogged down in posix idioms
it occured to me that since my first target is mac,
I should follow what they suggest
in the way of concurrency primitives .
...
there's also qt:
both open, cross-platform and easier than posix .
classification by superset decomposition
5.15: adda/oop/type cluster/
templates for subtype association:
[6.1: mis:
irrationals are simply the reason
why some reals are not Q's !
. what is the purpose of knowing how they are related?
isn't it just to know type compatibility?
if you produce an irrational,
you call it a real,
and if you didn't want symbolics
then you'd call it a float .]
. the mgt for type clusters(eg numbers),
may have some reusable code in that there are
many type clusters in which the subtypes have
values that are subsets of each other; eg,
N subsets Z subsets Q subsets R subsets C .
. number is also an example of there being
another way of describing subsets:
superset decomposition
(showing how a set is composed of other sets).
. saying which subset relations exist
doesn't neatly show the relation of irrationals
(ones not expressible as a ratio, and
having an infinite and non-recurring expansion
when expressed as a decimal).
N = 0.. infinity;
Z= {+1,-1}*N;
Q = {Z/N, Z};
irrationals = {pi, e, 2**(1/2), ...}:
pi/4 = +(^i=0...infinity| (-1)**i /(2i+1) )
pi/2 = *(^i=1...infinity| (2i)**2 /(2i)**2-1) )
pi = 4 / (1+ 1**2 /( 3+ 2**2 /(5+ 3**2 /(...)))
e = (1+1/infinity)**infinity .
R = {Q, irrationals, repeaters}
C = {i*R + R, R} -- i = (-1)**(1/2)
templates for subtype association:
[6.1: mis:
"( . having types specifying which subset relations exist)??
doesn't neatly show the relation of irrationals
irrationals are simply the reason
why some reals are not Q's !
. what is the purpose of knowing how they are related?
isn't it just to know type compatibility?
if you produce an irrational,
you call it a real,
and if you didn't want symbolics
then you'd call it a float .]
. the mgt for type clusters(eg numbers),
may have some reusable code in that there are
many type clusters in which the subtypes have
values that are subsets of each other; eg,
N subsets Z subsets Q subsets R subsets C .
. number is also an example of there being
another way of describing subsets:
superset decomposition
(showing how a set is composed of other sets).
. saying which subset relations exist
doesn't neatly show the relation of irrationals
(ones not expressible as a ratio, and
having an infinite and non-recurring expansion
when expressed as a decimal).
N = 0.. infinity;
Z= {+1,-1}*N;
Q = {Z/N, Z};
irrationals = {pi, e, 2**(1/2), ...}:
pi/4 = +(^i=0...infinity| (-1)**i /(2i+1) )
pi/2 = *(^i=1...infinity| (2i)**2 /(2i)**2-1) )
pi = 4 / (1+ 1**2 /( 3+ 2**2 /(5+ 3**2 /(...)))
e = (1+1/infinity)**infinity .
R = {Q, irrationals, repeaters}
C = {i*R + R, R} -- i = (-1)**(1/2)
1st-class functions and various environs
adda/oop/1st-class functions:
5.16:
. a function's owner is the environs in which
the function's body is defined; [6.1:
a top-level subprogram is owned by the library,
and thereby has access to the standard lib' .]
. most functions are owned by types:
the type's body provides the environs;
but 1st-class function support means that
an aggregate's components may be a function,
in which case, the agg is the owner,
so the agg's body and its other components
become the function's environs .
[5.18: clarification:
. agg's can have bodies like Ada packages;
and if the agg' body contains the function body
only then does the agg' own the function .
5.31: 6.28:
. the agg'component can also be
a pointer to an external function;
such a function then has no way to reach
agg' components;
conversely, Ada's stub declaration allows for
an agg'owned function to be defined externally;
it's still declared locally if not defined so,
and declaration is what gives it local access,
and a locality to call its own .]
[5.17:
. an agg's components can be addressed in 2 ways:
# directly:
. a function it owns knows what's available
and reaches an external x with (../x) .
# a filesystem approach:
. the function can get a list of
the names of surrounding components,
just as a human asks a filesystem
for a directory listing .
--
. a function's use of (self`name) could return
the name of the component it's been assigned to ... 6.1:
. it could be assigned to more than
one component of its owner;
so, that would have to be a list .]
5.31: deleting self:
. can a function delete itself from a agg'?
it can reach and modify other components
from within the agg' it's a component of;
so why not be able to delete itself?
it could still run after such a deletion
because it's an active process
and each act'rec on the stack display
is paired with a pointer to the associated code . [6.1:
. one reason for deleting self could be
a varying method pattern:
it calls multiple agg'components,
some of which may be self,
and changes methods to meet new conditions .]
5.17: all accesses must be cap'based:
[5.16:
. how would an external function
ask for access to the class var's?
. it can't use ../ because it's
local to an instance, whereas
class var's are local to the type's body .
. it could work like a filesystem,
where functions can request a list
of their owner's class var's .
. the type's body allows access by
populating the class's locals list
with the addresses it wishes to share
rather than leaving the list null ...]
...
. the idea of assignable functions
having access to class var's
must be integrated with a security model
that considers who's asking for the access
and who's affected by it .
. it's not just a matter of selecting
which locals are visible,
but also deciding which functions
can have that access:
the filtering might be by function-type,
function-authors, or function-libraries .
5.18: dimensions of environs:
. a function.ptr assigned to an agg' component
is just like when passed to a subprogram param;
in either of these cases,
a function body's own environ
is not the same as caller's body .
. there can also be structural environs
(what agg'path was used for accessing
a copy of the function's address).
. when a call is made, the function gets a
return address that is a shortcut to
this scope path:
main/sub/nth step/m-th step of sub.body(eg, a loop) .
. that leads to the call's location
which includes the data path needed to
access the function: [6.28: ...
by looking on the stack's return address,
and then looking at the code
that launched that function call,
we are finding the structural environs .]
. some variants of lisp
feature dynamic scope
in which a called function can expect access to
the caller's environ's .
. is there any language that provides
access to the structural environs?
. lisp functions can also know
who their caller is,
and what their caller's code is .
. it seems like the
full generalization of that would be
pointers to all related structures:
the owner, the caller,
the call or return point,
and the path of caller's access to function .
. practically though,
the simple and safe way is
accessing only what's available at compile time .
. if the function wants to share the caller's locals,
it can declare an inout param
that callers need to fill;
if the caller wants a function to share,
it can take ownership of the function .
5.16:
. a function's owner is the environs in which
the function's body is defined; [6.1:
a top-level subprogram is owned by the library,
and thereby has access to the standard lib' .]
. most functions are owned by types:
the type's body provides the environs;
but 1st-class function support means that
an aggregate's components may be a function,
in which case, the agg is the owner,
so the agg's body and its other components
become the function's environs .
[5.18: clarification:
. agg's can have bodies like Ada packages;
and if the agg' body contains the function body
only then does the agg' own the function .
5.31: 6.28:
. the agg'component can also be
a pointer to an external function;
such a function then has no way to reach
agg' components;
conversely, Ada's stub declaration allows for
an agg'owned function to be defined externally;
it's still declared locally if not defined so,
and declaration is what gives it local access,
and a locality to call its own .]
[5.17:
. an agg's components can be addressed in 2 ways:
# directly:
. a function it owns knows what's available
and reaches an external x with (../x) .
# a filesystem approach:
. the function can get a list of
the names of surrounding components,
just as a human asks a filesystem
for a directory listing .
--
. a function's use of (self`name) could return
the name of the component it's been assigned to ... 6.1:
. it could be assigned to more than
one component of its owner;
so, that would have to be a list .]
5.31: deleting self:
. can a function delete itself from a agg'?
it can reach and modify other components
from within the agg' it's a component of;
so why not be able to delete itself?
it could still run after such a deletion
because it's an active process
and each act'rec on the stack display
is paired with a pointer to the associated code . [6.1:
. one reason for deleting self could be
a varying method pattern:
it calls multiple agg'components,
some of which may be self,
and changes methods to meet new conditions .]
5.17: all accesses must be cap'based:
[5.16:
. how would an external function
ask for access to the class var's?
. it can't use ../ because it's
local to an instance, whereas
class var's are local to the type's body .
. it could work like a filesystem,
where functions can request a list
of their owner's class var's .
. the type's body allows access by
populating the class's locals list
with the addresses it wishes to share
rather than leaving the list null ...]
...
. the idea of assignable functions
having access to class var's
must be integrated with a security model
that considers who's asking for the access
and who's affected by it .
. it's not just a matter of selecting
which locals are visible,
but also deciding which functions
can have that access:
the filtering might be by function-type,
function-authors, or function-libraries .
5.18: dimensions of environs:
. a function.ptr assigned to an agg' component
is just like when passed to a subprogram param;
in either of these cases,
a function body's own environ
is not the same as caller's body .
. there can also be structural environs
(what agg'path was used for accessing
a copy of the function's address).
. when a call is made, the function gets a
return address that is a shortcut to
this scope path:
main/sub/nth step/m-th step of sub.body(eg, a loop) .
. that leads to the call's location
which includes the data path needed to
access the function: [6.28: ...
by looking on the stack's return address,
and then looking at the code
that launched that function call,
we are finding the structural environs .]
. some variants of lisp
feature dynamic scope
in which a called function can expect access to
the caller's environ's .
. is there any language that provides
access to the structural environs?
. lisp functions can also know
who their caller is,
and what their caller's code is .
. it seems like the
full generalization of that would be
pointers to all related structures:
the owner, the caller,
the call or return point,
and the path of caller's access to function .
. practically though,
the simple and safe way is
accessing only what's available at compile time .
. if the function wants to share the caller's locals,
it can declare an inout param
that callers need to fill;
if the caller wants a function to share,
it can take ownership of the function .
adopting oop features`round#1
5.16: adda/oop/integrating popular oop features:
. for each oop feature,
adda has to show how it's done,
or explain why it shouldn't be done
(eg, insecure, ill-fitting, ...);
eg, for oop's version of f(x), x`f,
how is adda providing f with access to x ?
where various oop styles differ:
. popular oop assumes the use of references:
all obj's are a ptr to a disposable heap obj;
whereas, adda assumes direct access to value,
ie, there's nothing to explicitely dispose of;
and when an assignment is made,
it happens to the value not a pointer .
[6.1:
. no garbage is generated because
any function that returns an object
does so through an inout parameter
in which it receives from the caller
the memory where the result will go .
]
. there are 4 modules used by oop:
a type-mgt or class object
and an instance object,
each with a {const, var} section; [6.28:
--
anything known to be constant is sharable;
it can be part of subprogram's code template
instead of the subprogram activation record .]
. functions of the form y = obj`f(x)
are actually calling a procedure:
f(input x,
inout obj,
inout y) )
thereby giving the function 2 implicit parameters,
represented in the method as the var's: y, and o:
# y,
as in y = f(x);
. y represents the address where
the return is being placed by f's caller .
. the function then gets to reuse y's mem .
# o,
as in o`f(x);
o is an object whose type defines f,
and f has access to all of o's internals .
adda's class vars:
. the type's body is where methods are defined;
this space can also declare variables
which are then sharable by all methods,
addressed in the usual unix way:
../local . [5.31:
. these var's are initialized at program startup,
like those in an ada package body .]
where is a local function's return directed?:
[6.1: intro:
. oop's y = x`f means f can both modify x,
and return things to y .
. a local function here means
local to an aggregate (an agg'owned function)
where (y= x.f) or (y= x#f)
can modify components of x, including itself,
and then return something to y .]
. the local function's return
can be assumed to target y because
if it wanted to operate on its owner,
it would simply use ../ to access those parts; [5.16: 5.17:
eg,
b`= obj.f -- here, obj is an aggregate;
and, one of its components is named f,
which is a function with an implicit arg of
potentially all of obj's other components;
finally,
f is in control of what gets assigned to (b);
because f determines what (obj.f) eval's to;
ie, obj itself is not what (b) is being assigned;
obj is merely the source of the function
which then provides the assignment's content .]
[5.31:
. the same reasoning applies to the usual
type-owned functions, y`= x`f,
they have the option of returning either the object
or something entirely different;
eg, x`++ -- this increments x,
but then returns x's former value .]
. the x`f form simply means that f has
inout access to x .[6.1:
(in the context of inheritance,
f is a abstract function whose method is determined by
the type that x belongs to,
but this feature is not specific to the x`f form,
it also applies to f(x)
-- it even applies to a+b because
both {a, b} share a common supertype
that knows how to mix its subtypes) .]
5.18: composite messages:
. obj'c allows for the composition of message-sends;
eg, x`= [a g b]; [x f y]
can be composed as [[a g b] f y]
because sending a msg to an obj typically results in
an obj pointer being returned;
ie, [x g b] points at x;
so, how does adda do that?
x`g(b)`f(y) could work the same as obj'c's
[[x g b] f y] . [5.31:
. why wouldn't the parse be
x`( g(b)`f(y) ) instead of
( x`g(b) )`f(y) ?
can the (f) in (x`f) be a variable instead a literal ?
(f x) can be expressed as (v`=x; f@v);
likewise, (x`f) could be (@x`@v) ?
. the purpose of (x`f) was to emulate
c's x++, and oop's x.f;
in those cases only literals are needed,
but obj'c has a call for variable msg's too .
. a neater way than x`@v
would be simply x`v,
where v had been declared to be a pointer to symbol .
. or use explicit parentheses:
(expression returns pointer to obj)`(
expression returns pointer to method symbol) .
6.1:
. while features should be complete
to the point of orthogonal,
this should not be at expense of
unintuitive syntax;
esp'ly for features that are used infrequently .]
. for each oop feature,
adda has to show how it's done,
or explain why it shouldn't be done
(eg, insecure, ill-fitting, ...);
eg, for oop's version of f(x), x`f,
how is adda providing f with access to x ?
where various oop styles differ:
. popular oop assumes the use of references:
all obj's are a ptr to a disposable heap obj;
whereas, adda assumes direct access to value,
ie, there's nothing to explicitely dispose of;
and when an assignment is made,
it happens to the value not a pointer .
[6.1:
. no garbage is generated because
any function that returns an object
does so through an inout parameter
in which it receives from the caller
the memory where the result will go .
]
. there are 4 modules used by oop:
a type-mgt or class object
and an instance object,
each with a {const, var} section; [6.28:
--
anything known to be constant is sharable;
it can be part of subprogram's code template
instead of the subprogram activation record .]
. functions of the form y = obj`f(x)
are actually calling a procedure:
f(input x,
inout obj,
inout y) )
thereby giving the function 2 implicit parameters,
represented in the method as the var's: y, and o:
# y,
as in y = f(x);
. y represents the address where
the return is being placed by f's caller .
. the function then gets to reuse y's mem .
# o,
as in o`f(x);
o is an object whose type defines f,
and f has access to all of o's internals .
adda's class vars:
. the type's body is where methods are defined;
this space can also declare variables
which are then sharable by all methods,
addressed in the usual unix way:
../local . [5.31:
. these var's are initialized at program startup,
like those in an ada package body .]
where is a local function's return directed?:
[6.1: intro:
. oop's y = x`f means f can both modify x,
and return things to y .
. a local function here means
local to an aggregate (an agg'owned function)
where (y= x.f) or (y= x#f)
can modify components of x, including itself,
and then return something to y .]
. the local function's return
can be assumed to target y because
if it wanted to operate on its owner,
it would simply use ../ to access those parts; [5.16: 5.17:
eg,
b`= obj.f -- here, obj is an aggregate;
and, one of its components is named f,
which is a function with an implicit arg of
potentially all of obj's other components;
finally,
f is in control of what gets assigned to (b);
because f determines what (obj.f) eval's to;
ie, obj itself is not what (b) is being assigned;
obj is merely the source of the function
which then provides the assignment's content .]
[5.31:
. the same reasoning applies to the usual
type-owned functions, y`= x`f,
they have the option of returning either the object
or something entirely different;
eg, x`++ -- this increments x,
but then returns x's former value .]
. the x`f form simply means that f has
inout access to x .[6.1:
(in the context of inheritance,
f is a abstract function whose method is determined by
the type that x belongs to,
but this feature is not specific to the x`f form,
it also applies to f(x)
-- it even applies to a+b because
both {a, b} share a common supertype
that knows how to mix its subtypes) .]
5.18: composite messages:
. obj'c allows for the composition of message-sends;
eg, x`= [a g b]; [x f y]
can be composed as [[a g b] f y]
because sending a msg to an obj typically results in
an obj pointer being returned;
ie, [x g b] points at x;
so, how does adda do that?
x`g(b)`f(y) could work the same as obj'c's
[[x g b] f y] . [5.31:
. why wouldn't the parse be
x`( g(b)`f(y) ) instead of
( x`g(b) )`f(y) ?
can the (f) in (x`f) be a variable instead a literal ?
(f x) can be expressed as (v`=x; f@v);
likewise, (x`f) could be (@x`@v) ?
. the purpose of (x`f) was to emulate
c's x++, and oop's x.f;
in those cases only literals are needed,
but obj'c has a call for variable msg's too .
. a neater way than x`@v
would be simply x`v,
where v had been declared to be a pointer to symbol .
. or use explicit parentheses:
(expression returns pointer to obj)`(
expression returns pointer to method symbol) .
6.1:
. while features should be complete
to the point of orthogonal,
this should not be at expense of
unintuitive syntax;
esp'ly for features that are used infrequently .]
2011-05-31
type constraint decl's
5.18: adda/type/constraint syntax:
. the lang' needs a compact integrated way to
indicate subrange;
eg, i.Z(1...10) -- new Z constrained to 1..10 .
. the parser rule could be that
if the typemark is for a parameterized type
then it expects a parameter;
if it finds an unexpected parameter
(ie, a parenthetical expression)
then it can assume it's a subtype constraint .
. as with functions, (@) can be used for
indicating a symbol returning parenthetical;
eg, i.Z@myConstraint;
eg, i.paramizedType@arg@constraint .
. the lang' needs a compact integrated way to
indicate subrange;
eg, i.Z(1...10) -- new Z constrained to 1..10 .
. the parser rule could be that
if the typemark is for a parameterized type
then it expects a parameter;
if it finds an unexpected parameter
(ie, a parenthetical expression)
then it can assume it's a subtype constraint .
. as with functions, (@) can be used for
indicating a symbol returning parenthetical;
eg, i.Z@myConstraint;
eg, i.paramizedType@arg@constraint .
markup and toc mirroring
5.11: 5.31: adda/markup/integrated markup:
. I had thought of the markup lang' as being
part of the editor -- just as html
is considered to be part a browser --
but in keeping with the one-lang philosophy,
the programming lang should include the
markup lang' -- meta-level lang,
as well as assembly -- low-level lang .
. these levels can have unique syntax
yet share as many qualities as possible .
. by being part of the same standard,
they are all easier to use and remember;
and by not leaving a mode out,
you avoid forcing people to roll their own;
of course, if that's their interest,
good openware should make it easier to do
by providing a reusable kit .]
5.11: adda/markup/toc mirroring:
. there are 2 ways to express nested subtitles:
# containers:
. the markup lang' has container tags:
-- subtitle: [(], [)] --
all titles within the container
are nested within the container's title;
nested titles shows up in the toc as being
indented deeper than their enclosure's title .
# toc's:
. the table of contents (toc) is auto-generated
from what is marked up as being subtitles;
conversely,
if the toc's indentation is changed;
the documents markup will be auto-adjusted
to actively reflect the toc's state,
and auto-generate container markup .
. I had thought of the markup lang' as being
part of the editor -- just as html
is considered to be part a browser --
but in keeping with the one-lang philosophy,
the programming lang should include the
markup lang' -- meta-level lang,
as well as assembly -- low-level lang .
. these levels can have unique syntax
yet share as many qualities as possible .
. by being part of the same standard,
they are all easier to use and remember;
and by not leaving a mode out,
you avoid forcing people to roll their own;
of course, if that's their interest,
good openware should make it easier to do
by providing a reusable kit .]
5.11: adda/markup/toc mirroring:
. there are 2 ways to express nested subtitles:
# containers:
. the markup lang' has container tags:
-- subtitle: [(], [)] --
all titles within the container
are nested within the container's title;
nested titles shows up in the toc as being
indented deeper than their enclosure's title .
# toc's:
. the table of contents (toc) is auto-generated
from what is marked up as being subtitles;
conversely,
if the toc's indentation is changed;
the documents markup will be auto-adjusted
to actively reflect the toc's state,
and auto-generate container markup .
representing meta-values
5.10: adda/enums/the power of zero:
. the system should be interested in
reserving some values for representing
the state of being undefined or out-of-range .
. this though, can be done by system tagging;
ie, every type could inherit from system
to get a bit that indicates whether the var
is in a well-defined state or not .
. generally,
there is no reservable value available:
. most enum'value sequences start with zero
because most value ranges have a value
that is analogous to zero:
you first ask if there is any value,
if not then zero,
else since there is a value,
which one is it ?
eg, {off:0, red:1, yellow:2, green:3};
"(off) is the absence of a color,
so "(off) would be represented by zero;
[5.31: likewise,
some enums have a special purpose for the last value too;
so that can't be reserved either .]
. the system should be interested in
reserving some values for representing
the state of being undefined or out-of-range .
. this though, can be done by system tagging;
ie, every type could inherit from system
to get a bit that indicates whether the var
is in a well-defined state or not .
. generally,
there is no reservable value available:
. most enum'value sequences start with zero
because most value ranges have a value
that is analogous to zero:
you first ask if there is any value,
if not then zero,
else since there is a value,
which one is it ?
eg, {off:0, red:1, yellow:2, green:3};
"(off) is the absence of a color,
so "(off) would be represented by zero;
[5.31: likewise,
some enums have a special purpose for the last value too;
so that can't be reserved either .]
explicitely expressable state
5.10: adda/images for every data value:
5.4: 5.10: 5.30:
. each value may be associated with
# an icon (iconic image):
. optional .
# a symbol (linguistic image):
--[5.31: ada calls this the image]
. all types can be represented as text:
eg, just as enum's have names for each value,
and numbers have a sequence of digits,
graphics have a matrix of color records,
each of which is a list of tagged numbers:
(red:1, green:2, blue:3).
# a digital value (representation);
--[5.31: ada calls this the enum`value
or the structure`representation]
ie, some structure of bit arrays,
where structuring can be done by
pointers or arrays .
[5.31: structures can be equal if they have
the same type, and equal components;
they can also be tested for less-than
with components treated like string characters .]
. a type may choose to hide its implementation;
[@] addx/info'hiding vs blackbox binaries
[5.31: however,
the system can store snapshots of itself,
with each object represented by
a particular string of integers;
which a private type can interpret in various ways .]
5.10: 5.30:
. given the type streetlight.type =
{off:0, red:1, yellow:2, green:3};
the image of red is the text "(red);
and its value is the integer: 1;
. red could have an icon colored red .
5.4: 5.10: 5.30:
. each value may be associated with
# an icon (iconic image):
. optional .
# a symbol (linguistic image):
--[5.31: ada calls this the image]
. all types can be represented as text:
eg, just as enum's have names for each value,
and numbers have a sequence of digits,
graphics have a matrix of color records,
each of which is a list of tagged numbers:
(red:1, green:2, blue:3).
# a digital value (representation);
--[5.31: ada calls this the enum`value
or the structure`representation]
ie, some structure of bit arrays,
where structuring can be done by
pointers or arrays .
[5.31: structures can be equal if they have
the same type, and equal components;
they can also be tested for less-than
with components treated like string characters .]
. a type may choose to hide its implementation;
[@] addx/info'hiding vs blackbox binaries
[5.31: however,
the system can store snapshots of itself,
with each object represented by
a particular string of integers;
which a private type can interpret in various ways .]
5.10: 5.30:
. given the type streetlight.type =
{off:0, red:1, yellow:2, green:3};
the image of red is the text "(red);
and its value is the integer: 1;
. red could have an icon colored red .
control orientations and compound documents
5.6: adda/oop/the orientation space:
--. this article explores how menus
should work in compound documents,
and how they relate to oop (obj'orientation) .
5.6: 5.31: equivalent terminology systems:
(user -- client
, app -- server
, menu -- type
, document -- object
).
5.6: 5.31: control orientations:
# open structure:
. text is an example of an open datatype:
(it's an array of symbols encoded with ascii);
any operation can be applied to this type
as long as it results in the same structure .
# open interface:
. only a particular set of operations can be applied;
but the menu is a public standard;
so, you can know ahead of time
whether something is on the menu or not .
# proprietary:
. neither the document structure nor the menus
are public standards;
so, only a particular app controls the object .
5.4: compound documents:
. support of compound documents means that
selecting multiple objects would result in
a menu consisting of the intersection of
the set of object`menus; 5.6:
every object can tell you the menu it supports
without having to adopt an interface .
5.31:
. if mac.finder were a compound document,
file`info would link not only to the owning'app
but also to that app's select-all menu .
--. this article explores how menus
should work in compound documents,
and how they relate to oop (obj'orientation) .
5.6: 5.31: equivalent terminology systems:
(user -- client
, app -- server
, menu -- type
, document -- object
).
5.6: 5.31: control orientations:
# open structure:
. text is an example of an open datatype:
(it's an array of symbols encoded with ascii);
any operation can be applied to this type
as long as it results in the same structure .
# open interface:
. only a particular set of operations can be applied;
but the menu is a public standard;
so, you can know ahead of time
whether something is on the menu or not .
# proprietary:
. neither the document structure nor the menus
are public standards;
so, only a particular app controls the object .
5.4: compound documents:
. support of compound documents means that
selecting multiple objects would result in
a menu consisting of the intersection of
the set of object`menus; 5.6:
every object can tell you the menu it supports
without having to adopt an interface .
5.31:
. if mac.finder were a compound document,
file`info would link not only to the owning'app
but also to that app's select-all menu .
2011-05-30
standard abi's motivation
5.18: addx/standard abi/motivation:
background:
. the typical example of mistaken expectation
is when an url acts like a script .
. many apps have input limitations
such as when a browser treats certain url's like scripts .
. a commandline could be given what you think is a filename
but because of expectations about filename limitations
a filename can be interpreted as a series of commands .
. this wouldn't happen if unix had
a common abi (app'binary interface);
because, instead of passing the file's name as text
(a form of screen scraping)
it could be passing an obj type-tagged as a filename
and then filename limitations become irrelevant .
4.15?: news.cyb/sec/qubes/Qlipper:
Larry McCay April 15, 2011 2:52 AM`
comment on [The Invisible Things Lab's blog]/
. this is another example of why an abi
is needed:
. what qubes has to do to get vm's communicating
is for each os to support a clipboard
that qubes can translate to a file
that is then sent over the intranet .
. an os's clipboard is understood as
supporting certain data types
with a certain type-tagging convention .
. if qubes has to understand all this anyway
it already does sanitizing by matching types [5.18:
(though it could help by checking for
malformed html and illegal unicodes); ]
but, because os's don't provide a common abi,
they are reduced to supporting only
some common text-based standards
like ascii, unicode, or html [5.18:
whereas, a common abi would also support
a binary version of a complete programming lang',
meaning that instead of just being text,
the code was parsed into a syntax tree;
and native functions were represented by codes
that are read more quickly than text .
. and,
when copying abi code from the pasteboard,
dom0 would be able to read and understand
the implicit capabilities of that code .]
. without an abi, qubes must have
apps communicating via a screen scraper;
but that's ok, because,
the whole point of security by isolation
is that we can never expect to
completely protect app's from being
hung by their own naivety;
what we can do is protect good apps
from being hung by bad ones .
background:
. the typical example of mistaken expectation
is when an url acts like a script .
. many apps have input limitations
such as when a browser treats certain url's like scripts .
. a commandline could be given what you think is a filename
but because of expectations about filename limitations
a filename can be interpreted as a series of commands .
. this wouldn't happen if unix had
a common abi (app'binary interface);
because, instead of passing the file's name as text
(a form of screen scraping)
it could be passing an obj type-tagged as a filename
and then filename limitations become irrelevant .
4.15?: news.cyb/sec/qubes/Qlipper:
Larry McCay April 15, 2011 2:52 AM`
comment on [The Invisible Things Lab's blog]/
A Qlipper app could be introducedJoanna @Larry:
to sanitize and add the appropriate context.
Sanitizing makes sure
what you copied is what you expected
and the context is used to
direct within the target Qubes domains.
. a "sanitizer" must know the limitations of the destination app... .--
. this is another example of why an abi
is needed:
. what qubes has to do to get vm's communicating
is for each os to support a clipboard
that qubes can translate to a file
that is then sent over the intranet .
. an os's clipboard is understood as
supporting certain data types
with a certain type-tagging convention .
. if qubes has to understand all this anyway
it already does sanitizing by matching types [5.18:
(though it could help by checking for
malformed html and illegal unicodes); ]
but, because os's don't provide a common abi,
they are reduced to supporting only
some common text-based standards
like ascii, unicode, or html [5.18:
whereas, a common abi would also support
a binary version of a complete programming lang',
meaning that instead of just being text,
the code was parsed into a syntax tree;
and native functions were represented by codes
that are read more quickly than text .
. and,
when copying abi code from the pasteboard,
dom0 would be able to read and understand
the implicit capabilities of that code .]
. without an abi, qubes must have
apps communicating via a screen scraper;
but that's ok, because,
the whole point of security by isolation
is that we can never expect to
completely protect app's from being
hung by their own naivety;
what we can do is protect good apps
from being hung by bad ones .
info'hiding vs blackbox binaries
5.10: addx/info'hiding vs blackbox binaries:
. info'hiding means being able to reuse a modules
without having access to the module`body;
by accessing only the module`header .
. only the linker needs the bodies of
a program and the modules it uses .
. the bodies are blackboxes:
usable but unviewable,
protecting both trade secrets
and unintended reuse or adaptation .
. addx's intent is simply to warn coders
that the implementation could change;
ie, if you rely on impl'details,
you can't expect easy updates;
instead,
you'd have to rewrite your code
in order for it to work with any new impl'details .
. addx does allow code obfuscation
since you can easily change names to nonsense;
on the other hand,
the user is a new co.maintainer of your code,
and can easily rename them again
to match ongoing understanding of their roles .
. as for binary black boxes,
adda compiles to c, and then to native binary,
but addx should't run a binary unless
either adda compiled it;
or, there's some other way to trust it .
. if there was some secure way to know
that the binary on my machine
was actually generated by
an untampered adda on your machine
then blackbox modules could be consistent with
the addx security model .
. another way to support blackbox binaries
is for addx to know of a secure website
where it could find such adda products .
. that could, however, bring
new complexity to the security problem:
each time you trust a website
that's another time you have to ask:
"(has that site been cracked recently?)
. by staying with the openware model,
you need be trusting only your platform
(the os, and other apps installed).
. some mutually-trusted 3rd party
could accept code and compile it to binaries;
then commercial interests would be assured privacy;
and trusting users would be assured
that this binary was generated by adda,
while non-trusting users
would be free to download pure openware .
5.10: todo.addx/making openware usable:
. an advantage of addx being openware
is that it minimizes trust requirements;
eg, if you're on Apple's mac,
the only thing you have to trust
is Apple's xcode compiler .
. if addx is built by mac's xcode
then xcode should be easy to get;
will it always ship with every new mac?
... in the qt crossplatform ide doc's
they assume xcode will always be
right at your finger tips .
yet, new versions require payment;
and the code base is getting huge;
so, if it's unused by most mac fans
why cut another entire dvd for every unit ?
addx should written in such a way that
the code can be compiled with
easy to get tools .
. for those who want a completely
native mac app,
some of addx will need to be
compiled with xcode .
. therefore,
they will need to download atleast a small binary
or get xcode .
. this small module should allow them
to build extensions;
so then most of their system
is still modifiable by them
yet is native code rather than addm .
xcode's lang is obj'c,
and that provides dynamic linking;
but does it bind gcc binaries ?
gcc itself has obj'c,
but xcode is no longer using gcc;
it uses clang . is clang free ? [..., yes .]
[5.30: anyway,
the plan for now is as was originally:
the source is meant to be compiled all at once,
and subsequent scripting is done with addm .]
5.10: pos.addx/qt on mac decreases security:
. I'm assuming that adda can protect my code
from abusing qt's large library;
and, qt itself reduces bugs by being easy to use .
. it's also a popular code base with a lot of eyes,
but one disadvantage with being popular on Windows
is that it will be worth more to malware writers .
. by requiring the qt codebase,
addx might be adding to a platform's vulnerability .
sharing a runtime:
. another possibility is that
if any other qt app's are run alongside addx,
they may be able to violate addx`privacy
so then addx can't make any privacy claims
to the user in this situation ?
5.20: addx/unix, KDE, and compon tech:
. I was recently baffled by this filename:
"( dims of addx (unix KDE compon tech) );
but, a review of the article put this together:
. when saying unix was a dimension of addx,
I was assuming linux was unix
and unix was the future platform .
. this article was pointing out that
linux domination plans needed dev tools;
and that, KDE was there for even beginners .
. linux's support for components
is a key to healthy competition and evolution .
. info'hiding means being able to reuse a modules
without having access to the module`body;
by accessing only the module`header .
. only the linker needs the bodies of
a program and the modules it uses .
. the bodies are blackboxes:
usable but unviewable,
protecting both trade secrets
and unintended reuse or adaptation .
. addx's intent is simply to warn coders
that the implementation could change;
ie, if you rely on impl'details,
you can't expect easy updates;
instead,
you'd have to rewrite your code
in order for it to work with any new impl'details .
. addx does allow code obfuscation
since you can easily change names to nonsense;
on the other hand,
the user is a new co.maintainer of your code,
and can easily rename them again
to match ongoing understanding of their roles .
. as for binary black boxes,
adda compiles to c, and then to native binary,
but addx should't run a binary unless
either adda compiled it;
or, there's some other way to trust it .
. if there was some secure way to know
that the binary on my machine
was actually generated by
an untampered adda on your machine
then blackbox modules could be consistent with
the addx security model .
. another way to support blackbox binaries
is for addx to know of a secure website
where it could find such adda products .
. that could, however, bring
new complexity to the security problem:
each time you trust a website
that's another time you have to ask:
"(has that site been cracked recently?)
. by staying with the openware model,
you need be trusting only your platform
(the os, and other apps installed).
. some mutually-trusted 3rd party
could accept code and compile it to binaries;
then commercial interests would be assured privacy;
and trusting users would be assured
that this binary was generated by adda,
while non-trusting users
would be free to download pure openware .
5.10: todo.addx/making openware usable:
. an advantage of addx being openware
is that it minimizes trust requirements;
eg, if you're on Apple's mac,
the only thing you have to trust
is Apple's xcode compiler .
. if addx is built by mac's xcode
then xcode should be easy to get;
will it always ship with every new mac?
... in the qt crossplatform ide doc's
they assume xcode will always be
right at your finger tips .
yet, new versions require payment;
and the code base is getting huge;
so, if it's unused by most mac fans
why cut another entire dvd for every unit ?
addx should written in such a way that
the code can be compiled with
easy to get tools .
. for those who want a completely
native mac app,
some of addx will need to be
compiled with xcode .
. therefore,
they will need to download atleast a small binary
or get xcode .
. this small module should allow them
to build extensions;
so then most of their system
is still modifiable by them
yet is native code rather than addm .
xcode's lang is obj'c,
and that provides dynamic linking;
but does it bind gcc binaries ?
gcc itself has obj'c,
but xcode is no longer using gcc;
it uses clang . is clang free ? [..., yes .]
[5.30: anyway,
the plan for now is as was originally:
the source is meant to be compiled all at once,
and subsequent scripting is done with addm .]
5.10: pos.addx/qt on mac decreases security:
. I'm assuming that adda can protect my code
from abusing qt's large library;
and, qt itself reduces bugs by being easy to use .
. it's also a popular code base with a lot of eyes,
but one disadvantage with being popular on Windows
is that it will be worth more to malware writers .
. by requiring the qt codebase,
addx might be adding to a platform's vulnerability .
sharing a runtime:
. another possibility is that
if any other qt app's are run alongside addx,
they may be able to violate addx`privacy
so then addx can't make any privacy claims
to the user in this situation ?
5.20: addx/unix, KDE, and compon tech:
. I was recently baffled by this filename:
"( dims of addx (unix KDE compon tech) );
but, a review of the article put this together:
. when saying unix was a dimension of addx,
I was assuming linux was unix
and unix was the future platform .
. this article was pointing out that
linux domination plans needed dev tools;
and that, KDE was there for even beginners .
. linux's support for components
is a key to healthy competition and evolution .
the state of scripting concurrency
4.19: adda/co/the state of scripting concurrency/intro:
[5.30:
. this excerpt from stackoverflow.com
had me looking at concurrency again:]
[5.30:
. processes are full programs running concurrently:
each process has its own space for
both variables and code;
threads are like processes except that
they share the locals and code
of the process that spawned them .
. threads and processes can be either
native -- implemented by the os,
or green -- impl'd by an app (eg, a scripting interpreter).
Erlang provides a green process(vs thread),
which is much more lightweight than a native process
because it does share (read-only) code space .
. a computer with multiple cores
can be truly concurrent:
doing more than one thing at the same time
by contrast, timeslicing is virtual concurrency:
giving each task a slice of computer time .
. the GIL (Global Interpreter Lock)
is a mutual exclusion lock
that prevents true concurrency:
insuring that app threads are timesliced,
rathering than being mapped to multiple cores .
. it's needed when the the interpreter,
it's libraries, or its plugins
are not thread-safe because of
threads being able to share variables
that aren't protected with atomic access:
ie, being able to complete a read or write
before having being interrupted by the timeslicer .
Ruby's support for concurrency:
. these GIL-free variants of Ruby
. the future of high performance concurrency
python's gil:
Juergen Brendel argues against the GIL;
Guido maintained the GIL is here to stay
. concurrent programming has a bad reputation
for being both buggy and undebuggable,
but it's based on work with threads .
5.30:
. to be efficient and safe,
a language needs to pervasively support
green processes:
a unit of concurrency that does share
read-only mem like a thread does
but does not share variable mem .
. pervasive support means that
not only is the standard library thread safe,
but all reusable modules are also .]
another way threads don't scale:
that are pass-by-copy;
the impl'details involve
read-only pass-by-reference .]
Why don’t we all switch to Erlang?
[5.30:
. this excerpt from stackoverflow.com
had me looking at concurrency again:]
"( If you have programmed expertly ingreen threads and the need for GIL:
Perl Python and in Java for 10 years,
then you'll probably write your program in Perl
because you'll complete the program faster,
the program will have fewer lines of code,
and the language will stay more out of your way.
If you are not an expert in Perl, Python, or Java,
and you have to choose one of those languages,
then I recommend that you choose Python.
... except if threading is important (re: GIL)...)
[5.30:
. processes are full programs running concurrently:
each process has its own space for
both variables and code;
threads are like processes except that
they share the locals and code
of the process that spawned them .
. threads and processes can be either
native -- implemented by the os,
or green -- impl'd by an app (eg, a scripting interpreter).
Erlang provides a green process(vs thread),
which is much more lightweight than a native process
because it does share (read-only) code space .
. a computer with multiple cores
can be truly concurrent:
doing more than one thing at the same time
by contrast, timeslicing is virtual concurrency:
giving each task a slice of computer time .
. the GIL (Global Interpreter Lock)
is a mutual exclusion lock
that prevents true concurrency:
insuring that app threads are timesliced,
rathering than being mapped to multiple cores .
. it's needed when the the interpreter,
it's libraries, or its plugins
are not thread-safe because of
threads being able to share variables
that aren't protected with atomic access:
ie, being able to complete a read or write
before having being interrupted by the timeslicer .
Ruby's support for concurrency:
. IronRuby builds on top of .NET Threads,[5.30:
so they map 1-1 to OS-threads as well;
JRuby does likewise on the JVM .
. these GIL-free variants of Ruby
provide threads without any warranty:. concurrency models supported by Ruby
it's up to you to insure that
all your dependencies are thread safe .
include Threads, Processes and. Ruby needs a standard actor/executor API
Fibers (systems-level coroutines).
. other abstractions to consider include
Coroutines, Actor Models, Petri Nets, Process Algebras
(particularly CSP and the Pi-Calculus),
Software Transactional Memory
and distributed Map/Reduce algorithms
-- see Go, Occam-Pi, Clojure and Erlang;
Ruby could impl' these with current libraries;
eg, EventMachine or RevActor .
-- not platform-specific impl's of actors .
. the future of high performance concurrency
is libdispatch/GCD;]-5.30
for the java/scala folks, there's HawtDispatch:
(JRuby's port of that is at github/jcd).
. HawtDispatch is a thread pooling and
NIO event notification framework API
modeled after the Apple`libdispatch API
that powers Apple's Grand Central Dispatch (GCD).
It allows you to easily develop
multi-threaded applications
without the usual problems .
python's gil:
Juergen Brendel argues against the GIL;
Guido maintained the GIL is here to stay
until someone can prove its removalBob Warfield 2007`analysis of gil:
doesn't slow down single-threaded Python code.
. the language doesn't require the GIL
but, the CPython virtual machine
that has historically been unable to shed it.
it was shown that even on the platform
with the fastest locking primitive (Windows at the time)
it slowed down single-threaded execution
nearly two-fold .
. removing the GIL complicates life for
extension module writers
by precluding the use of global mutable data .
There might also be changes in the Python/C API
necessitated by the need to lock certain objects
for the duration of a sequence of calls.
Guido is Right to Leave the GIL in Python,[5.29:
Not for Multicore but for Utility Computing
considering large scalability issues
in the world of SaaS, Web 2.0,
and utility computing fabrics;
eg, Amazon EC2(elastic computing).
. a concurrency capability based on threads
has done nothing to access multiple machines
-- for that you need socket-connected processes .
. furthermore,
a simple, safe and reliable concurrency language
should be focused on a [green]process model,
not a thread model.
. concurrent programming has a bad reputation
for being both buggy and undebuggable,
but it's based on work with threads .
5.30:
. to be efficient and safe,
a language needs to pervasively support
green processes:
a unit of concurrency that does share
read-only mem like a thread does
but does not share variable mem .
. pervasive support means that
not only is the standard library thread safe,
but all reusable modules are also .]
another way threads don't scale:
The fundamental problem with threads[. it is merely the semantics
is that sharing requires locking
which doesn’t scale (or compose),
and is prone to races and deadlocks .
Erlang features [green]processes
where isolation is enforced by the language
rather than the operating system .
. Erlang is a functional language
with strict copy semantics
and with no pointers or references.
that are pass-by-copy;
the impl'details involve
read-only pass-by-reference .]
Why don’t we all switch to Erlang?
Messages have to be copied.
You can’t deep-copy a large data structure
without some performance degradation,
and not all copying can be optimized away
(it requires behind-the-scenes alias analysis).
so, mainstream languages don’t abandon sharing;
instead, they rely on programmer’s discipline
or try to control aliasing.
2011-05-22
menu systems for compound documents
4.2: adde/menubar`contents:
subdesktops:
. a compound document is one composed of
trees and tables of hyperlinks, text,
graphics, numbers, and any new types
for which there are app's to drive them .
. it's as if there are
many app windows in a single document
just as there are
many app windows on a desktop;
therefore,
a compound document can be thought of
as being desktop within a desktop,
and could thus be called a subdesktop .
. adde can then be called
a subdesktop editor .
review of mac`menubar:
. there are various places to put a menubar:
# the mac`menubar is at the top of the display;
it contains a menu belonging to
whichever app is controling the current window;
# many non-mac systems have, instead,
window-specific menu's:
. the app's menu would be located at
the top bar of each window belonging to that app;
whereas the display's menubar would contain only
system-wide menu's (eg, admin' functions,
app's launchers, and a file finder) .
[5.3:
. the mac`menubar has a list of co.menus
(co.menus are side-by-side,
just as submenus are nested under other menus
).
mac's standard co.menus include:
( (system`name)-- about system, param's, updates;
, (app`name) -- about this app, param's, updates;
, file -- interactions with perm'storage;
, edit,format -- modify the currently open file;
, view -- customze how content is displayed
-- (doesn't modify the content);
, (app-specific menus, ...)
, window -- arrange or select the app's windows;
, help -- for both system-wide, and app-specific .
)
. mac'menu's are expected to be complete
in order to represent what the app does;
5.4: eg,
mac`finder's window has a search box,
but it also has this menu:
finder`menu#file/find .
mac`menu#edit:
[5.8:
. mac uses the edit.menu for
anything related to document modifications,
including select, as well as {copy cut, paste};
and, any service that optionally edits:
eg, find(and perhaps replace),
or spellcheck(and perhaps correct) .
. however, there may be other co.menus
that also provide edits;
eg, mac's textedit has menu#format
which modifies the selection's {font,style,...} .
. another editing co.menu is used by vmware,
(if you think of a virtual machine as a document);
vmware`menu#[virtual machine] is used for
pref's that apply only to the current document .]
[5.3: 5.8: a menu#edit for subdesktops:
. mac provides 2 ways to select data:
# edit#menu/select all
# use the mouse to define a subrange .
. therefore,
because subdesktops are compound doc's,
with a variety of datatypes combined;
there are more ways than [select all]
to select things by menu:
you can also subrange by type .
. whether for simple or compound doc's,
there should be a [select some] item
in which a given truth function can define
a subrange of the {moused, typed} selection .
. in sum, selection subrange provides,
for each type in the current document,
a checkbox and an optional constraint parameter;
eg,
[x] is .txt except [find "(todo)]
[ ] is .jpg except [ null ] .
. this can be integrated with the
[select all] like so:
[select all] brings up the
[select some] dialog,
showing you the list of types
with all possible types selected;
so if no subrange constraints are needed
then just pressing enter
works like [select all].
. if the new user doesn't appreciate a dialog,
the dialog can have a checkbox to
"( map this [select some].dialog
to command-shift-A ).
. the currently moused selection
is mirrored in the menu selection:
if a selection is already made,
the [select some] dialog will
reflect that selection state
by checkmarking only the types
that are currently selected .
]-5.8
[5.4: the dynamic menu:
5.4: 5.9:
. mac`menus can have dynamic content:
ie, they will grey-out any menu items
that aren't applicable to the current selection .
. fully dynamic menus can also
add and remove submenus .
. compound doc's have document-specific
combinations of datatypes;
therefore, fully dynamic menus are required
in order to display all the type-specific menus
of all the datatypes contained in the current doc'.
[5.10:
. if mac`menus weren't fully dynamic
then adde's mac`menu could be for adde-wide operations
and then the edit.menu would have a
[type-specific operations ...] item
that would open an adde-designed menu system
which can then support full dynamism .
[5.4: 5.6: 5.8: merging app menus:
. there are several ways in which
the menus of a doc's datatypes
are merged into a single menu system:
# simple:
. a submenu is named by type,
and selecting that command will then
be applied to components of that type only;
other types will be ignored .
. when on the mac,
these type-specific menus would be expected in
menu#edit, along with [select all] .
# subtype polymorphism:
. an example of this is the supertype: number;
its menu items apply to all numeric subtypes
(int,float, Q,Z,R,C) . [5.10:
. the typical supertype menu
would list any operations affecting all subtypes,
and would then have submenus
representing each subtype, and containing only
subtype-specific operations .
. subtyping is concerned with interfaces
rather than implementations;
so, if a float happens to have an integer value
it retags itself as being an int;
however, since ints are a subset of floats
something constrained to int
will never have a chance to
similarly retag itself to float .]
# representational polymorphism:
. representations include
{ value implementations,
, graphical image,
, and programming language image
( adda-representation text )
} eg,
. when numbers are selected,
I can either bold-format a numeric's text,
or I can add the numeric values . [5.11:
. adde must either detect when types use text,
or types must declare this;
types may want to suggest a preference
that would explain to the user
why the preference exists;
the user can overrule any preference
after oking a purpose alert .]
[5.10:
. if an app is using text to represent its content
then a text styling menu
would apply to that app's datatype
(of course, the other text-modifiers
do not apply because
the text represents a type state
not just strings of characters).
. the user may want to vary the text styling
depending on whether the app's mode is:
# show value's graphical image
(might not use text)
# show value's adda-representation
(might be unavailable*)
# show value's implementation .
*:
. while every datatype must be
implemented in adda;
that type's values are not required to
have a written form (adda-representation);
for example,
streetlight.type = (red, yellow, green);
the intended image of the value red
is an icon that is colored red,
the adda-representation of the value red
is the text "(red);
and the implementation of the value red
is the integer: 1 (assuming the
default encoding of enums starts with 1,
and seeing that red is the first value).]
# generic polymorphism:
. the [all types].submenu shows
what operations of identical name
are recognized by every type in the selection
even if each type's authors had no idea
that they were naming their functions the same . [5.11:
. this would include the case of subtypes
where a supertype's interface is shared;
thus it involves supersets of subtype polymorphism .]
]-5.4: 5.6: 5.8 .
[5.4: the editable menu:
mac`menus are not expected to be user-editable;
but they can launch editable windows .
. in adde's menu-editing mode,
the user has access to 4 menu systems:
# the original menu tree;
# the original keymap;
# the user's version of the menu tree,
# the user's version of the keymap:
. the keymap is a table representing the keyboard
labeled to show each key's function .
left hand . . . . right hand
[][][][high].[] [].[high][][][]
[][][][home].[] [].[home][][][]
[][][][low ].[] [].[low ][][][]
. it's colored to make it graphically obvious
where the home key's row and columns are;
and, users can change the graphics:
the colors, background illustration,
and the nested framing arrangements .
. to stay quick, a text-version is loaded first,
followed by the full graphics .
. after ending adde's menu-editing mode,
only the user's versions are shown .
. in the original keymap, app`authors can show
what they think the most popular functions are
by placing them on the easiest-reached keys .[5.6:
. user's can also have a library of keymaps,
including author's map, current map,
and any other user-designed maps .]
. the style of interaction between {user, keymap}
is user-selectable:
# remindful interaction style:
. when users are in command mode (vs text insert)
typing any key brings the keymap into view,
shows you what you just did, and waits for enter .
# compact interaction style:
. hitting a key fills the command box
with the name of the function you just selected,
and then the command box is waiting for
either {esc, enter} to {stop,launch} the command). [5.6:
. hitting enter on an empty command
would show the keymap .]
]-5.4
. users may want both a menusystem
and a keymap --(before now,
I thought a keymap would be sufficient).
. the keymap title bar has a list of
the types of objects in the current selection; [5.8:
but in the menubar this may be relegated to
a submenu of menu#edit .]
. users may want to place the app`menubar
either in the display`menubar,
or in the current window's menubar .[5.6:
. this will be possible on any system;
because, addx is acting as
a system within a system:
ie, it looks like it's being run by a vm player:
each window into addx represents an addx desktop
within which there are windows into adde documents .
summary of the window nesting:
. mac display ->
mac windows for a mac app named addx ->
addx windows for addx app named adde ->
app windows within an adde document .]
[5.4: hierarchical keymaps:
. the whole point of the keymap
is that it flattens the menu hierarchy
into a table of the user's choice;
however,
the existence of optional co.menus
implies the need for hierarchies of tables:
certain keys can be labeled to
launch new co.menus;
and then each optional co.menu item
is mapped to a cell of the co.menu-specific table .
. there could be room on the main table
in which case
optionality is expressed with grey-outs .
. the purpose of a keymap`title.bar
is indicate which table you selected;
left-arrow brings you to previous one .]
subdesktops:
. a compound document is one composed of
trees and tables of hyperlinks, text,
graphics, numbers, and any new types
for which there are app's to drive them .
. it's as if there are
many app windows in a single document
just as there are
many app windows on a desktop;
therefore,
a compound document can be thought of
as being desktop within a desktop,
and could thus be called a subdesktop .
. adde can then be called
a subdesktop editor .
review of mac`menubar:
. there are various places to put a menubar:
# the mac`menubar is at the top of the display;
it contains a menu belonging to
whichever app is controling the current window;
# many non-mac systems have, instead,
window-specific menu's:
. the app's menu would be located at
the top bar of each window belonging to that app;
whereas the display's menubar would contain only
system-wide menu's (eg, admin' functions,
app's launchers, and a file finder) .
[5.3:
. the mac`menubar has a list of co.menus
(co.menus are side-by-side,
just as submenus are nested under other menus
).
mac's standard co.menus include:
( (system`name)-- about system, param's, updates;
, (app`name) -- about this app, param's, updates;
, file -- interactions with perm'storage;
, edit,format -- modify the currently open file;
, view -- customze how content is displayed
-- (doesn't modify the content);
, (app-specific menus, ...)
, window -- arrange or select the app's windows;
, help -- for both system-wide, and app-specific .
)
. mac'menu's are expected to be complete
in order to represent what the app does;
5.4: eg,
mac`finder's window has a search box,
but it also has this menu:
finder`menu#file/find .
mac`menu#edit:
[5.8:
. mac uses the edit.menu for
anything related to document modifications,
including select, as well as {copy cut, paste};
and, any service that optionally edits:
eg, find(and perhaps replace),
or spellcheck(and perhaps correct) .
. however, there may be other co.menus
that also provide edits;
eg, mac's textedit has menu#format
which modifies the selection's {font,style,...} .
. another editing co.menu is used by vmware,
(if you think of a virtual machine as a document);
vmware`menu#[virtual machine] is used for
pref's that apply only to the current document .]
[5.3: 5.8: a menu#edit for subdesktops:
. mac provides 2 ways to select data:
# edit#menu/select all
# use the mouse to define a subrange .
. therefore,
because subdesktops are compound doc's,
with a variety of datatypes combined;
there are more ways than [select all]
to select things by menu:
you can also subrange by type .
. whether for simple or compound doc's,
there should be a [select some] item
in which a given truth function can define
a subrange of the {moused, typed} selection .
. in sum, selection subrange provides,
for each type in the current document,
a checkbox and an optional constraint parameter;
eg,
[x] is .txt except [find "(todo)]
[ ] is .jpg except [ null ] .
. this can be integrated with the
[select all] like so:
[select all] brings up the
[select some] dialog,
showing you the list of types
with all possible types selected;
so if no subrange constraints are needed
then just pressing enter
works like [select all].
. if the new user doesn't appreciate a dialog,
the dialog can have a checkbox to
"( map this [select some].dialog
to command-shift-A ).
. the currently moused selection
is mirrored in the menu selection:
if a selection is already made,
the [select some] dialog will
reflect that selection state
by checkmarking only the types
that are currently selected .
]-5.8
[5.4: the dynamic menu:
5.4: 5.9:
. mac`menus can have dynamic content:
ie, they will grey-out any menu items
that aren't applicable to the current selection .
. fully dynamic menus can also
add and remove submenus .
. compound doc's have document-specific
combinations of datatypes;
therefore, fully dynamic menus are required
in order to display all the type-specific menus
of all the datatypes contained in the current doc'.
[5.10:
. if mac`menus weren't fully dynamic
then adde's mac`menu could be for adde-wide operations
and then the edit.menu would have a
[type-specific operations ...] item
that would open an adde-designed menu system
which can then support full dynamism .
[5.4: 5.6: 5.8: merging app menus:
. there are several ways in which
the menus of a doc's datatypes
are merged into a single menu system:
# simple:
. a submenu is named by type,
and selecting that command will then
be applied to components of that type only;
other types will be ignored .
. when on the mac,
these type-specific menus would be expected in
menu#edit, along with [select all] .
# subtype polymorphism:
. an example of this is the supertype: number;
its menu items apply to all numeric subtypes
(int,float, Q,Z,R,C) . [5.10:
. the typical supertype menu
would list any operations affecting all subtypes,
and would then have submenus
representing each subtype, and containing only
subtype-specific operations .
. subtyping is concerned with interfaces
rather than implementations;
so, if a float happens to have an integer value
it retags itself as being an int;
however, since ints are a subset of floats
something constrained to int
will never have a chance to
similarly retag itself to float .]
# representational polymorphism:
. representations include
{ value implementations,
, graphical image,
, and programming language image
( adda-representation text )
} eg,
. when numbers are selected,
I can either bold-format a numeric's text,
or I can add the numeric values . [5.11:
. adde must either detect when types use text,
or types must declare this;
types may want to suggest a preference
that would explain to the user
why the preference exists;
the user can overrule any preference
after oking a purpose alert .]
[5.10:
. if an app is using text to represent its content
then a text styling menu
would apply to that app's datatype
(of course, the other text-modifiers
do not apply because
the text represents a type state
not just strings of characters).
. the user may want to vary the text styling
depending on whether the app's mode is:
# show value's graphical image
(might not use text)
# show value's adda-representation
(might be unavailable*)
# show value's implementation .
*:
. while every datatype must be
implemented in adda;
that type's values are not required to
have a written form (adda-representation);
for example,
streetlight.type = (red, yellow, green);
the intended image of the value red
is an icon that is colored red,
the adda-representation of the value red
is the text "(red);
and the implementation of the value red
is the integer: 1 (assuming the
default encoding of enums starts with 1,
and seeing that red is the first value).]
# generic polymorphism:
. the [all types].submenu shows
what operations of identical name
are recognized by every type in the selection
even if each type's authors had no idea
that they were naming their functions the same . [5.11:
. this would include the case of subtypes
where a supertype's interface is shared;
thus it involves supersets of subtype polymorphism .]
]-5.4: 5.6: 5.8 .
[5.4: the editable menu:
mac`menus are not expected to be user-editable;
but they can launch editable windows .
. in adde's menu-editing mode,
the user has access to 4 menu systems:
# the original menu tree;
# the original keymap;
# the user's version of the menu tree,
# the user's version of the keymap:
. the keymap is a table representing the keyboard
labeled to show each key's function .
left hand . . . . right hand
[][][][high].[] [].[high][][][]
[][][][home].[] [].[home][][][]
[][][][low ].[] [].[low ][][][]
. it's colored to make it graphically obvious
where the home key's row and columns are;
and, users can change the graphics:
the colors, background illustration,
and the nested framing arrangements .
. to stay quick, a text-version is loaded first,
followed by the full graphics .
. after ending adde's menu-editing mode,
only the user's versions are shown .
. in the original keymap, app`authors can show
what they think the most popular functions are
by placing them on the easiest-reached keys .[5.6:
. user's can also have a library of keymaps,
including author's map, current map,
and any other user-designed maps .]
. the style of interaction between {user, keymap}
is user-selectable:
# remindful interaction style:
. when users are in command mode (vs text insert)
typing any key brings the keymap into view,
shows you what you just did, and waits for enter .
# compact interaction style:
. hitting a key fills the command box
with the name of the function you just selected,
and then the command box is waiting for
either {esc, enter} to {stop,launch} the command). [5.6:
. hitting enter on an empty command
would show the keymap .]
]-5.4
. users may want both a menusystem
and a keymap --(before now,
I thought a keymap would be sufficient).
. the keymap title bar has a list of
the types of objects in the current selection; [5.8:
but in the menubar this may be relegated to
a submenu of menu#edit .]
. users may want to place the app`menubar
either in the display`menubar,
or in the current window's menubar .[5.6:
. this will be possible on any system;
because, addx is acting as
a system within a system:
ie, it looks like it's being run by a vm player:
each window into addx represents an addx desktop
within which there are windows into adde documents .
summary of the window nesting:
. mac display ->
mac windows for a mac app named addx ->
addx windows for addx app named adde ->
app windows within an adde document .]
[5.4: hierarchical keymaps:
. the whole point of the keymap
is that it flattens the menu hierarchy
into a table of the user's choice;
however,
the existence of optional co.menus
implies the need for hierarchies of tables:
certain keys can be labeled to
launch new co.menus;
and then each optional co.menu item
is mapped to a cell of the co.menu-specific table .
. there could be room on the main table
in which case
optionality is expressed with grey-outs .
. the purpose of a keymap`title.bar
is indicate which table you selected;
left-arrow brings you to previous one .]
freedom from having to trust
4.11: addx/binary extensions:
. the system protects the user from the app coder;
but for more freedom
the app coders perhaps could write extensions
(eg, for directly accessing some hardware [5.11:
and incrementally evolving native code like Python .]
).
. the safety model would be the usual tho':
the user has to ok a warning about
modified systems having no warranty by addx;
ie, the only reason for adding extensions
is to sneak around addx's
safety-minded limitations .
. addx might also ask the user
where they got this extension,
and suggest how they could find
similar functionality elsewhere .
. the safe way to get software
is open source code
written specifically in adda's lang;
which the addx system rewrites into
code it knows is safe;
. extensions don't allow this rewriting;
rather, they are asking the system
to install arbitrary code
which can have full power over your system .
. while such code may be
protecting trade secrets; [5.11:
adda code is guaranteed to protect
your system because the permissions are
per app', not per user (capabilities);
eg, your app can't write to your folders
unless you ok a range of them .
mis:
. this runs into the pc problem tho':
just because we're adults here
doesn't mean were not going to burn;
and then people are using the addx name
to lament how freedom is not idiot-proof;
much better to just take the blue pill
and keep people safe .
. keep in mind freedom vs trust;
the adda code can still do anything;
but only the adda code can be trusted to
tell you every rotten place
it's about to take you to .
"(can I search your folders?
can I use the internet?
do you want to ok what I send out? ...).]
. the system protects the user from the app coder;
but for more freedom
the app coders perhaps could write extensions
(eg, for directly accessing some hardware [5.11:
and incrementally evolving native code like Python .]
).
. the safety model would be the usual tho':
the user has to ok a warning about
modified systems having no warranty by addx;
ie, the only reason for adding extensions
is to sneak around addx's
safety-minded limitations .
. addx might also ask the user
where they got this extension,
and suggest how they could find
similar functionality elsewhere .
. the safe way to get software
is open source code
written specifically in adda's lang;
which the addx system rewrites into
code it knows is safe;
. extensions don't allow this rewriting;
rather, they are asking the system
to install arbitrary code
which can have full power over your system .
. while such code may be
protecting trade secrets; [5.11:
adda code is guaranteed to protect
your system because the permissions are
per app', not per user (capabilities);
eg, your app can't write to your folders
unless you ok a range of them .
mis:
. this runs into the pc problem tho':
just because we're adults here
doesn't mean were not going to burn;
and then people are using the addx name
to lament how freedom is not idiot-proof;
much better to just take the blue pill
and keep people safe .
. keep in mind freedom vs trust;
the adda code can still do anything;
but only the adda code can be trusted to
tell you every rotten place
it's about to take you to .
"(can I search your folders?
can I use the internet?
do you want to ok what I send out? ...).]
amazon-style component distribution
4.15: news.addx/alt's to the spikesource way:
gillmor gang and spikesource:
. spikesource is about selecting and testing
stacks of openwares from the
too-huge number of choices .
. the idea of rss updates were suggested
as a challenge to the spikesource design .
--
. it would take some safe architecture
like addx or ms`.net
for rss to be practically scalable:
anyone could stack any combination of rss feeds
because the architecture was designed to
safely use and mix indie works:
. the architecture would auto'ly accept
only high-level sources that it compiled itself,
and it would auto'ly enforce modularity:
making sure all the plugs & sockets fit each other .
. the spikesource design has to
hand-hold every piece it promotes,
and is not making optimal use of user reviews .
. it should be like amazon, but also sortable by
reviewer reputation or expertise in field .
(that may not be easy to do with volunteers,
but that's where the value is ).
gillmor gang and spikesource:
. spikesource is about selecting and testing
stacks of openwares from the
too-huge number of choices .
. the idea of rss updates were suggested
as a challenge to the spikesource design .
--
. it would take some safe architecture
like addx or ms`.net
for rss to be practically scalable:
anyone could stack any combination of rss feeds
because the architecture was designed to
safely use and mix indie works:
. the architecture would auto'ly accept
only high-level sources that it compiled itself,
and it would auto'ly enforce modularity:
making sure all the plugs & sockets fit each other .
. the spikesource design has to
hand-hold every piece it promotes,
and is not making optimal use of user reviews .
. it should be like amazon, but also sortable by
reviewer reputation or expertise in field .
(that may not be easy to do with volunteers,
but that's where the value is ).
Subscribe to:
Posts (Atom)
