Suggestion: Syntactic sugar for Maps!

[Isaac Dupree]

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#view-patterns

> 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