[MAILER-DAEMON: Returned mail: Host unknown (Name server: clipper.ens.france: host not found)]
Raul Deluth Miller
rockwell@nova.umd.edu
Tue, 25 Oct 1994 16:02:45 -0400
Date: Tue, 25 Oct 1994 15:58:10 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON>
Return-Path: <MAILER-DAEMON>
Subject: Returned mail: Host unknown (Name server: clipper.ens.france: host not found)
To: rockwell
The original message was received at Tue, 25 Oct 1994 15:57:31 -0400
from rockwell@localhost
----- The following addresses had delivery problems -----
rideau@clipper.ens.france (unrecoverable error)
----- Transcript of session follows -----
501 rideau@clipper.ens.france... 550 Host unknown (Name server: clipper.ens.france: host not found)
----- Original message follows -----
Received: from rockwell@localhost by nova.umd.edu (8.6.8/16.2)
id PAA02586; Tue, 25 Oct 1994 15:57:31 -0400
Date: Tue, 25 Oct 1994 15:57:31 -0400
From: Raul Deluth Miller <rockwell>
Return-Path: <rockwell>
Message-Id: <199410251957.PAA02586@nova.umd.edu>
To: mprince@crl.com, PIOS actives <A.J.Thornton@durham.ac.uk>,
casas@cse.ogi.edu, luthers@bnr.ca, rideau@clipper.ens.france,
srini@aqualung.columbiasc.ncr.com
In-reply-to: <Pine.SUN.3.91.941025120508.20082A-100000@crl.crl.com> (message from Mike Prince on Tue, 25 Oct 1994 12:08:10 -0700 (PDT))
Subject: Re: PIOS Feedback and short term plans
I'm a bit puzzled by the line of discussion which I'm characterizing
with the following quote:
. FRANCOIS-RENE I'd say high-level OS. Do not define bitwise behavior
. like under Unix/C. Just define high-level protocols, and an
. abstract intermediate-level langua ge. Moreover, we'll still need
. machine-centric layers. Only you'll address them only if you really
. need to (i.e. play music on a host, and not another one ten miles
. away :)
What is "high level"? APL (which is, arguably, one of the highest
level languages in existence) has operations on bit arrays -- which is
exactly bitwise behavior. Perhaps the call, here, is to carefully
focus the semantics of operations to allow for reasonable optimization
when fitting into a new operating environment? [But, note that
such optimization is directly at odds with rapid porting.]
Also note that there are two kinds of operations that need to be
considered: computations (which are transformations of symbols within
some environment) and communications (which has to do with the linking
of environments). At the "lowest level" we're going to need a robust
set of primitives (whose existence and semantics can be relied on, in
some sense of the word) which will be our communication standard(s).
Above that we need layer(s) of abstraction to bridge the gap between
the machine and human developers and users.
Incidentally, a "Forth like" implementation model doesn't imply that
(for example) continuations are not available -- continuation can be
implemented with stack copying (and communications already involves a
lot of copying -- except for the case where the information is already
present). However, I think one good place to start would be to
identify the areas where current language or os standards fall down --
these are areas where we're going to have to work harder.
Finally, another related project: the Scheme Underground:
http://www.ai.mit.edu/projects/su/su.html
They've already got a bytecode interpreter up, which may be of
interest for PIOS.
Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q
<rockwell@nova.umd.edu> y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e<n
NB. public e, n, y
x -: n&|&(*&y)^:d 1 NB. 1=(d*e)+.p*&<:q