Am Dienstag, 22. November 2005 07:33 schrieb David Menendez:
Keean Schupke writes:
Haskell already has static records (in H98)
Dynamic records are addressed by the HList library, which uses
extensions already present in GHC and Hugs (namely Multi-parameter
type-classes and
Am Montag, 21. November 2005 20:34 schrieb Max Eronin:
On 11/21/05, David Roundy [EMAIL PROTECTED] wrote:
class Coord a where
get_x :: a - Double
get_y :: a - Double
set_x :: Double - a - a
set_y :: Double - a - a
I'd say this is a typical OO solution to the problem that
The HList code does not need overlapping-instances, however it does use
undecidable
instances. This is not however bad like overlapping instances is.
Overlapping instances
can break module independance (as in defining a new instance can change
the meaning
of an existing class in modules that
My mistake, what you want is:
( mything .=. something
.*. value .=. (27::Int)
.*. logic .=. True
.*. HNil )
Admittedly the label creation would benefit from some syntactic sugar to
reduce typing...
Keean.
Bulat Ziganshin wrote:
Hello Keean,
Monday, November 21, 2005, 6:56:06
Just a follow up to my last post ... The HList paper also presents a way of
removing overlapping instances from _any_ class. So infact support for
overlapping
instances is no longer required - and this removes all the messy
problems with
overlapping instances and functional dependancies.
The
Am Montag, 21. November 2005 08:31 schrieb Bulat Ziganshin:
Hello Wolfgang,
Sunday, November 20, 2005, 6:21:05 PM, you wrote:
data Coord = { x,y :: Double }
data Point : Coord = { c :: Color }
A point is not a special coordinate pair. Instead it has a coordinate
paar as one of its
Hello Wolfgang,
Monday, November 21, 2005, 1:30:10 PM, you wrote:
data Coord { x, y :: Double }
data Point = Point {coord :: Coord, c :: Color }
because this allows a large number of procedures written to work with
Coord, to automatically work with Point. iy just a matter
Am Montag, 21. November 2005 14:27 schrieb David Roundy:
On Sun, Nov 20, 2005 at 04:21:05PM +0100, Wolfgang Jeltsch wrote:
Am Samstag, 19. November 2005 17:35 schrieb Bulat Ziganshin:
7. OOP-like fields inheritance:
data Coord = { x,y :: Double }
data Point : Coord = { c :: Color }
On Mon, Nov 21, 2005 at 02:48:48PM +0100, Wolfgang Jeltsch wrote:
Am Montag, 21. November 2005 14:27 schrieb David Roundy:
On Sun, Nov 20, 2005 at 04:21:05PM +0100, Wolfgang Jeltsch wrote:
Am Samstag, 19. November 2005 17:35 schrieb Bulat Ziganshin:
7. OOP-like fields inheritance:
On Mon, 21 Nov 2005, David Roundy wrote:
(b) Create some sort of class that allows getter and/or setter functions
for field access.
(a) involves the creation of a non-function syntax for something that is
essentially a function--and means you'll need boiler-plate code if you want
to
Hi,
Haskell already has static records (in H98)
Dynamic records are addressed by the HList library, which uses
extensions already present in GHC and Hugs (namely Multi-parameter
type-classes and function-dependancies).
So you can do this now... with reasonable syntax, for example
Hello Keean,
Monday, November 21, 2005, 6:56:06 PM, you wrote:
KS So you can do this now... with reasonable syntax, for example to
KS create an extensible record
KS (some thing .*. (27 :: Int) .*. True .*. HNil)
KS is a statically typed anonymous record.
it is not record, but
: Haskell Cafe
Subject: Re: [Haskell-cafe] records proposals list
Hi,
Haskell already has static records (in H98)
Dynamic records are addressed by the HList library, which uses
extensions already present in GHC and Hugs (namely Multi-parameter
type-classes and function-dependancies
David Roundy [EMAIL PROTECTED] writes:
I'd benefit from just a list of problems that the record proposals want to
solve.
1. The field namespace issue.
2. Multi-constructor getters, ideally as a function.
3. Safe getters for multi-constructor data types.
4. Getters for multiple data types
On 11/21/05, David Roundy [EMAIL PROTECTED] wrote:
class Coord a where
get_x :: a - Double
get_y :: a - Double
set_x :: Double - a - a
set_y :: Double - a - a
I'd say this is a typical OO solution to the problem that doesn't exist
Why do you need setters and getters for coordinate
On Sat, 19 Nov 2005, David Roundy wrote:
1. Field namespace issue:
Field names should not need to be globally unique. In Haskell 98, they
share the function namespace, and must be unique. We either need to make
them *not* share the function namespace (which means no getters as
functions),
Keean Schupke writes:
Haskell already has static records (in H98)
Dynamic records are addressed by the HList library, which uses
extensions already present in GHC and Hugs (namely Multi-parameter
type-classes and function-dependancies).
Is this the case? Every implementation of
On Saturday 19 November 2005 17:35, Bulat Ziganshin wrote:
Hello David,
Saturday, November 19, 2005, 4:57:09 PM, you wrote:
DR I'd benefit from just a list of problems that the record
proposals want to DR solve.
DR 1. The field namespace issue.
DR 2. Multi-constructor getters, ideally as
Am Samstag, 19. November 2005 17:35 schrieb Bulat Ziganshin:
[...]
7. OOP-like fields inheritance:
data Coord = { x,y :: Double }
data Point : Coord = { c :: Color }
of course this is just another sort of syntax sugar once we start
using classes to define getter/setter functions
I
Hello Wolfgang,
Sunday, November 20, 2005, 6:21:05 PM, you wrote:
data Coord = { x,y :: Double }
data Point : Coord = { c :: Color }
WJ A point is not a special coordinate pair. Instead it has a coordinate paar
as
WJ one of its properties. So the above-mentioned problem would be better
On Fri, Nov 18, 2005 at 05:42:41PM +0300, Bulat Ziganshin wrote:
can anyone write at least the list of record proposals for Haskell?
or, even better, comment about pros and contras for each proposal?
I'd benefit from just a list of problems that the record proposals want to
solve.
I can list
Am Samstag, 19. November 2005 14:57 schrieb David Roundy:
[...]
2. Multi-constructor getters, ideally as a function:
An accessor ought to be able to access an identically-named field from
multiple constructors of a given data type:
data FooBar = Foo { name :: String } | Bar { name ::
Hello David,
Saturday, November 19, 2005, 4:57:09 PM, you wrote:
DR I'd benefit from just a list of problems that the record proposals want to
DR solve.
DR 1. The field namespace issue.
DR 2. Multi-constructor getters, ideally as a function.
DR 3. Safe getters for multi-constructor data types.
David Roundy wrote:
4. Getters for multiple data types with a common field.
[skip]
4. Getters for multiple data types with a common field.
This basically comes down to deriving a class for each named field, or
something equivalent to it, as far as I can tell. This also works with the
24 matches
Mail list logo