On Monday 16 December 2002 18:18, Ashley Yakeley wrote:
In article [EMAIL PROTECTED],
Hal Daume III [EMAIL PROTECTED] wrote:
I spent about a half hour toying around with this and came up with the
following, which seems to work (in ghci, but not hugs -- question for
smart people: which is
On Monday 21 October 2002 20:29, Sigbjorn Finne wrote:
A new release of Hugs98 is just around the corner, introducing
a number of worthwhile extensions and enhancements (see
announcement blurb at the end of this message.)
To help us flush out any remaining issues/bugs, a release candidate
is
On Monday 19 August 2002 04:33 am, Alastair Reid wrote:
Does anyone know a workaround for this, or please tell me if I'm
just doing something stupid.
It sounds like there's a problem in the RPM package since Hugs itself
isn't that fussy. You could install Hugs from source yourself.
On Monday 25 February 2002 02:55 am, Simon Peyton-Jones wrote:
Not yet. But Jeff Lewis is (I believe) planning to work actively
on this.
Well put. I plan on working on this, but no sooner than mid-march.
--Jeff
___
Glasgow-haskell-users mailing
On Wednesday 13 February 2002 06:36 am, C.Reinke wrote:
Does anybody with their elbows in the
code think variable interpolation and/or
multi-line strings are good/doable ideas?
Would this be the sort of change one could make
without a lot of previous familiarity with
the
On Tuesday 05 February 2002 09:40 am, Brian Berns wrote:
I am new to functional programming and teaching myself Haskell. The
canonical Haskell fib function (e.g. as presented in the Gentle
tutorial) is:
fib = 1 : 1 : [ a+b | (a,b) - zip fib (tail fib) ]
This seems, to be polite, a bit
On Monday 04 February 2002 01:58 am, Koen Claessen wrote:
Hi all,
Now we are talking about implicit parameters, let us take up
the following problem with them on the Haskell mailing list
too.
[implicit parameters are not propogated down recursive definitions without
a type signature]
On Monday 04 February 2002 02:25 am, John Hughes wrote:
Not so fast! Proposing a solution means this is regarded as a problem!
But what is to say that the first behaviour is right in any general
sense?
The important thing is that the language semantics is clear, and this is a
semantic
John Hughes wrote:
What we need is different binding syntax for monomorphic and polymorphic
bindings. Roll on := and = ...
I agree absolutely that we need such a distinction. Although it's worth clarifying a
point. The monomorphism restriction doesn't exclude polymorphism, just
Ch. A. Herrmann wrote:
Simon == Simon Marlow [EMAIL PROTECTED] writes:
Simon The right thing to do on such a box is to use the RPM or
Simon debian package, if one is available.
For the reason below, RPM is not a solution for us. Currently, I'm
compiling GHC with a modified
Lennart Augustsson wrote:
I have been writing substantial Haskell programs and I use *NO* experimental
features. What I'm currently working on is over 2 lines of Haskell 98.
No extensions whatsoever. (It even compiles and runs with all available
Haskell implementations.)
Granted, I
Simon Peyton-Jones wrote:
This is a long message about the design of implicit parameters.
In particular, it is about the interaction of the monomorphism
restriction with implicit parameters. This issue was discussed
in the original implicit-parameter paper, but I wanted to articulate
it
S.D.Mechveliani wrote:
Simon P. Jones mentions some paper on implicit parameters
in his recent letter on Implicit parameters and monomorphism.
Please, where to find this paper?
You can slurp one up from here: http://www.cse.ogi.edu/~jlewis/
--Jeff
Simon Peyton-Jones wrote:
I only added 'with' because I did not want to steal *two* new keywords.
One is bad enough! I proposed using 'let' (not dlet), with the '?' to
distinguish dynamic from lexical bindings, but did not achieve
consensus.
I only added `with' to GHC originally because
"Manuel M. T. Chakravarty" wrote:
"Jeffrey R. Lewis" [EMAIL PROTECTED] wrote,
Lack of consensus = the status quo stays.
My order of preference:
1. [happy]. Use 'let'
2. [consent]. Use 'dlet' or 'with'
3. [hate] Use both 'dlet' and 'with'
Marcus Shawcroft wrote:
Ralf Hinze wrote:
It compiles just fine except that ghci is not built:
ghci
ghc-5.00: not built for interactive use
Do I have to specify this explicitly?
Cheers, Ralf
Hi
ghci is not built unless you are compiling with ghc 4.11 or better. Try
Mark P Jones wrote:
| I am finding functional dependencies confusing. (I suspect I am
| not alone.) Should the following code work?
|
| class HasConverter a b | a - b where
|convert :: a - b
|
| instance (HasConverter a b,Show b) = Show a where
|show value = show (convert
Simon Peyton-Jones wrote:
I think you can simplify the example. Given
class HasFoo a b | a - b where
foo :: a - b
instance HasFoo Int Bool where ...
Is this legal?
f :: HasFoo Int b = Int - b
f x = foo x
You might think so, since
Simon Peyton-Jones wrote:
Thanks. I've added both tests to the HEAD.
Jeff: let us know the outcome re bug-hunt.
Attached is a much shorter demonstration of the first bug. I don't have the HEAD
checked out anywhere right now, so it isn't convenient to change it myself.
--Jeff
P.S. the
José Romildo Malaquias wrote:
On Tue, Nov 14, 2000 at 05:02:30PM +, Malcolm Wallace wrote:
class C a where
ty :: a - String
instance (Num a) = C a where
ty _ = "NUM"
instance C Integer where
ty _ = "Integer"
Why GHC and NHC98 are more restrictive than
[EMAIL PROTECTED] wrote:
I can't get hugs98 to work under my linuxplatform. I have the Red
Hat distirbution 7.0.
The problem is that hugs requires a file called "readline.so.3" and
I have "readline.so.4" on my system. Does anyone know how to get
around this problem??
There will be a
Fergus Henderson wrote:
On 27-Oct-2000, José Romildo Malaquias [EMAIL PROTECTED] wrote:
On Fri, Oct 27, 2000 at 09:07:24AM -0700, Jeffrey R. Lewis wrote:
Yes, as implemented using the dictionary
translation, implicit parameterization can lead to loss of sharing, exactly in
the same
Simon Peyton-Jones wrote:
| I think I've worked out what's going on now. But I don't like it.
| When I use -fallow-undecidable-instances and -fallow-overlapping-instances
| (as I did) I was assuming (like Keith Wansbrough did) that
| GHC would do a Prolog-style backtracking search when it
José Romildo Malaquias wrote:
Hi.
While experimenting with the implicit parameter
extension to Haskell 98, implemented in GHC 4.08.1
and latest Hugs, I came accross a difference among
those implementations regarding overloading functions
with implicit parameters.
As a test consider the
John Launchbury wrote:
Koen,
If a language has the property that in one place, one can
use a "let" block to define polymorphic bindings, and in
another place one can only use it for monomorphic bindings,
then I think that is bad language design.
I don't think that's a very accurate
John Launchbury wrote:
Jeff,
Isn't that a bit of a dodgy argument? I don't know of any papers on `in'
polymorphism, but many about `let' polymorphism. If I see `let', I expect
polymorphism, and I'm not going to go searching for an `in'.
Not true (or if true, misguided).
I say dodgy
I just ran into this lovely little corner today, and wondering if anyone has
any nice suggestions for fixing it.
You can write the section (+ x) to specify a function to add `x' to
something. That's great, then you need to specify a function for subtracting
`x' from something. Great, you just
Jan Skibinski wrote:
On Thu, 1 Jun 2000, Jeffrey R. Lewis wrote:
No so, of course. (- x) means `negate x'. Bummer. What an unpleasant bit of
asymmetry!
How about ((-) x) ?
That, regrettably, is the wrong function. That function is \y - x - y. I wanted
\y - y - x.
--Jeff
Zhanyong Wan wrote:
"Jeffrey R. Lewis" wrote:
Jan Skibinski wrote:
On Thu, 1 Jun 2000, Jeffrey R. Lewis wrote:
No so, of course. (- x) means `negate x'. Bummer. What an unpleasant bit of
asymmetry!
How about ((-) x) ?
That, regrettably, is
Simon Peyton-Jones wrote:
Jeff Lewis has heroically put in the code for 95% of functional
dependencies,
but I don't think he's quite finished.
Jeff, what's your plan?
I'd like to have some time to finish this up in the next month - hopefully
before the HIM. The missing areas are mostly
"S.D.Mechveliani" wrote:
overlaps with the standard instance Eq a = Eq [a] ...
and causes, in the existing implementations, many error reports -
until the user satisfies everything by typing
f :: (Eq a,Eq [a],Eq [[a]],Eq [[[a]]],Eq a,
Eq [a],Eq [[a]],Eq
"S.D.Mechveliani" wrote:
The philosophy should be:
--
seeing in the program f ["foo","bar","baz"]
the compiler judges that f applies to certain xs :: [String].
According to the compiled type of f,
the instances Eq String, Eq (Maybe String)
Marcin 'Qrczak' Kowalczyk wrote:
The other issue is efficiency if you want f to behave the same way even
when the instance Eq (Maybe String) is not visible at f's definition.
It would mean that every overloaded function must be extended to
directly receive all dictionaries it needs. This can
"S.D.Mechveliani" wrote:
That is, f receives a dictionary of Eq methods on the type a, as
specified in its type. It builds a dictionary of Eq methods on the
type Maybe a itself, but the fact that it uses instance Eq (Maybe a)
is not visible outside.
No. Probably, here how it should be.
Fergus Henderson wrote:
On 16-Feb-2000, Jeffrey R. Lewis [EMAIL PROTECTED] wrote:
To my mind, the biggest flaw with overlapping instances is the separate
compilation issue: to whit, if the `instance Eq (Maybe String)' was in
a different module, not imported by the module defining `f
"Carl R. Witty" wrote:
"Jeffrey R. Lewis" [EMAIL PROTECTED] writes:
Marcin 'Qrczak' Kowalczyk wrote:
Parts of context reduction must be deferred, contexts must be left
more complex, which as I understand leads to worse code - only to
make overlapping instances
Marcin 'Qrczak' Kowalczyk wrote:
Sun, 06 Feb 2000 23:21:38 -0800, Jeffrey R. Lewis [EMAIL PROTECTED] pisze:
If context reduction choses a more generic instance when a more
specific one exists, then I consider that a bug.
http://research.microsoft.com/users/simonpj/Papers/multi.ps.gz
"S.D.Mechveliani" wrote:
Dear GHC,
I fear, there is some hard bug in ghc-4.06.
On the program
main = let p= 5 :: Integer
iI = eucIdeal "be" p [] [] [(p,1)]
r1 = Rse 1 iI dZ
dK = upGCDRing r1 eFM
--upRing
Simon Peyton-Jones wrote:
| If y'all agree that GHC should match hugs on this, it's only
| about a 4 line
| fix - I've tried it out already. On the other hand, I don't
| think that this
| will make Sergey a happy camper. Many instance declarations
| need to be
| tweaked. It's a tedious
Marcin 'Qrczak' Kowalczyk wrote:
Thank you for ghc-4.06!
The following code is accepted by Hugs, but ghc complains about type
variable r being not in scope. Adding "forall m r." causes the error
"each forall'd type variable mentioned by the constraint must appear
after the =", where Hugs
Sven Panne wrote:
"Jeffrey R. Lewis" wrote:
Currently (out of CVS), a compile of `hslib/lang' fails on FFI.lhs:
FFI.lhs:119: Data constructor not in scope: `SIZEOF_CHAR'
FFI.lhs:120: Data constructor not in scope: `ALIGNMENT_CHAR'
[...]
Some parts of the configuration
Greetings:
The Hugs/GHC CVS server (cvs.haskell.org) has just been moved to a
new machine. Everything should be the same, except that ssh may give a
dire warning message that starts off like this:
@@@
@ WARNING: HOST
"Ch. A. Herrmann" wrote:
I had just a fast look at the following I found at the
page "http://www.cse.ogi.edu/PacSoft/projects/Hugs/hugsman/exts.html"
for dynamic scoping:
min :: [a] - a
min = least with ?cmp = (=)
Actually, I'm not sure how referential transparency can be
Simon Peyton-Jones wrote:
| - Does other Haskell implementations (ghc, nhc, hbc, ...)
| would provide this extension in next releases? (This way,
| even been an extension, my system would be portable)
Jeff Lewis is well advanced with adding functional dependencies
into GHC; I believe
Mark Utting wrote:
Simon wrote:
Can anyone help with this? Simon and Sigbjorn are both
on holiday, and I am wonderfully ignorant about such things.
John McCarten wrote:
I recently emailed you concerning the installation of GHC,
I have now managed to install and configure to some
Claus Reinke wrote:
what I wanted to write was
a partial specification, which I would want to write as
foo := C a = a - b
Read e := t as "the type of e should be bounded by t". Choose a better
symbol if you like -- the idea is to keep the syntax of types unchanged,
and to introduce a
Wolfram Kahl wrote:
Jeffrey R. Lewis" [EMAIL PROTECTED] writes:
foo := C a = a - b roughly equiv to foo :: C _a = _a - _b
I can easily imagine that you might want some variables to be a bound, and
others to be exact, as in
foo :: C a = a - _b
I
"Sigbjorne Finne (Intl Vendor)" wrote:
Hi,
if you compile the contents of lib/ with FOR_HUGS
set to YES, you shouldn't run into either of these, e.g.,
sof$ make FOR_HUGS=YES AddrBits.hs
../src/ihc -fno-qualified-names --hugs -fno-imports\
-fint-is-int -c AddrBits.idl -o
The following patches are for ghc/interpreter, and fix some problems due
to the recent change in Weak/Foreign stuff.
--Jeff
In ghc/includes:
*** Assembler.h 1998/12/07 21:33:20 1.1
--- Assembler.h 1998/12/07 21:33:47
***
*** 118,123
--- 118,124
PTR_REP = 'P',
Hans Aberg wrote:
At 10:40 -0800 1998/11/13, Jeffrey R. Lewis wrote:
Say you've got some code that wasn't originally
monadic, and you now need to re-express your code in monadic form. You
apply the monad translation. Using the `kleisli' functions makes this
process simpler. Consider
Philip Wadler wrote:
You are right, beginners may stub their toe on factorial. On the other
hand, with the default set to Integer, beginners may stub their toe
on bad performance. Anyone familiar with, say, C, will be unsurprised
by the need to switch Int to Integer to get factorial to
When attempting to reconstruct the syntax for existential
quantification, I tried:
newtype Groo a = Groo (Either a b)
To my surprise, using ghc-4.00, this worked - without even using
`-fglasgow-exts'. (it doesn't work, with or without `-fglasgow-exts'
under 3.02)
Then I read the release notes
Simon Peyton-Jones wrote:
When attempting to reconstruct the syntax for existential
quantification, I tried:
newtype Groo a = Groo (Either a b)
To my surprise, using ghc-4.00, this worked - without even using
`-fglasgow-exts'. (it doesn't work, with or without `-fglasgow-exts'
GHC 3.02, outa-tha-box. In the program given below, compiled by:
% ghc -fglasgow-exts -c tt.hs -o tt.o
I get the complaint:
tt.hs:22:
No instance for `Conditional Bool [Bool]'
(arising from use of `ifc' at tt.hs:22)
I say there is an instance, given by the last instance decl in
Using an H/Direct CVS snapshot from several days ago:
Using ihc -c:
The generated greed-card code imports the prelude qualified, but
references Prelude entities unqualified in %fun decls. Example fragment
(see the last line):
module BDD
( Bdd
...
) where
import StdDIS
Compilation fails when entering the lib subdirectory because:
make[1]: Entering directory `/home/src/hdirect-230698/lib'
Makefile:4: ../mk/boilerplate.mk: No such file or directory
And indeed, there is no mk directory anywhere in the distribution.
--Jeff
[EMAIL PROTECTED] wrote:
* import and infix declarations anywhere in a module?
I am against this proposal. Collecting all such declarations
at the head of the module is better for human readers. Allowing
them anywhere would also complicate and slow down program analysis
that only
That's just what I intend to do. I don't see Std Haskell as a big
deal, but even little deals are worth completing rather than
leaving as loose ends... and I'm more optimistic than Paul about
the usefulness of Std Haskell. I would be happy to find a name
that was less grand and
Alex Ferguson wrote:
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:
Ralf Hinze wrote:
One could also argue that the culprit is Haskell's interpretation of
type variables of which Report (p. 34) says: `[...] the type variables
in a Haskell expression are all assumed to be universally quantified
[..]'. Here is an even more irritating list of possibilities ...
John C. Peterson wrote:
While some may argue that avoiding re-evaluation is the justification
for the monomorphism restriction, the real issue is ambiguity.
Without some form of monomorphism (or scoped type variables?? Someone
needs to convince me that scoped type variables fix everything
Christian Sievers wrote:
Hello, this is about a change in the prelude I'd like to suggest.
The following is obviously not what one would expect:
Prelude succ 100::Integer
Program error: {primIntegerToInt 100}
However, with the prelude defining succ to be
succ,
Alastair Reid wrote:
3. CGI startup and HUGS
Hugs scripts seem to take a very long time to start up.
Testing with this:
main = putStr "content-type: text/html\n\nhello world\n"
Hugs scripts have a noticeable response delay.
The equivalent Perl, C, and GHC executables all respond
S. Alexander Jacobson wrote:
On Thu, 2 Apr 1998, Fergus Henderson wrote:
On 01-Apr-1998, S. Alexander Jacobson [EMAIL PROTECTED] wrote:
Not having written a compiler before, this may be an ignorant question,
but how come you write these Haskell compilers/interpreters in C/C++
Jonas Holmerin wrote:
The other day, I tried to transpose an infinite list of finite list:
Simplified example:
transpose (repeat [1..5])
This won't terminate, since transpose is defined as
transpose :: [[a]] - [[a]]
transpose = foldr
--8556961D98DF73F92C98D9B2
Content-Type: text/plain; charset="us-ascii"
Tommy Thorn wrote:
In an attempt to gather experience with Philip Wadlers pretty printing
combinators, I converted a semi big pretty printer to his pretty
printing. My initial experiences are positive: while
On a sparc, Solaris 2.5.1, during make boot, I encounter the following
minor glitch:
==fptools== gmake boot --no-print-directory -r;
in /amd/church/projects/pacsoft/E/haskell/ghc-3.01/ghc/driver
67 matches
Mail list logo
