Hmm.. I'm confused :)
Felix has several different pointer types:
&T // pointer to a single object, never NULL
@T // pointer to a single object, may be NULL
+T // pointer to an array (incrementable), never NULL
So there's one missing and I needed it:
@+T // pointer to an array or NULL
I'm not sure that syntax flies : will it be confused with @ (+T) ?
I really don't want ANOTHER dang pointer syntax though, we've run
out of symbols :)
However there's an interesting alternative that might work:
@T = opt[T]
This would require a change:
@T ==> @&T
At present we have:
union cptr[T] = | nullptr | Ptr of &T;
typedef fun n"@" (T:TYPE) : TYPE => cptr[T];
and grammar:
//$ Felix pointer type and address of operator.
sthe_name := "&" sthe_name =># "`(ast_ref ,_sr ,_2)";
//$ C pointer type.
sthe_name := "@" sthe_name =># "(Prefix)";
//$ Prefix plus.
x[sprefixed_pri] := "+" x[spower_pri] =># "(Prefix)";
Unfortunately "prefixed plus" is a lower precedence than @ and & so
@+T
would be a syntax error but
@&T
would be ok. .. you'd need parens:
@(+T)
This is related to unary minus precedence: we want -a.b to mean -(a.b) for
example and not (-a).b whereas &a.b means (&a).b
Assuming the syntax can be worked out, this would mean the union for cptr
above would change to a typedef:
typedef cptr[T] = opt[&T]
and you'd use
None[&T]
instead of NULL or nullptr[T].
I think this may work, not sure (its confusing). Felix does an important HACK
here: if a type looks like this
union X[T] = N | S of L[T]
it uses a pointer to L[T] as the representation of S, and NULL pointer for N.
If a type uses
union Y[T] = U | P of &T
it uses a NULL pointer for U and the actual &T pointer for P.
These representations are NOT the same! In the first case
we use a pointer to the data in the S(ome) case. In the
second the P(ointer) case IS the data.
These special representations are vital to achieve a sane Felix
meaning for NULL pointers without any conversions.
The first representation is seen here
union list[T] = Empty | Cons of T * list[T]
and is vital: this makes an ordinary linked list
with a NULL pointer at the end. A slightly different
definition might get a uctor, or a pointer to a pointer
for the variant, which is inefficient and not really
so easy to work with in C.
however I think it will work anyhow because the representation
choice depends on whether the argument of the constructor number 2
is a pointer or not. So
opt[int]
will use a pointer to an int, but opt[ &int] will also use a pointer to an int
(NOT a pointer to a pointer to an int!!!!)
If this works you can do:
fun div (x:int, y;int) => @int
instead of
fun div (x:int, y:int) => opt[int]
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
