highlevel vs lowlevel

[Thomas M. Farrelly]

Over and over again the difference between lowlevel and highlevel is
taken as a method of solving problems. Frequently, when something is
difficult to conceptualize as expressed in a highlevel language, you are
compelled to use the words "highlevel" and "lowlevel". The usual
examples of such things are primitives ( like booleans, ints, functions,
if-statements ), device drivers ( like keyboard, console, audio, video,
disks ) and hardware ( like memory, mmu, cpu-modes ).

This leads to a situation where we only discuss lowlevel matters -
because that is where the problems lie. Therefor the frequent need to
emphasize over and over that _this_is_lowlevel_stuff_, it is all done
_behind_the_scenes_ so that the user doesn't have to worry about them.
But as we have all have experienced in the current software situation:
the user will eventually, and quite often, have to worry about lowlevel
things - because they are there and they ultimatly govern the entire
workings his/her computer. Among the reasons for these worries are nasty
optimizations in compilers and nasty opimizations done by programmers.
Lowlevel stuff sure is some nasty shit :)'

And then it hits me: what is the difference between lowlevel and
highlevel?

If I have a TV-set which can recognize my voice and I say to it "TV,
channel 3" or "TV, mute", and the TV acts accordingly, then I guess it
could be considered a highlevel interface. Still it could be better ( or
higher level ?) if I could say "TV, MTV" or even "TV, change to MTV and
turn up the volume a bit" or "TV, change to MTV, and mute all
commercials".

If the interface to the TV was text based, I don't see how that would
make it less highlevel.

There seems to be a common understanding that integers are likely to be
part the lower levels of a system. At least the implementation or
definition of how something can interact with an integer. But I don't
see how "5 + 3" is any lower level then what I said to the TV - it's
just that that was a TV and this is an integer, and "add five and three"
is just something you can say about integers, becuase they are integers.

Lowlevel/highlevel has nothing to do with reahing human-to-human like
interaction with a machine.

Further, I don't consider a convention that forces you to say "+ 5 3" or
"5 3 +" makes anything any more lowlevel. After all even "5 + 3" is just
a more common convention. But this is intuitive? No! You're just more
comftable using it because that's the way you've always written it and
always seen it written. "|/-|\" would work just as well.

Lowlevel/highlevel has nothing to do with "intuitive" or conventions.

Lowlevel/highlevel is not related the consept which we want to describe
- a concept is not highlevel or lowlevel.

Lowlevel/highlevel _is_ related to _how_ the consept is described. If
something is written/coded/implemented/defined in machinecode or
assembler, we consider it to be lowlevel, because we consider assembler
as a lowlevel language. If something is defined in a highlevel language,
like lisp or smalltalk, we consider it to be highlevel. But ultimatly,
for the computer to "understand" it, it has to be in a lowlevel form -
so we need compilers or interpreters in order to communicate with a
computer in a highlevel language.

Then, if the lowlevel/highlevel is not related to concepts, it should be
possible to pick one of the example "lowlevel" concepts above and
describe them in a highlevel fashion.

The lucky concept is ... [ shaking the hat thouroully, and digging deep
into the realm of wannabe lowlevel concepts ] ... 'memory'.

	memory:
		unit: byte
		size: unspecified
		 
		image: list of size units

And there it is, a highlevel definition of a very "lowlevel" concept.
Surely there is stuff like alignment and byteorder that is not
considered here, but I don't see that these pose any particular
problems.

But wouldn't it be utterly inefficient to use a highlevel definition of
'memory' - wouldn't it cause alot of overhead in the system? No, it's
dependent only on the definition of 'list'. If you have a efficient
implementation of list, with optimal memory usage ( storing only the
actual elements ), and corespondingly optimal access function ( inlined
direct access to elements ) then there is no problem in using this
definition. And many languages has list implementations with such
efficiency ( particularly C ). What about security? If you want boundary
checking, you will have to pay for it - you allways do. There could be
some compiletime analysis thingie which could "factor out" some of these
boundary checkings though. Anyways, the other security issues should be
covered by typing.

To conclude this session of babbling, I give a defintion of 'lowlevel'
and 'highlevel'. It seem less related to what I've been babbling about
than I would like, but please comment anyway.

Lowlevel:

Something is lowlevel if its existence in a system leaves out
information of its actual semantics.

This basically means that if the structure of something is not
explisitly stated in relation to its object then it is lowlevel. A
lowlevel defintion of 'memory' could be

	memory:
		image: list of some somethings

That is, 'memory' is a list, but we cannot reflect on what kind of
elements are in the list and how many. We could consult a manual, but
the manual is not in relation to the actual memory objects existence.


Highlevel:

Something is highlevel if its existence in a system totally describes
its actual semantics.


This definition of highlevel is more a defintion of 'toplevel'. Finally
lets define the level of a language:

The more a language lets you explisitly describe, the higher level a
language is.

"explisitly described" could be exchanged with "described in a way that
can be reflected upon in the same language". The oposite "implisitly
described" are all the static dependencies that you progam uphold
internally but the not-so-highlevel-language don't bother with. For
example the somewhat arbitrary state of 'max-keyword-length' you define
as a constant at the top of your compiler source, and you constantly
have to remember to boundary check against when traversing keywords. The
more highlevel approach to this would be to be able to explisitly define
the concept 'keyword' and be able to express what rules govern the
semantics of 'a keyword' so that the compiler can do the boundary
checking for you.



sjohoo!

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