> A simple irregular type is
> Irr a = Con a (Irr (F a))
> (as long as F uses a)
>
> The sort of instance I'm interested in is something like
> instance (Eq a,Eq (Irr (F a)) => Eq (Irr a)
> where the context only mentions (subexpressions of) type expressions
> encoutered while expanding t
On Wed, 10 Sep 2003, Ashley Yakeley wrote:
> Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
>
> > A simple irregular type is
> > Irr a = Con a (Irr (F a))
> > (as long as F uses a)
>
> Would this be an irregular type, with F as ((->) val)?
>
> data SymbolExpression sym val a = ClosedSymbolExpr
In article <[EMAIL PROTECTED]>,
Graham Klyne <[EMAIL PROTECTED]> wrote:
> > - implicit parameters
> > - template haskell
> > - FFI
> > - rank-N polymorphism (forall keyword)
> > - recursive 'do' (mdo keyword)
...
> Where do multi-parameter classes fit in?
I think some of the type exten
In article <[EMAIL PROTECTED]>,
Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
> A simple irregular type is
> Irr a = Con a (Irr (F a))
> (as long as F uses a)
Would this be an irregular type, with F as ((->) val)?
data SymbolExpression sym val a = ClosedSymbolExpression a |
OpenSymbolEx
At 13:13 10/09/03 +0100, Simon Marlow wrote:
Of course, if we change the language that is implied by -fglasgow-exts
now, we risk breaking old code :-) Would folk prefer existing syntax
extensions be moved into their own flags, or left in -fglasgow-exts for
now? I'm thinking of:
- implicit p
Hi everyone.
I've been looking at the restrictions on instances in the H98 standard
and thinking about alternatives. I would like to have a body of data type
and class/instance declarations so I can test how useful various
extensions would be. Please send or direct me to code that requires
-fallo
Hello everyone
I think I'm close to useful results on the instance restrictions.
First there's an obvious extension to the Haskell98 rule. The H98 rule
says the instance head must be a type constructor applied to type
variables, and the context must mention only those type variables. This
gives a
On Sun, 7 Sep 2003, Ashley Yakeley wrote:
> In article <[EMAIL PROTECTED]>,
> Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
>
> > Detecting circularity in a derivation is equivalent to accepting a regular
> > infinite derivation for instances. Would you have a use for irregular
> > derivation
There is no C-- backend for GHC (search the mailing list and you'll see
Simon asking someone to try to do this :P). GHC either generates code by
itself, or generates normal C code (with -fvia-c or -O2, iirc) and then
uses GCC to compile this.
On Wed, 10 Sep 2003, Graham Klyne wrote:
> In an e
In an exchange of ideas with a friend, this question arose:
[[
I've been looking at GHC, and it looks like it has generates machine code
directly rather than via C--. I know that Simon Peyton Jones (famous in the
Haskell world) is one of the authors of C--, but I can find no direct
connection betw
On Wednesday 10 September 2003 10:51, Ketil Z. Malde wrote:
> And now, let's just screw any backwards compatibility, and re-engineer
> the records system¹.
>
> I don't need any of this, and it makes my life harder. Are you guys
> going to keep at it, until I regret ever using Haskell?
I can't spe
Hal (and other interested parties):
I used Haskell to implement a model checker for a group of logics of time
and knowledge. In practice these are a bunch of extensions to the classic
CTL algorithms implemented in SMV [1].
The program itself (in terms of LOC) looks mostly like a compiler, and so
On Wednesday 10 September 2003 07:22 am, Hal Daume III wrote:
> I agree with Malcolm, with the possible addition of:
>
> keep -fglasgow-exts as it is (or, even, perhaps continue making it the
> "add all extensions keyword). also have -fffi, -farrows, -fth, etc.
> but also have, -fnoth and -fnoff
I agree with Malcolm, with the possible addition of:
keep -fglasgow-exts as it is (or, even, perhaps continue making it the
"add all extensions keyword). also have -fffi, -farrows, -fth, etc.
but also have, -fnoth and -fnoffi. that way, if a lot of us have code
that uses all the extensions ot
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> Of course, if we change the language that is implied by -fglasgow-exts now,
> we risk breaking old code :-) Would folk prefer existing syntax extensions
> be moved into their own flags, or left in -fglasgow-exts for now? I'm
> thinking of:
>
> - im
> > I also think that having backwards compatability is not much of an
> > issue. After all, ghc has introduces a number of not backward
> > compatable changes to haskell, and I never heard any complaints.
>
> Oh no?
>
> Implicit parameters: I'm sure it is a great thing, but I'd already
> us
I'm quite happy to have Haskell records remain the way they are.
I've used ML quite a lot, which of course has records without constructors.
But the problem with this is that (1) you get massive error messages;
(2) there isn't a mechanism for filling in empty slots. I don't think you
really gain
[This is a summary on the GUI discussion at the Haskell workshop/HIM,
as announced by Henrik Nilsson]
The future development of GUI libraries for Haskell
The development of Haskell applications with a graphical user interface
has long been complicated by the large number of mostly incomplete
l
> On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
> >
> > Shouldn't that rather be:
> >
> > class HasWibble a where
> > wibble :: a -> Int
> > set_wibble :: a -> Int -> a
> >
> > class HasWobble a where ...
>
> Or even:
>
> class HasWibble a b | a -> b
> [EMAIL PROTECTED] (Ketil Z. Malde) writes:
>
> > Robert Ennals <[EMAIL PROTECTED]> writes:
>
> BTW, isn't this more or less exactly what Simon suggested (at the very
> top of this thread)?
Not really, no.
I assume you mean the system suggested by Peter Thieman, outlined in the
initial email
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
>
> Shouldn't that rather be:
>
> class HasWibble a where
> wibble :: a -> Int
> set_wibble :: a -> Int -> a
>
> class HasWobble a where ...
Or even:
class HasWibble a b | a -> b where
wibble :: a -
> On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals
> <[EMAIL PROTECTED]> wrote:
>
> >class Wibble a where
> >wibble :: a -> Int
> >wobble :: a -> String
> >set_wibble :: Int -> a -> a
> >set_wobble :: String -> a -> a
> >
> >
> >data Foo = Foo {wibble :: Int, wobble :: String}
> >
[EMAIL PROTECTED] (Ketil Z. Malde) writes:
> Robert Ennals <[EMAIL PROTECTED]> writes:
BTW, isn't this more or less exactly what Simon suggested (at the very
top of this thread)?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Robert Ennals <[EMAIL PROTECTED]> writes:
[Heavy snippage, hopefully preserving semantics]
> data Foo = Foo {wibble :: Int, wobble :: String}
> deriving Wibble
> We could imagine the definition of Foo being automatically desugared to the
> following:
> data Foo = Foo Int String
> instan
On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals
<[EMAIL PROTECTED]> wrote:
>class Wibble a where
>wibble :: a -> Int
>wobble :: a -> String
>set_wibble :: Int -> a -> a
>set_wobble :: String -> a -> a
>
>
>data Foo = Foo {wibble :: Int, wobble :: String}
> deriving Wibble
>
> Yes, things are clearer and I rather like the idea. The only
> thorny issue is that the update function for field 'wibble'
> is formed from but not equal to the field name itself.
>
> In short, the magic thing would be in the 'deriving' clause:
>
> If the data type declares fields with names x_
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1, ..., x_n
an
> Hi!
>
> > So in summary, here is my proposal:
> >
> > No specific "extensible records" system.
> >
> > Define record update to be a function just like record selection is.
> >
> > Allow these functions to be in type classes.
>
> I do not understand the second and third point: As I understand
Hi!
> So in summary, here is my proposal:
>
> No specific "extensible records" system.
>
> Define record update to be a function just like record selection is.
>
> Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record sel
I'd like to add a voice of dissent here.
I would much prefer it if Haskell didn't add specific extensible records
support - even if it could be done without breaking backwards compatibility.
This is because I believe that extensible records encourage poor style. They
encourage people to expos
Johannes Waldmann <[EMAIL PROTECTED]> writes:
> What about "ad-hoc overloading" (allowing visible entities to share names,
> as long as they can be distinugished by their typing).
> This is orthogonal to the "proper records" issue (?)
> but it might improve the current situtation (?)
> and it see
What about "ad-hoc overloading" (allowing visible entities to share names,
as long as they can be distinugished by their typing).
This is orthogonal to the "proper records" issue (?)
but it might improve the current situtation (?)
and it seems backward-compatible (?)
Of course this would need an
Iavor Diatchki <[EMAIL PROTECTED]> writes:
> Adrian Hey wrote:
>> IMHO preserving the status quo wrt records should be low priority.
>> It really doesn't bother me much if new (useful) language features break
>> existing code. I think this is a better option than permanently
>> impoverishing the
On Wednesday 10 September 2003 04:54, Andrew J Bromage wrote:
> 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"
34 matches
Mail list logo
