Hi Kyle,
> With the Maybe example, one bit of syntax doesn't quite make sense:
>
> `Maybe(int)` - what is `int` describing here? What happens if the enum
> has a generic Left and Right? I think doing something along the lines of:
>
> enum Or(type U, type V) {
> Left { var value: T; },
> Right { var value: V; }
> }
>
> could work here.
>
I was following the current syntax for generic records, e.g.
record P { var x; }
var r : P(real);
That said, I definitely prefer your suggestion of naming the generic types
explicitly. I think this should supplant both existing options for generic
types (i.e. both `record P` above and `record Q { type T; var x: T}` would
become `record R(type T) { var x: T; }`).
Some open questions I see in this related to this topic:
>
> 1. Reference vs Value semantics for enums? Some situations want one or
> the other.
>
I'd say value semantics. In cases where the user wants reference semantics,
the value could be wrapped in something like rust's Box or Rc/Arc types
(c++'s unique_ptr or shared_ptr types). I'm of the opinion that making
value semantics the default (where reasonable), and making reference
semantics a tiny bit more work leads to better code.
We might want to discuss move semantics at some point, but I'm happy
postponing that.
2. Do we allow anonymous product types?
> enum Or(type U, type V) {
> Left( U ),
> Right( V, V )
> }
>
I have mixed feelings about this. If we require that the field names used
in select statements match those used in the enum definition, then enum
types defined in libraries might be awkward to use. For example, if Either
were defined in the standard library like so:
enum Either(type U, type V) {
Left{ var value: U; },
Right{ var value: V; }
}
Then the user is forced to use the name "value" in their select statement:
auto a: Either(int, real) = foo();
select a {
when Left{value} do ...
when Right{value} do ...
}
which might mask a variable in the enclosing scope, or might be less
desirable than using more informative names.
Maybe this is an argument against requiring that the field names used in
`select` match those used in the enum definition...
If we're going to allow anonymous products in enums, should we allow them
to stand alone as well (i.e. tuples with a type name)? Something like
`record X(int, string);`? How would generics look? Maybe we should adopt
angled brackets for generic types:
record Pair<A, B>(A, B); // a la rust
record R<U, V> { var x: U; var y: V; }
var r: R<int, real>;
enum Maybe<T> { Just(X), Nothing }
enum Maybe<T> { Just { var value: T; }, Nothing }
> Aside: I also like this syntax for record initialization it feels more
> in-tune with the value semantics.
>
> For now lets stick to the normal parens, and address this as a separate
> issue.
>
If we use positional pattern matching in `select`, and use parens for
initialization (i.e. a constructor), we don't really need anonymous
products. For example:
enum Either(type U, type V) {
Left{ var value: U; },
Right{ var value: V: }
}
var a: Either(int, string) = Right("hi");
select a {
when Left{count} do ... // meaningful name, not "value"
when Right{msg} do ...
}
enum Entity {
Person { var name: string; var ssn: string; },
Dog { var name: string; }
}
var bill = Person(name="Bill", ssn="123-45-6789");
// This is probably just as good as Person{name:"Bill",
ssn:"123-45-6789"};
If we do this, then anonymous products probably aren't compelling enough to
add to the language, either within enums or outside of enums.
I don't have strong feelings about any of this yet; just thinking out loud
at this point.
- Sean
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
