[nem-en] My thoughts on Nemerle

[Kamil Skalski]

2006/1/7, Alejandro Serrano <trupill at yahoo.es>:
> Sorry, this is a very, very long post. Sorry for it, but I has written

A long reply for the long post ;-)

>
> EXTENSION METHODS
>
> Extension methods are supposed to be some type of method that is invoked
> thorugh a type, but actually resides in another *static* class (module
> in Nemerle).

Yes, we have this one under http://nemerle.org/bugs/view.php?id=416
Basically it needs two things: macros attached to methods (this
requires plugging into typer after it resolves the actual call to some
method) and the actual addition of faked members to existing classes.
I just hope that Michal will take a look at this, because this is the
one of nicest features still waiting for implementation.

> For creating them, I think C# 3.0 syntax using this before the argument
> type is not needed, just decorating the method with the

After we have a macro (probably one attached to first parameter or
just method), which would add extension method to a class, these are
just cosmetic problems. We could easily have all the mentioned ways of
declaring extension method:
- public static foo (this s : string, ....)
- public static foo ([Extension] s : string, ...)
- [Extension] public static foo (s : string, ...)
- [Extension (string)] public static foo (...)

Also making a class level macro, which would add the 'this xx : TYPE'
first parameter to methods in a class should be easy.

What I like at most are first two (preferably second) ways of
specifying extension method.

> Another possible approach would be to create extension modules, where
> all public methods get the extension attribute for one type, altough I
> think that way we get less power. Then, inside the class, this would be
> a name for an actual hidden first parameter that would be included in
> all public methods. So:
>
>
> altough I find this would create a lot of problems with parametric
> polymorphism.

Agreed, this can be problematic with
[Extends (Bla [T])]
class Foo { }

though macros should handle it relatively good. But maybe we should
write this macro for convenience, it shouldn't be hard too.

>
> For extension methods use, I think the best way to go is to use "using"
> along with the name of the *class* (not namespace, as in C# 3.0) that
> contains the methods. Maybe some special "import" word can be used.

Ah, this is one thing, which would require some additional effort in
implementation. I like your idea of requiring opening the class with
extension methods. It seems much more clean than the MS (One) way ;-)

Also, I don't think we should limit anybody to modules - simply allow
extension method to be any public static method.

>
> JUST-RETURN FUNCTIONS (LAMBDA EXPRESSIONS IN C#)
>
> I think function syntax is good in Nemerle. However, seen C# 3.0, I
> think its syntax for lambda expressions could be used for functions that
> just return values. I think it can be easiy achieved with:
>
> x => x.Name
>
> could be translated to
>
> fun (x) { x.Name }

Yes, we also like this syntax. It should not be hard to tweak parser
to make "=>" an macro operator.

>
> Maybe it would conflict with pattern matching?

We were discussing it and indeed it could cause some problems, but in
general it should be possible (pattern parser could just eat first =>
and then treat everything until first | as expression, parsing => as
operator)

>
> TYPE INITIALIZERS
>
> This is one of the features I would like the most to see in Nemerle.
> This is just about getting this in constructors:
>
> def r = Point() { X = 1, Y = 3 };

Maybe some kind of infix macro-operator:
def r = Point () init (x = 1, y = 3);

I'm not sure if this initializator stuff change something in
overloading resolution (from what I remember in C# 3.0 they use just
Point (x = 1, y = 3), which could cause problems when mixing with
constructors existing in Point). If it isn't, the macro would be very
good approach here.

Could you cite the actual specification form C# 3.0?


>
> NULLABLE TYPES
>
> I don't think it neccessary, although I wouldn't mind to see it. Should
> we use a more difficult typing engine only for getting nullable types? I
> really think not.

Well, I'm quite neutral about nullable types. I never needed them in
Nemerle / C# yet, though I like the idea of convenient (at least as
convenient as in Java 5) wrappers for value types, so maybe adding
this additional syntax wouldn't be a bad idea.

> Buy maybe some things can be used:
>
> def f : float? = 3.0;
>
> for doing the conversion automatically, instead of:
>
> def f = Nullable(3.0);
>
> which I find stranger.

