apblack
commented
6 years ago I think that @kjx is making this more complicated that it needs to be.
We can make classes number and string intrinsic, and the meaning of a number and a string literal be given by methods in the current dialect. In the common case, these dialect methods would just re-export the the intrinsic number and string classes; the compiler would notice this, and avoid any additional overhead. (Recall that the code of the dialect is known at compile time.)
How the intrinsics are defined is not part of the language spec. What the intrinsics do is part of the spec, but their implementation should be left to the language implementor. The implementation of the intrinsics will obviously differ from one implementation to another. In minigrace I've implemented the native (language) code (implementation) method, which is essentially like asm in C. When writing the implementation string, one needs to know all of the compiler's implementation secrets. I don't think that this is bad, provided that we use this sort of non-portable code only in a limited number of places.
I really don't like appealing to ADTs (aren't objects good enough?), nor understand why doing so is any better than writing the intrinsic module using objects directly. Something like:
class number(literalString) -> Number {
def value is public = numberfromString(literalString)
method +(other : Number) -> Number { other.reversePlusIntrinsicNumber(self) }
method reversePlusIntrinsicNumber(other) {
// here we know that self and other are both intrinsicNumbers
native "st" code ‹^ (other + self) asGraceNumber›
}
...
}In fact, I don't see how the "ADT model" allows for bigNums or the Integer/Rational/Float hierarchy that we have talked about in the past. It seems to limit Grace to providing whatever cookies implement. Maybe I don't understand what it is really doing?
kjx
The spec defines things like Number, String, etc but doesn't say how they come from or how you can extend their code, etc. In particular, the spec leaves open the question as to whether you can inherit from primitive types.
What are some design options:
I like the NS model, but talking to @apblack, realised it is asymmetric - it moves the magic behaviour out of the NS objects, but leaves the magic 'data' there. This certainly suits e.g. tagged VMs where integers or floats are represented by some subset of bitpatterns that are invalid as pointers.
The cleanest model I can think of is to go the 'full William Cook'. The VM provides an (interlinked) set of ADTs - not objects. Individual instances of these ADTs offer no Grace methods, not even equality. To Grace code, they are opaque 'magic cookies' that can be stored in Grace object fields, passed as arguments etc. Perhaps there are branded types that can distinguish the ADTs to which they belong but nothing more. Behaviour for these ADTs is provided by a vm object (perhaps a set of singleton VM objects one per ADT) that have methods that take and return those magic cookies. Then all the Grace-level behaviour for primitives is written as vanilla Grace code that manipulates the magic cookies. There's no question e.g. about inheriting from magic cookies; you just can't. In this design, the integer class would be 100% Grace and would look like this:
This gives a clear interface to the VM ADTs, a cleaner data model (objects are either all primitive, or all Grace, but nothing in between), and separates out the language specification (interface of Grace Integer or Number classes) and the VM interface of the
vmIntegerADTmodule object.You'd probably want to do stuff with branded types, both on GraceInteger and VmIntegers. The
cookiedef could be handled specially in most VMs (perhaps the branded type is enough; perhaps you'd need an annotation too).I fear there is a subtle problem that - because the cookie must be purely exposed to Grace code - it may offer a route to an encapsulation breach if e.g. Grace code can even just do type tests - I guess that problem can be addressed by putting the brands and types into the vmModule too - so you really can only manipulate them if somehow you can get to code in those VM modules. In a typically Grace system, only the module implementing the Grace-level number class would import that module.
In terms of e.g. adding ownership or provenance or taint to Grace numbers or other primitives, this design resolves it nicely: those features could all be done in Grace code and the interface to the underlying primitives wouldn't need to be modified. I fear you'd need brands (or ownership) at the Grace level to make everything secure though (because the core interface for non-receiver method arguments is just
type { cookie -> VmInteger }which will admit a multitude of sins.Thinking for a minute about implementation though, this model need not necessarily be slower or more memory intensive than one based on primitive parts and inheritance. This is because in
non-boxedVMs, e.g. running Grace on top of JavaScript, or Java/Truffle/Graal - there's no way to inherit from primitives: you'll have to have a implementation field in the representation of the Grace object that holds the JS or Java VM integer (or string or whatever) anyway. Given branded types, the cookie field could be implemented as precisely a primitive field. Reading or writing that field would have to box and or unbox the primitives to make the Grace opaque cookies, but everything at that level would be functional, and if you can just inline the ADT code into the Grace code, the overhead should go away.