On 13/02/2015, at 3:40 PM, srean wrote:
> In that case let it be. enough of syntax bikeshedding :)
I do not have a good solution for low level loops at the moment.
I do think I have one for compact linear types though.
The problem with compact linear types at the moment is this:
Felix has a *principle* which says mutators require a pointer.
So
var x ...
&x <- v; // assignment
One reason for this is that it gets rid of lvalues as a concept.
More properly, it lays out very clear picture of the relationship
between values and objects, at least for product types.
Given a product object P with projection function j, then
val P = ..
j P = P.j
extracts the p component of a value and
var P = ...
(&P) . j
is a *pointer* to that component (allowing it to be mutated).
Note that for a variable P is "really" a pointer. The name of the
variable is actually &P, that is, & is NOT an operator. It's just
a part of the variable name, so there's no issue of applying
it to an expression. If you like the variable is an lvalue, but
no other expression is an lvalue.
Instead, projections are overloaded, there are two projections
named j
j: T -> U
j: &T -> &U
I hope you see this is quite a beautiful picture.
But compact linear types ruin it! There are certainly
value projections for type
3 * 2
considered as compact linear, but pointers to these
do not exist. We could have them we need a triple of
to make one:
address, divisor, modulo
If the type has size only limited by address space.
the divisor and modulo would need to be 67 bits each
on a 64 bit machine (although that's unrealistically large).
In any case such pointers aren't 64 bits like an ordinary
address.
The problem is, a pointer to 3:
&3
might be an ordinary address is embedded in a non-compact linear type:
int * 3 * string
but that information is not available just from the type
&3
It's nonsense. The only way to make it work would be for ALL
addresses to be triples. It's too expensive.
The solution is that we cannot use
* +
for compact linear type formation. We must use instead:
\otimes, \oplus
These form compact linear product and sums from compact linear types,
and cannot be applied to non-compact linear types. So for example we
can have
int * 3 * 6 * string
int * 3 \otimes 6 * string
The first product has 4 addressable components, the second one
only has 3. Value projections exist for compact linear type component
but either there are no address projections, or, we have a different
type of address such as
\oampersand // no such TeX operator but hope you get intent
With this idea, the compiler code for compact linear types is
much simpler because we don't have to pattern match to
find the boundaries etc. It's also sound. The current method
really isn't sound.
The main issue is that \otimes, \oplus are not combinators.
Their arguments must be compact linear.
There IS a way to handle this and retain parametricity.
Normally an operator is a function from
TYPE -> TYPE // or
TYPE * TYPE -> TYPE
All we need to fix it is a new meta-type:
CLTYPE
for compact linear types. It's a different category.
This means a type variable has to have kind annotation:
fun f[T:TYPE, CLT: CLTYPE] (x:T, y:CLT) => ....
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
