Adept's twin

[1muhgcmg]

Here it is:

https://github.com/NICUP14/MiniLang

What do you think about their Uniform function call syntax (UFCS)? It gives the feeling of coding in a dynamic language to me.

[IsaacShelton]

That looks pretty interesting.

Adept 2.x currently has one-way UFCS, where you can call methods as if they were functions.

I was initially against UFCS when designing Adept 2.x, but I've thought about it a lot more while creating Adept 3.x and I now think it might be good if some additional features around it exist. The current design of Adept 3.x has full UFCS, and I think we will be able to limit its downsides with some special attention.

The main drawbacks are that auto complete can become cluttered and formatters don't know if there is a preferred syntax for calling a function, but I think it offers a great intuitive way of having a pipe operator without needing to constantly think about whether you're calling a function or a method.

I thought about having a pipe operator be something separate, but then you get visual precedence ambiguity while reading it (for example x + y | getItem(4)) unless you use something like -> that people are already familiar with the precedence of. And even then, I don't know if there is much to gain by having functions and methods not be the same in a non-object-oriented language.

For languages with top-level functions, I think that the language itself should provide a good enough mechanism to deal with name collisions, but most don't. Which is why I think UFCS can feel bad sometimes, because languages with them are often missing good name collision resolution mechanisms.

Those are just my current thoughts. UFCS does sucks sometimes but other times it really is amazing. I'm trying UFCS in Adept 3.x right now to see how possible it is to have while reducing/eliminating the bad aspects of it, but today it is too early to tell if having UFCS is a mistake or not. The other unusual side effect of UFCS is that it means overloading has to be supported. I see the benefits of both having/not-having overloading, but just an interesting observation.

I think by adding a few new function annotations or by having special parameter names, these issues I mentioned can largely be eliminated though.