evlan.org describes many #addx features

10.31: news.adda/lang"evlan/
evlan.org describes many addx features:

. Kenton Varda's Evlan has many addx features;
but, it "(currently has no type system);
and, it died in 2007.10.1, when the author "(got a real job)!

. what first caught my was cap-based security:

Most of today's computer platforms operate under
a fundamental assumption that has proven utterly false:
that if a user executes a program,
the user completely trusts the program.
This assumption has been made by just about
every operating system since Unix
and is made by all popular operating systems used today.
This one assumption is arguably responsible for
the majority of end-user security problems.
It is the reason malware -- adware, spyware, and viruses --
are even possible to write,
and it is the reason even big-name software
like certain web browsers
are so hard to keep secure.
Under the classical security model,
when a user runs a piece of software,
the user is granting that software the capability
to do anything that the user can do.
Under capability-based security,
when a user runs a piece of software,
the software starts out with no capabilities whatsoever.
The user may then grant specific capabilities to the program.
For example, the user might grant the program
permission to read its data files.
The user could also control whether or not
the program may access the network, play sounds, etc.
Most importantly,
all of these abilities can be controlled
independently on a per-program basis.

. the other main idea like addx
is its being a virtual operating system
which runs on top of any other operating system;
via a virtual machine that is the sole access
to the underlying platform's OS .
. by a complete platform,
he means it is not specialized to be
efficiently accessing all of bloated unix,
but to define what it needs,
and then have the vm access what it needs
for impl'ing the Evlan virtual platform .

adda's secure by language idea:

Even better than implementing security in an operating system,
is implementing it in a programming language:
developers are able to control the capabilities available
to each piece of code independently.
Good practice, then, would be to only give each component
the bare minimum capabilities that it needs to
perform its desired operation.
And, in fact, it is easier to give fewer capabilities,
so this is what programmers will usually do.
The result is that if a security hole exists in some part of your program,
the worst an attacker can do is
gain access to the capabilities that were given to that component.

