HLL,LLL+ far11

[Francois-Rene Rideau]

Hello, dear friends
 Here are hints about what Objects should do under MOOSE, according to me:
O's should be able to do anything a past, present or future language will
be able to ask it, so that the OOing Kernel should be complete and 
extensible. These ideas are not well ordered by now, but  I hope there'll be
no understanding problem. These requirement include HLL,LLL and Kernel
requirements mixed together. I think the Kenel should manage anything the HLL
may do (even a type's syntax should be available as one of the type's method)
but you may think otherwise; tell me why; I think it must, because of
object portability; if OOing is available at low-level, the LLL standard
would be stronger, and IOC easier.
- Next to the running Kernel, there will be a OO managing unit able not
only to us, but create, verify, Objets and do non-trivial things on them;
it should also manage "virtual" objects and not only physical ones.
- O's should be generic: you can have type as parameter and/or results,
and have other types/parameters depending on a parameter type.
- the type of the object need not precede the object in physical memory;
however, with an object,s ID should come everything about the object,
including the type, etc. physical length of an object is a function
available for all O's (possibly varying with time), and usable since HLL.
a raw list of objects each preceded by its full type&info should be a valid
HLL type.
- objects (inclding types) need not be fully calculated/expanded: the
object "f(1)" where f is an integer function over integers, may be a valid
(virtual) integer.
- the language should know of imlicit variables: if a proc. uses a global,
static or eternal variable, this variabe will be known as an implicit
variable of the proc; you can also have default valued variables, variables
whose value depends on the other, .. Many syntaxes may describe the same
O., so that types should include more than just content info:
OBJECTS (including types) CAN HAVE "COMMENTS"; comments include object
read/write info, object equivalencies (other equivalent objects - useful
for portability: the system will choose which equivalent object best fits
the hardware), constraints on object, etc. Of course, comments need not be
present in physical memory togethe with the object; only a (virtual) pointer
to them need.
- more generally, you can specify logical constraints upon your variables:
you can force x=2y+1, for example where x and y are variables, or type(x)=y,
etc. You can label constraints and/or give them parameters so as to specify
when they apply or not. The Kernel should be able to maintain the lists
of constraints and generate constraints.
- (physical/virtual) subtypes may be accepted: for example a number from 2 to 7
is a subtype of integers; a C source is a subtype of ASCII texts, which may
automatically be a subtype of Unicode texts, as ASCII is a (virtual) subset of
Unicode; real numbers form a virtual subtype of complex numbers (even if in
the impl' complex number are built fro real numbers), etc.
- names are accepted at LL, though not the only way to access an object,
for obvious speed reasons.
- automatic lowest cost type cast should be achieved in the OO : each
function has a "cost" which may be asked by the Kernel (standard method);
when a program wants to cast an object to a type, the Kernel should be able
to find the shortest paht (if exists) between current and wanted type of the
O. It will suppose that all diffrent casts constructible with the casting list
given are equivqlent. The casting list may depend on the context.
- automatic casting from physical impl' to virtual us should be compatible
with multi* data integrity and security => there are sharing mecanisms.
Functions on sequences (=files) may tell which part of the input file musn't
be modified by another, and which part of the output file is valid at the time.
The most secure thing when we don't know is to make a function work with a
(virtual) local copy of the current value of the object given. In a garbage
colleting environment, this is no problem.
- Security: a host will know if it has compiled a program from HL or LL,
or if it had directly machine code. It will ask confirmation before
executing programs it's known from too low level only. user can give
glbal or conditionnal confirmatin (i.e* always ok/ ok for now but ask later/
maintain a list of parameters it was ok with/ in the most general case, ok
according to some function of the (explicit and implicit=the dictionnary)
parameters , etc)

 Well, please tell your mind about all that, say what pleases you, what you
dislike; flame at me if you would. Whatever, do it as soon as possible:
the soonest we agree on HL specs, the sooner we can define precisely LL
specs and begin to work. I hope this will be before the end of the month.
 
			   ,
			Fare, 200% time mooser, who should ne studying
						differential geometry !