Bugs item #1223893, was opened at 2005-06-20 04:47
Message generated for change (Settings changed) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1223893group_id=8032
Please note that this message will contain a full copy of the comment
Bugs item #1226252, was opened at 2005-06-23 16:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1226252group_id=8032
Please note that this message will contain a full copy of
Bugs item #1226252, was opened at 2005-06-23 16:23
Message generated for change (Comment added) made by malaire
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1226252group_id=8032
Please note that this message will contain a full copy of the comment
Who knows, please, where there are explained
hierarchical module names?
Is this a matter of Haskell-98 or of GHC ?
I looked into both of them (and also a bit into [EMAIL PROTECTED])
but could not find a basic explanation of the point, somehow missed.
Suppose that my user package called
I build a recent 6.4 stable branch snapshot on Linux/x86-64 (ie amd64)
today. Since several people expressed interest in it I just uploaded
it as binary dist tarball to:
http://haskell.org/~petersen/ghc-6.4.1.20050620-x86_64-unknown-linux.tar.gz
I'm happy to say with this gtk2hs now
Hi,
I am trying to make an unregisterised build. As my host machine, i use
a Mac running Mac OS X 10.4. When building ghc 6.2.2 on the host
machine (also running GHC 6.2.2), i get the error attached below
when doing 'make all' in ghc/. Does anyone
have an idea how to solve this ?
thanks,
Jim Apple wrote:
I'm having an IO speed problem. I need to input a long string of known
length and process it with a foldl. getLine and foldl take way too long;
is there a known faster way?
Use hGetContents and fold', the strict version of fold (It then takes
about 70 seconds to sum 18 megs of
Hello Andrew,
Thursday, June 23, 2005, 5:38:03 AM, you wrote:
AW To handle the problem of drawing all shapes, in c++, I would have a list
AW of shape pointers:
AW struct shape{ virtual void draw(...);};
AW struct circle : public shape {...};
AW struct square : public shape {...};
AW
Bulat,
Bulat wrote:
just create list of draw functions itself:
[drawCircle (10,10) 5, drawSquare (20,20) 10]
No! the exercise is about lists of shapes
not lists of results of drawing shapes.
This is clearly a major difference.
Bulat wrote:
for more complex tasks - declare interface as a
G'day all.
Thursday, June 23, 2005, 5:38:03 AM, you wrote:
To handle the problem of drawing all shapes, in c++, I would have a list
of shape pointers:
struct shape{ virtual void draw(...);};
struct circle : public shape {...};
struct square : public shape {...};
std::listshape * shapes;
Andrew,
you are circumventing the hard problem!
(Even though I am sure you just forgot to mention it.)
That is, the question is about drawing a *list* of shapes.
As correctly observed by Rathman ages back, one naturally
ends up with existential quantification when simulating
dynamic binding.
Andrew Ward wrote:
In Simon Thompson's The Craft of Functional Programming Second Edition,
page 226, it is mentioned that Laufer (1996) describes a Haskell
extension to allow dynamic binding. I was wondering if this has been
implemented as an extension in any of the haskell compilers, or
Hi all,
It looks like there's been a bit of recent discussion regarding module
and package namespaces. There is a certain possible design feature
that I don't think has been mentioned yet, that I think would be very
helpful, so I thought I should at least bring it up.
What I want is to be able
Andreas Rossberg:
Andreas R. wrote:
dynamic binding is just the OOO way of saying
calling a first-class function).
Let me presume that dynamic binding
was meant here in the sense of late binding, in the sense of
subtyping polymorphism. At least, the given shapes example
strongly suggested
On Jun 22, 2005, at 9:38 PM, Andrew Ward wrote:
Pal-Kristian Engstad wrote:
On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:
What would be the normal way for a Haskell programmer to handle the
typical shape example in beginner OO tutorials?
By not doing OO. You have to ask yourself,
Ralf Lammel wrote:
dynamic binding is just the OOO way of saying
calling a first-class function).
Let me presume that dynamic binding
was meant here in the sense of late binding
Yes.
in the sense of subtyping polymorphism.
No, as far as I read it, dynamic or late binding is orthogonal
Andrew Ward wrote:
Hi All,
In Simon Thompson's The Craft of Functional Programming Second Edition,
page 226, it is mentioned that Laufer (1996) describes a Haskell
extension to allow dynamic binding. I was wondering if this has been
implemented as an extension in any of the haskell compilers,
Lennart,
from a textbook perspective I agree
that this solution should be mentioned to make it easy
for non-Haskellers to get into the subject.
However (as you of course know, but I just don't understand
why you don't dare to mention the limitations a) and b) ...)
a)
Your constructor-based
My two cents:
In Coq, cf. http://pauillac.inria.fr/coq/doc8/main.html chapter 2.5.1
(Names of libraries and files), there is something similar:
Add LoadPath physical_path as dirpath.
E.g.:
Add LoadPath /home/sk/lib/foo as Foo.
Frederik Eaton (Thu, Jun 23, 2005 at 02:14:00AM -0700):
Hi all,
Yes, a) is a weakness, but usually I don't find it too restrictive.
I agree that extensible data types would be a very interesting
addition to Haskell, and I'd like to have it.
But the original question was how to do it in Haskell, and when I
hear Haskell i think Haskell-98 since it's the only
[apologies for multiple copies]
7th GPCE
Young Researchers Workshop 2005
In conjunction with
[apologies for cross-posting]
-
SECOND CALL FOR PAPERS
FACS'05
II International Workshop on
Formal Aspects of Component Software
Macao
October 24-25, 2005
On Wednesday 22 June 2005 06:38 pm, Andrew Ward wrote:
% This general pattern of dynamic binding I use over and over again. Could
% you give me some example code of this type of thing handled in Haskell's
% way? Assuming that the number of classes deriving from shape might get
% quite large.
What
On 6/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
getList = do
putStrLn Give me a number (or 0 to stop):
numString - getLine
let num = read numString
if num == 0
then return []
else return (num:getList)
This will give you an error as well. 'num' is of type
On 11/06/2005, at 11:18 PM, Thomas Sutton wrote:
In Java (C#, Python, etc) I'd do this by writing an interface
Formula and have a bunch of abstract classes (PropositionalFormula,
ModalFormula, PredicateFormula, etc) implement this interface, then
extend them into the connective classes
Thomas Sutton wrote:
Main :t (Impl (Prop p) (Poss (Prop p)))-- p - p
Impl (Prop p) (Poss (Prop p)) :: PC
So the type says that this is a formula in the predicate calculus?
(Even though you combine two formulae of modal logics.)
Are you happy with that? Just wondering?
Also, are you
Hello Ralf,
Thursday, June 23, 2005, 11:36:20 AM, you wrote:
just create list of draw functions itself:
[drawCircle (10,10) 5, drawSquare (20,20) 10]
RL No! the exercise is about lists of shapes
RL not lists of results of drawing shapes.
RL This is clearly a major difference.
in cases
Interestingly this is exactly the approach taken in the OOHaskell paper!
The difference is we used extensible records with subtyping (from the
HList paper)
to implement inheritance and overloading, which you cannot do with ordinary
Haskell records.
So you statment that it is better to do it in
I have discovered something I believe to be a problem in Haskell'98,
although it is not a simple bug as such - it has more of the flavour of
an unintended mismatch in the interaction of two separate features.
Since Haskell is deeply principled language, a feature conflict is
extremely rare, and so
A somewhat similar problem exists even without fields:
foo :: Either a b - Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine types we just have to accept that
some perfectly safe programs don't
I was under the impression that, in ghc 6.4 at least, GADTs did just that: use information gained by matching on the
type constructor to refine types. I sort-of expected that the extension to pattern matching would follow.
Or is that a nice paper waiting to be written?
Jacques
Lennart
On Thu, 23 Jun 2005, Lennart Augustsson wrote:
A somewhat similar problem exists even without fields:
foo :: Either a b - Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine types we just have
On Thu, 23 Jun 2005, Malcolm Wallace wrote:
module Fieldbug where
data Fields a =
VariantWithTwo { field1 :: a
, field2 :: a }
| VariantWithOne { field1 :: a }
The key point here is that the data structure with named fields has more
than one constructor, and
Andreas Rossberg said:
[Followups to Haskell Cafe]
as far as I read it, dynamic or late binding is orthogonal to
subtyping, or typing in general. It is just that most typed OO
languages
lump these concepts together.
Absolutely agreed.
Often a simple first-class function, or a record
Malcolm Wallace wrote:
voidcast :: Fields a - Fields Void
voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
voidcast v@(VariantWithOne{}) = v { field1 = Void }
I would not expect that updating only field1 can change the type of v.
The right thing is to construct a new value.
On Thu, 23 Jun 2005, Christian Maeder wrote:
Malcolm Wallace wrote:
voidcast :: Fields a - Fields Void
voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
voidcast v@(VariantWithOne{}) = v { field1 = Void }
I would not expect that updating only field1 can change the type of
Bulat,
a) building (i) a list of data is fundamentally different
from building (ii) a list of anticipated results of each datum.
I would be surprised to hear that this counts as a valid technique.
BTW, you can do the *same* in a lazy OO language. (No lazy OO language
at hand -- well lazyness can
Lennart Augustsson [EMAIL PROTECTED] wrote:
A somewhat similar problem exists even without fields:
foo :: Either a b - Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine types we just have to
On Thu, Jun 23, 2005 at 09:08:12PM +0200, Christian Maeder wrote:
Malcolm Wallace wrote:
voidcast :: Fields a - Fields Void
voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
voidcast v@(VariantWithOne{}) = v { field1 = Void }
I would not expect that updating only field1
It's true that GADTs does just that. But only if you use them.
And they are not part of Haskell. :)
-- Lennart
Jacques Carette wrote:
I was under the impression that, in ghc 6.4 at least, GADTs did just
that: use information gained by matching on the type constructor to
refine types.
Jonathan Cast wrote:
Lennart Augustsson [EMAIL PROTECTED] wrote:
A somewhat similar problem exists even without fields:
foo :: Either a b - Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine
41 matches
Mail list logo
