I'm in the middle of rewriting the pointer model.

At present we have:

        &T : pointer to object, fetch and store safely
        @T: pointer to object or NULL, run time check before fetch/store

and am adding (perhaps incorrectly):

        +T: incrementable version of &T, can't be NULL

+T is just the old carray[T]. Increment is unsafe.

Note varray[T] which is a GC managed store, with safe
index access (run time check on fetch and store, length
tracked by GC).

Unfortunately this model lacks: incrementble or NULL.
This is probably common: a C function

        func(T *p)

where p is either NULL or points to an array (most often
a buffer, or char array)

The model also lacks NTBS (null terminated byte string),
which has a definite run time determinate length.

If we look at core pointer properties:

        fetch
        store
        increment
        null-equal

we note that its safe to drop any operation except null-equal which
can be safely added. Dropping "store" gives you a const pointer.
We can refine "increment" which above means "random access"
to "input iterator, output iterator, forward iterator, bidirectional
iterators, random-iterator".

A stream is an example where we have a input iterator (for the
consumer, or an output iterator for the producer).

We're just running out of symbols for all the types.

I'm looking to solve this by generalising the pointer model.
It's nice that with the user programmable grammar and libraries
we can probably build a nice type model entirely in Felix
(without needing much support in the compiler .. if any!)

The "bottom line" with the pointer modelling is roughly that
we have some type ptr[T] with a set of methods (deref,
store, increment, etc). Another type of pointer is the
same representation but just has "less methods".
You can safely cast from the first to second type
(losing some methods can't hurt!)


I'm looking for a way to build this model. One interesting idea is
to use a class with virtual functions and all the methods,
but then instantiate it for some pointer types with less methods.
The downside is that improper use will not generate a type error,
instead you will get an instantiation error.

One trick I'm looking at leveraging is this: 

typedef pointer_properties  = (fetchable:void, stoarable:void, 
incrementable:void);

Of couse such a type cannot have any values, but the idea is to use it as a
phantom type. The nice thing about this is that every record type coercion
represents a safe conversion (since record coercions "drop" fields).

Our situation gets even more complex with managed an unmanaged objects.

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to