[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [e-lang] Data-E: Removing fixed literal type set
From:       Kevin Reid <kpreid () mac ! com>
Date:       2009-06-03 5:03:07
Message-ID: 2985E6F3-3771-4D17-A3DA-18CFA7E02E53 () mac ! com
[Download RAW message or body]

Data-E currently defines a fixed set of literal types: String,  
Integer, Float64, Character. This is less flexible than it could be.

Uses for generalizing the definition of literals:

   * I am borrowing Data-E for use on the JavaScript platform, where  
there are no native integers or characters; it would be convenient not  
to have to define handling for these types, yet not deviate from the  
Data-E 'standard'.

   * It would be nice for serialization formats such as deBytecodeKit  
to be able to define compact representations for e.g. byte arrays.

   * If we introduce more literal types to E in the future due to some  
change in What a Programming Language Ought To Have, it won't be a  
protocol change.

   * An intra-address-space comm system using Data-E for proxy  
handling would like to share between vats any object which is Data  
(deeply immutable and authorityless) and thread-safe.

                                ---      ---

I have proposed and MarkM has approved and refined this plan:

The buildLiteral/1 message to Data-E builders is renamed buildAtom/1.

A Data-E builder specifies the kinds of objects it will accept as  
atoms, by a guard which can be retrieved from it. (We need to choose  
the verb for this.)

This does not introduce a large compatibility problem (from  
differences in what is considered an atom) because: In most builder/ 
recognizer compositions, either the recognizer or the builder is  
deSubgraphKit. Since the subgraph builder deals in real objects, it  
can accept anything as an atom (and just return it). Since the  
subgraph recognizer deals in real objects, if the builder's atom guard  
rejects an object, the recognizer can proceed by using the uncall  
mechanism instead.

deSubgraphKit's recognizer only invokes the builder's buildAtom if the  
object under consideration is Data (i.e. authorityless), and  
deSubgraphKit's builder only accepts Data as atoms. This ensures that  
Data-E does not carry authority other than that explicitly described  
by uses of the defined exits.

                                ---      ---

I said this in discussion and MarkM wanted me to save it:

"There are objects you agree exist, there are objects you write down,  
and there are objects you take apart."

(Those being exits, atoms/literals, and calls, respectively.)

(Hm, analogy with mathematical notation: a number can be written as a  
well-known name like π and i, as digit data like 1.324, or as a  
formula like sqrt(2)/2.)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]