> Not to reject assertions (they would be welcome), but I think that you
> need something slightly different in a functional programming language.
>
> Assertions in procedural languages typically define system state before
> and after a particular function gets executed.
>
> State assertions ar
> To the newcomer who is not part of the FP academic community, this all
> makes life sort of difficult. These differences seem larger than the
> differences among C compilers and are MUCH larger than the differences
> among Java compilers. I have been trying to learn Haskell and have been
>
Yes, GHC does some CSE stuff, but not very much. I don't think it has a large
performance impact, but (as luck would have it) but I plan to work on it a bit
in the newt few months.
My advice would be: write clear code, and let the compiler do the
CSE. If it doesn't, complain to the compiler wri
> Greencard allows Haskell to call C (or Corba). Is there a way to give C
> code access to Haskell functions?
GHC does not yet allow this, but we are working hard on H/Direct,
a successor to Greencard, that will. It'll also allow you to
seal up Haskell programs inside COM objects. Timescale: a
> rigid and I belong to the small legion of amateurs who implemented their
> own math. domain system, Rings, Fields, Modules, etc. This apparently
> has no chance to be included into the Haskell standard, nobody cares.
Standards develop because people who care about particular aspects
of them pu
Folks,
As some of you will by now know, I am leaving Glasgow. I'm going
to move to the Microsoft Research lab in Cambridge (England),
in September 1998.
This is a big upheaval for me, but it's one I'm pretty excited about.
[Lest you should wonder, my reasons for moving are personal and
famil
> I was a little surprised to read this too. You make it sound as if GHC's
> free status was in jeopardy. Should we all go running for the hills if
> Microsoft decides to crook its little finger in our direction? I'm glad
> that you will continue to contribute to GHC, but it scares me to think
>
> If you have a statement like:
>
> result= a || b || c
>
> does Haskell guarantee that a gets evaluated before b?
> If it does then I only have to protect against pattern match failure in
> one place, a.
Yes; if a is true, b and c won't be evaluated. That's part of
the defn of ||
Simon
> I have a base class,Organization, with name and address functions.
> I want classes Buyer and Seller from Organization.
>
> Now if I want to create an 2 instances of Seller
> > data Yahoo = Yahoo
> > instance Organization Yahoo where
> > name _= "Yahoo"
> > addreess = ...
>
> > data DoubleC
> data Weirder a b = Weirdest a b
>
> class Weird c where
> f1 :: c -> c
> f2 :: Weirder a b -> c -> Weirder a b
> f3 :: Weirder a c -> Weirder c a
> f4 :: c -> c -> Bool
>
> instance Weird (d,e) where
> f1 (x,y) = (x,y)
> f2 w (x,y) = Weirdest x y
> f3 (Weirdest x y
Alex,
If I were you I'd dispense with "deriving(Read,Show)" in module Publisher,
and add an explicit instance for Read/Show on Publisher in PublisherDB.
That would solve your circularity problem.
Haskell does permit mutually recursive modules, but Hugs does not support
them, and GHC requires so
Alastair Reid has been very quiet, so I'll pipe up for him.
Here's a reasonable design for exceptions in Haskell:
* A value of Haskell type T can be
EITHER one of the values we know and love
(bottom, or constructor, or function,
depending on T),
> Another question: Is "handle" strict in the following argument:
>
> handle :: (IOError -> IO a) -> IO a -> IO a
> ^
> (meaning: will "handle f (return bottom)" be bottom?)
Good question. No, it's not strict in that sense.
Simon
> I was keeping quiet myself, because I am planning to write
> a paper touching on this topic. But the cat seems to be
> mostly out of the bag now, so I might as well pipe up.
I'm glad you did. That's a neat idea. I'm familiar
with the NDSet idea -- that's in the Hughes/O'Donnell
paper that Ke
> Just to reiterate. I strongly urge you to ensure consistent exception
> behavior. As a matter of course, two different compiles should not result
> in two different programs.
One of the wonderful things about functional languages is that they
do not prescribe the order of evaluation. To ac
> I thought about this problem some more, and I have realized that the
> problem of nondeterminacy for Haskell exceptions would in fact be
> considerably worse that I had previously considered. The trouble is
> that in the general case the problem is not just that the choice of
> which exception
> Simon, I'm sure that a really thorough programmer such as yourself
> would never forget to insert such a test. But, as was recently
> demonstrated on this mailing list ;-), I'm quite fallible.
> I'm sure there are many other fallible Haskell programmers around.
Don't worry, I'm fallible all r
Alex,
> > main = do input <- getContents
> > putStr $ addTwo $ makeLines input
>
> > addTwo lines = ask1++(ask2 (Strict x)) ++ (result (Strict y))
> > where x:y:xs = map read lines
> > ask1 = "Enter an Integer: "
> > ask2 _ = "Enter another Integer: "
>
> I just reread Dima's answer to my query about the database access in
> particular and am confused. Dima says that he can't allow queries
> outside the IOMonad because he has to worry about freeing memory (query
> output).
>
> However, Haskell/Com (built on top of Greencard?) seems to be able
> The paper says:
> "We are working on a distributed implementation of Concurrent Haskell.
> Once nice property of MVars is that they seem relatively easy to implement
> in a distributed setting..."
> I assume that they are not referring to GPH here.
> (I was surprised that at this statement giv
> The ghc compiler complains about 2 type errors in the following code:
>
> > data SearchResult a = Found a | Fail
> >
> > class (Eq key, Ord key) => Dictionary dict key dat where
> > delete :: key -> dict -> dict
> > search :: key -> dict -> (key,SearchResult dat,dict)
> > searchL
Folks,
GHC 3.02 supports multi-parameter type classes, but I have been
guilty of not documenting precisely what that means.
I've now summarised the extensions, informally but I hope
precisely, at
http://www.dcs.gla.ac.uk/multi-param.html
This includes some changes that aren't in 3.02,
> > Actually I think you would be better off with a class like
> > this:
> >
> > class (Eq key, Ord key) => Dictionary dict key where
> > delete :: key -> dict dat -> dict dat
> > search :: key -> dict dat -> (key, SearchResult dat, dict dat)
> > searchList :: [key] -> dict dat -
> | > > class (Eq key, Ord key) => Dictionary dict key dat where
> | > > delete :: key -> dict -> dict
> | ...
> | > the first error:
> | >
> | > Class type variable `dat' does not appear in method signature
> | > delete :: key -> dict -> dict
> | >
> | > Why does ghc expect tha
> |5. In the signature of a class operation, every constraint must
> | mention at least one type variable that is not a class type
> | variable. Thus:
> ...
> | > class C a where
> | >op :: Eq a => (a,b) -> (a,b)
> |
> | is not OK because the constrain
> Well, I have a convincing example (at least it convinces me ;-).
> There are several ways to define a type class for finite maps (aka
> dictionaries, aka lookup tables). Here is one taken from Chris Okasaki's
> book on purely functional data structures (p. 204):
I saw Mark yesterday, and have m
Folks
This message is to update you on the state of play so far
as Standard Haskell is concerned. I'm circulating to three
Haskell-related mailing lists; in future I'll mail only
the "haskell" list, so pls subscribe to it if you want to
see anything more.
You may remember that John Hughes has
> That's basically newtype with the data constructor omitted (I would
> prefer data to record). Unfortunately, this seems to be incompatible
> with the class system. (There was a long discussion on the Standard
> Haskell discussion list, unfortunately the entry vanished).
No, it just moved over
[I'm taking the liberty of broadening this to the Haskell
mailing list. I doubt anyone is on glasgow-haskell-users, where
it started, but not on the haskell list.]
> > I think this has been discussed before, but I've just run into it myself.
> > I have a MPC 'Set', in the usual bog-standard fas
> etc... all seem to be things that are waiting 'till Haskell 2. My
> point was that _something_ should be in Standard Haskell. The features
> you mention are likely to help when writing a better network library,
> but let's not get distracted from the option of including something
> straightfor
> More generally, regardless of the standards process, it feels like the
> GHC, Hugs define the de facto Haskell standard (it doesn't look like HBC
> is still in progress but I could be wrong). As such, it seems tough to
> write libraries right now as the upcoming GHC/Hugs release will contain
>
> > read :: Read a => String -> a
> > read s = let [(r,s')] = reads s in r
> >
> > This *won't compile* if you don't treat the let binding definition
> > monomorphicly. Without monomorphism, the types of r and s' are
> >
> > r :: Read a => a
> > s' :: Read a => String
> >
> > This leads to an a
> But if there are too many things missing, no one will use Standard
> Haskell - it already seems as if most of the people on this list are
> going to go straight to Haskell 2, which would mean that Standard
> Haskell might only be used for teaching.
Indeed, I do expect that most of the people o
> It seems that many prominent Haskell people are more or less associated
> with Microsoft. It has just been announced that Hugs may go into
> Microsoft Developers Studio and Simon Peyton-Jones is about to move to
> Microsoft. Is there a risk (or change, if you like) that Microsoft will
> eventual
Olaf suggests
> Hence I suggest that part (b) of rule 1 of the MR should
> be deleted, i.e. simple
> pattern bindings are just treated as function bindings. As I have said in a
> previous email, the recomputation issue could be handled by warnings from the
> compiler.
That would indeed not fall
> Simon L Peyton Jones wrote:
> > So far as GHC is concerned, I wrote on this list a month ago:
> > "More specifically, I plan to continue beavering away on GHC.
> > GHC is public domain software, and Microsoft are happy for it to
> > remain so, source code and al
>
> I'm going to ask a very stupid question.
>
> Why on earth is len computed twice in this example? I really don't
> understand this!
I have to confess that I mischievously hoped that someone
would say this: it demonstates the point nicely that
lifting the monomorphism restriction would ca
> Haskell doesn't seem to allow
>
> > instance Num (Int->Int) where ...
>
> or
>
> > instance Stringable String where ...
Haskell requires you to write instances of the form
instance context => T a1..an where ...
where T is a type constructor and a1..an are type variables.
This is
> I would like to avoid using show all the time for printing strings e.g.
>
> > val = "the sum of 2 and 2 is "++(show $ 2 + 2)++" whenever."
>
> I would prefer to type something like:
>
> > val = "the sum of 2 and 2 is "./(2+2)./" whenever."
> > -- i can' find a better haskell compatible opera
> I think the way that Hugs 1.3c handles it would meet your goals. All that
> it requires is a strict extension to the syntax for patterns to allow type
> annotations. These can be useful in their own right, but also can be
> applied
> to problems like the one that you gave:
>
> f :: [a] -> a
Dear colleague
We'd like to invite you to join us at the International Symposium on
Memory Management 1998, immediately preceding OOPSLA in Vacouver.
Memory management is becomming more and more important these
days, and the meeting should be a good chance to find out where
it's at, and to meet
> I cannot find there the subject. Could you citate?
Sorry, it turns out I missed your point entirely.
class (Ring r,AddGroup (m r)) => RightModule m r where
cMul :: m r -> r -> m r
So here, m :: *->*
What you really want is to say
instance Ring r => RightModule (\t->t) r where
> class (Ring r,AddGroup (m r)) => RightModule m r
> where
> cMul :: m r -> r -> m r
> -- "vector" (m r) multiplied by "coefficient" r'
>
> Haskell rejects this (m r) in the context. Could Haskell-2 allow it?
Yes. See http://www.dcs.gla.ac.uk/~simonpj/multi-p
> In any case, I hope that Simon will follow his urge to get Standard
> Haskell done with Real Soon Now, even if there is no overwhelming
> consensus on certain issues, so that we can then concentrate on Haskell
> 2.
That's just what I intend to do. I don't see Std Haskell as a big
deal, but eve
I think all this discussion about numerics in Haskell is great. I'm convinced
that designing good libraries is a major creative act, not just an add-on to a
language; and that the existence of good libraries has a big effect on how much
use a language gets. ('Good' means both having a well-desig
Folks,
I'm writing to say how I hope to progress the Standard Haskell
process. I have updated the 'State of play' page
http://www.dcs.gla.ac.uk/~simonpj/std-haskell.html
It now lists every change that I propose to make for Standard
Haskell. I now propose the following plan:
* Betwe
> Yes, I think it's a fine idea to loosen up the syntax and allow import and
> infix anywhere. But could someone clarify what the intent is with regards to
> the scoping of liberally sprinkled imports/infixes?
I've added a clarification; my intent was that all import and
fixity declarations wou
This is a summary of all the outstanding issues I'm aware of for Verison 1.2.
If there are others I've omitted, let me know.
Glasgow have the token for all files except the Prelude source files
themselves, which Joe has the token for.
There are actions on
Paul (check proposed syntax c
101 - 148 of 148 matches
Mail list logo
