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
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
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.
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
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.
___
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
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
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.
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
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
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
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
35 matches
Mail list logo
