Dear haskell team
I running Windows NT workstation 4.0 service pack
6.
I'am having problems setting up GHC on my
computer.
Does a GHC 4.06 exist for Windows NT? The
binary distribution says 4.05. When the setup program has completed the
task, where do I find the GHC compiler? I see a
Does a GHC 4.06 exist for Windows NT? The binary distribution says
4.05. When the setup program has completed the task, where do I find
the GHC compiler? I see a hsc.exe but not GHC.exe. A sample program
points to a GHC to test the setup.
The compiler driver is called ghc-4.05, not ghc
Two further comments on RegexString:
(1) I actually have to use Ian Jackson's excellent
matchRegexAll
function to do what I want. If this were documented and supported
I would appreciate it.
(2) While I can live without the facility (I think) it would nevertheless
be nice to
On Wed, 22 Mar 2000, Fergus Henderson wrote:
Actually, that raises an interesting question:
should instances of `==' be required to be hyperstrict
in cases where they return `True'?
Certainly no.
First, using (==) for that purpose is a hack. Does not work for e.g. a
list of functions or IO
On 22-Mar-2000, Qrczak [EMAIL PROTECTED] wrote:
On Wed, 22 Mar 2000, Fergus Henderson wrote:
Actually, that raises an interesting question:
should instances of `==' be required to be hyperstrict
in cases where they return `True'?
Certainly no.
First, using (==) for that purpose is
Strictness only improves efficiency and narrows cases when a function is
defined, but it can never improve correctness. There is no code that
requires strictness to work at all.
Unless we use extensions like GHC's Exception or unsafePerformIO. Or use
hGetContents and want to
Hi,
Hi,
the paper is titled " lazy functional state-threads" .
Under the topic "2.4 Encapsulation" consider the code
let v = runst (newVar True)
in
runST (readVar v)
Consider the last line ; if the type of readVar v is say " MutVar s Bool"
then readVar v will have type
On Wed, 22 Mar 2000, Frank Atanassow wrote:
But some programs make essential use of bottom in a denotational way,
and then functions defined on the type in question are required to be
strict.
They can't, because each legal function is continuous. If it has a
different value depending on
In ideal world, programmers will be editing their programs
with fancy pretty-printing and editing tools. All kinds of
massive annotations would be then possible but they will be
invisible to a programmer's eye and not obscuring
his/her code. Compilers
There seems to be some agreement at least that a clean and unintrusive
syntax like POD or the ISE Eiffel stuff is preferable to something as
noisy as XML; it certainly seems to me that it would be much more
rapidly adopted. Regarding such a system's power,
Jan Skibinski writes:
How come
On Wed, 22 Mar 2000, Keith Wansbrough wrote:
Jan... could you write up a proposal for such a system for Haskell,
with
1. The exact requirements (the comment conventions the programmer
must observe), and
2. A list of what could be automatically generated by a system
Jan Skibinski writes:
How come ISE Eiffel tools can handle all of this so
nicely from a clean ascii, readable source code? As far
as I can remember the only ugly looking comment line sits
somewhere at the top and says something like this:
"Document: $blaha
On Wed, 22 Mar 2000, Frank Atanassow wrote:
Could you give us a link to a description of this mechanism? I looked through
www.eiffel.com but could only find more general descriptions of the
language/compiler.
Strange as it may seem, Bertrand Meyer decided not to
include any
Suppose Sven implements his `len' function as above, and furthermore
implements a library which depends on this function being hyperstrict.
Suppose next that I implement an instance of `==' that returns `True' without
evaluating the arguments, and then finally suppose a third programmer called
I was up all night and I need few hours of sleep,
so I will not be ready with any proposal till
tomorrow. In meantime you may take a look at
www.numeric-quest.com/news/NQ-comments.html.
This is a document I wrote many years ago, but
it seems
On Wed, Mar 22, 2000 at 12:44:11PM +, Keith Wansbrough wrote:
There seems to be some agreement at least that a clean and unintrusive
syntax like POD or the ISE Eiffel stuff is preferable to something as
noisy as XML; it certainly seems to me that it would be much more
rapidly adopted.
A
Hi,
very slow. After we made the insert operation in the AVL tree
hyperstrict and a few similar changes, our program behaved very
well and is surely faster than if written in C using naive data
structures and algorithms. We used combinators like strict2 f x
y = strict
Wed, 22 Mar 2000 15:23:32 +0100 (MET), Bjorn Lisper [EMAIL PROTECTED] pisze:
I think the cleanest solution is to add a method "hseq" to the Eval
class, which is similar to seq but evaluates its first argument
hyperstrictly before returning its second.
You mean "implicit Eval"? Then I would
Me:
I think the cleanest solution is to add a method "hseq" to the Eval
class, which is similar to seq but evaluates its first argument
hyperstrictly before returning its second.
Marcin 'Qrczak' Kowalczyk:
You mean "implicit Eval"? Then I would certainly not call this solution
"clean". Even
Wed, 22 Mar 2000 17:26:25 +0100 (MET), Bjorn Lisper [EMAIL PROTECTED] pisze:
I don't know about full polymorphism (I guess hseq would not work
well for function-typed arguments, for instance), but I know there
are situations where it can be important from a practical perspective
to add
Ross Paterson [EMAIL PROTECTED] wrote,
On Wed, Mar 22, 2000 at 12:44:11PM +, Keith Wansbrough wrote:
There seems to be some agreement at least that a clean and unintrusive
syntax like POD or the ISE Eiffel stuff is preferable to something as
noisy as XML; it certainly seems to me that
(Message didn't get through the first time. Reposting.)
Hi
What you suggest sounds like a solution that's easy to learn, useful, and
can be implemented with modest effort. It might be the a good solution
for the problem at hand, documenting the haskell libraries.
However, if one would take
On 22-Mar-2000, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
I'm not convinced that it [hseq] should exist at all. Much can be archieved
by adding strictness flags to data definitions, or at most suitable
problem-specific functions / classes. It should not be *very* important
to
23 matches
Mail list logo
