Re: Promoting adoption of Smalltalk

Steve,

Out of curiousity, let's play a purely hypothetical thought game.

What if:
=======
a) QKS had a SmallScript tool that read jar files and autocreated/updated
AOS Platform classes and AOS Platform methods (containing Java opcodes)
based on the definitions contained in the jar files.

b) QKS had a jitter subclass for the AOS Platform VM that could directly JIT
java byte-codes to machine code using register/calling conventions that were
fully compatible with the base AOS VM opcode jitter class. Potentially
including the ability to support the JNI.

c) These facilities were part of the free SmallScript-SE version.
=======

Would this be useful?

Would it enable you to have the ability to make effective use of Java under
the AOS VM?

A "no" answer suggests there is some controlled/proprietary elements that
hinder the use of Java vis-a-vis other open-source languages (separate from
their execution technology).

---
What if you had the same effective capability for Python, or Perl on the AOS
VM?
---

Just Curious,

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

"A SERFer" <[hidden email]> wrote in message news:[hidden email]... of dollars.
> >Someone, somewhere has to pay for that. Presumably the reason you don't
want
> >to help make Squeak ready for your purposes is that it will cost *you*
too

"Dave Harris" <[hidden email]> wrote in message
news:[hidden email]...
> [hidden email] (Cees de Groot) wrote (abridged):
> > I've seen interfaces and sandboxing libraries
>
> Do you have a reference for the sandboxing libraries?

See my comments further on about how this is done efficiently within the
dynamic binding architecture of dynamic languages with optional dynamic type
systems.

>
> I would have expected this to be an area where a static type system
> helps.

Static typing only affects "timing" and "modus-operandi" for the
checking/validation of security information. I.e., with static typing the
security access can be checked at the time a method is jitted since all its
function and variable/data references are resolvable. In a dynamic type
system, variable/data access is handled as in a static (only) type VM, but
security access for method calls can (or must if static type information is
not present) be deferred until a message is (invoked and) bound (to a
method) via the generic (top-level) binder.

It is correctness (which is different from security/sandboxing) that can be
determined via static typing. I.e., as I know you aware from seeing your
website earlier this year, static typing enables correctness verification to
be done at compile time on generated code. Correctness really has a limited
relationship to security.

In complex or highly adaptive systems such as we often see on the web today,
static validation of correctness has limited value compared to the level of
type-safety/performance-safety offered by dynamic languages which control
pointer access and enforce fully dynamic (runtime) type binding
verification. Static typing often leads to implementations that are too
rigid in the face of schema/version changes -- fragile base class issues
being a very old and perhaps best known example.

> For example, for security we want an immutable String.

Immutable properties for objects have been part of the AOS Object Model and
thereby in QKS Smalltalk since it was developed in 1991.

> This is hard to do in Smalltalk because an instance's initial state
> is set sending it messages, and there is no built-in language mechanism
> for preventing untrusted code from sending the same messages.

You're making a generalized statement (mostly true of course) that is
actually a description of implementation not language issues. QKS Smalltalk
provides infrastructure for dynamically changing the state of an object to
be immutable or read-only, or marking all instances of a class as immutable.
All such basic object properties are runtime enforced. The whole question of
immutable semantics in Smalltalk was an issue I raised pretty heavily in
1993-1994 as being a problem. It was, as a result of my ANSI x3j20
involvement, also a moderately big point of discussion during the ANSI
Smalltalk process -- at least to level of raising awareness of the issues
among the participants.

The unified immutability/read-only mechanism provided by the AOS Object
model's semantics is a basic part of QKS Smalltalk. It ensure consistent and
proper semantics for literals such as <String>, <StyledString>, <GUID>,
<StaticList> are preserved, and how primary <PoolVariable>s referencing
class names are protected.

SmallScript (and the new v4 AOS Platform VM) extends these features with
built in language mechanisms for blocking access to code via enhanced
language level scoped binding semantics. The architecture of QKS Smalltalk
is designed to allow callee's the ability to very efficiently determine who
or what is calling them; the SmallScript language formalizes this. As in
many Smalltalk implementation's the entire active callchain can be reflected
upon.

This is further enhanced by the AOS Object Model whose namespace
architecture is unified/integrated with the semantics of the binding system.
Which results in binding based on having the following information:
<receiver-behavior> <message-selector> <calling-scope> <arg-types>
<return-type>.

Security and sandboxing in a dynamic type system can result in better
performance because it can be lazier. It only needs to be verified when a
given message is invoked. The verification does not need to be done for each
callsite within each method, but rather can be done for each combination of
<calling-scope> AND <bound-method-signature>. So the dynamic mechanism is
significantly more efficient than the static mechanism.

> I can imagine ways around it but they are more-or-less clumsy.
>
>   Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
>       [hidden email]      |   And close your eyes with holy dread,
>                               |  For he on honey dew hath fed
>  http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

[hidden email] (David Simmons) wrote (abridged):
> > I would have expected this to be an area where a static type system
> > helps.
>
> Static typing only affects "timing" and "modus-operandi" for the
> checking/validation of security information.

Agreed; however, in practice static type systems (specifically Java's)
usually have support for notions like "private" built in. Both a concise
notation for expressing the policy, and support at VM level for enforcing
it.


> > This is hard to do in Smalltalk because an instance's initial state
> > is set sending it messages, and there is no built-in language
> > mechanism for preventing untrusted code from sending the
> > same messages.
>
> You're making a generalized statement (mostly true of course) that is
> actually a description of implementation not language issues.

I was talking about standard Smalltalk. As far as I know the ANSI
Smalltalk spec does not define a "private" keyword or anything similar.

I know most Smalltalks have a way of marking methods as "private", if
only with a comment, but it is usually just documentation. Eg Dolphin has
"private" as a kind of method category, but makes no attempt to restrict
senders of private messages.

Dolphin also provides mechanisms to reflect on the runtime stack, and I
expect this could be used to discover whether the sender of a message is
the same as the receiver. However, this stuff doesn't seem to be part of
the ANSI library and is presumably not portable.

Also, although we can use these facilities to implement a privacy
mechanism, the result would not be what I call would call "built-in". I
mention some other approaches in a Usenet article posted at the same time
as this one, and none of them are really transparent. For that we would
need to hack the compiler and/or VM.


> QKS Smalltalk provides infrastructure for dynamically changing
> the state of an object to be immutable or read-only, or marking
> all instances of a class as immutable. All such basic object
> properties are runtime enforced.

I gather QKS Smalltalk has a lot of extensions; multi-methods, mixins
etc. All worthwhile stuff, but much of it falls outside what I would
consider standard Smalltalk.


> The whole question of immutable semantics in Smalltalk was an issue
> I raised pretty heavily in 1993-1994 as being a problem. It was, as
> a result of my ANSI x3j20 involvement, also a moderately big point
> of discussion during the ANSI Smalltalk process -- at least to level
> of raising awareness of the issues among the participants.

Good. And thanks. I notice ANSI does not require any mutating methods for
Strings, and that kind of thing certainly helps.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."