#1923 Future Fantom

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:

@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.

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:

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.

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.

Login or Signup to reply.