If we introduce map syntax it should be overloaded. Just as list syntax should be (and will be once I get some time to do it). -- Lennart On Thu, Nov 27, 2008 at 7:10 PM, Don Stewart wrote:

dons:

...

circularfunc:

...

I suggest Haskell introduce some syntactic sugar for Maps.

Python uses {"this": 2, "is": 1, "a": 1, "Map": 1}

Clojure also use braces: {:k1 1 :k2 3} where whitespace is comma but commas are also allowed.

I find the import Data.Map and then fromList [("hello",1), ("there", 2)] or the other form that I forgot(because it is to long!) to be to long...

So why not {"hello": 1, "there": 2} ?

Well, one problem is that we don't have a definitive Map library. Which kind of Map would you like? IntMap/Map/AVLTree? Some other tree?

That said, you could certainly write a little preprocessor/quasiquoting/template haskell for dictionary literals.

Perhaps overloaded *dictionary* literal syntax? So we could have

instance Dictionary Map k instance Dictionary IntMap instance Dictionary HashTable instance Dictionary Trie k

etc.

That would be pretty awesome..

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

Thomas Davie wrote:

On 27 Nov 2008, at 19:59, circ ular wrote:

...

I suggest Haskell introduce some syntactic sugar for Maps.

Python uses {"this": 2, "is": 1, "a": 1, "Map": 1}

Clojure also use braces: {:k1 1 :k2 3} where whitespace is comma but commas are also allowed.

I find the import Data.Map and then fromList [("hello",1), ("there", 2)] or the other form that I forgot(because it is to long!) to be to long...

So why not {"hello": 1, "there": 2} ?

let's look at your argument. I'll ignore spaces in character counts because they're all optional here. fromList [("hello", 1), ("there", 2)] { "hello": 1 , "there": 2 } Basically there are two overhead: - "fromList", or "Data.Map.fromList". I'll get back to this later. - that the pair-tuple constructor uses three characters "(", ",", ")" rather than Python's one ":". The latter is easy to fix! ":" already means something in Haskell, so we'll have to pick something else. a & b = (a, b) fromList ["hello" & 1, "there" & 2] or we could start to get creative, for aesthetic purposes... ["hello"? 1, ], or ["hello":-1, ] to define new data (or type synonym?) ":-". Now comes "fromList" and the issue of monomorphism of normal lists. Well, you're going to have to (or want to) specify the type you want at some point, perhaps. The name of the function could be less ugly than "fromList". If you expect pattern-matching, there's another can of worms, and I suggest looking into GHC's new lightweight "view patterns" (I wonder if they can really do this well, though? -- because fromList/toList sorts.) http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/syntax-extns.html#vi...

In a similar vein, I suggest not only to not do this, but also for Haskell' to remove syntactic sugar for lists (but keep it for strings)!

not too hard to cope with, though ugly IMHO if we translate it the obvious way: fromList ("hello" & 1 : "there" & 2 : [])

[...] 3) (requiring you to agree with my opinions about tuples) it would allow for clearing up the tuple type to be replaced with pairs instead. (,) could become a *real* infix data constructor for pairs. This would make us able to recreate "tuples" simply based on a right associative (,) constructor. I realise there is a slight issue with strictness, and (,) introducing more bottoms in a "tuple" than current tuples have, but I'm sure a strict version of the (,) constructor could be created with the same semantics as the current tuple.

you are right, if you follow a simple asymmetric restriction (which, alas, keeps you from using them as ordinary pairs) : data Tup a b = Tup a !b type Tup0 = () type Tup1 a = Tup a () type Tup2 a b = Tup a (Tup b ()) type Tup3 a b c = Tup a (Tup b (Tup c ())) --or, infixr 5 Tup type Tup2 a b = a `Tup` b `Tup` () --etc. -Isaac