Re to Johan Van Schalkwyk

[Francois-Rene Rideau]

>From rideau Sat Oct 22 15:23:17 1994
Subject: Re: MOOSE Project -- new OS ?
To: jvs@iconz.co.nz (Johan Van Schalkwyk)
Date: Sat, 22 Oct 94 15:23:17 MET
In-Reply-To: <Pine.3.89.9410222339.A18757-0100000@iconz.co.nz>; from "Johan Van Schalkwyk" at Oct 23, 94 12:37 am
X-Mailer: ELM [version 2.3 PL11]

> 1. I have played around in several languages, but apart from assembler, 
> the only one that I have found to be more or less what I've been looking 
> for has been Lisp. It is however crippled by its parentheses (not just 
> "LISt Processing" but "Lots of Irritating Single Parentheses". Also, 
> parsing Polish notation from left to right is a real pain in the a***!
Yes, I like those languages; but I also like typing, because type errors
are a pain in the * to correct, whereas they are automatically findable.
See ML for a typed functional language (CAML-light on ftp.inria.fr is a
free imlementation that runs on macs, pcs and unices).

> 2. So I've played around with what I call "POWER" parsing (for POlish 
> With Evaluation in Reverse). Let me give you an example: In Lisp you 
> might write something along the lines of:-
Well, I mean no offense, but syntax is not what's the most important to me.
To me, semantics are quite more important, and user-level macros or parsers
should allow any type of syntax one likes.

> 3. This basically defines my top level. Obviously, there are a hell of a 
> lot of technicalities, etc. It is quite workable. I can control 
> practically every aspect of eg. a PC's function with about a hundred 
> verbs. Also, logical extensions to the language are easy and intuitive. 
> Let us say you have a verb AtX <number> that moves the cursor position on 
> screen to the position specified by <number> (leaving the Y position 
> unchanged). If you want to define a verb that finds the current X 
> position on screen, you _might_ define it as WhereX <number> (adding 
> another verb to your endlessly growing list), but I find it more mnemonic 
> to just have something like:
> 
> 		> AtX ? <number>
That's prolog-like definition of a name according to what is input or output.
I like it. But perhaps the BETA way of doing it (having an x subobject, where
any object setting calls an object-defined function) is better. I dunno.



> 4. Okay, that's quite enough about my crazy language - you probably think 
> that I'm totally nuts, by now. I just wanted to give you a flavour of 
> what I'm playing around with.
  If I thought so, I wouldn't answer (or perhaps something like "go to hell").
But I think you're overstressing the syntax. I myself lost several years
for the same reason. What Iearnt those last years when I could see the world
through internet and CS courses, is that semantics (i.e. the meaning, the
contained thing) is more important than syntax (i.e. the aspect, the
container); this I've always known, but it somehow became clear and obvious
to me. Of course, badly designed syntax won't allow easy
description of the semantics, but I'm sure that semantics should be designed
first, and that syntax should be designed and modified to conform to it.
  Please think about it. I'm talking from experience I'd like to share.
I lost much too much time thinking about the perfect natural-language like
or simple-constructor based syntax.


> 5. [...]
> I feel that one of 
> the reasons why languages such as C tend to be non-intuitive and ugly to 
> program in (my crazy opinion, anyway) is that the design does not stress 
> a minimal approach - they seem to never have heard of orthogonality. 
Quite so.

> Also, I really believe that whenever you program a computer to do 
> anything more than an absolutely trivial task, you are effectively 
> creating a language (even if it is just a very simple language where all 
> the instructions consist of pressing a few keys or clicking a mouse on a 
> menu).
I can't agree more. That's why it's stupid to have a new language for every
new thing: everyone would need a different language; it'd be the Babel tower.
What we need is a single language that can extend itself naturally, specialize
to any field of computing.

> So if you are working on a high level, you are effectively working 
> within a whole hierarchy of complex and badly designed languages, and 
> trying to create your own little "language" on top of this. The lower 
> levels are meant to be transparent, but this is almost never the case. 
> The more complex the setup, the more likely an intermittent and 
> irritating error is.

> The solution as I see it is to keep things 
> absolutely simple (a la RISC), and rigorously exclude any instructions/ 
> constructs that impair lucid interpretation on any level.
Yes, and no (according to the point of view).
Yes, basic constructors should be simple, so the semantics is easy to
understand.
But no, everything shouldn't be done directly from those simple construtors.
That would mean always doing low-level things.
Abstraction is needed. When a program works for any kind of structure with
such kind of access, why restrict it to a list-based implementation, or an
array-based one ? Every program must be defined in its most generic form,
and the user will specialize to the form that allows best performance.

Reuse *is* important. Today, reuse above language constructs is 0%, because
there is no secure form of genericity in commonly used languages.
A language like ML (see CAML-light again), allows genericity; but having
complete genericity in ML leads to verbose programs (which is why actual
genericity of existing ML programs is a compromise), because ML understands
no kind of implicit or partial information passing (which is called
Object-oriented techniques). I'm disgusted when I see that 99.9% at least
of code being written is just rewriting old stuff for use in a new program,
because no reuse thing exists.

