On 26/02/2011, at 6:05 AM, Erick Tryzelaar wrote:

> On Fri, Feb 25, 2011 at 10:18 AM, john skaller
> <skal...@users.sourceforge.net> wrote:
>> 
>> Hmmm.. any thoughts?
> 
> I'm all for simplification of the innards of felix, so reducing
> tuples, structs, and records down to the same thing sounds great to
> me. Even better if we get rid of lvalues :) Now, on to the details:
> 
>> product sname { f1name: f1type; ... }
> 
> Is the "sname" is there so that we can say whether or not the product
> type is nominally or structurally typed?

Yes, precisely. In fact, tuples/records are nominally typed, its just that
the use the canonical name "". Err .. actually structs are structurally typed
its just that they have a tag "sname" ... er .. well now there's no difference
between structurally typed and nominally typed.

Note: the syntax above is only a for the purposes of explaining
the underlying Ocaml constructor.

> 
>> struct X { a:int; long; b:int; }
>> 
>> The padding long has a name: 1.
> 
> I'm not fond of this. I think either all field names must be provided,
> or none are, or else it'd get confusing.

Yes, but the downside is that padding fields require names.
Also, consider functions "a la Python" where you have some positional
and some keyword arguments.

But actually I tend to agree: there's a difference between what Felix compiler
handles, and what concrete syntax we allow.

> Most people expect that
> adding a field to a structure shouldn't cause code to break beyond the
> construction, but changing the structure to this:
> 
> struct X { a:int; d:long; long; b:int; }
> 
> could result in some pretty subtle bugs


True.

>> Field access is by
>> 
>> field value
>> 
>> That is, the field name is an ordinary production function.
>> 
>> Now, the notation
>> 
>> value . field
>> 
>> is just reverse application. The only hassle is this:
>> 
>> struct X { x:int; };
>> fun x: X -> int = "1";
>> 
>> var a: X = X (x=1;);
>> 
>> println$ a . x; // which x?
> 
> Yeah, I can see that being confusing. Worse:
> 
> struct Vector { x:int; y:int; z:int };
> var a: Vector = Vector (x=1; y=2; z=3);
> val x = 2;
> 
> println$ a.x; // will it print 1 using the projection function, or 3
> using the value of x to look up the third item in the structure?

That depends on the "scope" of the projection. If the scopes
are the same we would get an ambiguity. If the scope of the projection
is "inside" the struct (as at present) it has priority.

We used to use "get_x" for this but that sucks.. token pasting .. grrr.


> This all sounds great. Will these pointer values be automatically
> lowered to their pointed value, or will we always have to dereference
> them? For example, will we be able to do:
> 
> cstruct X { x:int; y: int; };
> val z = X (x=1; y=2;);
> println$ z.x + z.y;
> 
> Or will we have to write:
> 
> println$ *(z.x) + *(z.y);

Well to be consistent, you'd have to dereference them; in C this is done by:

        z->x

I'm not sure I like this. to start with I won't do this, I'll leave operator & 
and
variables as they are. The product type changes will flow through the whole
compiler .. not a small job. We can leave

         x = y

as a synonym for

        *x <- y

so hopefully not much will break. I'm also thinking about mutable/immutable
fields etc.

Note some of this flows on to arrays, i.e. tuples T ^ N. I'm thinking that 
normally
Felix core data types should just be immutable, including arrays. Unless
stored in variables. 

In the case of a variable the data structure is STILL immutable. In other words
for a struct X { x:int; }

        var a: X = X(1);
        a.x = 1; // NOT ALLOWED

That's the **theory**. You can replace the whole variable, that's it.

So then we have functional update:

        a = { a with x = 1; };

which does that .. and then:

        a. x = 1; // Syntactic sugar for functional update.


is allowed again.. and then ..

        // optimiser just modifies the field

so we're back where we started, except the whole thing is much more 
"functional".
Functional language with pointers and variables.

This was we don't need:

        struct X { val immut: int; var mut: int; }

we just have the whole thing mutable or not. But maybe we want the above.


--
john skaller
skal...@users.sourceforge.net





------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to