p h p E S P

Help

Language Poll II

This is the second poll about various stuff in the Nemerle language. Please take a minute or two to fill it.
1. Which of the following features would you like to be added first to Nemerle. You can mark more than one, but the less you mark, the more important they are :-)

The numbers are issues numbers in our issue tracking system.

If you use the Other... line, you can report the issue to our system and include number. You can also give some more description in the comments section.

The [hard] marks are only for reference.
#416 allow extending existing classes [hard]   47.2% (17)
#316 Allow PInvoke methods   38.9% (14)
#142 default parameters   27.8% (10)
#138 matching on properties   38.9% (14)
#409 Omitting the prefix when matching variants   25.0% (9)
#178 Add [method: Pure] and [assembly: Pure] attributes [hard]   5.6% (2)
#180 null-checks when fireing events   13.9% (5)
#303 indexing operator on tuples   38.9% (14)
#181 safe casts to enum types   22.2% (8)
#213 Type inference for private methods [hard]   19.4% (7)
Other: chained asignation: a=b=1;   2.8% (1)
Other: increments, decrements, ToString on enums   2.8% (1)

2. Do you think the following expression should give an ambiguity error? 
  using SomeOther;

  class Buffer { public this () { ... } }

  class SomeOther { public static Buffer () : void { ... } }

   {
     ...
     Buffer ();
     ...
   }
Buffer() is valid as a function SomeOther.Buffer() call or as creation (and ignoring) of an instance of Buffer. On the other hand, compiler could just choose the function returning void, because this is what is expected in the middle of the sequence.
It should be an ambiguity error   66.7% (24)
It should select the void-returning function   19.4% (7)
TOTAL   86.1% 36
3.

Would you like to have return and break statements in Nemerle? They are against functional style, but sometimes seems cleaner, especially since we have a handful of imperative loops already (while, for, foreach).

The statements are most likely to be implemented as macros inside the Nemerle.Imperative (or just Nemerle.Ugly ;-) namespace, so using Nemerle.Ugly; will be needed to use them.

Note that we are not going to add general goto support. However the break statement is going to support label to facilitate jumping out of a nested loop.

Yes, yes, yes! They should be available by default, without any using!   30.6% (11)
Yes, this is good idea, but not by default, please.   19.4% (7)
Well... I don't like it, but if you have to -- put it in a namespace.   27.8% (10)
No, there is no place for this stuff in Nemerle!   13.9% (5)
TOTAL   91.7% 36
4. It is sometimes necessary to specify type arguments of a method upon call. For example: SomeFun[int] () -- here the type argument cannot be inferred, and therefore has to be specified. It is hardly ever used, because our inference engine is quite smart.

The most likely place where it can be needed are type constructors, like def x = Dictionary[int,string]().

Now the problem is syntactic. We cannot use the syntax above, because we cannot distinguish it from indexer reference at the syntactic level. We also don't want to use C#-ish SomeFun<int> (), for some other parser-related reasons.

Which syntax should we choose? We are not happy with any of the possibilities listed here, so feel free to add your own.
Foo.[int,string] (note the dot after Foo)   27.8% (10)
Foo [of int, string]   22.2% (8)
Foo [with int, string]   8.3% (3)
SomeType [of int, string], SomeFun [with int, string] (0)
Other: Dictionary() of [int,string]   2.8% (1)
Other: Don't know, but the proposed ones are ugly. The first is sightly less ugly.   2.8% (1)
Other: drop indexer reference and use Foo[int, string] (use foo.at(1) instead of foo[1])   2.8% (1)
Other: Foo () : Foo [int * string]   2.8% (1)
Other: Foo<int, string>   2.8% (1)
Other: Foo[_ : int, _ : string]   2.8% (1)
Other: No punctuation at all other than whitespace. Just use SomeFun int (). Same for other type arguments too.   2.8% (1)
Other: no syntax force the user to explicit types of the arguments SomeFun(a :int, b :string)   2.8% (1)
Other: some two-character brackets for all generics if neither [] nor <> can be used   2.8% (1)
Other: SomeType(int, string)(), SomeFun(int)()   2.8% (1)
Other: [int, string] Foo or For [= int, string]   2.8% (1)
TOTAL   88.9% 36

5. How well do you know Nemerle?
Very well   22.2% (8)
Quite well, wrote bigger example   16.7% (6)
Wrote small example   38.9% (14)
Read some docs   11.1% (4)
This is the first thing about Nemerle I've ever seen   5.6% (2)
TOTAL   94.4% 36
6. Comments, you may also include email contact if desired:
#Response
1-- Kamil Skalski
1--Michal Moskal
1:*
1:-)
1brandonbarker(a)ieee.org
1Foo<int> really would be the nicest, so you should at least have explained on the survey the "other parser-related reasons" so possible work-arounds can be discussed.
1For the type parameter ambiguity, would a "new" keyword solve the problem with constructors? def x = new Dictionary[String,int]() cakoose(a)yahoo.com
1Good job guys, nemerle is a great language.
1I don't use Nemerle, just have some opinions on language design. qrczak(a)knm.org.pl
1I would also like to see more documentation on using the advanced features of macros -- particularly modifying and generating classes.
1Nemerle is great already, keep it up!
1On #2, I don't understand how you could know that the function returning void is what is expected in the middle of the sequence. What if the function returned string or worse yet a Buffer object? On #4, Why is any punctuation other than white space needed for type arguments? Rather than Hashtable [int, string] why not just Hashtable int string? Or more complicated: Hashtable int List string instead of Hashtable [int, List [string] ].
1Please keep up with the good work. I am especially interested in Nemerle's macros.
1The features I'd like incorporated: * Laziness + memoization * Haskell-like [x | x <- xs, x <y] * Haskell-like [1..10], [a..z] and such
Go back to Management Interface