can a scripting engine really be safe?

6.1: addx/can a scripting engine really be safe?:

. I just heard that Apple will no longer allow apps to
communicate by sending each other AppleScripts;
instead they need to use each other's API .
. this I found confusing because I had a different understanding
of applescript connectivity:
. apps exported an API that applescript could understand,
and then applescripts could use all such apps .
. I guess what they were saying is that, counterintuitively,
only AppleScript had been able to use such API's:
you couldn't do so from the native lang (objective C).
. anyway, this got me to asking the question:
can a scripting engine really be safe?
here's my yes:

hybrid of efficiency and encapsulation for oop

4.8: adda/oop/hybrid of efficiency and encapsulation:

. oop's inheritance is notorious for
sharing instance var's (ivar's);
but, why can't direct access still be
more controlled, like ada param's are ?

4.10: review:
. in typical (popular) oop`inheritance,
efficiency is gained when the interface
commits to a particular list of ivar's;
the inheritor's ivar's get tacked on to
the ivar record being inherited (super's) .
. encapsulation can be maintained anyway
despite the lack of privacy,
because the super can opt to mandate
that only the super's methods
can operate on the super's ivar's .
. if opting instead to share ivar's with inheritors,
then their accesses can be done quickly
since they bypass calling a function;
but, everyone in the inheritance chain
is communicating via shared var's;
and in this way, new bugs can be caused whenever
any party of the inheritance chain gets modified .
4.10:
. one way to allow direct but controlled access
is by having optional watch functions:
. inheritors have direct access
but it's confined to reads and writes;
ie, rather than having continuous access,
it's like the ada`parameter model
where the inout param's are modeled by
copying the initial value,
working on one's own copy,
and then overwriting the param`target
when the function is returning .
. if the super wants more control over
its own ivar's,
it can put a watch on them:
after a write, it can do range testing
or check for internal consistency;
if it raises an error,
the system can know who did that last write .

. the interface shouldn't have to list ivar's;
the ivar's that are listed are simply
those meant for sharing with inheritors .
. the ivar's that actually model object state
are known only to the init functions .

eiffel vs ada

11.10: adda/lang/eiffel vs ada
Tucker Taft:

. pre- and post-conditions can be
fairly easily and efficiently included in Ada code.
Invariants seem difficult to emulate directly in Ada.
If you're really interested in the
formal use of assertions with Ada,
maybe Anna is a solution for you.

. although I like the assertion stuff in Eiffel,
I think the language has a number of "inelegant" aspects.
For example:
# exception handlers only at
the top level of a routine,
with the only way to "handle" an exception
being by retrying the whole routine.
# No way to return from a routine in the middle.
This makes it a pain in the neck
to search through a list for something in a loop,
and then return immediately
when you find what you want.
(I have never found the addition of
extra boolean control variable
a help to the understanding of an algorithm.)
# Namespace control
handled by a separate sublanguage,
and no real higher level concept of
"module" or "subsystem."
An obscure notation like "!!" (construction).
being used for an important and frequent operation;
# No way to conveniently "use" another abstraction
without inheriting from it.
# No strong distinctions between
integer types used for array indexing.
# Using the same operator ":="
for both (aliasing) pointer assignment,
and for value assignment,
depending on whether the type is "expanded."
(Simula's solution was far preferable, IMHO).
-- And most critically:
# No separate interface for an abstraction.
You can view an interface by running a tool,
but this misses completely the importance of
having a physical module that represents the interface,
and acts as a contract between
the specifier or user of an abstraction
and its implementor.
In Eiffel, one might not even be truly aware
when one is changing the interface to an abstraction,
because there is no particular physical separation
between interface and implementation.
I consider many of the above problems quite serious,
with some of them being real throwbacks
to the old style of programming languages
where there were no well defined
interfaces or modules.
Hence,
I cringe a bit when people say
that Eiffel is the "most elegant" OOP
and that they would use it
if only it were practical to do so.
In many ways,
I think Ada is much better human-engineered than Eiffel,
with important things like range constraints
built into the language
in a way that makes them convenient to use.
Although general assertions are nice,
they don't give you the kind of
line-by-line consistency checks
that Ada can give you.
To summarize --
Although Eiffel certainly has a number of nice features,
I don't consider it ready for prime time
as far as building and maintaining large systems
with large numbers of programmers.
And from a human engineering point of view,
I think Ada is significantly better.

jhc0033:
Eiffel targets a largely similar audience of
"correctness-oriented" programmers that Ada does.
However, it took some digging around
(no introductions to the language mention it)
to discover that Eiffel has a gap in its type system.
Guess what, type theory is a branch of math,
and OOP is a spiritual following.
I know what takes precedence in my book.
The Eiffel community's attitude is basically:
"we'll just pretend 2+2=5 because we can
use it to justify some teachings".
Ludovic Brenta:
I evaluated Eiffel too when I read Bertrand Meyer's
Object-Oriented Software Construction book.
The two things I dislike the most about Eiffel
are the lack of range constraints on numeric types
and the fact that almost all contract checks
are deferred to run-time.
Helmut

- Ada has a built in concurrency model (like java)
and Eiffel does not.
In Eiffel there is SCOOP
(simple concurrent object oriented programming)
which tries to integrate concurrency into the language.
But there is not yet any Eiffel compiler available
which implementes SCOOP.
- Eiffel has "Design by Contract"
which is a very powerful mechanism to get your SW right.
Using assertions in your code appropriately,
you are able to catch a bug much closer to it's origin
than without DbC.
DbC opens up the road for a verifying compiler
(i.e. a compiler which can at compile time
verify if contracts are not broken).
I don't understand why the promotors of Eiffel
haven't made the language more complete
in terms of standardization,
standard libraries and concurrency.

Pascal Obry:

Ada even supports a Ravenscar profile
(where no dead-lock can occurs)
usable for high-critical systems.
1995 oop: programing by extension and dynamic dispatching
2005 oop: protected/tasking interface that can be inherited.

helmut:

The ECMA Eiffel language specification is a well written document
(it is a language specification document
and not a document for the Eiffel user).
It lacks only in the area of
void safety, initialization
and covariant redefinitions (catcalls).
The problem:
It has not been updated since june 2006.
I.e. it reflects a status which has never been implemented
(and will probably never be implemented,
not even by EiffelStudio).

Eiffel`author Bertrand Meyer provoked by Ada.

