Tom Novelli | 24 Mar 18:56 2005

Reviving TUNES


   I've been working on my own little Forth-OS project for a while, not
really paying attention to Tunes.  I guess I didn't miss much... it barely
looks alive.  I'm getting into it again... I'd really like to see some of
these ideas put into practice, breath some life into it...

   Our holy grail is the Garbage Collected Distributed Persistent Object
Store... and we also want language translation, migration, abstract
interfaces, an optimizing compiler, automatic proof of correctness... 
Let's set all that aside for now and reach for something within our
grasp: "TUNES--", because that's better than nothing, better than unix
or windows.
   I wouldn't worry about translating C programs automatically... it's
probably easier to do it by hand, or better yet, start from scratch. 
Bad languages make for bad programs which could really use a redesign.

   The "official" plan is to use Forth as the LLL (we'll need a few I/O
drivers too) and Scheme as the HLL- (we'll want a simple memory manager
for that).  We can use Retro-Forth as the LLL and model our Scheme after
TinyScheme.  Retro also has an assembler.  We can do a lot with Forth and
Scheme; it could be a useful OS, as-is.  TUNES--.
   Then we'd get started on this Persistent Object Store (simple at first) 
and an automatic proofing program.  After that, eventually, I guess we'd
meet up with the real HLL - Slate or something like that.  Whoever does
the HLL will have plenty of time... it would be pointless to set a date
for any of this stuff because you KNOW we'll be late. :)  Just take it as
it comes.. 

   I don't intend to do all this; I intend to add networking and graphics
to Retro instead.  I just thought I might inspire someone else to take the
(Continue reading)

Tom Novelli | 24 Mar 18:57 2005

Re: Database Theory Links


Kyle Lahnakoski <kyle <at> arcavia.com> wrote:
>
> Massimo Dentico wrote:
> 
> > 
> > - ftp://ftp.netcom.com/pub/hb/hbaker/letters/CACM-RelationalDatabases.html
> > 
> > In my experience he is right. However, even OODBMS are not the ultimate
> > solution, at least in the current state.
> 
> I will agree that no all data can be effectively represented in a
> database.  I found the theory excellent starting point for defining,
> what I call, "set operations".  There are currently * basic DB operators
> (depending on who you talk to) select, filter, join, aggregation, union,
> intersection, difference, and cartesian product.  I am trying to write a
> document on a ninth DB operator: the "Self Join"; it will complete much
> of DB theory's shortcomings (but still not a holy grail).

Self Join... do you mean a simple way to nest subassemblies to an
arbitrary level, rather than an explicit join for each level?  That would
certainly help.

Still, the theory is fundamentally flawed.  It's based on index cards,
where items are referenced by some "key" (e.g., catalog number).  When the
US military started building computers, they just used them to automate
centuries-old logistics practices.  They accumulated piles of
punch-cards.  Relational database theory offered a way to keep that data
consistent... and 30 years later they adopted it.

(Continue reading)

Picon

Criticism ... synthesis?


This has three parts.

Part 1. A request.
-----------------

Can somebody _please_ forward me the communications from 14 - 16 
December,
as I was in transit from NZ to RSA and missed all, including 
responses to
my comm of 14 December (am).

Part 2. Response to Fare &c
---------------------------

>Hey, there. Please everyone tell what he thinks about it all, if he
>agrees with me (the no-kernel decentralized, but secure design), or
>Mike's (a monolithic hugeware centralized unsecure kernel, as I see 
it);
>or if you have other suggestions that show that we both are wrong, 
and
>how to correct our ideas so that they be right.

Mike has MY vote. I also think you're being _grossly_ unfair to him.

1. You use "monolithic" in criticism of an idea that is 
straightforward,
and instead postulate a more complex system!

2. "hugeware" ?
(Continue reading)

Picon

Re: Criticism ... synthesis? .. criticism..

Hi all!

>   I'm new to here 
(Welcome).

> 1. We want to define a set of data structures *in* the system.
>   
>   Yet, we all know that data structures *do* fix the HLL we use, 
[...]

Thanks for highlighting this. I really do not believe that it is 
possible to be all things to all people. My objective would be much 
more "limited" - i.e. to define an "OS" that is as powerful and 
general as I can make it, with a higher layer "language" that 
provides ease of use. My interest in the other 50 million programming 
languages would be secondary and subsidiary - although I do believe 
that smart programs written in a coherent HLL might be able to adapt 
great big chunks of eg C or PASCAL for their own use, for example!

> although I have nothing against Lisp, Forth, SmallTalk, Dylan, SML,
> Caml, Scheme, C, C++, C+ <at> , Pascal, Concurrent Pascal, Rascal, Mumps,
> APL, <insert your favorite one here>, I would strongly resent anyone
> trying to force me to use one of these.  I want the freedom to use the
> best language available for my task, and would strongly resent the OS
> I use to limit me.

The reason why _I_ve been forced down to a lower and lower level is 
simply that, although several languages (eg LISP) have very desirable 
features, and have indeed tickled my fancy, NONE has come up to 
scratch when it comes to getting down and doing some really serious 
(Continue reading)

Picon