--[. keep in mind that this won't work without
also implementing security at the hardware level;
this is the level where modularity can be enforced;
otherwise, malware could just jump to
what ever code there is with the permissions it needs .
(see qubes doc's) .]

It is often possible to restrict all "dangerous" capabilities
to one very small piece of code within your program.
Then, all you have to do is make sure that
that one piece of code is secure.
When you are only dealing with a small amount of code,
it is often possible to prove that this is the case.
It is, in fact, quite possible to prove
that a program written in a capability-based language
is secure.

[. great to know if your os and every other app
-- that means esp'ly your browser --
are all written in this provable language ? ]

see: Capability-based Security is used in the
EROS operating system and the E programming language.
Also, Marc Stiegler et al.

addx's idea that concurrency is the key
to secure speed:

Evlan has strong support for highly concurrent programming
being a purely functional language,
Where automatic parallelization is not possible,
there are very lightweight threads (without stacks).

Most of today's systems use imperative languages
meant for a single CPU; eg, [written in adda:]
processAll(results#t.type).proc:
for(i.int = results`domain):
      results#i`= processItem results#i
).

. in c, it would process each item in order,
from first to last.
It does not give the system any room to
process two items in parallel
or in some arbitrary (most-efficient) order .

adda aspires to be simple:

It is far easier to remember
multiple uses for a single construct
than to remember multiple constructs.

--[. however he has ada-itis and braggs about
having only 19 keywords;
one of which is "(where)
which could have been said with a reused "(:) .]

interoperability done via compatibility layers:
If and when the legacy software is no longer in use,
the compatibility layers can be removed,
leaving only the ultra-efficient Evlan core behind.

functional:
Because Evlan is purely functional,
no function call is allowed to have "side effects".

. see www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=225
(dead link, is this right: queue.acm.org/detail.cfm?id=864034)?
-- ask google where else that link can be found:

Natural programming languages and environments

Communications of the ACM September 2004/Vol. 47, No. 9

by Brad A. Myers, John F. Pane, Andy Ko

This article presents findings on natural programming languages.
(i.e. natural as in intuitive in the UserCentric way)
It advocates features for programming languages,
that are justified by these findings.
Areas include:
    SyntacticSugar, that causes fewer errors
    (it more intuitive/natural).
    Better integrated debugging-support,
    esp. for hypotheses about bug-causes.
which suggests that humans like to write rules of the form
"When condition X is true, do Y".
I am not yet sure to what extent this will
change the current system, however.

natural programming:

By "natural programming" we are aiming for
the language and environment to work the way that
nonprogrammers expect.
We argue that if the computer language were to
enable people to express algorithms and data
more like their natural expressions,
the transformation effort would be reduced.
Thus, the Natural Programming approach
is an application of the standard user-centered design process
to the specific domain of programming languages and environments.

[at that link is a] good short summary of the
Natural Programming project here at CMU.
We're affiliated with the EUSES consortium,
which is a group of universities working on
end-user software engineering.
google's 2007 Update on the Natural Programming Project

Functional Bytecode

Bytecode for the Evlan virtual machine
uses a functional representation of the code.
In contrast, the VMs of Java and .NET
use assembly-like imperative instructions.
. the GNU C Compiler's "Static Single Assignment" phase
is actually very close to being equivalent to
a purely functional language. [no overwrites]
If GCC does this internally just to make optimization easier,
then it doesn't take a huge stretch to imagine a system which
compiles imperative code to functional bytecode .

--[11.30:
. another contrast to assembly-like imperative instructions
is addm's idea for a high-level interpreter:
instead of translating from an abstract syntax tree (AST)
into a sequence of assembly instructions;
addm, the vm, would try to evaluate an AST . ]

The purpose of constraining variables to types
is to get the compiler to check your work for bugs
and optimize code as well .
. if you could specify that an index to an array
must be less than the size of the array
-- and if the compiler could then check for that --
then buffer overruns (one of the most common bugs
leading to security holes in modern software)
would be completely eliminated.
(run-time bounds checking can prevent buffer overruns,
but then users see your app shutting down unexpectedly).

survey of programming architectures

11.15: web.adda/oop/architectures:

the categories of inheritance:

# type clustering (inclusion polymorphism):

. numbers are the classic type cluster;
that type's major subtypes have overlapping interfaces;
and they need a supertype to coordinate biop's
(binary operations; a function with 2 arg's;
eg, addition's signature is: +:NxN->N )
whenever the param's have unmatched subtypes
(eg, RxC->C, ZxN->Z, /:NxN->Q, ...).

type cluster/supervision models:
#coordinated:
. the set of polymorphic subtypes is fixed,
and the supertype knows how to convert between them;
because,
it knows the data formats of all its subtypes .
# translated:
. the supertype provides an all-inclusive
universal data format;
eg, numbers -> complex .
. all subtypes convert between that format
and their own .

type cluster/subtypes must include range constraints:
. range constraints are essential for efficiency
as well as stronger static typing;
because, range limits are what allow
direct use of native numeric types .
. typical native types include
{N,Z,R}{8,16,32,64,128} .

# type classing (Subtype polymorphism):
. declaring a type is a member of a class,
and is compatable with that class
by inheriting its interface;
the new type is then usable
anywhere the inherited class is . [12.31:
. the type class is defined by its interface;
any type following that interface
is considered a member of that class .
. it's not about sharing code by extension;
it's organizing hierarchies of compatability .]

# type cluster combined with type classing:
. the subtypes of a type cluster
can be type classed; eg,
a dimensioned number could inherit from int;
and then to coordinate with the numeric supertype
it uses functionality from int.type
to deal with these messages:
{ what is your numeric subtype?
, your numeric value?
, replace your numeric value with this one
} .
. with just that interface,
any subclass of any numeric subtype
can be used in any numeric operation . [12.31:
. all self-modifying operations ( x`f)
can be translated as assignments (x`= f(x));
so then the inherited subtype
provides all the transform code .]

#type classing without clustering:
11.20:
. without type clustering;
what does type classing do then?
are biop's supported? polymorphism?
. historical reasons for inheritance:
# polymorphism
# type compatability
# reuse of work .
. you want to extend a type's
structure and functionality,
not interfere with its code base,
and still be useful everywhere your ancestors are .

. in the popular oop model,
the inherited work is reused by
adding to an inherited type's
functionality and instance var'space
(creating a polymorphism in the type).
. there's type compatability because
the obj' can handle all the ancestor's
unary and self-modifying functions;
but, popular oop approaches differ on
how biop's are handled .

. the classic, math'al oop uses clusters, [12.31:
which can handle biop's because the supertype
has limited membership to its type class
and can thus know in advance
what combinations of subtypes to expect
among a biop's pair of arg's .
. in a system without clustering's
closed class of subtypes
then there is no particular type to handle
the coordination of mixed biop arg's .
(that mix can consist of any types in
one arg's ancestors, or their descendents).]

. if subtypes can redefine a biop,
then a biop's method might be arbitrated by:
# nearest common ancestor:
the arg' set's nearest common ancestor type;
# popular:
the first arg determines the method;
# translation:
. an inheritable type has a universal format
which inheritors convert to,
in order to use the root's biop method .]

# incremental composition:
. it can be simplifying to describe a type
in terms of how it differs from other types;
this case includes anything not considered to be
type clustering or subclassing .
. revisions such as removing inherited parts
can preclude type compatability;
in such cases, compatability could be declared
with the use of a conversion map .
. incremental composition provides
module operators for building in ways
familiar to lisp users:
code can read other code, modify it,
and then use it as a module definition .
[11.20:
. with incremental composition,
any inheritance behaviors should be possible;
but the built-in inheritance should be
simple, classic type clustering and classing
as described above .
. the directions of popular oop
are not helping either readability or reuse;
esp'y unrewarding is the ability to
inherit multiple implementations
that have overlapping interfaces .]

#frameworks:
11.15:
. generic types can implement frameworks:
a type is an interface with all code supplied;
a generic type
leaves some of its interface undefined
or optionally redefinable,
with the intent that parameter instantiations
are customizing the framework;
eg,
a typical gui framework would be impl'd as
a generic task type;
so that creating an obj' of that type
initiates a thread of execution
that captures all user input
and responds to these events by
calling functions supplied by the
framework's customizing init's .]

adda/oop/value types:
11.16:
. the classic use of oop is type clustering
as is done for numerics:
it provides users of the numeric library
with an effortless, automated way
to use a variety of numeric subtypes
while also employing static typing,
and enjoying any enhanced readability or safety
that may be provided by that .
. coercions and range checks can all be
tucked under the hood,
without requiring compliance from clients .
. this automation is possible because
the designer of a type cluster's supertype
is using subtype tags to determine
each value's data format .

. the supertype module is also
the only place to coordinate
multiple param's having unmatched subtypes;
after one param' is coerced to match the other,
operations involving matched binary subtypes
are then relegated to subtype modules .

11.19: intro to value`type:
. static typing generally means
that a var's allowed values are confined to
one declared type,
and perhaps also constrained;
eg, limited to a range of values,
or a specific subtype .
. if that declared type is a type cluster,
it's values will include a type tag
for use by the supertype module,
to indicate which of its subtype modules
is responsible for that data format .

. type.tags are sometimes seen as a way to
replace Static typing with ducktyping
(where the tag is used at run-time
to check that the given value has a type
that is compatible with the requested operation).
. type clustering, in contrast to ducktyping,
is static typing with polymorphism
(statically bound to the cluster's supertype);
and there, the purpose of the type.tag
is merely to allow the supertype module
to support a variety of subtypes,
usually for the efficiency to be gained
from supporting a variety of data formats;
eg,
if huge complex numbers won't be used,
then a real.tag can indicate there is
no mem' allocated for the imaginary component;
or,
if only int's within a certain range will be used,
then the format can be that of a native int,
which is considerably faster than non-native formats .

. the value's subtype (or value`type)
is contrasted with a var's subtype
to remind us that they need not be equal
as long as they are compatable;
eg,
a var' of type"real may contain
a value of type"integer;
because they are both subtypes of number,
and the integer values are a
subset of the real values
(independent of format).

. the obj's subtype puts a limit on
the value`types it can support;
eg,
while a var' of subtype"R16 (16bit float)
can coerce any ints to float,
it raises an exception if that float
can't fit in a 16-bit storage .

. another possibly interesting distinction
between var' types and value`types
is that value`types have no concept of
operating on self; [11.19:
a unary operation over a value`type
doesn't involve any addresses,
and there is nothing being modified .
. while popular oop has a var`address
modify itself with a msg,
eg, x`f;
classic oop would say that was an
assignment stmt plus a unary operation:
x`= x`type`f(x) -- shown here fully qualified
to indicate how modularity is preserved:
the function belongs to x's type .]

. adda can also enforce typing between
unrelated types like {pure number, Meters},
but the system depends on supertype designers
to correctly handle their own subtypes .

. in addition to the distinction between
{library, application} programmers,
there is also kernel mode:
the adda run-time manages all native types
so that any code that
could be responsible for system crashes
is all in one module .

10.23: news.adda/compositional modularity:
11.14: Bracha, Lindstrom 1992`Modularity meets Inheritance

We "unbundle" the roles of classes
by providing a suite of operators
independently controlling such effects as
combination, modification, encapsulation,
name resolution, and sharing,
all on the single notion of module.
All module operators are forms of inheritance.
Thus, inheritance not only is
not in conflict with modularity in our system,
but is its foundation.
This allows a previously unobtainable
spectrum of features
to be combined in a cohesive manner,
including multiple inheritance, mixins,
encapsulation and strong typing.
We demonstrate our approach in a language:
Jigsaw is modular in two senses:
# it manipulates modules,
# it is highly modular in its own conception,
permitting various module combinators to be
included, omitted, or newly constructed
in various realizations .

10.23: Banavar 1995`compositional modularity app framework:
11.14:

. it provides not only decomposition and encapsulation
but also module recomposition .
. the model of compositional modularity is itself
realized as a generic, reusable software arch',
an oo-app framework" Etyma
that borrows meta module operators
from the module manipulation lang, Jigsaw
-- Bracha 1992`modularity meets inheritance .

. it efficiently builds completions;
ie, tools for compositionally modular system .
. it uses the unix toolbox approach:
each module does just one thing well,
but has sophisticated and reliable mechanisms
for massive recomposition .
. forms of composition:
#functional: returns are piped to param's;
#data-flow: data filters piped;
#conventional modules: lib api calls;
# compositional modularity:
. interfaces and module impl's
operated on to obtain new modules .

. oop inheritance is a form of recomposition;
it's a linguistic mechanism that supports
reuse via incremental programming;
ie, describing a system in terms of
how it differs from another system .
. compositional modularity evolves
traditional modules beyond oop .

. that compositional modularity
sounds interesting,
what's the author been up to recently?
reflective cap'based security lang's!

Bracha 2010`Modules as Objects in Newspeak:

. a module can exist as several instances;
they can be mutually recursive .
. Newspeak, a msg-based lang has no globals,
and all names are late-bound (obj' msg's).
. programming to an interface (msg's vs methods)
is central to modularity .

. it features cap'based security:
# obj's can hide internals
even from other instances of the same class;
# obj's have no access to globals
thus avoiding [ambient authority]
(being modified by external agents) .
# unlike E-lang, Newspeak supports reflection .

Newspeak handles foreign functions
by wrapping them in an alien obj,
rather than let safe code
call unsafe functions directly .

--. this is the equivalent of SOA:
whatever you foreigners want to do,
do it on your own box (thread, module)
and send me the neat results .

pico puts some clothes on lisp!

12.13: lang"pico:

. what kind of academic site would drop their link
(pico.vub.ac.be/~wdmeuter/RDL04/papers/Bracha.pdf)
to an important paper like Gilad Bracha's
pluggable types! ? welcome anyway,
to Brussel's Vrije univ's pico project,
the marriage of Scheme and normal infix notation
for a lispy pascal !

Pico is the smallest but expressive language
for teaching computer concepts to
non-computer students (eg, Physics and Chemistry).
. it adapts Scheme's syntax (significantly)
and semantics (subtly):
* the semantics had to be simple
even if some Scheme features became inaccessible.
* the syntax had to be like that in math;
* ease-of-use, portability, interactivity...
must have priority over performance;
Pico features garbage-collected tables (i.e. arrays),
higher order functions, objects,
meta programming and reflection.
* Pico as a language had to coincide with
Pico as a tutoring system;
the boundaries between programming and learning
had to be totally removed.

Pico is no longer used as a tutoring language
but this is a consequence of mere politics;
[eg, mit moved from Scheme to Python
because Python too was a good teaching lang'
that was also useful (eg, for working with
the new robotics lib' mit adopted).]

Today, Pico is still used as a means to teach
principles of language design,
interpreters and virtual machines
in a sophomore course:
Theo D'Hondt's hll concepts:
. all software used in this course are built in Pico.
Even the virtual machine itself is built in Pico
(it is a so-called meta-circular implementation
using a previously created ANSI C Pico machine).

Theo D'Hondt's computational geometry course:
. it uses c and version of pico
( a graphical extension
with syntax modified to enhance readability).

Theo D'Hondt's Growing a Lang from the inside out:
Programming Language Engineering
is the assembly and mastery of
constructing and applying
programming language processors.
. we need to review research like continuations,
and critique the current attempts at concurrency .
. this series of lectures discusses the need for
language processor design to be extensible,
similar to Guy Steele's 1998 OOPSLA phrase
“Growing a Language”
refering to the need for an expressive core
that is easily extended .
We need to bridge the gap between
the abstract concerns addressed by the language
and the features offered by the hardware platform
-- keeping in mind software reuse .

12.14: beyond pico:
AmbientTalk is influenced by E.lang and pico;
it's intro'd here along with google's Go.lang:
Another evolving area of computing
concerns programs running on mobile devices
linked in "ad hoc" wireless networks.
AmbientTalk, an experimental language presented by
Tom Van Cutsem from Vrije Universiteit Brussel in Belgium,
explores a new paradigm called
"ambient-oriented programming,"
which departs from traditional distributed computing
in two main ways.
First, it does not rely on central infrastructure.
Second, it's smart enough to buffer messages
so that when the connection drops,
they're not lost, and when the connection is restored,
it sends the messages through as if nothing happened."

12.13: adda/double colon operator in pico:
pico'declarations:
Pi::3.1415
immutableFun(x)::x
. pico'declarations (name::value)
introduce immutable symbols (i.e. constants)
whereas pico'definitions
introduce assignable names [variables].
# Definition
eg, x:4, add(x,y):x+y, t[5]:10
a variable is defined, a function is created,
or a table is allocated and initialized.
# declaration
[defines the same things, but immutably];
eg, Pi::3.14, t[3]::void and f(x)::x.

stack-based vs queue-based langs

6.10:
. Jasvir Nagra (www.cs.auckland.ac.nz/~jas) writes:

Features of some programming languages make some algorithms
more elegantly expressly than others
. E has two calling conventions
- one that is stack-like and one that is queue-
which makes both styles of visitors pleasantly expressible
(slightly modified to emphasize the similarity) .
. I realize its not really much more to allocate a queue
but its a pretty pattern and makes it particularly easy to mix DFS and BFS:

def depth(tree, visit):
""(. stack-based languages might favor depth-first
because it is easy to take advantage of the call stack
instead of having to allocate a new data structure to store a queue
)
for child in tree`children:
depth(child, visit)
visit(tree)

def breadth(tree, visit):
""( in a queue-based language more people would use a breadth-first visitor.
)
for child in tree`children:
breadth<-(child, visit)
visit(tree)