G'day all.
On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:
> but this might be an issue for others, who have to maintain "legacy" code.
You know a language has made it when we're talking about "legacy" code.
On the other hand, you have to worry about a pure declarative langua
G'day all.
On Fri, Aug 29, 2003 at 05:39:09PM -0700, Hal Daume III wrote:
> I'm attempting to get a sense of the topology of the Haskell
> community.
I used Haskell to write a compiler for the RenderMan shading language
for a former employer. Unfortunately, the compiler never shipped.
I still
G'day all.
On Wed, Aug 27, 2003 at 04:57:27PM +0100, Simon Marlow wrote:
> GHC tries to do so, but sometimes gets it wrong. See the
> -fwarn-incomplete-patterns flag. We'd appreciate it if someone could
> overhaul this code - it's been on the wish list for a long time.
As a matter of curiosity
G'day all.
On Wed, Aug 27, 2003 at 04:03:52PM +, Jonas Ritter wrote:
> >+ :: Intervall -> Intervall -> Intervall
> >(a,b) + (c,d) = (a+c,b+d)
In general this is insufficient because of floating point rounding.
The "standard" IEEE 754 rounding rule is the floating point equivalent
of roundin
G'day all.
On Wed, Aug 20, 2003 at 07:42:59AM +0200, Jan Scheffczyk wrote:
> I always thought that there is a tiny difference between "let" and "where":
They're semantically equivalent. See, for example:
http://haskell.org/onlinereport/decls.html#sect4.4.3.2
Cheers,
Andrew Bromage
___
G'day all.
On Tue, Aug 19, 2003 at 11:11:23AM +0100, Ganesh Sittampalam wrote:
> I was thinking of a situation like
>
> let x = unsafePerformIO readFooFromDB in x+x
>
> I see from your "Secrets of the GHC inliner" paper that x wouldn't be
> inlined by GHC, but it seems to me like a serious abu
G'day all.
On Sat, Aug 09, 2003 at 01:32:49AM +0200, Wolfgang Jeltsch wrote:
> ghci -fglasgow-exts -fallow-overlapping-instances compiles it without
> complaint
If it helps, ghci will complain the first time you actually try to use
it.
Cheers,
Andrew Bromage
___
G'day all.
On Mon, Jul 21, 2003 at 01:07:39PM +0200, Christian Maeder wrote:
> >>Mere overload resolution (over monomorphic types) is not NP-hard. (This
> >>is only a common misconception.)
>
> I can only repeat my above sentence.
I'm a firm believer in the maxim that the best way to find info
G'day all.
On Sat, Jul 19, 2003 at 01:52:32AM -0400, Dylan Thurston wrote:
> It's maybe easiest to think in terms of group theory with an
> action on a set: you're just distinguishing between the multiplication
> of group elements and the actual action. This distinction is not
> usually reflecte
G'day all.
On Fri, Jul 18, 2003 at 11:08:16AM +0200, Christian Maeder wrote:
> Mere overload resolution (over monomorphic types) is not NP-hard. (This
> is only a common misconception.)
No, but as you note below, the "interesting" cases are. Most
of the more interesting number-like types are p
G'day all.
On Fri, Jul 18, 2003 at 04:08:25AM -0400, Dylan Thurston wrote:
> What's wrong with that solution?
Working with these operators, I would spend a significant amount of
time getting the '<' and '>' notations right rather than writing
code. I don't like that.
For example, using the sug
G'day all.
On Thu, Jul 17, 2003 at 04:46:13PM +0100, Jon Fairbairn wrote:
> Someone mentioned multiplying by a scalar. I think this is a
> good application, but what we need is to agree (somehow) on
> the symbol used. I've used (*.) and (.*), with the dot being
> on the side the scalar is on (on
G'day all.
On Thu, Jul 17, 2003 at 05:21:47PM +0200, Christian Maeder wrote:
> Why do you outrule other useful libraries (see above). In fact ($) is
> quite cryptic (for a non-Haskeller).
Actually this gives me a perfect opportunity to rant a bit. :-)
($) is a wart, even for a Haskeller. It h
G'day all.
On Fri, Jul 11, 2003 at 04:28:19PM -0400, Dylan Thurston wrote:
> Don't be silly [...]
Never!
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
G'day all.
On Thu, Jul 10, 2003 at 11:16:56PM -0700, Ashley Yakeley wrote:
> As written, this is _not_ a good idea. Trust me, you end up having to
> put type annotations everywhere. Even (3 + 4 :: Integer) is ambiguous,
> you have to write (3 :: Integer) + (4 :: Integer).
But that's what defau
G'day all.
On Wed, Jul 09, 2003 at 05:25:20PM +0200, Jerzy Karczmarczuk wrote:
> While this is a possible solution, I would shout loudly: "Arrest this man,
> he is disrespectful wrt math!". Actually, this shows once more that the Num
> class and its relatives is a horror...
Yup.
I recently di
G'day all.
On Tue, Jul 08, 2003 at 08:56:10AM +0100, Simon Peyton-Jones wrote:
> No it does not. As the paper explains.
Serves me right for playing with the toy before I read the manual.
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECT
G'day all.
On Mon, Jul 07, 2003 at 11:23:59AM +0100, Simon Peyton-Jones wrote:
> The paper has a strongly tutorial flavour, and comes complete with a
> prototype implementation that you can play with.
Does the prototype implementation not support recursive lets?
*Main> tcs "let fix = (\
G'day.
On Tue, Jul 01, 2003 at 10:02:36AM +0200, [EMAIL PROTECTED] wrote:
> Does anybody know of a suffix tree implementation
> for Haskell? Are there algorithms for a (lazy) functional
> setting?
Yes. Take a look here:
http://www.techfak.uni-bielefeld.de/~kurtz/publications.html
Th
G'day all.
On Wed, Jun 25, 2003 at 08:48:12AM -0700, Hal Daume wrote:
> I'm not sure this is really necessary (at least syntax-wise).
Well, of course, no extension is absolutely necessary in a Turing-hard
language. :-)
For the record, here are a couple of other solutions which avoid the
problem
G'day all.
I've been toying with an idea for a small language extension, and I
was curious what you all think of this.
As a motivating example, consider the following standard typeclass:
class Bounded a where
min :: a
max :: a
This is an example of what I refer t
G'day all.
On Wed, Jun 04, 2003 at 07:31:03PM -0500, Tim Sweeney wrote:
> Conjecture: It's impossible to implement RefMonad directly in Haskell
> without making use of built-in ST or IO functionality and without unsafe or
> potentially diverging code (such as unsafeCoerce).
> Any takers?
WARNIN
G'day.
Some general advice...
On Wed, Mar 26, 2003 at 04:30:08PM -0600, Weix, Rachel Lynn wrote:
> Currently I'm having problems with type checking due to Haskell being
> a strongly typed language.
Problems with type checking are almost never caused by Haskell being
a strongly typed language.
G'day all.
On Tue, Mar 11, 2003 at 08:34:06AM +1300, Tom Pledger wrote:
> If, on the other hand, you want to vary the state type *during* a
> single monadic computation, it gets messy. You could try one of the
> following.
Very often, you just want to vary the state type for some portion
of the
G'day all.
On Mon, Mar 03, 2003 at 12:10:28PM -0500, Matthew Donadio wrote:
> This is my biggest gripe with Haskell, at least for what I do. The
> numeric class system is good, but it assumes that the sub-classes are
> distict, where in fact integers are a proper subset of reals, which
> are a p
G'day all.
On Fri, Feb 21, 2003 at 04:28:27PM -0800, Richard Nathan Linger wrote:
> What do people think about this?
> Has anyone else ever wished they had such support for unnamed sums?
I sometimes wish that Haskell did _not_ have support for unnamed
product types. To be honest, how hard is it
G'day.
On Wed, Feb 19, 2003 at 09:46:02AM -0600, Rex Page wrote:
> Here are two things I found interesting:
> 1. The author comments that programs are not theorems.
No, he argues that programming _languages_ are not theorems.
All that is required of a theorem is that it is correct.
A tool, o
G'day.
On Mon, Feb 17, 2003 at 01:44:07AM -0500, Mike T. Machenry wrote:
> I was wondering if it's better to define them as type classes with the
> operations defined in the class. What do haskellian's do?
I can't speak for other Haskellians, but on the whole, it depends.
Here's the common sit
G'day all.
On Fri, Jan 24, 2003 at 06:13:29PM -0500, Norman Ramsey wrote:
> In a fit of madness, I have agreed to deliver a 50-minute lecture
> on type classes to an audience of undergraduate students. These
> students will have seen some simple typing rules for F2 and will
> have some exposure
G'day all.
On Tue, Jan 14, 2003 at 07:13:57PM +1100, Fergus Henderson wrote:
> That's not the only problem. The other problem is that because
> `Typeable' instances aren't built-in, `fromDynamic' is not type-safe.
> The implementation of `fromDynamic' calls `typeOf' and then if the types
> match
G'day all.
On Tue, Jan 07, 2003 at 10:01:38PM -0600, Kim-Ee Yeoh wrote:
> Why can't field labels have the same name in different types?
Because it would generate two functions with the same name.
> I'm not an expert on programming languages, but doesn't it seem
> that Haskell, as a strongly-typ
G'day all.
On Wed, Jan 08, 2003 at 08:42:20AM +1100, Thomas Conway wrote:
> I'm fairly new to Haskell, but worked on Mercury until recently.
> Mercury has a type "univ" which might be declared something like:
>
> data Univ = Univ a
The equivalent would be:
data Univ = forall a. Univ a
G'day all.
On Thu, Jan 02, 2003 at 08:39:18AM +, Alastair Reid wrote:
> Please note that this is NOT TRUE!
Whoops, you're right. Sorry, my mistake.
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/l
G'day all.
On Wed, 1 Jan 2003, Andrew J Bromage wrote:
> > It has quite different performance characteristics, though. In
> > particular, this uses O(n) stack space whereas the accumulator one
> > uses O(1) stack space.
On Wed, Jan 01, 2003 at 12:17:10PM +0200, Shlomi
G'day all.
On Mon, Dec 30, 2002 at 01:47:37PM -0600, Artie Gold wrote:
> One suggestion, though is that you're working too hard; there's really
> no reason to define a locally defined function. The much simpler:
>
> long [] = 0
> long (x:xs) = 1 + long xs
>
> will do quite nicely.
It has quit
G'day all.
Just to clarify...
On Tue, Dec 03, 2002 at 12:42:21PM -0500, David Bergman wrote:
> But, design patterns are clearly overestimated as a tool for (indirect)
> code production, you are right in that.
Absolutely agreed. Design patterns are little more than:
- A common language
G'day all.
On Mon, Dec 02, 2002 at 01:05:27PM -0500, David Bergman wrote:
> It seems like all the patterns, at least the ones in the GoF's
> enumeration, can be expressed as higher-order functions and classes if
> we only would have a way to traverse a record structure dynamically. If
> someone c
G'day all.
On Mon, Dec 02, 2002 at 10:27:21AM +0100, John Hughes wrote:
> There are patterns of that sort in our programs, which we would probably
> rather call design techniques, which aren't so easily captured by a
> higher-order function definition.
As a matter of interest, _why_ would we rat
G'day all.
On Mon, Dec 02, 2002 at 08:26:06AM +0100, Johannes Waldmann wrote:
> well I love design patterns, it's just that in Haskell-land
> they are called higher-order functions, or polymorphic functions, etc.
Can I safely translate that as "We use design patterns but we don't
like the name?
G'day all.
On Thu, Nov 28, 2002 at 12:32:19PM -0500, Paul Hudak wrote:
> reminds of what I think is one of the biggest problems with conventional
> software development: the lack of appreciable mathematics in the
> specification, design, coding, or implementation of programs.
In the interest of
G'day all.
On Mon, Nov 25, 2002 at 12:19:10PM +0100, George Russell wrote:
> I have a confession to make. Andrew Bromage's list-based code is
> much faster than my array-based code. So I think I shall end up
> adapting Andrew Bromage's code, even though I do not understand it.
You mean you did
G'day all.
On Fri, Nov 22, 2002 at 05:13:07AM +1100, Fergus Henderson wrote:
> Would a Mercury version help? The Mercury distribution includes a
> Mercury version of Myer's algorithm: it's in the directory `samples/diff'.
Disclaimer: I wrote the Mercury version.
That particular algorithm heavi
G'day all.
On Thu, Oct 24, 2002 at 04:05:05PM +0100, Simon Peyton-Jones wrote:
> I definitely can't do that at this stage. I have never liked
> Float/Double/Ratio being in Enum, but there is no possibility of
> removing them now. A year or two ago, maybe.
Just to clarify: Did you mean for Hask
G'day all.
On Wed, Oct 16, 2002 at 08:40:18AM +0100, Simon Peyton-Jones wrote:
> There aren't many type constructors T for which T a is an equality
> type...
I can think of a few, like IORef. Admittedly I can't think of any that
are also monads.
Cheers,
Andrew Bromage
G'day all.
On Tue, Oct 15, 2002 at 04:47:22PM -0700, Hal Daume III wrote:
> I was wondering if anyone has a brand-spaking-new version of edison or
> anything like it. The edison docs still refer to ghc 4.06, which can't be
> good. If not, is there an edison-like project out there?
Chris Okasa
G'day all.
oOn Tue, Sep 10, 2002 at 03:39:26PM -0400, [EMAIL PROTECTED] wrote:
> I was wondering if anyone has implemented a Balanced Ternary Tree
> module for haskell.
Odd you mention that. Just about finished one myself:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hfl/hfl/edison/Assoc/
G'day all.
On Mon, Jul 29, 2002 at 02:50:55PM -0700, Hal Daume III wrote:
> I need a data structure which is a map from Ints to Doubles; the
> distribution of the Ints is in the range say 0-2 and a map will
> contain somewhere around 100-200 elements. I need to be able to query
> *very* qui
G'day all.
On Wed, Jul 31, 2002 at 04:03:46PM -0700, Hal Daume III wrote:
> I'm not afraid of math (it was my undergraduate degree) and rather enjoy
> theorems, but I'm also insanely practical and am interested in a book
> which has a large section on *efficiency*.
You might want to look throug
G'day all.
On Mon, Jul 08, 2002 at 09:21:32AM +1200, Tom Pledger wrote:
> That's a matter of opinion. It's strong in all the areas I care
> about, but someone else may find it a pain that there's no way to
> prevent a module from exporting all its evidence declarations.
It _is_ a matter of opi
G'day all.
On Thu, May 30, 2002 at 01:10:03PM +0200, Johannes Waldmann wrote:
> Python has it as well (they stole it from Haskell?)
Python's layout rule looks more like Occam's than Haskell's, to my eyes.
Aside: Was Occam the first language of the post-punched-card era to use
layout as syntax?
G'day all.
On Thu, May 16, 2002 at 11:48:58PM -0700, Ashley Yakeley wrote:
> I have a curious Haskell design pattern. It's called "one class per
> function".
When used in conjunction with fundeps, I call it "hacking C++-style
function overloading".
Sometimes I think it would be handy if the P
G'day all.
On Thu, May 16, 2002 at 07:24:10AM -0700, Simon Peyton-Jones wrote:
> I'm slowly getting around to this. Design questions:
>
> (A) I think it would be a good compromise to declare that operators
> like "+" are type *constructors* not type *variables*. So
> S+T
> would be a
G'day all.
On Wed, May 15, 2002 at 08:13:22PM +0200, [EMAIL PROTECTED] wrote:
> BTW, FP is older than OOP. So why are we so late :-) ?
I know you meant it as an offhand remark, but I think there are two
serious reasons why.
The first one is that OOP and GUIs happened at around the same time
an
G'day all.
On Wed, May 15, 2002 at 12:53:30PM +0100, Claus Reinke wrote:
> Btw, I wouldn't subscribe to Andrew's opinion that "there isn't a lot of
> functional (or even declarative) software engineering experience out
> there.".
Just to clarify: I meant to emphasise the _declarative_ part rath
G'day all.
On Tue, May 14, 2002 at 04:47:13PM -0500, Jeffrey Palmer wrote:
> Are there any options for people like me, or does my functional experience
> remain limited to the hobby* work I can squeeze in at night and on weekends?
>
> Thoughts?
The first thing you have to understand is that t
G'day all.
On Mon, May 06, 2002 at 05:54:06PM +1000, Andrew J Bromage wrote:
> Here's my humble contribution.
Oh, I should point out that this is the KMP algorithm, not the
Dijkstra one. (For all I know, they're the same, of course.)
Chee
G'day all.
On Mon, May 06, 2002 at 02:15:55PM +1000, Garner, Robin wrote:
> How you would do this in a functional implementation is another question -
> Dijkstra's example is comparing two arrays, and there may be inefficiencies
> translating it to a list-based implementation.
Here's my humble
57 matches
Mail list logo
