[Haskell-cafe] SoC Proposals?
Is there any way to propose a SoC idea right now? My account doesn't seem to have been created correctly, so I can't login to the Trac. I think it'd be interesting for a student to abstract the layout model in xmonad, separating it into an independent library. Other applications could then use this library, like Yi, for other types of tiling. I'd love to see other ideas related to Yi, too. It's a great project but on the verge of death (although the maintainer, JPB, is interested in mentoring). -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SoC Proposals?
Be sure to try your user name without any capitals - that worked for me... On Tue, Mar 16, 2010 at 6:59 PM, Jeff Wheeler j...@nokrev.com wrote: Is there any way to propose a SoC idea right now? My account doesn't seem to have been created correctly, so I can't login to the Trac. I think it'd be interesting for a student to abstract the layout model in xmonad, separating it into an independent library. Other applications could then use this library, like Yi, for other types of tiling. I'd love to see other ideas related to Yi, too. It's a great project but on the verge of death (although the maintainer, JPB, is interested in mentoring). -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SoC Proposals?
On Tue, Mar 16, 2010 at 9:32 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Be sure to try your user name without any capitals - that worked for me... The account I created is jeffwheeler -- all lowercase, no spaces -- unfortunately, so that doesn't seem to be the problem I'm hitting. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SoC Proposals?
I cannot login too. Account is mihai.maruseac. On Wed, Mar 17, 2010 at 5:37 AM, Jeff Wheeler j...@nokrev.com wrote: On Tue, Mar 16, 2010 at 9:32 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Be sure to try your user name without any capitals - that worked for me... The account I created is jeffwheeler -- all lowercase, no spaces -- unfortunately, so that doesn't seem to be the problem I'm hitting. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A proposals
wren ng thornton wrote: Another nice thing this suggests is the ability to use underscore as a pattern for when you know the compiler will infer the type but it's too complex to want to write out (e.g. while experimenting). I'd love this! M. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] A proposals
Martijn van Steenbergen wrote: wren ng thornton wrote: Another nice thing this suggests is the ability to use underscore as a pattern for when you know the compiler will infer the type but it's too complex to want to write out (e.g. while experimenting). I'd love this! F# has this and I find it very useful. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] A proposals
Hello Martijn, Monday, September 28, 2009, 1:42:10 PM, you wrote: Another nice thing this suggests is the ability to use underscore as a pattern for when you know the compiler will infer the type but it's too complex to want to write out (e.g. while experimenting). in case you not seen this and may be interested: http://okmij.org/ftp/Haskell/types.html#partial-sigs -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A proposals
Bulat Ziganshin wrote: in case you not seen this and may be interested: http://okmij.org/ftp/Haskell/types.html#partial-sigs Yes, I know there are workarounds (and I use them sometimes). It'd be nice if there was direct support for them. :-) Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A proposals
I'd like to see something resembling as-patterns in type signatures. Specifically, there are cases where I'm inclined to use (m ~ pat) in a type context when m isn't otherwise constrained, just so I can use m as an abbreviation for pat. To reduce these cases, I'd like to see the syntax m...@pat allowed for use in type signatures, with m becoming simply an alias for pat. Thoughts? I've added a ticket here http://hackage.haskell.org/trac/ghc/ticket/3545. Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A proposals
On Sun, Sep 27, 2009 at 5:29 PM, Louis Wasserman wasserman.lo...@gmail.com wrote: I'd like to see something resembling as-patterns in type signatures. Specifically, there are cases where I'm inclined to use (m ~ pat) in a type context when m isn't otherwise constrained, just so I can use m as an abbreviation for pat. To reduce these cases, I'd like to see the syntax m...@pat allowed for use in type signatures, with m becoming simply an alias for pat. Thoughts? I've added a ticket here. Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I was looking for a feature like this just the other day, for more succinctly defining a type class that made use of several associated type synonyms. Sincerely, Bradford Larsen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A proposals
Louis Wasserman wrote: I'd like to see something resembling as-patterns in type signatures. Specifically, there are cases where I'm inclined to use (m ~ pat) in a type context when m isn't otherwise constrained, just so I can use m as an abbreviation for pat. To reduce these cases, I'd like to see the syntax m...@pat allowed for use in type signatures, with m becoming simply an alias for pat. Thoughts? I've added a ticket here http://hackage.haskell.org/trac/ghc/ticket/3545. +1. I've often wanted this when doing type-level programming. Another nice thing this suggests is the ability to use underscore as a pattern for when you know the compiler will infer the type but it's too complex to want to write out (e.g. while experimenting). With x...@_ you could even share the complex type in multiple places, since x will be bound to some actual type rather than being universally quantified. (Of course, ISTR someone's suggested the underscores in the past and had it rejected. Alas.) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 function-dependancies). Is this the case? Every implementation of HList that I've seen also uses overlapping and undecidable instances. The paper about HList I have seen does explicitely say that the authors were finally able to avoid using overlapping instances. I don't know about undecidable instances but I thought (and hope very much) that they don't need them too. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 doesn't exist Why do you need setters and getters for coordinate in purely functional language? Doesn't data Coord = Coord Double Double, functional composition and monads solve problems in way better than inheritance? The most impressive feature of haskell for me, as a former OO-design patterns-UML is great programmer was that I don't have to and in fact must not use OO and inheritance and can write code that doesn't leave you guessing what exactly it is doing and what is not. And that the language forces you make good design decisions and doesn't let you make wrong ones. Inheritance is no doubt one of the most sensless solutions for code reuse i have ever seen. Yes, yes, yes! :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 are already compiled). Undecidable instances merely means the compiler is not capable of proving that the constraints terminate. In the case of an HList they obviously do (where the constraint recursion is structurally over the length of a list termination is obvious). This is more a weakness in the compiler rather than some problem with the HList code. Keean. Wolfgang Jeltsch wrote: 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 function-dependancies). Is this the case? Every implementation of HList that I've seen also uses overlapping and undecidable instances. The paper about HList I have seen does explicitely say that the authors were finally able to avoid using overlapping instances. I don't know about undecidable instances but I thought (and hope very much) that they don't need them too. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 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 heterogenous list, in my feel. record must be indexed by field name, not by type name or position ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 current HList source distribution runs in hugs with -98 +o only because of lazyness on out part. All the occurances of overlapping instances can (will?) be removed from the source if it becomes an important issue (most of them are in auxilliary definitions that are not in the paper, like Show for HList. If you program in the completely non overlapping instances model, then compiler support for deriving TTypeable would be nice, or compiler support for a type level equality constraint (TypeEq could become a built-in). But just to make it clear - compiler support for this is not necessary, you just define instances of TTypeable for all your datatypes. There is a template-haskell library that can automatically derive TTypeable for any datatype as well. Keean. David Menendez wrote: 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 HList that I've seen also uses overlapping and undecidable instances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 properties. So the above-mentioned problem would be
better handled this way:
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 of
usability. currently, my program is full of double-dereferncing, like
this:
[...]
You should never use bad design to increase usability, I'd say.
[...]
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] records proposals list
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 of
usability. currently, my program is full of double-dereferncing, like
this:
[...]
WJ You should never use bad design to increase usability, I'd say.
to be exact now i have the following definitions:
data FileInfo = FileInfo
{ fiFilteredName :: !PackedFilePath
, fiDiskName :: !PackedFilePath
, fiStoredName :: !PackedFilePath
, fiSize :: !FileSize
, fiTime :: !FileTime
, fiIsDir:: !Bool
}
-- |File to compress: either file on disk or compressed file in existing archive
data FileToCompress = DiskFile {
cfFileInfo :: FileInfo
}
| CompressedFile {
cfFileInfo :: FileInfo
, cfArcBlock :: ArchiveBlock-- Archive datablock
which contains file data
, cfPos :: FileSize-- Starting byte of
file data in datablock
, cfCRC :: CRC -- File's CRC
}
i prefer to replace second definition with the
-- |File to compress: either file on disk or compressed file in existing archive
data CompressedFile : FileInfo =
CompressedFile {
cfArcBlock :: ArchiveBlock-- Archive datablock
which contains file data
, cfPos :: FileSize-- Starting byte of
file data in datablock
, cfCRC :: CRC -- File's CRC
}
and then use procedures, written to work with FileInfo, to directly
work with CompressedFile also. now my program is full of constructs
like:
uiStartProcessing (map cfFileInfo (arcDirectory arcinfo))
let fileinfo = cfFileInfo compressed_file
and double-dereferencing about i wrote in previous letter. such change
will allow me to omit all these superfluous code. imho, new design will
be more natural and allow me to think about my algorithms instead of
implementation complications
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 }
of course this is just another sort of syntax sugar once we start
using classes to define getter/setter functions
I thought that even many OO people say that inheritance of fields is not
good practice. So why should we want to support it?
Think of it instead as being syntactic sugar for a class declaration:
class Coord a where
get_x :: a - Double
get_y :: a - Double
set_x :: Double - a - a
set_y :: Double - a - a
As I pointed out in another e-mail just sent, this kind of special syntax only
solves a very specific problem so that it's questionable whether this syntax
should be included into Haskell. However, if we manage to create a more
generalized approach, inclusion of it into the language might be quite fine.
In addition, having a line which begins with data declaring a class is
*very* misleading, in my opinion.
[...]
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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:
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 thought that even many OO people say that inheritance of fields is not
good practice. So why should we want to support it?
Think of it instead as being syntactic sugar for a class declaration:
class Coord a where
get_x :: a - Double
get_y :: a - Double
set_x :: Double - a - a
set_y :: Double - a - a
As I pointed out in another e-mail just sent, this kind of special syntax
only solves a very specific problem so that it's questionable whether
this syntax should be included into Haskell. However, if we manage to
create a more generalized approach, inclusion of it into the language
might be quite fine.
In addition, having a line which begins with data declaring a class is
*very* misleading, in my opinion.
Data lines declare instances all the time via deriving. If something like
this were implemented--and really this applies to any scheme that creates
functions to access record fields--there would need to be a set of implicit
classes for field access. To fix the namespace issue with field names, the
only two solutions (as far as I can tell) are
(a) Don't create getter or setter functions for field access. This is what
the SM proposal does.
(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 create accessor functions. (b) means a proliferation of classes, which
is perhaps more problematic, but you gain more from it--you avoid the
requirement of a special syntax for accessing fields of a record. So if
some variant of (b) is practical, I'd vote for it. I'm not attached to the
inheritance idea, but it's basically a limited form of (b).
--
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 create accessor functions. (b) means a proliferation of classes, which is perhaps more problematic, but you gain more from it I'm not sure it's all that bad if we can avoid namespace pollution? -- [EMAIL PROTECTED] Performance anxiety leads to premature optimisation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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). So you can do this now... with reasonable syntax, for example to create an extensible record (some thing .*. (27 :: Int) .*. True .*. HNil) is a statically typed anonymous record. In other words there is no need for any more extensions to GHC or Hugs to implement Records (although having a type-level type-equality constaint would simplify the internal implementation of the library)... For details see the HList paper: http://homepages.cwi.nl/~ralf/HList/ Regards, Keean. Bulat Ziganshin wrote: Hello Haskell, can anyone write at least the list of record proposals for Haskell? or, even better, comment about pros and contras for each proposal? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] records proposals list
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 heterogenous list, in my feel. record must be indexed by field name, not by type name or position -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] records proposals list
I certainly agree with Keean. It's just that the given example is a bit misleading. As Bulat observed, the example is about a heterogeneous list, as opposed to a record. But there are of course tons of record examples to be found, if you follow the HList link. Ralf P.S.: The HList paper also has a reasonable related work section, which might hold more information of the kind that Bulat asked for. -Original Message- From: [EMAIL PROTECTED] [mailto:haskell-cafe- [EMAIL PROTECTED] On Behalf Of Keean Schupke Sent: Monday, November 21, 2005 7:56 AM To: Bulat Ziganshin Cc: 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). So you can do this now... with reasonable syntax, for example to create an extensible record (some thing .*. (27 :: Int) .*. True .*. HNil) is a statically typed anonymous record. In other words there is no need for any more extensions to GHC or Hugs to implement Records (although having a type-level type-equality constaint would simplify the internal implementation of the library)... For details see the HList paper: http://homepages.cwi.nl/~ralf/HList/ Regards, Keean. Bulat Ziganshin wrote: Hello Haskell, can anyone write at least the list of record proposals for Haskell? or, even better, comment about pros and contras for each proposal? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 with a common field. 5. Setters as functions. 6. Anonymous records. 7. Unordered records. Personally, I would quite like to have first-class labels. By this I mean the ability to pass record labels as arguments, and to return them as results. With this one generalisation, it would be possible to cover most of the wishlist above. A generic getter and setter could be defined simply as polymorphic functions e.g. get :: Label n - Record (n::a | r) - a set :: Label n - a - Record r - Record (n::a | r) upd :: Label n - (a-a) - Record (n::a | r) - Record (n::a | r) You could even define your own preferred syntactic sugar for these operations e.g. r . l = get l r .. and the higher-order uses fall out for free map (get foo) listOfRecords There are several proposals incorporating this idea. Oleg Kiselyov and Ralf Lämmel, Haskell's overlooked object system http://homepages.cwi.nl/~ralf/OOHaskell/ Daan Leijen, First-class labels for extensible rows http://www.cs.uu.nl/~daan/pubs.html Benedict Gaster and Mark Jones, A Polymorphic Type System for Extensible Records and Variants http://www.cse.ogi.edu/~mpj/pubs/polyrec.html Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 in purely functional language? Doesn't data Coord = Coord Double Double, functional composition and monads solve problems in way better than inheritance? The most impressive feature of haskell for me, as a former OO-design patterns-UML is great programmer was that I don't have to and in fact must not use OO and inheritance and can write code that doesn't leave you guessing what exactly it is doing and what is not. And that the language forces you make good design decisions and doesn't let you make wrong ones. Inheritance is no doubt one of the most sensless solutions for code reuse i have ever seen. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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), or somehow stick the field labels into classes. I found that problem more annoying when starting with Haskell. But since I do now try to define only one data type per module, equal field names don't collide so easy anymore. It remains the inconvenience that field names must be qualified with the module name rather than the record variable name. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 HList that I've seen also uses overlapping and undecidable instances. -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] records proposals list
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 a function.
DR 3. Safe getters for multi-constructor data types.
DR 4. Getters for multiple data types with a common field.
DR 5. Setters as functions.
DR 6. Anonymous records.
DR 7. Unordered records.
DR Argh. When I think about records too long I get dizzy.
really you are wrote solutions for all these problems (except 6), and
it's just an additional syntax sugar (like the fields itself). for
beginning, we must split this list to two parts: belonging to static
(like H98) and dynamic (anonymous) records. items in your list
(except 6) belongs to static ones. dynamic records is whole different
beast and it's really hard to master, so the first question will be:
are we wanna to have in Haskell only static records, only dynamic
records or both?
as i see, GHC team want to implement such proposal, which will
resolve both issues. and wainting (waiting+wanting:) for such
solution, they are don't implement suggestions which address only
static records problems
but the dynamic records is too complex thing: it may be syntactically
incompatible with H98, it may require changes to GHC internals and so
on, so they are delayed until better times
besides this all, i want to add one more item to your list:
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
Please take a look at the recent paper by Daan Leijen
(http://www.cs.uu.nl/~daan/pubs.html#scopedlabels). I think this would
solve the mentioned problems and has the additional advantage of
supporting anonymous records. The author claims his proposal to be
integrable with most known type systems.
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 thought that even many OO people say that inheritance of fields is not good
practice. So why should we want to support it?
A point is not a special coordinate pair. Instead it has a coordinate paar as
one of its properties. So the above-mentioned problem would be better
handled this way:
data Coord { x, y :: Double }
data Point = Point {coord :: Coord, c :: Color }
[...]
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] records proposals list
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
WJ handled this way:
WJ data Coord { x, y :: Double }
WJ 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 of
usability. currently, my program is full of double-dereferncing, like
this:
if (fiTime (cfFileInfo arcfile) = fiTime (cfFileInfo diskfile))
maximum (last_time' : map (fiTime.cfFileInfo) dir)
let size = fiSize (cfFileInfo cfile')
bytes = sum$ map (fiSize.cfFileInfo) directory
let keyFunc = fiStoredName . cfFileInfo
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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 the issues that seem important to me, but I am sure my list
isn't complete. Also note that some of these goals may be mutually
contradictory, but agreeing on the problems might help in agreeing on the
solutions.
A getter is a way to get a field out of a record, a setter is a way to
update a field in a record. These may be either pattern-matching syntaxes,
functions or some other odd syntax.
Here's the quick summary, expanded below:
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 with a common field.
5. Setters as functions.
6. Anonymous records.
7. Unordered records.
2. Multi-constructor getters.
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), or somehow stick the field labels into classes.
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 :: String }
However we access name, we should be able to access it from either
constructor easily (as Haskell 98 does, and we'd like to keep this).
3. Safe getters for multi-constructor data types.
Getters ought to be either safe or explicitly unsafe when only certain
constructors of a data type have a given field (this is my pet peeve):
data FooBar = Foo { foo :: String } | Bar { bar :: String }
This shouldn't automatically generate a function of type
foo :: FooBar - String
which will fail when given a FooBar of the Bar constructor. We can always
write this function ourselves if we so desire.
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
namespace issue, since if we are going to define getters and setters as
functions, we either need unique field labels or we need one class per
field label--or something equivalent to a class for each field label.
5. Setters as functions.
It would be nice to have a setter function such as (but with perhaps a
better name)
set_foo :: String - Foo - Foo
be automatically derived from
data Foo = Foo { foo :: String }
in the same way that in Haskell 98 foo :: Foo - String is implicitely
derived.
Note that this opens up issues of safety when you've got multiple
constructors, and questions of how to handle setting of a field that isn't
in a particular datum.
6. Anonymous records.
This idea is from Simon PJ's proposal, which is that we could have
anonymous records which are basically tuples on steroids. Strikes me as a
good idea, but requires that we address the namespace question, that is,
whether field labels share a namespace with functions. In Simon's
proposal, they don't.
This is almost a proposal rather than an issue, but I think that it's a
worthwhile idea in its own right.
7. Unordered records.
I would like to have support for unordered records, which couldn't be
matched or constructed by field order, so I could (safely) reorder the
fields in a record. This is really an orthogonal issue to pretty much
everything else.
Argh. When I think about records too long I get dizzy.
--
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals 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 :: String }
However we access name, we should be able to access it from either
constructor easily (as Haskell 98 does, and we'd like to keep this).
Let's take a concrete example. Say, I have a type Address which is declared
as follows:
data Address = OrdinaryAddr {
name :: String,
street :: String,
number :: Int,
city :: String,
postalCode :: Int
} | POBoxAddr {
name :: String,
poBox :: Int,
city :: String,
postalCode :: Int
}
In this example, it would be really good if there was a getter function for
extracting the name out of an ordinary address as well as an PO box address.
But in my opinion, the above declaration is not very nice and one should
write the following instead:
data Address = Address {
name :: String,
destination :: Destination,
city :: String,
postalCode :: Int
}
data Destination = OrdinaryDest {
street :: String,
number :: Int
} | POBoxDest {
poBox :: Int
}
And with this declaration we wouldn't need getter functions which are able to
access identically-named fields from different data constructors of the same
type. So I wonder if this feature is really sensible.
[...]
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] records proposals list
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.
DR 4. Getters for multiple data types with a common field.
DR 5. Setters as functions.
DR 6. Anonymous records.
DR 7. Unordered records.
DR Argh. When I think about records too long I get dizzy.
really you are wrote solutions for all these problems (except 6), and
it's just an additional syntax sugar (like the fields itself). for
beginning, we must split this list to two parts: belonging to static
(like H98) and dynamic (anonymous) records. items in your list (except
6) belongs to static ones. dynamic records is whole different beast
and it's really hard to master, so the first question will be:
are we wanna to have in Haskell only static records, only dynamic
records or both?
as i see, GHC team want to implement such proposal, which will resolve
both issues. and wainting (waiting+wanting:) for such solution, they
are don't implement suggestions which address only static records
problems
but the dynamic records is too complex thing: it may be syntactically
incompatible with H98, it may require changes to GHC internals and so
on, so they are delayed until better times
besides this all, i want to add one more item to your list:
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
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] records proposals list
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
namespace issue, since if we are going to define getters and setters as
functions, we either need unique field labels or we need one class per
field label--or something equivalent to a class for each field label.
This is a problem similar to one I had to solve for HSFFIG to design a
syntax to access fields of C structures (where different structures may
have fields of same name but of different types).
I ended up with a multiparameter class parameterized by a C structure
name, field name, field type, and for each occurrence of these in C
header file I autogenerated an instance of this class.
See
http://hsffig.sourceforge.net/repos/hsffig-1.0/_darcs/current/HSFFIG/FieldAccess.hs
for the class itself, and a typical instance (autogenerated of course)
looked like
instance HSFFIG.FieldAccess.FieldAccess S_362 ((CUChar)) V_byteOrder where
z -- V_byteOrder = ((\hsc_ptr - peekByteOff hsc_ptr 0)) z
{-# LINE 5700 XPROTO_H.hsc #-}
(z, V_byteOrder) -- v = ((\hsc_ptr - pokeByteOff hsc_ptr 0)) z v
{-# LINE 5701 XPROTO_H.hsc #-}
for a field `byteOrder' of type `unsigned char'.
This might work in general for what is proposed in the item 4 quoted
above. A class with 3 parameters will be needed, and perhaps some
syntactic sugar to autogenerate it and its instances. The only downside
is GHC needs too much memory to compile all this: I had to add a
splitter utility to HSFFIG otherwise GHC failed short of memory on even
several tens of C structures.
Dimitry Golubovsky
Middletown, CT
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
