New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Record Types #120
Comments
Am I correct in understanding that
where TUPLE might actually be something explicit, anonymous or defined somehow by the typechecker, I haven't thought that through. I'm not sure if I see much of an advantage, with the proposed changes in shared initializer parameters the above could already be shortened to:
and with the builder pattern intrinsic to Ceylon we could use this to make something like:
and I'm sure with some clever thinking we could make a library that does what @luxspes wants, right? |
So, if I understand you correctly, no it can't be shortened to that. I forgot to mention, these are anonymous record types. We don't want to have to specify a new class each time, because we want to be able to modify the types. For example, the As for a library, the challenge is making a library that works for all anonymous record types. The only ones I know of use that can address features like We might have some some differences in our goals that we can take advantage of, but it'll take some investigating. Or, we might just have to come to some sort of compromise. That is, of course, if we even choose to have record types. |
Ok I understand, but that either means we statically determine those -Tako On Sat, Dec 24, 2011 at 12:07, Ross Tate <
|
@quintesse I think at the actual Java level a record is just a tuple (you add support for tuples and later layer support for records on top of it). The names would be something that exists at the typechecker level and eliminated during lowering. |
But can that handle the dynamic situation? Because normally with tuples you -Tako On Sat, Dec 24, 2011 at 18:51, Gavin King <
|
Same is true of records. Really, they're just considered syntax sugar for a tuple in the languages I've looked at. |
Which then removes a large part of its usefulness IMO |
You raise good points. Interestingly, the implementation concerns suggest an approach for the type problem as well. Implementation (for dynamic situations)All record types erase to the same implementation, say an associative array (we could do a hashmap, but record types are typically small so an associative array would be faster). If an instance has type Type Approach (suggested by implementation)Let For No removing fields (sorry); subtyping should take care of some of that though. If |
Related: #745. |
In the discussion for Tuples (#81), @luxspes brought up the issue of record types, a variant of tuples which are particularly important to databases and relational algebra.
One database given was:
resulting in
RELATION { TUPLE {SourceUserName 'Joseph', TargetUserName 'Peter', RelationshipName 'Friend'} }
.If we use the syntax
{SourceUserName:String,TargetUserName:String,RelationshipName:String}
to denote a record type in Ceylon, and the syntax{SourceUserName="Joseph", TargetUserName="Peter", RelationshipName="Friend"}
to denote a record instance in Ceylon, then we can encode that example using comprehensions (#82):and
rel
would have inferred type{SourceUserName:String,TargetUserName:String,RelationshipName:String}*
and essentially have value{{SourceUserName="Joseph", TargetUserName="Peter", RelationshipName="Friend"}}
.Another example was, rather than
where you have to list all the fields you're not even messing with, we should be able to do
So, if we extend the syntax for records with
rec.+field=value
to take a recordrec
and make a new record with extra fieldfield
with valuevalue
rec.-field
to take a recordrec
and make a new record that's the same except without fieldfield
then we can do this in Ceylon with the following:
The syntax is a bit wordier than the database example, but that's because the database example is extremely context sensitive with a lot of implicit capturing. For example, if there were some previously defined variable g, then it's not clear whether the g+h expression should reference the previously defined g or the column g.
These thoughts open up a number of issues:
The text was updated successfully, but these errors were encountered: