| From: Ross Paterson [mailto:[EMAIL PROTECTED]
|
| On Thu, Mar 04, 2004 at 09:21:23AM -, Simon Peyton-Jones wrote:
| My personal view is this: we should have adopted the ML view of
records.
| It solves the immediate problem, and no more elaborate scheme seems
| sufficiently right to be
Conor McBride wrote:
[...]
There's a catch, of course. When you write
r | e
you give the typechecker no clue as to the type of r: it just
has to infer the type of r and hope it's a datatype.
This is reminiscent of an issue I encountered a year or so ago, when
designing a language. The main
| detail, of course ;). What I'm secretly hoping is that the
| GHC/hugs/HBC people will see what I'm trying to achieve, tell me I'm
| totally nuts, and then suggest an alternative, much simpler approach
| which gives us exactly the same goal ...
As I implied earlier, I am thus far unconvinced
| So there is no sub-typing, no row polymorphism, no attempt to give
| f r = r.x
| a fancy type that makes f applicable to any record with an x field.
|
| On the other hand, there is also no problem with many records having
the
| same field name either, which is the problem we started with.
Simon Peyton-Jones wrote:
If the big bug-bear is record selectors, let's focus on them
exclusively. I now think that ML got it right. ML records are simply
labelled tuples.
Note that this is true only for SML, not for Caml.
So just as (Bool,Int) is an anonymous type, so is
{x::Bool, y::Int}.
Simon Peyton-Jones wrote:
| Actually, #l is just syntactic sugar for (\{l=x,...}-x), which
implies
| that you might need type annotations.
Yes I was wrong to say that there are no implicitly-defined record
selectors; (#l r) is exactly that. Syntactically I'd prefer (r.l); but
regardless, it's a
On Thu, Mar 04, 2004 at 09:21:23AM -, Simon Peyton-Jones wrote:
My personal view is this: we should have adopted the ML view of records.
It solves the immediate problem, and no more elaborate scheme seems
sufficiently right to be declared the winner.Alas, like all other
proposals, it's
Hi
While we're talking about SML, I think there are a few other things
worth stealing...
1) I still miss multiline pattern matching in lambda
(fn p1 = e1 | p2 = e2 | ...)
not strictly necessary, but often less disruptive of the text than
either a let/where-introduced helper-function or \ x
On 28/02/2004, at 1:30 AM, Per Larsson wrote:
In my humble opionon explicit module prefixes are a feature, which
enhance
code clarity, and not something you want get rid of using rather
complex
namespace extensions. However, as Alastair Reid's mail in this thread
indicates there are weaknesses
Simon Peyton-Jones wrote:
In Haskell today, you can at least tell what value is bound to each
identifier in the program, *without* first doing type checking.
I'm afraid I'm confused. In the following code
data Z
data S a
class Card c where c2int:: c - Int
instance Card Z where c2int _
| In Haskell today, you can at least tell what value is bound to each
| identifier in the program, *without* first doing type checking.
|
| I'm afraid I'm confused. In the following code
|
| data Z
| data S a
|
| class Card c where c2int:: c - Int
|
| instance Card Z where c2int _ = 0
|
The idea that I've been throwing around is to be able to define a
separate namespace for each type; a function can either belong in a
global (default) namespace, or belong in a particular type's
namespace. So, in the above example, instead of writing addToFM fm
..., we could instead
On 27/02/2004, at 9:51 AM, David Bergman wrote:
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular data type.
In this respect, Haskell is at a disadvantage vs most object-oriented
languages, because in them, you can write
On 27/02/2004, at 4:48 PM, Brandon Michael Moore wrote:
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote:
On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote:
1) now I have to manually declare a class definition for every single
function, and I have to declare it in advance before any module
defines
At 09:28 27/02/04 +, Simon Peyton-Jones wrote:
Which 'add' function is chosen depends on type type of 'fm'. But the
add function that is chosen in turn influences the type of the other
arguments. For example, in the call (fm.add foo), the type of 'foo' is
influenced by the choice of 'add'.
On Fri, 27 Feb 2004, Simon Peyton-Jones wrote:
The idea that I've been throwing around is to be able to define a
separate namespace for each type; a function can either belong in a
global (default) namespace, or belong in a particular type's
namespace. So, in the above example, instead
In my humble opionon explicit module prefixes are a feature, which enhance
code clarity, and not something you want get rid of using rather complex
namespace extensions. However, as Alastair Reid's mail in this thread
indicates there are weaknesses in haskell's export mechanism. But these
Andre Ozone wrote:
On 27/02/2004, at 9:51 AM, David Bergman wrote:
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular
data type.
In this respect, Haskell is at a disadvantage vs most
object-oriented
David Bergman [EMAIL PROTECTED] writes:
| The idea that I've been throwing around is to be able to define a
| separate namespace for each type; a function can either belong in a
| global (default) namespace, or belong in a particular type's
| namespace. So, in the above example, instead
I've had an idea stewing in my head to do with per-type function
namespaces, that the current module namespace discussion reminded me
about. The problem is that there is a limited namespace for functions,
so that if you define a new data type, it is unwise to call functions
which work on that
I've had an idea stewing in my head to do with per-type function
namespaces, that the current module namespace discussion reminded me
about. The problem is that there is a limited namespace for functions,
so that if you define a new data type, it is unwise to call functions
which work on
On 27/02/2004, at 3:47 AM, Keith Wansbrough wrote:
I've had an idea stewing in my head to do with per-type function
namespaces, that the current module namespace discussion reminded me
about. The problem is that there is a limited namespace for
functions,
so that if you define a new data type,
I think that this is a problem that can be solved with a simple convention
change, rather than a language extension - instead of appending type
names, I think it would be much better if modules simply used the short,
convenient, common names and expected the user to import them qualified
where
On 27/02/2004, at 8:28 AM, Abraham Egnor wrote:
I think that this is a problem that can be solved with a simple
convention
change, rather than a language extension - instead of appending type
names, I think it would be much better if modules simply used the
short,
convenient, common names and
Mr. Ozone wrote:
[snip]
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular data type.
In this respect, Haskell is at a disadvantage vs most object-oriented
languages, because in them, you can write x.add, and the
Gabriel wrote:
| This overloading by namespace is usually called either ADL
| (Argument-Dependent Lookup) or Koenig Lookup (especially in C++.)
Actually in C++, it is called argument dependent name
lookup, and that is the way the C++ definition text calls
it. As Andy Koenig has himself
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote:
On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote:
1) now I have to manually declare a class definition for every single
function, and I have to declare it in advance before any module defines
that function (most serious problem; see below),
2)
On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote:
For example, say I'm writing the Data.Complex module; there's a
function in that module phase :: RealFloat a = Complex a - a. So,
how do you put this phase function into a type class? Perhaps you
could abstract away from the RealFloat and
Hello!
So, how can you come up with a type class which provides a polymorphic
'add' function, considering you don't even know how many parameters
each data type's individual add function uses?
Very easily: every Haskell function takes only one
argument. Always. Ever.
For example, say I'm
[EMAIL PROTECTED] writes:
addToFM :: Ord key = FiniteMap key elt - key - elt - FiniteMap key
elt
addToSet :: Ord a = Set a - a - Set a
So, how can you come up with a type class which provides a
polymorphic 'add' function, considering you don't even know how many
parameters each data
30 matches
Mail list logo