(Yannick Duchêne) a écrit :

I talk to him (back in 1990 or 1991) one time:
the Eiffel inventor hates Ada .

Adam:

. It appears that Meyer has some criticisms of Ada,
but I couldn't find anything that would indicate
that he hates it.
His Eiffel site has an article about the Ariane 5 crash,
but he said there that
the language couldn't really be blamed
because the problem could have been caught
using Ada's exception mechanism
if the programmers had used it properly.

dependency versioning

7.10: adda/lib'mgt/dependency versioning:

[7.27: summary:
. these are rough ideas for
how to keep a library of software components
modifiable and evolvable,
without having problems with version conflicts .]

. intro to versions conflicting with portability:

"(
Forth was interesting in that
not only it was written in itself,
but all the internals were available
to any programs written in it,
and, furthermore, could be changed at will.
The thing is, Forth lacked abstraction.
Yes, you could change the compiler.
But, of course, you’d have to know
how the specific compiler worked:
eg, for threaded code, variants included:
generated {indirectly, directly, subrouting},
and generated {bytecode, machine coded}.
So it had no portability at all.
)

--. that inspired these ideas:

. in addition to there being
versions for systems;
any component that allows being changed,
must have it's own version number
for both the spec' or interface changes,
and the impl' or build changes .
. if the author (ie, the name of a fork)
is not specified with the version number;
then it's assumed to be from the main source .

. to be portable with forks,
the original site must provide
version numbers for
all components, and all forks .

. in order for a fork to use
the original project's name,
it must subscribe to the original's
versioning protocol:
a component lists its dependencies
which includes the release version
of a particular fork
modified with the release versions
for particular components .

. that means when a library or app
is introduced to a platform's lib mgt,
it gives the expected release versions:
this is described economically by saying
most components' versions are that of
some author's system release;
while a few components vary from that release,
and are described individually .
. the lib'mgt then checks these dependencies,
and tries to procure them if not present .

. the user should also be notified
when an installation has
many unique dependencies;
at least if the practical size
is significantly larger
than the app's stated size .

. each version requires its own
space in the library,
along with pointers to
whatever other units are using it;
so then, if you uninstall a unit,
all its bloat goes with it,
unless a dependency is still used
by other units .

unifying records with parameters

9.3: adda/unifying records with parameters:

. how is the arg an instance of record literal

with need to specify in/out mode too?

. how to param as record when it has additional properties?

types have similar : const is in-mode .

const cannot got to out or inout,

also out mode is same as ptr to type,

which is a record type,

. to be functional

rather than say inout in the param spec's,

list {out, inout}'s along with externals affected

together with the function's return .

. how does server refer to caller's locals?

same as caller would?

server could be either {local, external} to caller,

so make naming relative to server

plus,

if external,

then expecting access to caller local is a special priveledge

say in/out caller`

instead of reserved words,

just predefined optional reserved .

11.15: adda/type/contracts vs parameter`type:

. contracts are the way to

diff'tween a param's working type

vs what its init'value can be .

. this idea might be merged with

exceptions being part of a function's spec' .

. it could be like this:

f(x.t= ( ~range -> exception, nil -> default),

);

