Highlevel + Lowlevel

[Thomas M. Farrelly]

Yuriy Guskov wrote:
> 

[ human actions ]

> Resuming it, and returning to programming (or ) we could divide it to as follows:
> 1. Executing.
> 2. Interpreting.
> 3. Programming.
> 4. Designing.
> 
> Appropriately we have four kinds of code:
> 1. Binary.
> 2. Symbolic.
> 3. Abstract.
> 4. Natural.
> 
> The point is we should integrate them all or, at least, keeping in mind.

Yepp.

Lets use other words than "highlevel" and "lowlevel". Lets instead use
"general" and "specific". Their not pairwise synonyms but I think they
project the idea of level quite nicely - it's a different way of looking
at things.

This way, the translation of a highlevel expression to a lowlevel
expression can be seen as a specialization. Initially you tell the
computer what to do, then the computer specializes this, from beeing an
expression about what the user would like to do, to an expression which
achieves it in the current context. The resulting specialization would
typically be a chunk of machinecode with static dependencies on the
context.

The whole idea of creating static dependencies is as follows: the
general expression in itself is useless to the computer - it has to be
in a context which defines the meaning of the expression. Since the
general ( not dependent on context ) expression now _is_ in a context,
the computer can start figuring out what it means. This is done by
translating it to an expression of "lower level". The lower level
expression is more specific ( to context ) and thus has static depencies
on context - it cannot be moved about as freely as the initial
expression. The reason for this is the static dependencies, which in
practice would constitute of "inlined" code and data, where the data is
typically pointers to things in the context such as stdout, screen,
libraries, ...


Seen from this angle, it's possible to outline actsactly _how_ we
integrate or keep in mind the fact that we would like the whole range of
levels available:

	Let the user/programmer specify as much as needed when programming.

If I say

	say "hello"

then that is a very general expression. When this is translated to a
more specific expression, it uses the default way to say what it says,
for example stdout.

	say "hello" to user "some-user"

is more specific.

	say "hello" to process $4430-3040 in 7bit compressed ascii

is still more specific.


So the keyword is "default". If the user doesn't care, he/she doesn't
bother, and use the default. If no useful defaults can be set ( which is
seldome the case ) then they are required parameters.

Also, often during development, you are forced to deal with partially
implemented objects ( or functions ). In the terminology above such an
object would just constitute an expression which is not fully specified.
If required things are missing then the translation to a specific
expression is not possible.

If you haven't told it what to do - don't expect it to do it. 




> Now there are a lot languages for each layer separately. But we must work in
> direction of some integration of all layers.

i.e removing the destinction. Or rather removing the global destinction
between levels, and making it part of the local
what-does-the-computer-understand-by-this ( interpretation ) mechanism.

I could ( very possibly ) be wrong, but wouldn't that make a tower
architecture - like the reflective tower thing in Maude ?




I'll have a go at the list of different actions. I think four is too
many, and I think I would want "analysis" to be one of them, mabe
instead if "interpretation". I know oo people ( Booch for example ) like
them to be:

	1. Analysis
	2. Design
	3. Implementation

where analysis would be the considering of the situation, desing would
be the constructing of the general expression ( the word abstract is
better than general in this context ), and implementation would be the
degenerating of the abstract expression to a specific expression. In
human terms, implementation is the "doing" or "acting".

But all these three can in turn be seen as a specification, so I dare to
claim

	1. specification

In human terms it gets a bit awkward.





===============================================================================
    Thomas M.  Farrelly     s720@ii.uib.no     www.lstud.ii.uib.no/~s720
===============================================================================