Re: set up blues
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 hsc.exe but not GHC.exe.A sample program points to a GHC to test the setup. Can you point me to update information or a source where I can properly install GHC 4.06? I've tried the "fptools" pack but it seems abit confusing...one message states the the "happy-inplace" cannot be found...Has anyone experience this problem? I need a clear step by step "cook book" approach to installing and running the haskell compiler on windows NT. Can you be of any assistance? Thank you, Sam.
Re: set up blues
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 (admittedly this is a bit silly). You can just copy it or make a link to it called ghc. Can you point me to update information or a source where I can properly install GHC 4.06? I've tried the "fptools" pack but it seems a bit confusing...one message states the the "happy-inplace" cannot be found...Has anyone experience this problem? I need a clear step by step "cook book" approach to installing and running the haskell compiler on windows NT. Can you be of any assistance? At the moment 4.06 doesn't (AFAIK) build on Windows NT (at least, it's OK under cygwin, but not under mingwin; in addition, the build system is slightly broken). I'm working on it, to get a new Windows build together; unfortunately, major changes since 4.05 have led to a certain amount of bit-rot with respect to the Windows version. You should probably stick to 4.05 for now. -- http://sc3d.org/rrt/ | certain, a. insufficiently analysed
Re: Which regular expression library?
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 be able to toggle at least case sensitivity and line mode, as Regex allows you to do. Something like the attached modified version of RegexString should do the trick, without breaking anything. Simon Marlow wrote: I'm worried that Regex might be obsolescent. If I change to RegexString, can I be sure that it's going to stay and be supported for the next two years? Sure. We might change the name though - I'd like to rename RegexString to Regex if/when we replace Regex with a PCRE version. Cheers, Simon RegexString.lhs
Re: == and hyperstrictness
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 actions. Is unnecessarily inefficient for sets with non-unique representation and equality defined through conversion to sorted lists. Does not work as expected if equality uses only a part of value, which makes a perfect sense when e.g. the rest of a value contains something that can be derived and is stored for efficiency only. Second, the definition of hyperstrictness must be quite arbitrary for some nonstandard extensions. What to do with Dynamic? With ForeignObj containing StablePtrs inside? If it is worth, it could be defined as a class, and could be even automaticelly derivable. I must have seen it somewhere. I doubt it is so useful though. Suppose Sven implements his `len' function as above, and furthermore implements a library which depends on this function being hyperstrict. It generally cannot depend on it. 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 explicitly close a file to work around limits of concurrently open files, or to write to that file, or to use Posix.forkProcess. IMHO the behavior of hClose wrt. hGetContents should be changed. Currently the result depends on whether something has been evaluated (at least with GHC)! About the only such place in Haskell 98. -- Marcin 'Qrczak' Kowalczyk
Re: == and hyperstrictness
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 a hack. OK, you convinced me on that point. Thanks. Suppose Sven implements his `len' function as above, and furthermore implements a library which depends on this function being hyperstrict. It generally cannot depend on it. 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. Sometimes efficiency is important, and it is quite possible for a function to depend on strictness for reasonable performance. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: == and hyperstrictness
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 explicitly close a file to work around limits of concurrently open files, or to write to that file, or to use Posix.forkProcess. I think there are cases where strictness is a condition of correctness. It depends on whether or not you are using bottom to model an element of your intended semantic domain. Most programs don't: they only use bottom for operational convenience, for laziness, say, or to model non-termination or errors when the program is incorrect. 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. I admit I can't think of any just now, though... :) Maybe someone else can think of an example? -- Frank Atanassow, Dept. of Computer Science, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-1012, Fax +31 (030) 251-3791
a question about a paper
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 "ST s Bool". the article sais " s is free " . So my question is why hasn't readVar v the type " forall s ( ST s Bool) " ? Thanks Jan Brosius
Re: == and hyperstrictness
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 whether its argument is bottom or not, the value for bottom argument is bottom. The only way an additional strictness can change the semantics is to make a previously working program fail. Some extensions allow other weird things. In GHC it is possible to write an approximation of the function "detectBottom :: a - Maybe a" with obvious meaning, which would try to evaluate the argument for specified time and only return incorrect Nothings when the evaluation is taking too much time or perhaps memory. -- Marcin 'Qrczak' Kowalczyk
Re: HaskellDoc?
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 will be clever enough to handle pretty-printed and annotated source code. But the programmers will never have to look into those special files. They will always work with nicely presented views of the possibly ugly internal representation of the source code. But we do not live in such ideal world yet and what we use daily are ascii editors for developement of our programs. For a strange reason we are way behind the ordinary computer users who do not care for ascii editors at all. Because of our dependence on ascii format I protest those proposals whose aim is to help some (hypothetical) tools to generate fancy looking views: interfaces, cross-references, etc. No matter what some say, some of us will be still wanting to work directly with the ascii source code. But if such code is obscured by all those hints and helpings for automated tools, such as XML tags and so on, the source code presentation will be quite ugly and very hard to use directly. As someone already said here: programmer's comfort first of all. Tools suppose to help us, not to impede our work. If they are not intelligent enough - tough luck, scrap them and find something better. 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 $Date...". But the rest is pretty -- as it supposed to be. There are plenty of views that are given to Eiffel users as his/her choice. And all of them are produced from the same readable source code on the fly. So-called short form which ignores inheritance? Here you go! Flat form, fully blown API with inheritance. Flat-short form. Extracts of description of classes. Cross references. Lists of heirs, lists of parents. The only help a programmer gives to the Eiifel tools is a bit of self-discipline. Location of comments. Obligatory class comments. Preconditions and postconditions that help to clarify the intended usage of the methods. Licencing garbage at the bottom, not at the front of the file. Well thought of comments: concise and clear. I am just looking at one such extract, and -- beside different representation of signatures -- all of this look very Haskell! Even comments start with dash-dash. :-) And it looks really good. Jan
Re: HaskellDoc?
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 ISE Eiffel tools can handle all of this so nicely from a clean ascii, readable source code? As far [.. description of lots of neat things it generates automatically from minimal additional comment conventions elided ..] The only help a programmer gives to the Eiifel tools is a bit of self-discipline. Location of comments. Obligatory class comments. Preconditions and postconditions that help to clarify the intended usage of the methods. Licencing garbage at the bottom, not at the front of the file. Well thought of comments: concise and clear. 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 utilising these. If we had a concrete proposal for something simple and usable, I'm sure all of us here on the Haskell list would be happy to thrash out the bugs and maybe go away and implement some of it. Regards, --KW 8-)
Re: HaskellDoc?
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 utilising these. Ok, I'll try to come up with something informal for a start. Jan If we had a concrete proposal for something simple and usable, I'm sure all of us here on the Haskell list would be happy to thrash out the bugs and maybe go away and implement some of it. Regards, --KW 8-)
Re: HaskellDoc?
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 $Date...". But the rest is pretty -- as it supposed to be. There are plenty of views that are given to Eiffel users as his/her choice. And all of them are produced from the same readable source code on the fly. So-called short form which ignores inheritance? Here you go! Flat form, fully blown API with inheritance. Flat-short form. Extracts of description of classes. Cross references. Lists of heirs, lists of parents. 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. -- Frank Atanassow, Dept. of Computer Science, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-1012, Fax +31 (030) 251-3791
Re: HaskellDoc?
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 documentation of the Eiffel language and libraries in ISE Eiffel distribution. Unless his policy has changed in meantime there is little chance to find such information on ISE site. The assumption was that user supposed to buy his book "Eiffel: The Language", as well as the description of libraries. The reference to these, I am pretty sure, _can_ be found on ISE site. I happen to have the book here, and several other interesting pre-releases of other materials from many years ago. Bertrand Meyer, Reusable Software - The Base object-oriented component libraries" Kim Walden, Jean-Marc Nerson, Seamless Object-Oriented Software Architecture (Analysis and Design of Reliable Systems), Draft, February 4, 1994. [This introduces static and dynamic models, the BON notation (Business Object Notation) and uses those for case studies] Jan
Re: == and hyperstrictness
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 say Joe comes along and uses my type with Sven's library. If it breaks, who is to blame? 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. Then Sven can write len :: Eq a = [a] - Int len [] = 0 len (x:xs) = x `hseq` (1 + len xs) We did this in "Data Field Haskell" - a dialect of Haskell for collection-oriented programming which we have designed and made a prototype implementation of - where we happened to need this functionality. (Those of you who are interested can have a look at http://www.it.kth.se/labs/paradis/dfh/. I plan to make a "public release" of of the system and announce it here, but there are still some problems with the installation scripts so I have put the release on hold until we have sorted these problems out. For now, download at your own risk :-) Björn Lisper
Re: HaskellDoc?
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 reasonably valid even today. I am not terribly ashamed of it. You will find there few hints about the subject we are discussing here. It refers to Java, but it does not matter. Inside that document there are also pointers to my two class hierarchy browsers for Java - with documents that are also relevant to our subject. The Xcoral-based class hierarchy browser is still available, although I have not touched it for years, so it is outdated and do not understand more modern features of Java. But some people still use it. Jan
Re: HaskellDoc?
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 simple approach might ask authors to do the following: 1. Use Haskell's literate comment convention (either one). 2. Give explicit type signatures for all exported functions. 3. Place comments before the things they describe. In particular, module overview at the start of the file, interface comments before type signatures. That's not much, but a program could then extract the interface without knowing a lot of Haskell. Extra structure for these comments could be worked out later.
Re: Fw: speed of compiled Haskell code.
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 (strict f x) y to achieve a simple code. Jan I find this interesting. It would be nice if you would like to Jan explain me what you mean by " hyperstrict" I agree with the definition of hyperstrictness, that a function is hyperstrict if it evaluates its arguments completely. What I meant concerning the AVL tree was not complete hyperstrictness but, that all parts which influence the structure of the tree are evaluated when a new element is inserted. The crucial point is that the application of the tree constructors must be strict to guarantee that the restructuring balancing operation is performed immediately. The comparison operators and the condition in if-then-else are strict anyway and, thus, will force sufficient evaluation. However, data stored in the tree that is not used for the operations on the tree need not be evaluated. Cheers Christoph
Re: == and hyperstrictness
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 certainly not call this solution
"clean". Even the full polymophism of seq is considered controversial,
and the Eval class was explicit before.
It can be argued that since every type contains its bottom, there is a
natural seq for each type, and the implementation would probably use
uniform interface for evaluation of the head for all types anyway,
so seq is probably justified. But I can very hardly think about
hyperseq as fully polymorphic.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: == and hyperstrictness
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 the full polymophism of seq is considered controversial, and the Eval class was explicit before. 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 varying degrees of strictness explicitly. Then I think the cleanest solution is to have explicit operations which give you this, with a clearly stated semantics, rather than the "x==x" kind of hack. Björn Lisper
Re: == and hyperstrictness
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 varying degrees of strictness explicitly. Then I think the
cleanest solution is to have explicit operations which give you this,
with a clearly stated semantics, rather than the "x==x" kind of hack.
I agree that it should be a separate operation (if it should exist
at all). I only objected to hseq having the type "a - b - b",
as seq. It could be "SomeSuitablyNamedClass a = a - b - b".
I'm not convinced that it 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 evaluate exactly what one has in mind - the essence of laziness
is that it is not harmful - except perfomance... It's good when the
compiler can infer itself where laziness can be safely eliminated.
In imperative programming there are varying degrees of shallow
and deep copying of objects. The problem is that in general there
exists no fixed set of variants covering all needed cases, provided
that we don't distinguish between subobjects that need to be copied
or linked in the type descriptions. Here the situation is similar:
there exists no fixed set of well defined variants. And it's easier
when we mark types instead of providing a polymorphic function.
Fortunately it matters much less than shallow / deep copying - it's
"only" performance. (And fortunately functional languages don't have
the problem of deep copying.)
The definition of seq is quite simple if we define what bottom is
and when two values are "the same". It's much harder with hyperseq,
it depends on what are algebraic types. It's a less "natural" concept.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: HaskellDoc?
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 it would be much more rapidly adopted. A simple approach might ask authors to do the following: 1. Use Haskell's literate comment convention (either one). 2. Give explicit type signatures for all exported functions. 3. Place comments before the things they describe. In particular, module overview at the start of the file, interface comments before type signatures. That's not much, but a program could then extract the interface without knowing a lot of Haskell. Extra structure for these comments could be worked out later. I completely agree with 2 and 3, but why require 1? Although I like the idea of literate programming, it doesn't seem to encourage programmers to add comments to "real" programs (ie, sizeable software). The result are "literate" programs with 95% code and 5% comments, which are just more noisy due to the literate comment conventions - look at ghc's source for what I mean. Points 2 and 3 work fine with normal comments. I am usually using the following layout for my Haskell programs: -- compute the product of two matrices -- -- * all sublists must be of equal length -- matMul :: [[a]] - [[a]] - [[a]] -- -- using Strassen's divideconquer algorithm -- matMul xss yss = ... As you propose, the interface comment precedes the type signature. Everything after it (comments and code) belongs to the implementation and should not be copied into a pure interface specification.[1] IMHO, the biggest obstacle to the proposed scheme are module-global comments on implementation aspects, ie, comments that do not belong into the interface and are not attached to a single function, because they influence the design of the implementation of the whole module. How can a tool distinguish these from module-global comments that are part of the interface description? One approach to this problem would be to adapt a style similar to that of the Lisp people, where `;', `;;', `;;;', and `' are used for different kinds of comments. We could use `---' for global comments that are to be copied to the interface and `--' for comments that shouldn't. This makes it not only easy for a tool to distinguish the two, but also gives a human reader a clear understanding of what the author felt is an assertion about the interface of a module and what is a comment describing the current state of the affairs, but which may change in following version of teh code. Cheers, Manuel [1] Some people might be worried that the type signature is drowned among the comments. This is not a problem in an editor using colour-based highlighting of syntactic forms (a feature that any decent program editor these days has).
Re: HaskellDoc?
(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 this way, one should keep the tool simplicistic. Or you could end up defining just another ad hoc tag syntax for just another literate programming system. I strongly disagree with the idea of incorporating any documentation generation facility into the language, or the compiler. The compiler's job is to produce good executables, not documentation. As has been noted, the GHC team can't "solve all programming problems in the world". What the compiler, or some other tool that comprehends the Haskell syntax, could do, is provide a way to read the source code, and output it again, with some of the structure made explicit by inserting (XML-) tags. This output could then be used by a documentatin generation tool, such as an Eiffel-like one. This way, you could separate the language specific task of making sense of the code, from the documentation generation system. After all, the general problem of producing program documentation is not Haskell specific at all. A word on heavy infrastructure. I mean, the infrastructure is exactly as heavy as it is for the users to install and use it. There were thoughts of building complete new text editors and programming environments. Making some existing text formating system easy to install on a range of platforms, would require much less effort. Whatever front end markup method will be adopted, using XML as a target language, and a XSL-based formatting system for typesetting would probably still be the solution of choice. bye
Re: == and hyperstrictness
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 evaluate exactly what one has in mind - the essence of laziness is that it is not harmful - except perfomance... It's good when the compiler can infer itself where laziness can be safely eliminated. `hseq' would sometimes be useful in conjunction with exception handling, for ensuring that some sub-expression was fully evaluated within the scope of an exception handler, rather than being lazily evaluated with some parts of the evaluation occurring outside the scope of the exception handler. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
