Challenge my assumptions!

Thomas M. Farrelly
Mon, 05 Jul 1999 22:19:08 +0200

Jim Little wrote:
> Tunesters,
> I'm in the middle of a big research push for Prism.  A lot of groundwork
> is being laid for critical issues such as language interoperability.
> Before I get too far, I'd like you to challenge my fundamental Prism
> assumptions.  It will soon be too late to change them easily.
> Here they are:
> 1) The basic Prism data types (_Bit, _Stream, _Map) are SUFFICIENT to
> represent any concept, particularly programs.

In order to comment on this, one needs to know what ways can _Bit,
_Stream and _Map can be manipulated. Data in itself without any ways to
interpret it is effectively useless. Like Billy says, programs = data +

So lets say you had the following operations:

	APPEND some-bit TO some-stream

to build a stream. You'll need a NEW-BIT and a NEW-EMPTY-STREAM as well.

	APPEND some-stream AND some-other-stream TO some-map

to build maps from an empty map. The operation adds the rule: map
occurences of some-stream to some-other-stream - like macro expansion.
Guess that's what a _Map is.

	TRANSFORM some-stream USING some-map

lets you apply some mapping to some stream. I.e. given the stream
'ABCABC' and the mapping ( ( A -> a ) , ( B -> b ) and ( C -> c ) ) you
get the result 'abcabc'.

Just an example.

But it will get you nowhere, since the point of doing stuff to these
three primitives is _not_ to be doing stuff to these primitives at all -
but to build something - particularly "anything". Or as you put it
"represent any concept".

Lets assume that you mean: will all formally definable concepts be
representable by some collection of operations on the three basic Prism
data types?

We all know, or believe we know, that the answere to this is true.
Dependent on the choice of operations available, of cource - but that's
easy: overkill is the way to go ;? .

Anyway, by grouping Prism things together, you want to create arbitrary
things. So, you need some way to group operations together. Like in
BASIC where the grouping is a 'program' and the relation among things in
a group is 'order of evaluation'. But it turns out that that model is
too much simplified, so even though lots of things are possible in BASIC
( its one of those turing equivalent languages ) there are some things
that you just cannot do. One obvious thing is parrallell execution. You
may argue that such and such a BASIC can has interrupt handling and so,
but that's beside the point. I cannot create a program that uses
parallell execution in lines 1000-2000 just by implementing parallell
execution in lines 500-900. Eighter one is possible, but their not
groupable - unless reflection applied, but then other difficulties

There are other aspects of grouping things. One is dependecies. Like
what does one group of things need to know about the internal structure
of another group of things in order to evaluate predictably.

So programming isn't just about the potential to achive something
arbitrary, but the possibility to take the achived something and group
the things that describes it into something useful - like a term,
abstraction, procedure, function, terminology, class, library, macro,
ontology, toolbox, menu, window, button, protocol or whatever suitable
to that particular something you want to achive. "reusability" is
dependent on this and in turn, so is "progress".

> 2) The basic Prism data types lend themselves to INTUITIVE metamodels
> for representing specific types of concepts, especially programs.  I.e.,
> it's EASY to create Prism metamodels (or, at least, they introduce
> minimal added difficulty).
> 3) There is NO LIMIT on the range of metamodels that a person may
> create.  Metamodels may be created for any human concept.  (This one
> seems obvious to me, since metamodels are defined with natural language,
> but hey! that's why it's an assumption...)
> Fare, you once criticized my choice of _Bit, _Stream, and _Map for the
> Prism meta-metamodel.  That's what I'm asking about now.  Does the
> meta-metamodel meet my goals?  (If my assumptions are correct, it
> does.)  Should I replace it with something else?  (If so, please explain
> how the alternative also meets my goals, and how it is better.)
> Everyone else, please chime in!

Dependent on your goals. Personally, I think relflection is a point, and
I don't see how that is provided in your model.

Something better? Well if TUNES is implementable on a computer, it
surely is implementable in DOS, but that doesn't imply that DOS is
TUNES. Mabe that was what A. Turing was trying to say?

    Thomas M.  Farrelly