*That's* why I'm writing a new CS (not Operating System, but Computing System).

But also note that for reuse to be possible, security is a must, thus
type checking and more than that, program specification. If you can't be
absolutely sure that some piece of code you got from someone you don't know
will work as you want , you won't ever use it, and you'll be right not to.
It was only by seeing the huge library of code available through internet
then had to write some code for work without being able to use any part of
these library, that I deeply interiorized this need for security.


> 6. So I see any programming attempt as part of a continuum. There may be 

That's exactly what I just said. We constantly need abstracting some part
of the code. There is no fixed limit of three or four or any finite number
of layers in abstraction (which is why ISO standards try to do with their
bullshit OSI layer model). Each program is well defined in its own proper
layer of abstraction; and layers are not in a total ordering, but a partial
one: if A needs B and C, D needs B and E, there's no reason to put A and D in
the same layer, or one above the other; they're just defined in different
non-disjoint contexts.


> [...]
> memory and / or output ports. Unfortunately, we often seem to be driven 
> by the hardware designers .. they define what is available, we construct 
> our program (on all levels) around this, rather than saying "WE WANT 
> THIS. THIS IS OUR STANDARD. WE WILL DEFINE OUR SOFTWARE AS SUCH AND SUCH. 
> IF YOU CANNOT PROVIDE THIS FOR NOW, WE WILL STILL DEFINE THE STANDARD AS 
> SUCH, AND WILL JUST HAVE TO MUCK AROUND (ON A SLIGHTLY LOWER LEVEL OF OUR 
> SOFTWARE HIERARCHY) TO SIMULATE WHAT WE REALLY WANT" !!
That's even worse than OSI: just one big level of abstraction, with an
arbitrary choice of functions.


> 7. The flipside of course is that one should know what one is dealing 
> with. If I ask for a number, I want to know _exactly_ how long it is, not 
> some arbitrary assurance from the programming language that it may be 
> such or it may be such, depending on the system on which we are running, 
> thank you for nothing! (If I go into a restaurant and order a steak, I 
> want to know if it is 250g or 500g)!
You too see that program specification is needed. I too have known it for
a long time, but now, I understand it and why it is needed (and not only a
toy). And timing specification can be as useful as effect specification,
as our computers will never ever execute programs instantaneously. But as
for the *exactly*, it is impossible. *enough* is quite enough.

> I have a lot of ideas in this 
> regard, specifically with respect to assembler design. Tentatively, I 
> think that there should be just three levels:
> 
> Level 0: lowest level. May need considerable effort / ingenuity to 
> implement concepts defined on Level 1. But ideally, should all be ultra-
> fast and implemented in hardware. All timing should be precisely defined, 
> and accessible to the next level.
Yes, but this level should also be implementation-dependent, and reserved
for use by those who *really* want it, in time-critical portions of their
programs (i.e. ultra-fast graphics or signal processing, OS code, compiler
back-end, etc). Normal users shouldn't *have to* use it. And a code
portion could have several equivalents in several different low-level contexts.

> Level 1: The "assembler" level. But cf my example above about drawing a 
> line! I have several ideas about what "ideals" should be implemented on 
> this level.
Assembler is still in the implementation-dependent part to me.
Note that I do not want to forbid low-level parts; just to allow not to use
them, and to provide portable equivalents (thus a time-critical routine may
have several versions to run optimally on different hardware, whereas a
non-time-critical routine will only have a slow high-level version).

> Level2: The "top" level. Perhaps something along the lines of the 
> incredibly simple language I gave you a flavour of above.
Your language is too low-level to me. Again, I love low-levelness (or I
wouldn't be writing an OS !), but only when it is needed. Sometimes (most
of the time, once the OS is written, if it really is well written), a high
level of abstraction is needed.

> You may well find the above ideas too trivial to comment on, or disagree 
> totally. Please feel free to be completely honest! If you want to hear 
> more, just say so! Perhaps you could give me a few ideas of your own?

I really need someone ready to dirty his hands with the low-level stuff in
my OS. Uhappily, whereas I have many ideas, I *know* that this stuff is the
non-essential part of the OS. By non-essential, I mean that if I am to convince
people helping me in my project and later using my OS, I must have a *working*
version, however slow, whereas low-levelness will bring me speed and
efficiency but nothing that would make my OS better than it would be if
running on a faster computer (that would be available for a higher price, or
just by waiting long enough). Thus, I deeply need help from someone who will
cope with the low-level details of the system. Will you be that man ?
I cannot promise any success, just tenacity.

> (I hope there are not too many typos in the above, as I composed it on 
> the fly).
None that I noticed.



You really recall me my previous self two years ago: full of good ideas, but
without an overview of the why it should be done in such perfectionistic
way, and enthousiast about small things when I didn't see the big thing yet.
Please do not see any offense in my words. I don't know if I'm older than you
(born 28 nov 1973), but I *think* (may be wrong !) I've made more errors than
you in the past, and thus have gained a little experience about how things
are and should be.

Read you soon !

(BTW, can you talk from your site to mine ? do you have IRC connection ?)