In July 2003, a discussion in this list named locating package.conf
(http://www.haskell.org/pipermail/glasgow-haskell-users/2003-J
uly/005511.htm
l) concluded that make install on Windows is not supported. Has this
evolved since then?
No, 'make install' is still not supported on Windows,
Unpacking the attached bundle and running the following with ghc=GHC6.2
(Linux, compiled from the ghc-6.2 tag), produces the following:
# cd packagesbug
/home/ger/test/packagesbug
# CompileBug
/home/ger/test/packagesbug/package1
Chasing modules from: CompileFlags.hs
Compiling CompileFlags (
Yes, sorry about that. We'll add them shortly. (It's nice to know that
someone is using this stuff!)
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Abraham Egnor
| Sent: 26 February 2004 22:18
| To: MR K P SCHUPKE
|
[Moving to GHC users list]
There are several things that aren't research issues: notably, faster
copying, fewer intermediate lists, fewer state-monad-induced
intermediate closures. These are things that would move sharply up our
priority list if you had a real application that was stumbling on
The idea that I've been throwing around is to be able to define a
separate namespace for each type; a function can either belong in a
global (default) namespace, or belong in a particular type's
namespace. So, in the above example, instead of writing addToFM fm
..., we could instead
On 27/02/2004, at 9:51 AM, David Bergman wrote:
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular data type.
In this respect, Haskell is at a disadvantage vs most object-oriented
languages, because in them, you can write
On 27/02/2004, at 4:48 PM, Brandon Michael Moore wrote:
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote:
On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote:
1) now I have to manually declare a class definition for every single
function, and I have to declare it in advance before any module
defines
At 09:28 27/02/04 +, Simon Peyton-Jones wrote:
Which 'add' function is chosen depends on type type of 'fm'. But the
add function that is chosen in turn influences the type of the other
arguments. For example, in the call (fm.add foo), the type of 'foo' is
influenced by the choice of 'add'.
On Fri, 27 Feb 2004, Simon Peyton-Jones wrote:
The idea that I've been throwing around is to be able to define a
separate namespace for each type; a function can either belong in a
global (default) namespace, or belong in a particular type's
namespace. So, in the above example, instead
Subject: [Haskell] regular expression syntax - perl ain't got nothin on
haskell
Agreed, Perl certainly ain't got nothing on Haskell, but we could go even
further than just imitating (although better than the original) Perl
functionality. =)
Hence:
As a spin-off of another project [1], we found
Niklas Broberg wrote:
.. We came up with the idea of HaRP: Haskell Regular Patterns.
taking data and patterns as typed trees
obviously is the right thing (tm).
in principle, such patterns describe regular tree languages
(if we disregard nested data types for the moment - they give CF
languages)
In my humble opionon explicit module prefixes are a feature, which enhance
code clarity, and not something you want get rid of using rather complex
namespace extensions. However, as Alastair Reid's mail in this thread
indicates there are weaknesses in haskell's export mechanism. But these
Andre Ozone wrote:
On 27/02/2004, at 9:51 AM, David Bergman wrote:
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular
data type.
In this respect, Haskell is at a disadvantage vs most
object-oriented
13 matches
Mail list logo
