Having used Fantom for some time. I have compiled a list of issues that in my opinion might plague/interest future Fantom.
DSL
Right now writing them is a bit of a chore. Having used XText, I'd love if there was either a built-in tool or some kind of MetaDSL<| |> that would make this task as trivial as writing DSLs for XText (It's really really easy).
Extending Fantom
Currently it's a bit hard to extend Fantom. For example adding a new async keyword to language is hard. Impossible, actually. Good languages should have the ability to grow. There should be some way (even really hard way) to inline DSLs into Fantom.
Customizing built in types
It's pretty cool syntax that Fantom has for it's list/maps. But I've seen people complain on other places that they want to implement their own Lists, which is a fair point. Sometimes the programm you uses would benefit a lot from having their own implementations of it. So I guess it would be of interest to allow some kind of mechanism to create their own custom implementations to lists.
Operator Overload
Right now we are adding @Operator left and right. I think that is the right direction. Having seen use of Operator overload done wrongly , I think I have came to a conclusion that the greatest misuse of Operators (other than priority and unarity) is the impossibility to search what it represents. But what if Operators were actually aliases of methods that could take any unicode. What I have in mind is this:
@Operator("∪")
public Obj[] union(static Obj[] this, Obj[] that)
//I'm assuming extension methods work like this
[1,2,3]∪[2,3,4] // [1,2,3,4]
[1,2,3].union([2,3,4]) //equivalent to above
Constraint on variables
There was some discussion about using some domain restrictions on types. Which reminded me of Liquid Types. Check those out, maybe they will help you with your problem.
SlimerDudeTue 19 Jun 2012
It's an interesting standpoint you're coming from - for I've never felt the need to delve into DSLs, extend the language or customise types. But I do like your idea of the operator overload, it seems like a natural progression, though I can't think of where I'd use it myself.
Maybe I'm boring but I just kinda use Fantom as a pragmatic language to get things done. Serialisation and concurrency I do use quite a bit, and Fantom is pretty good at that.
Re: DSL
After going through Ivan's article on Exploring Fantom DSLs I was of the opinion that to be really really useful, DSLs needed tighter integration with the Fantom compiler - which kinda raises a chicken'n'egg situation.
I've also stayed clear of DSLs because I think the syntax is Kinda<|ugly|> and nothing a decent class / API can't fix.
This post isn't meant to be a downer, I just find it interesting I've never thought about the above points before.
Steve.
brianWed 20 Jun 2012
Hi Daniel,
All great points! Here is my thoughts:
DSLs
These are difficult to create because they are really compiler plugins, not user defined macros. I am not sure what the right spectrum is, but I'm not sure it would actually be a good thing for people to go around and create their own DSLs for every library - it would actually drastically decrease modularity. I think there is a ton of work we could do to increase their power and ease though.
Extending Fantom
I think this is a good thing. The main thing about Fantom is uniform readable code (same thing that makes Java "great"). In the end what you really want to do is empower community to enhance through OO model, not by changing syntax. We could potentially make this more flexible like allowing people to omit dot in method calls - but leads to problems Ruby, Scala have in decreasing readability and creating dialects of your language.
Customizing built in types
You can pretty much already do this today with it-blocks and add operator. For example if I had a MyBag class that had an add method, then I could do this:
bag := MyBag { a, b, c }
Operator Overload
Same thing as above - I think any increase of scope of operators would only decrease readability.
This directions are too far from my practic. This is not matter for me.
I want 1) extension methods and 2) serialization improving.
The hardest thing in Fantom is intersection of four feature: 1) serialization 2) inferitance 3) ctors 4) non-nullable fields
Every feature is clear and good in separate from others. But when I use they together then I confused and I rewrite my code dozens of times.
This is hard to explain cuz for this I need to extract big example from my code. Later I will collect hardships of serialization and I will write post.
I think Fantom need to improve serialization orthogonality.
DanielFath Tue 19 Jun 2012
Having used Fantom for some time. I have compiled a list of issues that in my opinion might plague/interest future Fantom.
DSL
Right now writing them is a bit of a chore. Having used XText, I'd love if there was either a built-in tool or some kind of
MetaDSL<| |>
that would make this task as trivial as writing DSLs for XText (It's really really easy).Extending Fantom
Currently it's a bit hard to extend Fantom. For example adding a new
async
keyword to language is hard. Impossible, actually. Good languages should have the ability to grow. There should be some way (even really hard way) to inline DSLs into Fantom.Customizing built in types
It's pretty cool syntax that Fantom has for it's list/maps. But I've seen people complain on other places that they want to implement their own Lists, which is a fair point. Sometimes the programm you uses would benefit a lot from having their own implementations of it. So I guess it would be of interest to allow some kind of mechanism to create their own custom implementations to lists.
Operator Overload
Right now we are adding
@Operator
left and right. I think that is the right direction. Having seen use of Operator overload done wrongly , I think I have came to a conclusion that the greatest misuse of Operators (other than priority and unarity) is the impossibility to search what it represents. But what if Operators were actually aliases of methods that could take any unicode. What I have in mind is this:Constraint on variables
There was some discussion about using some domain restrictions on types. Which reminded me of Liquid Types. Check those out, maybe they will help you with your problem.
SlimerDude Tue 19 Jun 2012
It's an interesting standpoint you're coming from - for I've never felt the need to delve into DSLs, extend the language or customise types. But I do like your idea of the operator overload, it seems like a natural progression, though I can't think of where I'd use it myself.
Maybe I'm boring but I just kinda use Fantom as a pragmatic language to get things done. Serialisation and concurrency I do use quite a bit, and Fantom is pretty good at that.
Re: DSL
After going through Ivan's article on Exploring Fantom DSLs I was of the opinion that to be really really useful, DSLs needed tighter integration with the Fantom compiler - which kinda raises a chicken'n'egg situation.
I've also stayed clear of DSLs because I think the syntax is
Kinda<|ugly|>
and nothing a decent class / API can't fix.This post isn't meant to be a downer, I just find it interesting I've never thought about the above points before.
Steve.
brian Wed 20 Jun 2012
Hi Daniel,
All great points! Here is my thoughts:
These are difficult to create because they are really compiler plugins, not user defined macros. I am not sure what the right spectrum is, but I'm not sure it would actually be a good thing for people to go around and create their own DSLs for every library - it would actually drastically decrease modularity. I think there is a ton of work we could do to increase their power and ease though.
I think this is a good thing. The main thing about Fantom is uniform readable code (same thing that makes Java "great"). In the end what you really want to do is empower community to enhance through OO model, not by changing syntax. We could potentially make this more flexible like allowing people to omit dot in method calls - but leads to problems Ruby, Scala have in decreasing readability and creating dialects of your language.
You can pretty much already do this today with it-blocks and add operator. For example if I had a MyBag class that had an add method, then I could do this:
Same thing as above - I think any increase of scope of operators would only decrease readability.
Mic Wed 20 Jun 2012
Also maybe some ideas could be taken from:
* http://en.wikipedia.org/wiki/Haxe
* http://en.wikipedia.org/wiki/Opa_%28programming_language%29
Akcelisto Fri 22 Jun 2012
This directions are too far from my practic. This is not matter for me.
I want 1) extension methods and 2) serialization improving.
The hardest thing in Fantom is intersection of four feature: 1) serialization 2) inferitance 3) ctors 4) non-nullable fields
Every feature is clear and good in separate from others. But when I use they together then I confused and I rewrite my code dozens of times.
This is hard to explain cuz for this I need to extract big example from my code. Later I will collect hardships of serialization and I will write post.
I think Fantom need to improve serialization orthogonality.