One of the hard things I have had to do in Felix compiler is deal
with some "glossing over conveniences" which are probably not
a good idea. It make the compiler complex and makes some things
ambiguous at the expense of simplicity and cleanliness, in the name
of some brevity.
In particular, a tuple of one component is identified with the component,
an array is just a tuple, but the type is lost for 0 length arrays.
I am thinking to throw this out. Instead, arrays and tuples will
be distinct, there will be a tuple of one object, there will be
arrays of 1 and 0 components and the 0 component array
will retain its type.
This means you will have to write the converters in your code.
It means a function taking an array will only work with arrays,
not accidentally think a non array is a 1 element array.
In terms of representation at the C level it's a real pain,
I have to cast between arrays (actual C arrays wrapped in a struct)
and tuples, because you cannot initialise an array in C or C++89
with an expression.
The conversions are isomorphisms with zero run time cost.
So you would have using an old notation:
var a0 = array[T,0](); // zero length
var a1 = array[int,1] 43;
var a1 = [< 42 >];
var a2 = [< 1,2 >];
The [< .. >] construction makes an array with the number of elements
being 1 less than the number of commas. So
var x = 1,2;
var one = [< x >];
has ONE element, not two. It's syntax NOT an operator. TO get two elements:
var two = array[int, 2] x;
uses a constructor which specifically says there are 2 elements.
It would be the same for tuples: tuple of 1 element distinct from the element.
This is in line with lists, which can have 0, 1 or more elements.
The problem at the moment is that code that handles tuples and
other code that handle arrays converge with ambiguity when you
get down to 1 or zero elements, and worse, tuples of 3 ints
are the same as an array of int length 3, so care is needed overloading
to make sure the array handling variant always takes preference
over the tuple one (since tuples are more general).
Making the type distinct will allow recursive polymorphic functions
for each data type without interference since the types simply won't
overlap.
Similarly, compact linear types will be distinct. At the moment
a trick is used to get a compact linear encoding, but it fails
badly if you get a noncompact type and extract a part of it
which happens to be compact linear.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
