I picked up an old project this weekend and knocked it into orbit along with most of the common assumptions I had about implementing languages in java.
What i had 6 months ago was an artificial heap tool to create cursors in a tract of RAM that act as structs, and the means to generate pojo facades, or visitors, very effective for mmap'd stuff.
this weekend I added the concept of an execution environment to the heap metaprogramming. I'm also working out the generator [re]- generating the successive generators (a nod to The Diamond Age, Seed Technology :))
I created a mmap'd abstraction of heap, a small cache-friendly register page, and a int[] stack abstraction to provide a context mechanism.
I decided upon predicate-subject execution pairing in order to provide an execution environment directly within a graph-store of triples, thus a large mmap'd extent of triples can themselves be executing their representative functions upon graphs so designed as programs, where function vectors assign meanings to triple predicates.
the java binding of predicate->subject interaction to heap objects falls upon an invented vtable.
the vtable uses enum (Enum extends VTable, actually) elements as methods. vtable instances carry a 'traits' bitmap to facilitate 'state' transform 'views' of the byte-extents rather than java inherited type system. thus two objects with common traits or a path to common traits can 'view transform' their bytes of heap state to a LCD medium polymorphically. additionally, traits path resolution can be transferred among vtables at runtime as a growing cache of type impedance resolutions.
the vtable's functions, which are java's enum elements have symbolic names matching their predicates. matching as many predicates as possible in fact, in an execution order.
to illustrate the simplest component, here's a genuine metaprogram java enum creating 3 concrete struct storage slots of int heap, and what happens at time.
java syntax:
enum Triple implements VTable{
subject(4), //offset = 0; offset is a computed final value in the elements
predicate(4), //offset += 4
$as$Predicate(predicate), //copy ctor 'predicate' element, size and offset are copied not computed
object(4), //offset +=size==8 now, total final length of the bytes is 12 (8 offset +4 bytes data)
$as$Uri(0,0){[...]} //size=offset=0, pointer to triple, has methods but no writable extent.
;[...]
}
layout of heap bytes:
enum Triple{ 0__________b
subject 0__3
predicate| 4__7
|$as$Predicate 4__7
object 8__b
$as$Uri 0-- // as in just a pointer to the struct head
}
narrative:
$as$Predicate is an enum element that looks and acts like "predicate" element, but differs in a few ways by very cheap arrangement of the java source code.
1) the state of $as$Predicate as it pertains to its artificial heap struct is identical.
2) the name of $as$Predicate itself contains a predicate, "as", allowing one to 'infer' that there is a triple "as" or providing a 'predicate' on its behalf, where a trait would specify Triple needs Predicate traits
3) predicate and $as$Predicate java enum elements don't share methods, or names, but do share data.
$as$Uri -- one of several ways to provide an enum element with struct pointer offset information and methods
the java enum elements provide a type inference hint as to what they intend to do. they contain as many methods as required for the traits they start out with to make this happen, and it is hoped with as much type inference as can be achieved in java..
thus 'predicate' seems a little less constricting than choosing either the term "function" or "method".
the java method's names within the java enum elements are short, and incidentally, as a type inference and polymorphic experiment, the attempt is that the java$enum$element$Methods are all named '$', or '$$', and so on, exposing the outer most '$' externally, and to use local methods '$$' by type inference dispatch from within '$' execution, and so forth choosing '$$$' from there.. etc, via generics -- an experimental work in test to impose maximum type inference via javac and generics wildcard-capture.
Figure-A ; Literate programming using symbol declarations as Predicate Assertions
a simple syntax to seed VTable definitions and typedefs:
enum Graph{
$as$Set$$Vertice(Set),
$as$Set$$Edge(false),;
}
declarations representative of the semantic linkage produced at and successive code generations:
enum Vertice{
/** a java enum slot before code-regen, runtime bound
automatically in time as $as$Point(Point)
*/
$as$Point,
/**
the same effect, after reflecting the previous generation.
*/
$as$Triple($as$Value$Type.){{$as$Value$Type=Triple.class;}},;
}
enum Pair{
$as$first(4), //pointer ->
$as$second(false),; //
}
enum Edge{
$as$Pair$$Vertice(Pair),;
}
Triple t = (Triple) Triple.$(ByteBuffer heap, byte[] register, int[] stack)
//semantic typedef: (my) $ (slot within) as $ (my) Set $$ (Set having ) Vertice
as close to
public final static ((Vtable)MyType).java$enum$element$method.$(...)
as possible but no closer.
...unifying java method names is hoped to reduce the complexity of n*m Functor*Methods combinatorial at runtime, allowing the type specifications to be a hidden ugliness of java rather than a geometrically growing typecast typing practice exercise, or to toss out type introspective inference entirely by forcing method clients to call (Object)foo
and finally, by (manually) naming the function symbols as closely descriptive of their intent as possible, need all simple functions be retained or executed once so declared? this is a question for inference at a later juncture, but the hope is to produce a system of pure java compilation, and to aid in features which promote the greatest runtime entropy.
there is an additional component to outwardly expressive symbol names -- semantic inference.
I already produced a simple reflection based source code regenerator from the reflection artifacts of the objects at runtime. a package's enums are regenerated.
these enums, designed as stateless visitors prior to the vtable binding concepts, also semantically link to each other based on symbol names and predicate hints in the first edition. they do this linking both at time in java and at reflection/generation time in the tool, same outcome with slightly different implementations.
I have added $as$comment$String and $as$java$sourcecode$String attributes to generative elements, both enum classes and enum elements, so that reflection can access these as String field.get(), put them into the source code being generated, and something ASM and BCEL cannot accomplish, display source code and comments at runtime.
Using Annotations as a data fork on the reproductive elements of the source representation was considered, but as forks go, it makes more work for the reflection process of re-assembling source code, and increases dependancies.
I'm interested in some amount of syntactical facilitation of other predicate logic representations and grammars, not opposed to a runtime regex thunk in the background if needed, to align the manual and syntactically facilitated tricks that are generator-refined over time.
there is enough here to go forward writing a really, seriously twisted performance form of java triple store on shmem heap, aided as well by a second project of mine underway building a sparql query and caching relational mapper in c++. Sparql queries in a JVM context is probably not an important criterion, its more the bus throughput of working on the triples once they are in a common blob on disk (unified structurally to the c++ triple cache layout, and mmap'd).
