[nem-en] My thoughts on Nemerle

[Michal Moskal]

On 1/8/06, Kamil Skalski <kamil.skalski at gmail.com> wrote:
> 2006/1/7, Alejandro Serrano <trupill at yahoo.es>:
> > 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.

I promise I will.

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

The problem if we allow [Extension] on other than first parameter? Would
this be compatible with extension methods in C# 3.0?

> > 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 ;-)

I'm not sure: while this seems cleaner, forcing people to write ten more
'using's in front of their file may not be that good idea.

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

Yeah.

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

I believe they are useful for static contract checking.

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

Maybe this is just op_Implicit in Nullable[T]?

> > SUPPORT FOR COMING SYSTEM.QUERY FUNCs
[...]
> > 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)

There is a standard [1] and a reference implementation [2] of a set
of classes supporting functional stuff like functional values and
tuples. There are however problems -- functional values are generic
delegates and tuples are all structs (including 10-tuple). Neither
can be efficient, but what to expect from die hard Haskell hackers :-)

[1] http://www.ecma-international.org/publications/files/ECMA-TR/TR-089.pdf
[2] http://www.mondrian-script.org/ecma/#Anchor-Ecma-49575

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

I didn't know they have a mailing list :-) Subscribing...

--
   Michal Moskal,
   http://nemerle.org/~malekith/