however, as with c,

the user should be able to see param instantiation

as being just like an assignment:

all syntax should match how a record is being assigned .

unifying contracts, permissions, and capabilities

7.5:

merge:

. dynamic permission setting .

. sometimes a var needs {read, write, exe} status under prgm control;

eg, locals of a program

which are external to that program's subprograms

can specify which subprogram can have what access .

. it can create local names dynamically

-- a filesystem that is local to a program .

. it can either statically declare var's as const,

or dynamically set permissions like this:

obj`access(user: rwe) .

. imagine that your program controls variables

with exactly the same power with which you control files:

not only do you have creation-time or compile-time control

of how a variable can be accessed;

you also control at run-time, whether to create a new variable,

what to name it, and how it can be accessed .

. this is thinking like a lisp programmer:

the simplest path to automating your intelligence

is to give your automation

all the same controls that your intelligence has,

so that you can code it just the way you do it .

. it is also simplifying a language

to unify all similar features .

. the next step is moving from permissions to capabilities .

. rather than obj's saying who has what access;

the agents come with contracts that explain

what access they need,

and then the system insures

that they stick to their contractual access limits .

7.6:

unifying permissions with cap's is part of oop contracts,

simple objects like Number have an empty contract:

they don't interact with anything .

. complex contracts include files used, files kept,

other objects or systems being communicated with,

info being communicated,

7.7: adda/dimensions of contracts:

. contracts are usually literals,

an immediate value that the compiler can use,

but they also need to be parametric (a parameter of generics)

and inheritable from employer .

7.23: adda/capabilities:

. adda does not have to be inefficient in its total control of resources:

its allowances are set as read-only pointers .

. the capabilities are expressed as

read-only pointers to the allowed functions .

. if capabilities change,

the pointer becomes invalid,

and the process then throws an exception when it tries to use it .

. after looking at the modularity of rsbac,

I was thinking that was really inefficient,

but combined with my idea for adda here,

the expensive decisions have to be made only once,

apon declaring a need for the object,

and often that can occur during compilation .

--. some notes on rsbac:

Rule Set Modeling of a Trusted Computer System,

Generalized Framework for Access Control (GFAC)

. the clear separation between

Access Enforcement Facility (AEF),

Access Decision Facility (ADF)

with

Access Control Rules (ACR)

and Access Control Information (ACI).

The AEF, as part of the system call function calls the ADF,

which uses ACI and the rules

to return a decision and a set of new ACI attribute values.

The decision is then enforced by the AEF,

which also sets the new attribute values and, in case of allowed access,

provides object access to the subject.

The Access Control Enforcement Facility (AEF)

intercepts every security relevant system calls,

compiles them and performs a request to the

Access Control Decision Facility (ADF).

The ADF will ask every Decision Module

for its opinion on this request.

The answer from every module is combined by the ADF

with a restrictive metapolicy,

giving a final answer that is sent back to the AEF.

The object is accessed normally

if access has been granted previously .

If everything went without denial or error,

the AEF sends a notification to the ADF.

The ADF tells the modules to update their attributes

from the data structures.

The ADF sends back an acknowledgement to the AEF.

Control and optional data are returned to the process.

7.7: addm/unifying cap's with permissions:

. great, I found a good description of a capability!

now I can figure out how it's related to file permissions .

. in the simple permissions system,

your acct is associated with either the user or admn role;

and, when you ask for a view of available files,

you are handed virtual cap'keys that depend on your role:

admn's have free access,

and users get what the admn's give them .

. any program your role uses will inherit

the virtual cap'keys due your role .

. in the role-based access control system,

there are special groups that users can belong to:

{ power users, backup tech's, ... various special roles};

so then file access depends on what group

your acct is a member of .

. again, you have to be careful of what role you're playing

because the tools you use will be inheriting your cap'keys .

. in a cap'key system,

a program will not inherit your role,

instead the system will inform you that your new program

is wanting access you haven't given it,

and then provide you with a menu of all the cap's you have:

per-folder permissions, net activities, ... .

7.14:

. I had conceived the cap' problem by this typical situation:

I have an app that should do a job on one object and not other .

. now is it ok if this app calls another app to do something with this obj?

. my assumption was that I can't trust this app anyway,

so I minimize its destructiveness by saying whatever it does

will only happen to the selected obj;

but there must be some limit to this:

if it can call something that can transitively call on-line,

my obj -- with personal info -- just went online .

. this is called the confinement problem,

and it's solved the way you would think:

your app needs permission to reach on-line

and to reach any other app that may transitively reach online .

. revocation:

how can you revoke a cap'key given to an app?

you need to send it a proxy, like a pointer,

but instead of leaving the pointer dangling,

it creates a situation where

the proxy's target has been instructed to

deny any additional services .