LLL

Dear Mike (et al)

> > On Sat, 17 Dec 1994, Dr. J. Van Sckalkwyk (external) wrote:
                                      ^^ Yep. They screwed up the 
spelling of my surname. Not the first to do so. (van Schalkwyk)

> > > 2. DEFINE OUR LLL
> > >     a. symbolic registers, including "pointer registers"
> 
> Forth like, so we have
>     DataStack   (a typeless stack for data manipulation)
>     PathStack   (how to return from subroutine calls)
>     Code        (points to current METHOD)

I was thinking of having specific stacks etc as one level up, and the 
LLL merely being a pretty general method of describing and 
manipulating available resources. A sort of symbolic assembly 
language.

> > > >     b. necessary flags
> 
> None, stack holds info.

As above. From my minimalist point of view, I think it is an outrage 
to store information in a byte / word / dword when a bit will do, and 
is readily available to be used on all systems (are there systems 
without a carry flag)? This is different from having a wealth of 
conflicting and complicating standards, where one will do! Maybe I'm 
just being particularly biased this am!

(Continue reading)

Picon

Re: Criticism ... synthesis?

Dear Fare

> > Can somebody _please_ forward me the communications from 14 - 16 
>> [..]
> Err, the complete tunes archive is on the usual moose ftp site:
> frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/TUNES/mail*/tunes*
> If you can't ftp, I'll bounce all that to you...

Apologies. Just trying to avoid downloading a few hundred K file on 
my 2400 bps for the sake of a few K (my telephone bills are always 
horrendous). But I _can_ FTP.

> inline possible code to call other objects directly ? Why have some
> constant overhead however simple the communicating objects are ?

I want to achieve a balance between speed and generality. 
Optimization can follow. It is better to write slow (but not 
unnecessarily slow) code that works, and then speed it up, than to 
write blindingly fast bullshit.

> This would mean a limit to object grain below which having it systemwise
> it a loss; so that peoplee would be forced to build systems over ours to
> manage small objects, and have to build complex interfaces to allow
> combining their possibly small objects to system objects !!!

No.

>    That's the flaw of microkernel. You don't remove centralization by
> reducing the size of the kernel, but by eliminating the kernel.

(Continue reading)

Picon

CORE CODE!

PROPOSED CORE CODE FOR IMPLEMENTATION OF LLL

This letter has 3 parts:

1. Symbolic assembler (J) conventions

2. Core code, with explanation

3. Recapitulation.

I would have liked to have explored various conventions in more
detail prior to this, but the time seems right to "come clean" 
about my ideas!

1. Symbolic assembler conventions
=================================

a. Syntax
---------

All references are to DWORDs (32 bits)
All numbers are hexadecimal
Naming and operand conventions are 80X86 flavoured
 (for now, but no bias implied).

b. Registers, Stacks, memory
----------------------------

The core code assumes that the following exist:
2 General purpose registers AA, BB
(Continue reading)

Picon

"J"

Dear Raul

Thanks! (Pure ignorance on my part). Just out of interest, what is 
"J" and who owns it. Do they also own "j"?

Bye, JVS.

Picon

Juliusz, old chap!

Dear Juliusz

> hopes I completely mirific.  
{?}

> JVC's answer seemed to imply that he..
I am not a VCR (JVS)!

> agrees with me on everything, but arrives to completely different
> conclusions.  I have to say that I don't really understand his
> reasoning.
1. It is not possible to create a platform that will run everything,
always, faultlessly.
2. I do believe however that  it IS possible to create a "symbolic
assembly language" (convention) that can be used on most (all?) 
current machines. Good assembly language programmers only use a small 
proportion of the wide variety of instructions available on most 
current processors. You only _need_ a small selection of instructions 
to execute most tasks.
3. This symbolic assembly language can then be used to create HLL(s) 
that do useful work on all the machines, with a common "core". I do 
_not_ mean that you can now take code in any arbitrary language and 
exepct it to run faultlessly in "our" system.
4. The simpler we keep things, the more likely we are to succeed.
5. If you have formal proof that the above is bullshit, please submit 
it.
6. If however, you merely _believe_ that I am talking rubbish, and 
have nothing substantial to contribute, don't waste your time with 
this group!

(Continue reading)

Picon

Re: CORE CODE!

Dear Raul

> I'd be interested in knowing why you factor out "meaning," I couldn't
> get the concept of any of these memory regions from your post.

Probably sloppy language on my part. The basic idea is that if you 
have a "variable" (eg fred) it has an attached "value" or "meaning". 
The value is a 32 bit number that can be _any_ one of the primitive 
data types. All references to "fred" in our interpreted language are 
simply pointers to the location in memory that contains this 
value. The basic idea is something like this: (adopting an arbitrary 
syntax that will probably serve to confuse you even further - sorry)!

Set up value of "fred" by:

> Set fred' [This is the value of fred]'     <send message>

or perhaps

> Set fred' 12345 <send message>

or 

> Set fred' T <send message>

and then obtain the value of fred by:

> fred  <send message>

Where the interpreter encounters "fred" (actually the pointer to the 
(Continue reading)


Gmane