Cale Gibbard writes:
> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure. Indeed, it's becoming common to type the result of some
(In reply to
http://www.haskell.org/pipermail/haskell/2005-December/017109.html
)
One of the key things about those nested monads is that
*often* you
don't have to write things like
return $ throwError msg
but can simply write
throwError msg
because the nest has all the features of its
On Mon, Dec 26, 2005 at 06:45:09PM +0100, Niklas Sorensson wrote:
> That's what I thought. But I'm still curious when it is used, and why
> it isn't a suitable solution for unboxed polymorhic functions in most
> cases.
I always thought A nice extension would be to allow polymorphic
functions that
On Wed, Jan 04, 2006 at 08:55:39AM -0500, David Roundy wrote:
> Ah, good point, I hadn't thought about that. My proposal was to keep
> record updates which would indeed mean that we'd need to require that all
> "foo"s in a given data type have the same type. Which I don't think is a
> bad thing e
G'day all.
I wrote:
> > My feeling is that do { p <- xs; return e } should behave identically
> > (modulo the precise error message if the pattern match fails) to
> > map (\p -> e) xs. Your proposal would make it into a map/filter
> > hybrid.
Which, of course, it is now. I blame lack of caffei
what type would
f x = x { foo = "hello" }
have if there were multiple types with 'foo' as a field name?
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
It seems to me that trac is mainly about the various 'fptools' projects
and hawiki is about haskell topics in general.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo
Am Mittwoch, 4. Januar 2006 22:30 schrieb [EMAIL PROTECTED]:
> [...]
> Though possible "mchoose" might be more appropriate.
These leading m's are not nice in my opinion.
> Even more appropriate might be to rationalise some of these naming
> conventions.
Yes, we should remove those m's and use q
On 04/01/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> G'day Cale.
>
> Quoting Cale Gibbard <[EMAIL PROTECTED]>:
>
> > I personally feel that the inclusion of 'fail' in the Monad class is
> > an ugly solution to the problem of pattern matching, and gives the
> > incorrect impression that monad
Am Mittwoch, 4. Januar 2006 21:54 schrieb Cale Gibbard:
> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure.
I totally agree!
> [
G'day Cale.
Quoting Cale Gibbard <[EMAIL PROTECTED]>:
> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure.
So do I.
> We ought
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have some builtin notion of
failure. Indeed, it's becoming common to type the result of some
function in an arbitrary monad
On Wed, Jan 04, 2006 at 09:12:42PM +0200, Krasimir Angelov wrote:
> The point isn't in the amount of coding but in the performance. It
> isn't required to build intermediate data structures.
Well, you've got intermediate data structures in HSQL. In particular,
each column access must traverse an
On 2006-01-04, Krasimir Angelov <[EMAIL PROTECTED]> wrote:
>> I use ForeignPtrs everywhere in HDBC to try to make sure that nothing
>> like this happens, and also that The Right Thing happens if a database
>> handle gets garbage collected without being explicitly closed first.
>
> I prefer not to r
The point isn't in the amount of coding but in the performance. It
isn't required to build intermediate data structures.
2006/1/4, John Goerzen <[EMAIL PROTECTED]>:
> On 2006-01-04, John Goerzen <[EMAIL PROTECTED]> wrote:
> > It's probably the same amount of coding either way:
> >
>
> [hsql-esque
On 2006-01-04, John Goerzen <[EMAIL PROTECTED]> wrote:
> It's probably the same amount of coding either way:
>
[hsql-esque example]
> fetch sth
> h1 <- get sth "col1"
> h2 <- get sth "col2"
> func h1 h2
I should add that yet another option with HDBC is:
l colname colmap = Map.lookup colname col
2006/1/4, John Goerzen <[EMAIL PROTECTED]>:
> After looking at the code again, it's possible that it's because you're
> never calling pqClear on the result set. So the results returned by
> PostgreSQL linger in memory forever.
Right! This was a bug. It is fixed now. Thanks.
> I did have memory i
Hello,
On 1/4/06, David Roundy <[EMAIL PROTECTED]> wrote:
> > What happens to record updates?
> >
> > setFoo x r = r { foo = x }
> >
> > Or is the proposal to remove updates as well?
>
> Ah, good point, I hadn't thought about that. My proposal was to keep
> record updates which would indeed mean
On 2006-01-04, Krasimir Angelov <[EMAIL PROTECTED]> wrote:
>> I also had extremely high memory usage when dealing with large result
>> sets -- somewhere on the order of 700MB; the same consumes about 12MB
>> with HDBC. My guess from looking briefly at the code is that the entire
>> result set is b
On 2006-01-04, David Roundy <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 04, 2006 at 02:17:27PM +, John Goerzen wrote:
> Haskell 98 already requires you to code up set* functions (provided you
> want them), so I'd only be doubling the amount of work you need to do. If
> you can get by with the exi
On 2006-01-04, Krasimir Angelov <[EMAIL PROTECTED]> wrote:
> 2006/1/4, John Goerzen <[EMAIL PROTECTED]>:
>> The final thing that prompted me to do this was that the PostgreSQL --
>> and possibly the Sqlite -- module for HSQL was segfaulting. I spent
>> quite a bit of time with gdb and the HSQL cod
On Tue, Jan 03, 2006 at 08:25:01PM -0500, Dylan Thurston wrote:
> On Mon, Jan 02, 2006 at 08:43:56AM -0500, David Roundy wrote:
> > data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
> >
> > desugars to something like
> >
> > data FooBar = Foo Int | FooBar Int Int
> >
> > foo
On Wed, Jan 04, 2006 at 02:17:27PM +, John Goerzen wrote:
> On 2006-01-02, David Roundy <[EMAIL PROTECTED]> wrote:
> > My proposal is simply to remove the automatic declaration of accessor
> > functions. In Haskell 98,
> >
> > data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: In
On 2006-01-02, David Roundy <[EMAIL PROTECTED]> wrote:
> My proposal is simply to remove the automatic declaration of accessor
> functions. In Haskell 98,
>
> data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
I would find this to be incredibly annoying. The fact that these
a
On Wed, Jan 04, 2006 at 11:53:59AM +0100, Ulf Norell wrote:
>
> On Jan 4, 2006, at 2:25 AM, Dylan Thurston wrote:
>
> >On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
> >>David Roundy wrote:
> >>>On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
> >One open quest
On Jan 4, 2006, at 2:25 AM, Dylan Thurston wrote:
On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
David Roundy wrote:
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
One open question (in my mind) would be whether we'd allow
data Foo = FooInt { foo :: Int } |
26 matches
Mail list logo
