Boo

What about

l = [1,2,3] of object

h = {1: "Hello", 2: "World"} of object, string

Oh, much better! Bamboo, your opinion?

It would be great to realize both proposal: type inference by default and explicit typification.
Quite good if generic hash and list are System.Collection.Generic.List and Dictionary or
their childs.

I like it.

I'll start by extracting a GenericList class out of Boo.Lang.List, I want to use the functionality there with generics. Let's see.

Why not use the original System.Collections.Generic.List? Most of the extra behavior of Boo's list can be achieved via extension methods/properties, except maybe negative indexing, which we want to separately add as to any IList, anyway.

In fact, most of the Boo.Lang.List extra behavior (like AddUnique, Reverse, FindAll etc.) should be added via extensions to IList or ICollection, not to some specific implementation. Some of it already exists as .NET 3.5 extensions.

I really don't think there's a good cause to introduce new collections. Avoiding it will save users from having to repeatedly convert ILists into Boo lists and vice-versa.

For now I'm just extracting a generic base class from List. If all goes well, List will simply become an alias to the new List[of T] type.

There are 3 things that I'm not sure how to properly support with the std generic list, you might want to comment:

• value based equality (Equals should return true if all the elements are equal (including nested arrays, etc))
• hashcode based on all the elements
• nicer ToString representation

1. value-based Equals is problematic, considering arrays don't natively support it (or do they?). It won't make much sense if {{[(1,2,3)].Equals([(1,2,3)])}} returned true but (1,2,3).Equals(1,2,3) returned false.

2. You can achieve all of these with inheritance, but perhaps it'll be better to make Boo's list a wrapper for any IList<T>, and provide a default constructor which uses a new internal List<T>. That way you can transform an IList<T> into a boo list in O(1).

3. The rest of the functionality should still be applied to IList<T> via extensions, in my opinion.

4. Keep in mind that most of this functionality is present (and possibly better supported) in the .NET Framework 3.5.

The == operator preserves value semantics for arrays. if you call the Equals method you get the runtime view of equality...

Your point 3 is a very interesting idea indeed.

That's confusing. I thought Boo's == operator translates directly to C#'s Equals operator...
Does it work dynamically?

arr1 as object = (1,2,3)
arr2 as object = (1,2,3)
assert  arr1 == arr2

It's not confusing when you know the rules

boo's equality operator preserves equality semantic for arrays, lists and hashes.

Enter boo code in the prompt below (or type /help).
>>>a1 as duck = (1, 2, 3)
(1, 2, 3)
>>>a2 as duck = (1, 2, 3)
(1, 2, 3)
>>>a1 == a2
true
>>>a1 is a2
false
>>>