Andy and I had a very productive meeting tonight on various syntax aspects of Fan.
The first thing we debated was the variable declaration/assignment combo:
FooBar x = new FooBar()
FooBar x = new FooBar("paren1", 2)
This syntax sucks because you have to repeat yourself - it ain't DRY. The 95% case is that the variable type declaration and constructor are the same. So we looked at two alternatives:
A (Ruby like):
FooBar x = new
FooBar x = new ("paren1", 2)
B (Inferred Typing):
x := new FooBar
x := new FooBar("paren1", 2)
We decided that option B is our preferred choice. Option B is basically the infered typed approach (like Boo), where we infer the type of x to be the type of the right hand side. However unlike other dynamic languages we won't allow the use of the standard = assignment operator, but rather require a special operator, the := def-assign operator that does a combo variable definition and assignment.
The def-assign syntax will be supported for both local variables and fields. If we do method parameter defaults, we might consider it there too.
andyWed 7 Dec 2005
Also, keep in mind I can always explicitly type my variable. These are both valid:
FooBar foo := new FooBar
Widget foo := new FooBar
brianWed 7 Dec 2005
I think the key decision is whether we force use of := even when the type is declared. For example:
Int x; // allowed
x := 5; // allowed
Int x = 5; // (A) is this allowed?
Int x := 5; // (B) is this allowed?
So do we
Allow A only
Allow B only
Allow A and B
I think I tend to favor option 2, although that might be tough switching from C/Java
brianThu 8 Dec 2005
We agree that all declarations wil be forced to use the := operator:
Int x; // allowed
x := 5; // allowed
Int x := 5; // allowed
Int x = 5; // compile time error
brianThu 15 Dec 2005
I took a quick look at reworking the code to use inferred typing. I think it is going to be a real pain the ass because I don't think you can tackle it linearly like other resolve steps in the pipeline. For literals it is easy. But for arbitrary expressions, I have to resolve them first (which is fairly late in the pipeline). But resolving all the arbitrary expressions requires knowing the types of the fields and variables! I'm sure there is some trick I just have figured it out yet.
brianFri 16 Dec 2005
I checked in Type Inference. It's pretty sweet. I support type inference using the := def assign operator for field definitions and local variable definitions. It turns out infering the type for local vars is really robust because at that point everything needed is guaranteed to be resolved. Infering fields is a little trickier because it has to happen much earlier in the pipeline - but common cases like literals are handled. I think that's pretty acceptable, because in general you really want the shortcut for local vars. And I'm not sure how much you would use anything other than a literal for a field (maybe a factory method).
brian Wed 7 Dec 2005
Andy and I had a very productive meeting tonight on various syntax aspects of Fan.
The first thing we debated was the variable declaration/assignment combo:
This syntax sucks because you have to repeat yourself - it ain't DRY. The 95% case is that the variable type declaration and constructor are the same. So we looked at two alternatives:
A (Ruby like):
B (Inferred Typing):
We decided that option B is our preferred choice. Option B is basically the infered typed approach (like Boo), where we infer the type of x to be the type of the right hand side. However unlike other dynamic languages we won't allow the use of the standard = assignment operator, but rather require a special operator, the := def-assign operator that does a combo variable definition and assignment.
The def-assign syntax will be supported for both local variables and fields. If we do method parameter defaults, we might consider it there too.
andy Wed 7 Dec 2005
Also, keep in mind I can always explicitly type my variable. These are both valid:
brian Wed 7 Dec 2005
I think the key decision is whether we force use of := even when the type is declared. For example:
So do we
I think I tend to favor option 2, although that might be tough switching from C/Java
brian Thu 8 Dec 2005
We agree that all declarations wil be forced to use the := operator:
brian Thu 15 Dec 2005
I took a quick look at reworking the code to use inferred typing. I think it is going to be a real pain the ass because I don't think you can tackle it linearly like other resolve steps in the pipeline. For literals it is easy. But for arbitrary expressions, I have to resolve them first (which is fairly late in the pipeline). But resolving all the arbitrary expressions requires knowing the types of the fields and variables! I'm sure there is some trick I just have figured it out yet.
brian Fri 16 Dec 2005
I checked in Type Inference. It's pretty sweet. I support type inference using the := def assign operator for field definitions and local variable definitions. It turns out infering the type for local vars is really robust because at that point everything needed is guaranteed to be resolved. Infering fields is a little trickier because it has to happen much earlier in the pipeline - but common cases like literals are handled. I think that's pretty acceptable, because in general you really want the shortcut for local vars. And I'm not sure how much you would use anything other than a literal for a field (maybe a factory method).