[nem-bug] [Nemerle 0000689]: Detached signatures for methods (haskell style)

[feedback at nemerle.org]

The following issue has been CONFIRMED.
======================================================================
<http://nemerle.org/bugs/view.php?id=689> 
======================================================================
Reported By:                d
Assigned To:                
======================================================================
Project:                    Nemerle
Issue ID:                   689
Category:                   The Macro Library
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
======================================================================
Date Submitted:             06-02-2006 18:36 CEST
Last Modified:              12-06-2006 20:11 CET
======================================================================
Summary:                    Detached signatures for methods (haskell style)
Description: 
 Haskell, as you probably well know, has type inference, so no types have
to be explicitly specified, BUT you *can* specify them as a means of
documenting code and enforcing it's desired meaning (type), so that no
coding mistakes will alter the type an yield a different function, than
expected/wanted.
 These signatures can be detached from the actual function body with a
syntax like this:

add :: Integer -> Integer -> Integer
add x y = x + y

{- or -}

map :: (a->b) -> [a] -> [b]
map f  [] = []
map f (x:xs) = f x : map f xs

 What I'm proposing is a similar feature for Nemerle. Consider this:

Add : int * int -> int
static Add (x, y) { x + y } 

// instead of

static Add (x : int, y : int) : int { x + y }

// or

Map : list ['a] * ('a -> 'b) -> list ['b]
public Map (l, f) { $[ f(x) | x in l ] }

// instead of

public Map['a, 'b] (l : list ['a], f : 'a -> 'b) : list ['b] {
      $[ f(x) | x in l ]
}

 I guess at least some immidiate benefits are obvious..
1) Clarity - the code is more readable without all the typing clutter. 
2) Backward and forward compatibility - this would work now, without type
inference on global members and at the same time, clear, concise code, not
obfuscated by interwoven type specifications, could be written AND no
changes will be necessary when type inference on global members becomes
available - those who preffer could just remove the signatures alone,
others could leave them for the purposes mentioned earlier. I myself would
keep them, so this feature would be, to me, as good as global type
inference itself and it's way easier to implement.
Besides, when this global type inference arrives, people will stop writing
types explicitly. This may be nice for them, but it may make code harder to
understand for others - that's where detached signatures come in play, as a
neat way do specify and document code.

The syntax proposed above may not look very 'native' to Nemerle, so
something else might be figured out, but any way this would be done - I'd
welcome it :)
======================================================================

----------------------------------------------------------------------
 d - 06-02-06 18:41 
----------------------------------------------------------------------
Haskell has syntax to handle inheritance and such stuff with these detached
signatures as well - more details can be found at http://www.haskell.org/ .
Probably a good place to start would be http://www.haskell.org/tutorial/ .

Issue History
Date Modified  Username       Field                    Change              
======================================================================
06-02-06 18:36 d              New Issue                                    
06-02-06 18:41 d              Note Added: 0001322                          
06-10-06 00:04 d              Issue Monitored: d                           
12-06-06 20:11 nazgul         Status                   new => confirmed    
12-06-06 20:11 nazgul         Category                 Language Feature => The
Macro Library
12-06-06 20:11 nazgul         Description Updated                          
12-06-06 20:11 nazgul         Additional Information Updated                    
======================================================================