Note that nullable types also have some special cases for typer, like
implicit conversions between T and T?. After I get used to this idea,
it seems quite nice.

>
> SUPPORT FOR COMING SYSTEM.QUERY FUNCs
>
>
> One of the first things I find in System.Query related to Nemerle in the
> Func generic delegates. May that be the chance to get Nemerle functions
> compatible to C# and the other .NET languages? This has the problem of

Well, currently we do automatic translation when needed. That is if
some function takes delegate as parameter and we try to pass 'fun (x)
{ bla }' to it, then Nemerle function is automatically converted to
the needed delegate. The only problem is the other direction,
when we specify 'foo (x : int -> int) : int' then it is translated to
method taking Nemerle.Builtins.Function [int,int], which is not a
delegate. The fact we do not use delegates is purely of performance
reasons - delegates are 2-4 times slower than our current
implementation (even on MS.NET 2.0, where is was probably optimized).
I would like to have a option (maybe an assembly-level attribute) to
control what compiler uses when implementing functional types. This
might not be easy to implement though.

> remain compatibility with previous Nemerle functions, but we haven't
> reached 1.0 yet, so we can change it yet ;-). I think this would be a
> great step.
> However, I find some difficult thinks on the implementation.
>
> Compute (f : int -> int, x : int) : int {
>     f(x)
> }
>
> would become:
>
> Compute (f : Func[int, int], x : int) : int {
>     f(x)
> }
>
> Maybe something like that:
>
> def sum_five = 5 + _;
>
> should get type Func<int, int>?
>
> I think this is very useful for compatibility with other languages,
> something that has not been really achieved in .NET now: Nemerle has one
> set of libraries, Boo some other, F# remains totally in-understandable
> for me :-)

I don't think that interoperability at this level is possible at all.
Compiler creators will not cooperate well at this level of detail
(everybody needs something different). Simply if one want to have
interoperable API, the one should use some set of delegates and then
it should be easy to use this common delegate-based API in every
language (as I stated above, Nemerle can easily pass its functional
values to methods expecting delegates)

>
> SQL-LIKE QUERY EXPRESSIONS
>
> This has two different parts. First of all, whether we should make lists
> System.Query-compatible or not.
> Second, if we should include something like query expressions in
> Nemerle. Maybe, a set of macros could make the work, so it can be easily
> done. The syntax can come from the one in C# spec.
>
> def c = from c in customers
>         where c.City == "London"
>         select c;

I still wonder why they didn't make it  'select c from customers where
c.City == "London"'..
but probably they had some good reasons.
I'm afraid that simple syntax extensions will not be able to handle
this syntax in fullness, but it should be possible (though with more
effort) to create macros with raw token syntax extensions to parse it.
And at this point I guess we are finished - this SQL stuff in C# is
nothing more than syntactic sugar for calls to System.Query.

>
> STRING FORMATING À LA String.Format
>
> I really find it very useful, but I see the problem of mixing
> not-String.Format-like strings and the other ones. Well, a feature like
> that is always good for everyone.

Could you get into details? What kind of mixing causes problems?

>
> CONTRACTS
>
> Some time ago, I tried to speak to Spec# guys, but in Microsoft Research
> only a few people get into projects (or it seems), so I could not get
> any relevant information. This is, however, really useful.

It is possible that a person from our institute will do some
experiments in joining theorem prover from Spec# to code generated by
Nemerle. After a few months of observing Spec# mailing list I can say
that:
a) people really like the idea of contracts (I like and use the more
and more often myself)
b) static analysis causes maaany problems
c) there are still many design problems, especially at how static analysis works

>
> OPERATOR OVERLOADING
>
> Is this already supported in Nemerle? If it isn't, it would be fine to have.

I guess it is supported. You can define operators just like in C#.

> A MACRO-AND-FEATURES-GUIDE
>

Surly, we have so many nice features that they often get lost or
forgot when describing Nemerle to people... and documentation is still
not very well organised. Any ideas on how to make it easier to find
relevant information are welcome.

--
Kamil Skalski
http://nazgul.omega.pl