New address
I apologize to anyone who wrote me last week and did not get any response. For a reason unknown to me I can no longer access the email account which I used when subscribing to this list. I hope this address will remain stable enough. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANN: Konka doc
Hi All, You might be interested in Konka documentation, which is available either in HTML format: http://www.lun.pl/konka/doc/konka-doc.html or as a raw source -- from which either HTML or a View format can be generated in two seconds: http://www.lun.pl/konka/files/konka-doc.zip http://www.lun.pl/konka/files/konka-doc.tar.gz The preface to Konka doc explains how to generate the View format on the fly, so if you get tired of scrolling the big 360K HTML version (with images and tabularized 25 Remote API functions) download one of the above plus the Rebol/View interpreter from http://www.rebol.com This small 530 executable installs in seconds and deinstalls even easier - by erasing. It is worthy to have - even just for the sake of making and reading the Konka documentation. Konka is a portable software for local and remote generation, transformation, viewing and "snapshoting" of 3D scenes. Any language, which speaks TCP can interface to Konka via its set of well documented Remote API functions. The documentation has one chapter on Haskell and one on O'Haskell and Timber. Two simple simbot examples demonstrate how to use Konka API in GHCI. The overview of Haskell-Konka API is provided. Low level clients are presented for Haskell and O'Haskell. Regards, Jan _ Finally, a free email address your friends will remember! Become [EMAIL PROTECTED] at http://www.emailaccount.com/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: library Directory.hs
On Tue, 19 Jun 2001, Nicole Gabler wrote: > O.k. thank you Wolfgang!! > Then I will tell you my problem exactly. Perhaps anybody can help me: > My haskell programm is in the root directory. I want to parse from several > files in different directories. How can I do this?? That depends what you want to do. If you know the names and locations of files, you can easily access them by specifying full FilePaths. And this is definitely supported by Hugs. With some gymnastic you can even get directory listings - if you are willing to use Hugs as a string server. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
A pecular algebraic data structure
I've been working with one pecular algebraic data structure, named Register, which is described in currently upgraded http://www.numeric-quest.com/haskell/QuantumComputer.html. or in gzipped version of the same document http://www.numeric-quest.com/haskell/QuantumComputer.html.gz. Section 13 of that document outlines the background for the topic of this message. But the section is just way too long to quote it in here. But to summarize it: data Register is pecular because it is indexable but not observable in a standard way, and because two different representations can describe the same state. In theory there should be well defined transformation from one representation to another. This seems to me as a good subject for some research work. Granted that there are many experts on functional data structures out there (I do not want to pressure any of you gurus, so I am not naming anyone :-)), could you please look at the write-up and help me with the following questions? + Is the Register data structure strangely unique, or does it fit somewhere into a hierarchy of known functional data structures? I would be happy to learn that the latter is the case, since I could then start looking at it at a more formal, well known and tested way. + Is a non-uniqness of representation amenable to formal treatment, such as deforestation? Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Advantages of Paper
Judging from my logs, some libraries, such as University of Chicago library, do their own indexing of WWW. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Ix class
On Tue, 15 May 2001, Matt Harden wrote: [..] > I would like _any_ pair of Ints to be an acceptable boundary for the > honeycomb, not just the ones that represent valid indexes. For example, > (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current > definition of rangeSize makes this impossible, which is why I would like > to override it. By the way, the Library Report does not explicitly say > that the bounds have to both be valid indexes, though it does imply this > with the sample definition of rangeSize. There is an old article [1], that is somehow related to what you do. Looks like it could add some extra fuel to your arguments if re-examined in terms of current Haskell. [It might be also interesting to those discussing arrays in the other thread.] Jan [1] D.B. Carpenter, Some Lattice-based Scientific Problems, Expressed in Haskell, http://citeseer.nj.nec.com/157672.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell Simulator of Quantum Computer
> Hoping to get some early feedback I am posting this > very preliminary version: > http://www.numeric-quest.com/haskell/QuantumComputer.html > > Jan The bug mentioned in the write-up has been fixed and QFT behaves well now. New versions of both files (module and html page) are ready at the same location. Sorry for talking to myself, but the thought of having posted something buggy (in hope of getting some help) really bothered me. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell Simulator of Quantum Computer
Hoping to get some early feedback I am posting this very preliminary version: http://www.numeric-quest.com/haskell/QuantumComputer.html Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: List of words
On Wed, 2 May 2001, Jerzy Karczmarczuk wrote: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Not really. No one wants to answer my questions. :-) Do you think that this list is the only source of easy solutions? See what people ask Google and what Google sends to our web server: procedural+design+for+a+program+that+accepts+a+string +as+input+and+then+converts+all+upper+case+to+lower+case +and++vice-versa+and+prints+resulting+string+as+output Must be a tough and generic problem. Notice that Haskell is not mentioned here at all, but yet Google happily directed it to one of Haskell pages here. By the way, this is not the longest question that I've seen in the logs. Some are so long and weird that must match any web page out there. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
factorizing a tree
I need some help with some optimization of certain trees: data Tree = Leaf Item | Product Tree Tree | Sum (Double, Tree) (Double, Tree) with this additional "collating" property: Sum (Double, Leaf Item) (Double, Leaf Item) ==> Leaf Item I have certain control over the shape of such trees. I love products, but sums are expensive and hence my goal is to avoid them at all cost. If this is unavoidable then I try to push the sums down the tree as deeply as possible. By doing that I am sometimes able to collate a sum of two leafs into one leaf, and that's great. But even without the collation effect a deeply set sum is still better than the top sum. One of the functions, f say, is given two indices i, j from the range (1, depth of the tree). It should modify the layer "j" based on the information contained in the layer "i" - producing new tree of the same depth. A naive solution looks like this: f :: Int -> Int -> Tree -> Tree f i j tree = Sum (1, g i j tree) (1, h i j tree) where g = ... h = ... but this is the most costly solution. One way of pushing the sums down the tree is to do something of this sort: f i j (Product t1 t2) | (i <= d) && (j <= d) = Product (f i j t1) t2 | (i > d) && (j > d) = Product t1 (f (i-d) (j-d) t2) | where d = depth t1 depth t = ... I wonder if there are some known practises for handling such problems. Or am I overlooking some very simple solution? If I did not clearly specify the problem it is probably because I did not want to post here too much of irrelevant information. I can clarify it if required. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
modules Eigensystem and LinearAlgorithms
Experimenting recently with some quantum problems I've decided that it's time to add some long overdue algorithmic support for module QuantumVector. So here are two new modules added to our collection: http://www.numeric-quest.com/haskell/LinearAlgorithms.hs http://www.numeric-quest.com/haskell/Eigensystem.hs The former partially overlaps with module Orthogonals, but their most important algorithms are different, although both modules use lists for representation of matrices. This is still work in progress, but usable as it is for Hermitian matrices. Both modules are thoroughly documented, so here are just few buzzwords: Housholder reduction, complex reflection, Hessenberg matrix, similarity, triangularization, tridiagonalization, operators and maps. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
quantum search algorithm
Directly from the oven :-): http://www.numeric-quest.com/haskell/QuantumSearch.hs Excerpt from a short module description is given below. Jan Grover's algorithm assumes that one is given a quantum function, also called an oracle, that indicates, when confronted with any number between 0 and N-1, whether this number is or is not the special number being sought. The algorithm enables one to find a marked item in unstructured N-item database in a time that scales not as N, as a classical computer would require, but only as sqrt N. Putting it another way: the maximum number of calls to oracle is proportional to sqrt N. Think about a scenario when the oracle charges you per call, or when its computations are very lengthy. The answer is probabilistic, but given with very high degree of probability. In our implementation the 'search' function is able to find specifically marked number from the assemble of 8 numbers: 0..7 in just two calls to oracle, with very high degree of probability. The 'test' performs m such searches. Note that the final stage of the search is simulated as a quantum measurement performed on the state vector. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Interesting application for RandomIOR
Well, at least interesting for me ... Thinking a bit about modelling of a standard interpretation of a measurement in Quantum Mechanics I came up with this tiny addendum to module QuantumVector: http://www.numeric-quest.com/haskell/Observation.hs which simulates apparently random choice of an eigenvalue and collapses the state to its corresponding eigenvector. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Proposal: module namespaces.
Wrong namespace! Could you please, move your further discussion on this subject to [EMAIL PROTECTED]? You pauperize the other archive while polluting this one. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: FW: Consortium Caml
If this idea is also being considered for Haskell I suggest to examine NICE pages to see how it works in practice. NICE = Non-profit International Consortium for Eiffel. http://www.eiffel-nice.org Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell Module Browser with code
Classes available from the description page at http://www.numeric-quest.com/haskell/explorer/browser.html Works in Squeak. Supports Hugs and NHC. Support for other environments is planned. Hugs Module Browser is good only for Linux/Unix users due to current lack of a support for pipes and processes in Mac/Windows. NHC Module Browser should work in any environment since it does not need to communicate with external processes. This is the interim release, far from being finished, not optimized, with some glitches and unfinished design. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Hash Functions
On 12 Jan 2001, Steinitz, Dominic J wrote: > I was thinking of using MD5 or SHA-1 for an application. > Is there a Haskell library that contains these or other hash algorithms > that have a very low probability of giving clashes? > > Dominic. http://www.numeric-quest.com/haskell/bridge/index.html contains interface to MD5 code in C via Greencard. There is a support for one function only (the only function I really needed for a certain CGI application) digest :: String -> String. It uses 'unsafePerformIO' but you could redesign it changing its signature to digest :: String -> String IO or extend it to supply other functions you need. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Learning Haskell and FP
On Tue, 2 Jan 2001, George Russell wrote: > Paul Hudak wrote: > > > > > Unforunately, the "Gentle Introduction To Haskell" that > > > haskell.org links to is not a very useful introduction. > > > > John and I should probably rename this document, since it really isn't a > > very gentle intro at all. We should probably also downplay it's > > prominance on the haskell website. It was written rather quickly many > > years ago, at a time when there was not a single textbook on Haskell. > > So it's probably outlived it's purpose, although I do believe that some > > people still find it useful. > [cut] > Nevertheless I think it might be a mistake to downplay it unless > there's a better publicly-available introduction with which you can > replace it. Very valid observation. John, Paul: Wouldn't be worthwhile and possible to gradually upgrade it within some sort of a supervised documentation project at Yale, as part of your regular teaching curriculum? Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Learning Haskell and FP
On Thu, 28 Dec 2000, Benjamin L. Russell wrote: > On Thu, 28 Dec 2000 16:48:57 +0100 > Frank Atanassow <[EMAIL PROTECTED]> wrote: > > i r thomas wrote (on 28-12-00 12:50 +1000): > > >> "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho > > > > > "(It's) An old pond! The sound of water steadily > > dripping in..." > >"[It's] An old pond! The sound of water as the frog jumps in" Keeping with the minimalistic spirit of Haskell: pond frog plop! -- by James Kirkup, an English poet -- Supposedly from Hiroaki Sato collection of 80 English translations -- of this haiku. -- 3 down 77 to go.. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Parser Combinators in C
On Wed, 22 Nov 2000, Koen Claessen wrote:
[cut]
> http://www.cs.chalmers.se/~koen/ParserComboC/parser-combo-c.html
>
> I thought it could be fun for Haskell programmers to see
> this. (One of the problems with this webpage is that I do
> not really know for who I am writing it...)
>
> So if you have any comments or suggestions, please tell me!
I can see its usefulness for development of a family
of some compiler-independent, light-weight utilities for
Haskell, operating on sources of Haskell modules:
+ Converter from literate to non-literate source code.
If I am not mistaken, each Haskell compiler and Hugs has
its own version of "unlit" program. However, each
"unlit" is compiler specific and dependent on other
*.c and *.h files. There is nothing platform or compiler
specific in this problem that could not be handled
by a generic utility, running ouside any Haskell system.
+ Code and comments extractor
A code extractor ("give me a list of default methods for class
XXX", etc.) from Haskell sources would be a useful addition to
any kind of a high level GUI browser. Its logic could be much
simpler if source modules were first prefiltered by "unlit".
From my utilitarian perspective, it does not matter whether
such utilities are developed in Haskell and then compiled to C
or in your framework of a pure C - as long as they are generic,
lightweight and C-compilable on any platform (Unix for
start).
I am brewing my own code for such tasks, but I would gladly
use somebody's expertly designed utilities instead.
Jan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: A prototype explorer for Haskell
On Fri, 10 Nov 2000, Paul Hudak wrote: > Good work Jan. I have two comments/questions: Thank you, Paul (and all the others that responded privately). > 1) Why can't we do this sort of thing in a Haskell GUI tool such as > FranTk? What is missing that would make it as easy as in Squeak? If you take the adverb "easy" away then my answer would be "nothing". I do not want to preach Squeak. I've done enough of it already. But the reality is that Smalltalk has excellent IDE tools, proven by 20 years of practice. What I have shown on the web pages is just a tip of the iceberg. And those tools can be easily adapted to other tasks, far from their original concept of usage. For example, the Object Inspector.. This is in fact one of debug tools. Had I chosen to use its original version you would have seen much more verbose printout on my web page - telling you what exactly you are looking at: strings, arrays, dictionaries; their full contents, etc. But for this application all of that would be irrelevant and unneceserily foggy. So I browsed several related classes (using of course Squeak's IDE) and finally found three methods to adjust. Instead of modifying the original classes, I subclassed - getting in effect quite different customized tool. That was quite inexpensive thing to do. From then on I could concentrate on the task on hand: understanding what I am receiving from Hugs and deciding on how to structure and present the data. Anyone could have done it easily. It's just that one day I was struck by a thought: what's so sacred about interlanguage marriages? Do they really have to be close in spirit to qualify? Like C and C++? Maybe this is why we still do not have any decent front end tools for Haskell? And then another thought: How about an unlikely aliance of the purest functional language with the purest object oriented language? No compromises! And do not worry, Haskell could not possibly get polluted - after all it has monads standing on guard! :-) > > 2) Why can't we as a community create "front-end" tools such as this > that can be used with several compiler back-ends? > [cut] A gui-less universal support would be quite useful too, so GUI tools from any toolkit, could tap to something common for all Haskell environments, not necesserily Hugs. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
A prototype explorer for Haskell
Check http://www.numeric-quest.com/haskell/explorer/explorer.html and tell me what you think about it. The tool uses :browse command of Hugs. There is always a choice for this kind of work: + Parse the source modules. Pro: Tools are portable to other environments. Contra: source code is not type checked and might be buggy. + Be lazy and tap to work of others, such as Hugs. Pro: Modules are typed checked. Contra: tools are not portable. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The world's smartest i/o device for Haskell
Since I have noticed some moderate interest in this subject: several hundred visitors to the main page - some recurring, several dozens peeks at the module Hugs.st (some recurring again) and several encouraging private messages - including some from the pillars of this congregation (only one public message from Hannah though), I am posting this message as my final addendum: I had hesitated whether or not post my original message to this forum. But thanks to the encouraging messages (and they really count when one is not sure how stupid or not the subject is) I will be occasionaly doing some further work on some interfaces to Squeak. But I will not be bothering this list with any related announcements. If you are interested - check the pages from time to time: www.numeric-quest.com/haskell/smartest.html www.numeric-quest.com/haskell/Hugs.st (linked from the above anyway). But since I am still standing on the soapbox: In meantime, the first page has been decorated by a simple GUI example, a Hugs observer. The file Hugs.st has been also significantly upgraded to include several safety measures and multithreading support in order to be able to interrupt lengthy or non-terminating Hugs computations. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
The world's smartest i/o device for Haskell
Described in: http://www.numeric-quest.com/haskell/smartest.html Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: A small problem.
> As Ralf mentioned you can compute the area of the triangle without > using square roots: Just for the record guys: you cannot cheat and skip 'sqrt' computation if the triangle has any arbitrary orientation in 3D - unless you know its plane normal. :-) Jan
Re: A small problem.
On 22 Aug 2000, Friedrich Dominicus wrote: > Dear Haskell Fans, I'm afraid that I'm a bit dumb but I'm somewhat > stuck. > > Can someone give me a hand on this problem > > I wrote this code to solve SOE, exc 5.1. > > import Shape > > triangleArea :: [Vertex] -> Float > triangleArea (v1:v2:v3:_) = let a = distBetween v1 v2 > b = distBetween v2 v3 > c = distBetween v3 v1 > s = 0.5 * (a + b + c) > in sqrt (s * (s-a) *(s-b) * (s-c)) > triangleArea _ = 0 By the way: A classical way of calculating area of a triangle is to compute cross product r = p x q, where p = v2 - v1 and q = v3 - v1, and then take half of its norm; 1/2 * sqrt (r1^2 + r2^2 + r3^2). Here, function 'sqrt' is called once only (providing that you compute vector 'r' algebraically, not via norms); that is: r1 = p2*q3 - p3*q2 r2 = p3*q1 - p1*q3 r3 = p1*q2 - p2*q1 In your example you call 'sqrt' four times (I presume here that 'distanceBetween' is defined in terms of 'sqrt'). Although I appreciate the reason why this algorithm has been exposed in SOE, it is - in fact - quite inefficient due to all those 'sqrt' computations. Furthemore, if you wish to compute area of a polygon, you can indeed split it into a list of triangles, sum all the vector products, and finally take one only 'sqrt' of the result and divide it by two. It works for any type of polygons, even those that have local convexes, for example 'stars', etc. Internal 'holes' in your polygons can be also automatically accounted for. Take a look at www.numeric-quest.com/haskell/solid/Solid.html (section 6.2 and 8.1) and www.numeric-quest.com/solid/Solid_test.html (section 5) for some examples. This is a bit more that you need, but it also show how to compute not only areas but also area integrals (for this I use Sierpinski's fractals). Truthfully, the later algorithm require some rethinking and optimization, which I have not done as yet. Jan > > > o_array :: Shape -> Float > o_array (Polygon (v1:vs)) = >let ph = phelp vs >in > foldr (+) 0.0 (map triangleArea ph) > where phelp :: [Vertex] -> [[Vertex]] >phelp (v2:v3:vs) = (v1:v2:v3:[]):phelp (v3:vs) >phelp _ = [] > > > what I want is to replace the recursive phelp function with a function > using higher order functions. > > My base idea is splitting up List of Vertices into a list of exactly > three vertices calculating that area and adding them all. > > BTW, I do not like the above solution anyway. It's too bulky. So if one has > another idea on how to tackle it, I would be very thankful to some > hint. > > Best regards > Friedrich > > -- > for e-mail reply remove all after .com >
Re: Haskell and the NGWS Runtime
> No. A definitive test is to submit the page to the validator at the World > Wide Web Consortium's web site (http://validator.w3.com/), which (not > surprisingly) finds 455 HTML errors, beginning with the absence of a document > type declaration. I bet you that 99% web pages on the net would not pass this test. Try http://www.haskell.org/index.html, or any other older pages out there (including mine, of course). This (and some other validators) are quite picky and do not distinquish between severe errors, (yes, yes some "fancy" *.htm pages cause my Netscapes to freeze) and innocent variations of the strict rules, such as adding between list items to enhance its readability. Jan
Re: doubles
> > Aha . And how many digits will GHC offer me? I would think that you will get the same number of digits as is available for C - unless some bits are reserved for something special, which I am not aware of. For example, in some implementations of Smalltalk the most significant bit is used as a flag to distinquish between a reference to an object and an unboxed integer, hence their integers are one bit shorter than in C. Jan
Re: doubles
On Thu, 10 Aug 2000, Sebastian Schulz wrote: > Hi! > > How can I use Doubles which are more exact than six digits? > For example HUGS gives me : > > >1,23456789 > 1.23457 1. What you see printed and what is used in internal computations are two different things. 2. But Hugs'es Double is the same as Float, anyway. This used to be a low priority for Mark. > > I want to rotate coordinates with eulerian matrizes and I'm using the pi > from the Prelude ( 6 digits). > After about 1000 360°-rotations I have an error of about 0.1% ; but I > want it more exact. Try compilers or STHugs instead. Jan
Re: basAlgPropos state, Cayenne
On Fri, 28 Jul 2000, S.D.Mechveliani wrote: > And there arises a question. > To make the implementation accessible, the paper file has to be > included there as the necessary part of documentation. Maybe, not > literally the paper, but something that 90% coincides with it. > On the other hand, I want the paper to be published somewhere, maybe, > in some conference proceedings, or I do not know, where. Just to have > a `publication' and a "hard" reference, not only an http location. > So, I wonder, > * where to submit the paper, > * whether publishing its file in www as a part of the library > documentation may destroy its future acceptance for publication. > > Who could advise, please? I suggest "http://xxx.lanl.gov" e-print server. Although originally designed for physics, it also hosts sections from mathematics, nonlinear mechanics and computer science. Publishing electronically does not prevent you from publishing the same article in traditional journals. As a matter of fact 70% e-print articles from xxx.lanl.gov are reprinted somewhere else. This is being encouraged by both media. For example, you can modify your abstract on LANL server anytime to tell the world that: + your article has been accepted for hardcopy publication + your article appeared in such-and-such journal. I hope this helps. Jan
Re: Haskell libraries, support status, and range of applicability(was:Haskell jobs)
On Mon, 24 Jul 2000, Claus Reinke wrote: > Jan Skibinski: > > On Wed, 19 Jul 2000, Claus Reinke wrote: > > > > [List of some examples of library status information..] > > > Someone asks about GUIs on comp.lang.functional, on the > Haskell list, or elsewhere, and we just point them towards the > library list at haskell.org - question answered, problem solved, > isn't Haskell just nice?-) True. > Seeing a last-contact date for a library tells me more: on that > date, the authors' plans where these. I always put two dates on my pages for the exact same reason, which you are raising. But doing it on my own web is one thing, and putting extra burden on shoulders of John Peterson and Olaf Chitil is quite another. I would suggest to take the example from xxx.laml.gov and formalize submission process via form interface. As you might have noticed, the LANL e-print server does not accept free-form abstracts, because that used to lead to a mess -- including misspellings of the very word 'abstract'. I have never submitted any request to the maintainers of www.haskell.org to place links to my modules. Yet, several of them are there, and that tells me that either John or Olaf does occasional scan of messages from this list and update the pages from time to time. It is quite a burden to keep everything up to date. The automatic submission process should solve several things: + Put up-to-date status information on the www.haskell.org. + Ease the maintenance process of those pages. For those who do not know how it works on LANL server: + You register yourself as an author and receive password for any future submission of your articles. + During submission of a particular paper your receive another password, which relates to that paper only. Based on this you have a power to correct your paper or even withdraw it. > I think that would be a good idea for Haskell (but please, > not at the level of comma positions;-). I used to be bitching about that too:-). But I later realized that those little things are also really important for readability of the software. > > Perhaps haskell.org could give out reference numbers for > software? So instead of the haskell.org maintainers searching > high and low for existing software, library authors would actually > submit their stuff to get a reference number, so that they and > their users could refer to the software as published on haskell.org > as [HS-LIB-2000-01] or [HS-TOOL-2000-02] or whatever? LANL classification system is simple: quant-ph/0007059 means: Section Quantum Physics, year 00, (2000), month 07, article number 59 received in that month. > > Once we have references to software (not only to nice publication > talking about software), the next step could be some form of > software review, perhaps itself published online as > "haskell.org - quarterly software review"? I second both of your proposals. Alternatively some sort of reader driven scoring system could be worthwhile to consider - with a power given to authors to withdraw their submissions. Such mechanism exists on LANL server. This is fair to authors. I think, a number of libraries on Haskell pages reached some critical mass and it is about time to think of quality rather than of manifestation of quantity of Haskell applications. Jan
Re: Haskell libraries, support status, and range of applicability(was: Haskell jobs)
On Wed, 19 Jul 2000, Claus Reinke wrote: [List of some examples of library status information..] They are all fine and useful. But I do not see any clear incentives for authors for doing so, apart from their desire to make libraries perfect .. in their spare time, if any, of course. If the develepment of good libraries had similar gratifying effects as publishing scientific papers the situation could have looked quite differently, I guess. I just read "Heath B.O'Connell, Physicists thriving with paperless publishing", e-print physics/0007040, (on "xxx.lanl.gov"), and I was amazed to learn how well this paperless revolution works there, notwithstanding all sorts of extra efforts needed for this to work as smoothly as it does. But there _is_ a strong incentive to be quickly read, and in the same token, to access information as quickly as possible. But what kind of gratification one gets from writing a library, good or bad? Don't ask me, I have not seen any so far, unless when I do something strictly commercially. Secondly, I have not seen any real peer review on this level. I cannot speak for others, but the feedback I receive does not count; sporadic encouragement is not what is important here and web access statistics is useless too. Long time ago ISE Eiffel had so-called EifellShelf, where contributions from third parties were carefully scrutinized by a group at ISE in order to assure quality and conformance to standards. I do not know whether this model is still in operation, but I really liked it then, even though I had to put my commas and blank spaces just right, or put assertions where I had considered them unncecessary at first. It did not harm my pride at all, and it really helped everyone on a long run. Jan
Re: Eifskell
On Wed, 5 Jul 2000, Anton Moscal wrote: > IMHO, the closest analog of Haskell among OO languages is Cecil: > Cecil contains closures, object initialization in Cecil is lazy and > objects are immutable by default etc. > > And the main: Cecil multimethods in conjunction with the Cecil static type > system looks similar to Haskell approach to overloading, based on type > classes. > > But Cecil and Haskell is a two different languages. > > PS: Cecil URL: http://www.cs.washigton.edu/research/projects/cecil/ See also "Cecil: using Eiffel" www.eiffel.com/doc/manuals/library/cecil/page.html A quote: "Cecil, designed by ISE, is the C library that permits C and C++ applications (as well as applications in other languages) to take advantage of almost all Eiffel facilities." ISE = Interactive Software Engineering, Santa Brabara, (Meyer's company). Jan
Re: Eifskell
On 4 Jul 2000, Marcin 'Qrczak' Kowalczyk wrote: > Tue, 4 Jul 2000 00:40:18 -0700 (PDT), Ronald J. Legere <[EMAIL PROTECTED]> >pisze: > > > I think this is driven by the recent addition of closure like > > 'agents' (http://www.eiffel.com/doc/manuals/language/agent/). > > They are poor substitutes of closures. > ... Maybe they are, but this will evidently help with certain problems, which used to be quite awkward to solve in Eiffel, such as implementation of higher order functions. If this thing were already in when interfacing to NAG C libraries (EiffelMath) coding pointer-to-pointer-to-pointer thingies (and NAG has plenty of them) would have been much easier for us then. From this perspective this new language extension is a progress and should be generally welcome. Jan
Re: Questions about printing and rounding Float numbers
On Mon, 26 Jun 2000, Michael Marte wrote: > I always thought that the Int argument to showsPrec is the precision. > So what is it good for? The library report does not explain it. I sometimes use it to distinguish between the top and the lower levels of nested data structures, which allows me to shorten the output, as in: Tensor [[1,2,3],[4,5,6],[7,8,9]], rather than Tensor [Tensor [1,2,3], Tensor [4,5,6], Tensor [7,8,9]]. Jan
Re: Quantum oscillator
Sorry for the repeated message. It appears that our "qmail" mail server re-sends e-mails from its queue any time I have to reboot the network. Jan
Quantum oscillator
Yet another testing module for QuantumVector module: www.numeric-quest.com/haskell/QuantumOscillator.html There is a lot of pretty theory and very little code because the theory solves it all; well, almost, since one can always find some mundane tasks for Haskell to handle. But the code at least tests tensor products for three-dimensional, anisotropic oscillators. Harmonic oscillators are as important to physicists as "factorial" and "fibonacci" functions are to Haskellites. :-) Very few examples in Quantum Mechanics have exact solutions and this is one of the few good exceptions. And pretty too. It serves as a backbone for building more complex apparata, and there are plenty of applications that can be modelled as harmonic oscillators. I could not help posting this example. Jerzy does it too in his paper. Jan
Re: More on Quantum vectors...
In a second round I have made several improvements to the formalism of QuantumVector module. Module Momenta is also adjusted to match the changes. The most notable improvement is related to tensor products of vector spaces. Previous definition was not good enough; although it could deal with many subsystems but they had to be of the same type. This restriction has been now removed. It does not sound like much, but in fact this is a significant leap forward. I have few interesting examples in mind which I intend to demonstrate later. On Tue, 6 Jun 2000, Frank Atanassow wrote: > I am aware of the many books on QM. However, I would not expect a > CS person to read a whole book just to read a paper which has > to do with QM. I do not see a single principle of physics employed in module QuantumVector. This is all preparatory work based solely on some mathematics. There is some physics in module Momenta though, and I provided some summary of few laws a reader should know. > > Sure, it's a rehash of material available elsewhere, but it only needs to > touch the points which are relevant for your paper. Section 6 of QuantumVector is devoted to linear operators and is mainly a rehash of known definitions, to quote you. You can find some documentation there. This was not a main goal though; I was trying to demonstrate that all known definitions of operators, such as inverse, adjoint, unitary and hermitian, are valid -- even though we deal here with strongly typed language and have to assure that we do not compare apples to oranges. Operators, as I view them here, are not just tables of unnamed numbers; in many cases they map one distinct type to another. Jan
Crossing the 98 border
So far I was able to stick with standard Haskell 98 features in the module QuantumVector I am working on. But now it seems to me that I do not have any other choice but to use Mark's extension of multiple parameter classes. The problem I have is described below. Question: Is there any way to code it in Haskell 98? Question: If not, how portable is Mark's extension? Do I need to use it at all? Jan === The problem is rather simple. I have two different kinds of vectors: Ket a and Bra a and two conversion functions "toBra" and "toKet". I also define linear operators, which can be either of the form: a :: (Ord a, Ord b) => Ket a -> Ket b or b :: (Ord a, Ord b) => Bra a -> Bra b These functions produce the adjoint operators: toBra . a . toKet :: Bra a -> Bra b toKet . b . toBra :: Ket a -> Ket b But I want to define a function adjoint, such that: (adjoint . adjoint) a == a, or (adjoint . adjoint) b == b I defined it this way: adjoint op = dual . op . dual class Dual a b | a -> b; b -> a where dual :: a -> b instance (Ord a, Ord b) => Dual (Bra a) (Ket b) where dual = toKet instance (Ord a, Ord b) => Dual (Ket a) (Bra b) where dual = toBra It all works perfectly well in Hugs -98 extension, but I am afraid I am losing some portability here.
Re: More on Quantum vectors...
On Mon, 5 Jun 2000, Frank Atanassow wrote: > Jerzy Karczmarczuk writes: > > ...although apparently there are exactly two readers/writers > > of this thread on this list. Oh, well, it is as boring as any > > other subject. > > I'm reading it. I think this field of application could be very > interesting. Jan, could you write up a paper on it, with enough of the > mathematical background for non-physicist CS people to grok it? Well, Frank, there are zillions of papers and books on mathematical background of QM and I certainly would not add anything of a consequence here. A theoretical foundation of Quantum Mechanics is the Hilbert space. Dirac's formalism is a neat notation for that space and the physicists like it, but you could use any other notation for that matter. If you are asking for a paper on application of QM that's again uncountable a task. But if you are asking for a paper on QM vs. FP - that's another story. Jerzy sent one pointer in his last post. I hope more papers of this kind will appear in the future. I would like to elaborate a bit more on what was already said on applications of QM. There are tonnes of riches of QM worth exploring. Some mathematicians have done it in the past and some do it today. Some do not have a clue what's there and that's a pity. This is what I have learned from my days as a consultant in an engineering field: a real life brings more interesting puzzles that I could have ever invented by sitting at my desk and scratching my head. (*) Open any book on Quantum Mechanics and flip the pages at random -- there is high probability that wherever your finger points there are still some unresolved problems waiting for you to compute. Jan (*) P.S. Speaking of real life inspirations... One apparently silly example: At a top of a high class office bulding there is a running track for afficionados of exercising. Runners cause track vibrations. Vibrations cause noise. Noise propagates few stories down and annoy the VIP. The VIP wants the problem fixed. The building is new and noise/vibration consultants had been involved in the project from the start. But they obviously missed something. Well, the track is isolated by sandwiched layers of rubber and other isolation. Stress waves reflect and refract in the sandwich, which happens to have some undesirable coefficients of refractions. As a result the standing waves build up to extremely high levels. Now, someone, somewhere could have written a paper "Isolation properties of sandwiched materials", but how on earth he/she would ever invented something of this sort in the first place or - granted that - how could he/she ever appreciate an importance of this little problem? Yesterday my friend posed a question about a concentric cable whose 1 mm diameter conduit is welded to the base of a printed circuit board. All of this sits on some tower in Texas and is exposed to extreme temperature changes. That causes high stress concentrations on the contact surface between wire and the weld. The weld breaks. But that's another unbelievable story...
Re: Module QuantumVector
On Fri, 2 Jun 2000, Jerzy Karczmarczuk wrote: > I hope that this work will progress. So it does. I started working on linear operators. New version of the module is available for downloading. Much still needs to be done, but the closure formula is already there. Conceptually this seemed to be a tough piece, but in fact the implementation is pretty simple and consistent with all the rest. And this is the real workhorse of the formalism and corresponds to what one would use in matrix representation (which we do not wish to use, as this is one of the goals of the entire exercise). A |x> = |y> - Abstract equation A |k> = |y> - Theoretical closure formula (sum over basis k). a >< x-> y - Haskell implementation of closure Few examples of A show how to re-label representation, and to "rotate" the basis. > For the moment I would only > say, that the orthogonality requirement of Jan is a bit constraining, > limiting the applicability of the theory to discrete (even finite?) > spaces, Discrete yes, finite no. > while it would be interesting to work with, say |x>, with > x belonging to R3... I had to start somewhere. There is enough abstraction for me at the moment. Hopefully it can be generalized, but even if not than there are many discrete cases to work with. > Moreover, I assure you that some non-orthogonal > bases are of extreme importance in physics, a canonical example > being the coherent states in optics. I am sure they are (*). Give me a break, will you? :-) Thanks for the comments. Jan P.S. I think Jerzy is talking about cases conceptually sketched below. / e2|e2' /| / | /___ | contravariant basis e1 \ covariant basis \ \ e1' e1 * e2' = 0 e1*e1' = 1 e2 * e1' = 0 e2*e2' = 1
Composing quantum angular momenta
After two days of polishing the stuff I am pleased to announce availability of the module Momenta: www.numeric-quest.com/haskell/Momenta.html Those who already downloaded the unofficial version are adviced to get the new one. It is cleaner and much faster. I also upgraded QuantumVector as well, where I added few important bits for new Momenta to work correctly. I am quite pleased with myself :-). This stuff works like a charm so far. The explanation follows. Jan === While computation of the total angular momentum for a system of classical particles is a rather trivial task, this is not so for quantum systems. To describe quantum system of several interacting subsystems one must properly define a vector space spanned by eigenvectors of observables defined for the entire system as a whole. Its basis, or rather a set of several mutually orthogonal bases, can be obtained by linear transformation of a tensor product of the bases defined for the uncoupled subsystems. The problem is how to find the coefficients of such transformation. There exists a recursive method due to Clebsch and Gordan, which does just that for two quantum subsystems describing angular momenta. It can be generalized onto three or more subsystems. For example, four subsystems (a, b, c, d) can be first partitioned into (((a, b), c), d) and then the Clebsch-Gordan method can be applied three times in the inside-out fashion. Although conceptually simple, this method is too daunting for by-hand computations. However it can be easily handled by computer programs, such as this Haskell module. There are two reasons for writing this module. First of all, the problem of composing angular momenta is pervasive in Quantum Mechanics; without much of an exaggeration we say that a significant portion of any typical textbook on Quantum Mechanics is in one way or another related to a composition of angular momenta. From this perspective, this module can be considered a basic library module for quantum mechanical applications. But this module can be also considered a test case for the QuantumVector module, which is currently under development. Its abstract computing machinery needs to be tested on some concrete non-trivial problems, such as this one. This module produces ready to go eigenvectors of combined states and verify their correctness. Due to all the background work we have done so far on the abstract Dirac formalism and to the elegancy of Haskell itself, the algorithm is simple and, most probably, much clearer than in other implementations.
Re: mode in functions
I watch in amusement how my name is glued to someone else's prose. I mildly protest :-) Jan
Re: mode in functions
On 1 Jun 2000, Ketil Malde wrote: > Jan Skibinski <[EMAIL PROTECTED]> writes: > > > For tar_x, tar_xv, tar_v kind of things people > > invented objects, recognizing that "tar -x" > > approach is not a user friendly technology. > > Oh? You realize there are Unix weenies on this list, don't you? > Cryptic commands with equally cryptic options is very user friendly > for an interactive command line. I'm a lot more flexible, effective > and efficient with that, than with any "object"-branded user interface > I've tried. Well, I said that it was just mine opinion, to which I stick. "De gustibus non est disputandum". No need to feel offended about Unix. I use Linux every day. But that does not change my opinion about switches. This is the olden days technology. I do not know what "object-branded" interfaces you are familiar with, but NextStep for example was able to hide all those unpleasent things quite nicely and tar was (is?) quite friendly there. [And you also had all fancy filters automatically appearing in any application menu. Nice interprocess communication. But you could still use scripts as in any other Unix, of course.] Tar command is really a very good example. I was quite tempted to copy here a header of "man tar", but I guess everyone knows how big this beast is. I certainly would not wish to cope with anything like this in any language I use -- unless I re-wrote it first to some friendlier form. Jan
Re: negate and sections
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) ? Jan
Re: mode in functions
On Thu, 1 Jun 2000, S.D.Mechveliani wrote: > About the type constructor for mode, I half-agree. > But about a single function - no. > If you require the single functions > sort_merge, sort_insert, sort_quick, > do you also require > tar_x, tar_xv, tar_v instead of tar > ? > As to quotRem - diveRem, it has the three extra friends to export. > Since we are expressing "i_like --i_dislike" opinions, here is mine: For tar_x, tar_xv, tar_v kind of things people invented objects, recognizing that "tar -x" approach is not a user friendly technology. Jan
Module QuantumVector
Here is our first attempt to model the abstract Dirac's
formalism of Quantum Mechanics in Haskell.
www.numeric-quest.com/haskell/QuantumVector.html
The exerpt from the summary follows.
Jan Skibinski
---
We recognize a quantum state as an abstract vector | x >,
which can be represented in one of many possible bases --
similar to many alternative representations of a 3D vector
in rotated systems of coordinates. A choice of a particular
basis is controlled by a generic type variable, which can
be any Haskell object -- providing that it supports a notion
of equality and ordering.
The base vectors are abstract: on one hand they are just
used for identification purposes, on another -- they obey
all the rules of a vector space. Any vector | x > can
be represented as a linear combination of the base vectors
and complex scalars. [..]
We only require and impose the condition, that any two
base vectors from the same basis are orthonormal, as in:
< (i, j) | (p, q) > = d (i, j) (p, q)
where the left hand side is a scalar product and on the
right is a generalized definition of the classical Kronecker's
delta.
With this abstract notion we proceed with Haskell definition
of two vector spaces: Ket and its dual Bra. We demonstrate
that both are properly defined according to the abstract
mathematical definition of vector spaces. We then introduce
inner product and demonstrate that our Bra and Ket can be
indeed considered the vector spaces with inner product.
Multitude of examples are attached in the description. To
verify the abstract machinery developed here we also
provide the basic library module Momenta -- a non-trivial
example designed to compute Clebsch-Gordan coefficients
of a transformation from one basis of angular momenta to
another.
Re: Fuzzy.hs
On Fri, 12 May 2000, Malcolm Wallace wrote: > > nhc98 and ghc4.06 show a different message: > > > > Fuzzy.hs:188: Variable not in scope: `fromInt' > > The function "fromInt" is not part of Haskell'98. Replace its sole use > with "fromIntegral", and the module compiles just fine with nhc98. > > Regards, > Malcolm > Until original Fuzzy.hs is upgraded I will temporarily host its modified version in Fuzzy_oscillator directory. See: www.numeric-quest.com/haskell/oscillator/Fuzzy_oscillator.html Two changes were required: the first is mentioned by Malcolm (for Nhc and Ghc) and the second relates to Show (for Hugs). I upgraded Fuzzy_oscillator (upgraded reference to the original location of Fuzzy.hs, importing GD instead of Gif, regenerated pictures in PNG format, changes to plotting functions) and GD modules as well. The latter had the same "fromInt" problem. Function "fromInt" is still being accepted by Hugs98 though. Jan
Re: Fuzzy.hs
On Fri, 12 May 2000, Wilhelm B. Kloke wrote: > Hi, > > I am trying to reproduce the fuzzy oscillator example by Jan Skibinski. > ( http://www.numeric-quest.com/haskell/Fuzzy_oscillator.html ) > I am having problems to compile the module Fuzzy.hs. As I am > just in an early learning stage, I need help to understand the error. > > hugs98 e.g. says: > > Reading file "/usr/local/share/hugs/lib/Prelude.hs": > Reading file "Fuzzy_oscillator.lhs": > Reading file "Fuzzy.hs": > Type checking > ERROR "Fuzzy.hs" (line 76): Cannot build superclass instance > *** Instance: Num (a -> b) > *** Context supplied: Num b > *** Required superclass : Show (a -> b) [...] This subject was already discussed in thread "Show class on ADT with functions" (original message by Mike Jones, 2000.05.05). Few answers were given. Fuzzy.hs was written long time ago by Warwick researchers. Similarly, my Fuzzy_oscillator.lhs is 1.5 years old. I do not have any idea as yet why Fuzzy used to work with old versions of Hugs. If someone from Warwick reads these messages the chance is that they will fix Fuzzy.hs. If not, I can only promise to look into things and provide patches for Fuzzy to assure that Fuzzy_oscillator works again. It needed the face lift anyway due to the replacement of Gif module by the newer GD module. Jan
Re: When is it safe to cheat?
On Tue, 9 May 2000, Frank Atanassow wrote: > Jan Skibinski writes: > >Any good idea? First prize: a bottle of something good. :-) > > There is a thing known as an Entropy Gathering Demon (EGD). > > >From http://www.lothar.com/tech/crypto/ : You have been nominated for the first prize, thank you. That's all make sense to me. Now that I know I should blame myself for not noticing this little daemon running all the time on our machines. But to give others a chance I will postpone the final announcement :-) Jan P.S. I do not have a clue as yet why my mailer mishandled my question about sources of randomness. I thought it was sent few days ago. Sorry if you received it twice. I had few hardware problems recently, the servers were down few times. Add to it yesterday's terrifying storm - I could not belive my eyes when I saw sparks coming out the receptacles. What a week!
Re: When is it safe to cheat?
On Tue, 2 May 2000, Keith Wansbrough wrote: > Off-topic, I know, but even if this worked as I think you intend, > it would hardly be random and would certainly be unsuitable for use as a > nonce. Applying `mkStdGen' to the current time doesn't make it any more > random! You might as well use > > nonce size = take size (cycle (map chr (chop_into_smaller_bits timeFrom1970))) > > where chop_into_smaller_bits expresses timeFrom1970 in base 36 or something. > > An attacker can certainly guess within a few seconds (= a few trials) when your >connection was negotiated. > Good point. Short of reading some truly random device (perhaps ambient temperature fluctuation) this can be always theoretically defeated. I can only make life more difficult to the attacker by trying to outsmart him algoritmically (Or to confuse him. My clock is always several hours too late or too early. Just kidding) Any good idea? First prize: a bottle of something good. :-) Jan
Re: basAlgPropos
On Wed, 3 May 2000, S.D.Mechveliani wrote: > > > But this is not good enough to attract general attention > > and to make it easy to discuss about. The onus is still > > on you, to be frank. > > It is large enough. If I expand it with more comments, people will > be frightened by its messiness and would speak more about its > complexity. Probably, it is better to add the comments in the form > of responses. But, for example, you wrote more than page of > comments, and there is nothing to really respond. The impression is > still that the proposal had not been read. Responding to your challenge I am sending to you a very long private note with suggestions how to restructure your current proposal. Jan
Re: discussing basAlgPropos
Sergey: I will only make a short observation here - skipping other unnecessary details which do not move this discussion in right direction. You misread me, I wanted to help. Specifically, I sensed a tone of resignation in your letter dated Wed, 26 Apr, 2000 in reponse to Fergus: Fergus:> I think the "jury" is unlikely to rewrite the proposal; Fergus:> more likely, they will simply reject the proposal. Fergus:> It is up to the proponent(s) of the proposal to rewrite it. Sergey:>>I have no idea of how such committee may appear. Sergey:>>Neither do I care much of what with this proposal will happen. If you are satisfied with a current process, I rest my case. Friendly, Jan P.S. I read your proposal. I saw your comments within it. I could even extract some sort of a small and a big picture. But this is not good enough to attract general attention and to make it easy to discuss about. The onus is still on you, to be frank.
Re: Impasse for math in Haskell 2
On Tue, 2 May 2000, Jerzy Karczmarczuk wrote:
> Well, all this is ambiguous. A "big picture" and
> "something moderate" contradict themselves IMHO.
Not necessary. How about moderately big picture? :-)
Seriously, I really worry that Sergey's initiative
does not receive proper attention it deserves
- as you said. Any initiative for that matter.
Some small ones popup here and there. I think
all of this needs some organization. A process
that would push the ideas forward to some
constructive resolution.
"Crying loud" ("if you miss something") is not
a solution. You may get a patch if you are
lucky. But here is a big chance to get something
done in reasonably complete or semi-complete way.
You sound pessimistic about such a process, and
I really do not understand why. On one hand you list
several shortcomings of Haskell that "worry you for
years", then you mention your own goodies that you
have developed for pure joy - which I am sure
(judging by the papers of yours I read) would be
beneficial to this project, then you worry about "jury"
and "their benevolent consideration". Forget about
the later - there is no jury and never be. I am sure
most of us would benefit from an open discussion on
the subject.
We all make mistakes and some of us (if not most) are
ready to admit them - unless we are "priests of science"
jellously guarding our little "altars of science" - quite
ironically described by Truesdell in [1]. I hope this
does not apply to anyone on this list.
Did I coax you enough to head the project, or
at least take a part in it? :-)
> The "object-like" classification of math.
> structures *is not enough*.
Fine. Then let's try to graphically show the static
portion and describe the missing dynamics and
detailed operations in words - as you did in your
examples.
"There is nothing that can be said by mathematical
symbols and relations which cannot also be said
by words."
But to be true to the spirit of the above quot
I should finish it up:
"The converse, however, is false. Much that can
be and is said by words cannot successfully
be put into equations, because it is nonsense."[1]
Jan
[1] Clifford Truesdell, Six Lectures on Modern Natural
Philosophy, Berlin: Springer-Verlag, 1966]
Re: Impasse for math in Haskell 2
On Mon, 1 May 2000, Tom Pledger wrote: > > Here's an example of something which could be done, without major > language extensions: insert a partial ordering class between Eq and > Ord. (It's something I've advocated before, so I won't dwell on it > this time.) That's why some sort of a big picture might hopefully help to clearly organize the process into several stages of the iteration loop: + What extra features would be really desired and, first of all - WHY? How will it make Haskell more useful from math-oriented application perspective? Opinions will differ, I am sure, but some small common subset could be probably accepted by most at first iteration. + How to implement them? What strategies are feasible? What seems to be happening now is some sort of sporadic voting on Basic Algebra Proposal as a whole: "I like it", "I dislike it", "I agree with part of it", etc. Some opinions has been expressed but nothing visible constructive is coming out of the current process. I think this happens because the Proposal is quite specific and mixes Sergey's point of view on some implementation issues and his naming convention with generic goals and needs. A recurring comment is that a particular feature should not be implemented as class, but datatype, etc. If I could suggest to Sergey, or anyone else who feels competent in doing so: + Start with a big picture and forget details for a moment. Use standard naming convention from Mathematics Subject Classification, so we all could refer to it, check it, and compare notes. Graphic representation would be nice. + Justify the needs for all those elements from the big picture. What am I buying from this as a whole and why I need this particular structure? What can I do with it? [That's why I cited Tegmar's diagram yesterday: he evidently knew where he was heading] The bottom line is that some convincing arguments for changes are needed first before implementers are to be bothered at all. Jan
Impasse for math in Haskell 2
It appears to me that we have reached some impasse in a design of basic mathematical structure for Haskell 2. Sergey's proposal "Basic Algebra Proposal" is there, but for variety of reasons (a language barrier being probably one of them) it does not seem to reverberate on this group. Shouldn't we thus start with something more moderate, that does not offer a concrete solution as yet, but at least presents some framework for a serious discussion? I recently came again across a "wacko" (in the words of its author) 1998 article by Max Tegmark "Is the `theory of everything' merely the ultimate ensemble theory?": ftp.sns.ias.edu/pub/max/toe.ps.gz - USA ftp.mpa-garching.mpg.de/pub/max/toe.ps.gz - Germany The www reference to this is on his web page: "Which mathematical structure is isomorphic to our Universe?", www.hep.upenn.edu/~max/toe.html Interesting in itself, although highly controversial, the paper graphically sketches a portion of the hierarchy of matemathical structures (or rather a web) in its introduction. It refers to Mathematics Subject Classification from American Mathematical Society, www.ams.org/msc/ Tegmark's sketch (both in the paper and on web page) is obviously geared towards his interest in `TOE' - which is fine with me but others from this list might have completely different picture in mind. Wouldn't it be useful to start a discussion on the future of math structures in Haskell 2 with something similar on hand? For example, Sergey could convey his ideas in a more compact and clear way, using this approach. And hey, there is Functional Graph Library waiting to be used too.:-) After all, Haskell98 Report has something of this sort as well. Jan
Re: When is it safe to cheat?
On Sat, 29 Apr 2000, Fergus Henderson wrote: > On 28-Apr-2000, Jan Skibinski <[EMAIL PROTECTED]> wrote: > > > > When can I safely cheat haskell compiler/interpreter > > by pretending that I perform pure computations, > > when in fact they are not? > > That depends on what degree of safety and portability you want. > If you want the greatest degree of both of those, then currently > the only safe answer is "never". The Haskell 98 Report does not > standardize `unsafePerformIO', and so there are no guarantees > about whether future implementations will have such a function, > or what it would do, or when it would be safe. That's the best answer I got. It should be framed. If my implementation currently cheats a bit but it works in Hugs, that's my responsibility and my possible future headaches. Period. Lennart wrote: > So, currentSecond is not safe to the kind of compiler optimizations > that a good Haskell compiler can do. > You can't make a working currentSecond if you don't involve IO in the > type, that's just the way it is. Just out of curiosity: Is your compiler clever enough to do just what you said? Another words, would this attached code fail to produce random nonce string ( the idea apparently criticized by Erik, but I do not care where this came from. It works fine in Hugs-98, February 2000 release). Humor me please :-) nonce :: Int -> String nonce size = take size (filter isAlpha (randoms $ mkStdGen (fst $ unsafePerformIO timeFrom1970))) timeFrom1970 :: IO (Int, Int) -- you can simulate it somehow, but -- source code is available to all -- at www.numeric-quest.com/haskell/bridge/ Erik, Frank and Nigel: I appreciate your answers too. Please try to understand that I am searching for clear answers about the limits of usage of "unsafePerformIO". I do not try to "outsmart compilers". I often do just that in my other life - rocking a boat a little. Really! When I take a dinghy for my first sail, when the weather is warm, wind gusty, no baggage and children on boat then I drive her to her limits to gain some confidence of what can I do with her. Jan Skibinski
When is it safe to cheat?
Facing a risk of being stomped all over again without reason, I nevertheless post this question to get to the bottom of things: When can I safely cheat haskell compiler/interpreter by pretending that I perform pure computations, when in fact they are not? Here is a real example, from my Md5Digest module which works fine in Hugs: digest :: String -> String digest string = unsafePerformIO ( marshall_string_ string >>= \x1 -> prim_Md5Digest_digest x1 >>= \x2 -> unmarshall_string_ x2 >>= \x3 -> return x3 ) From my naive perspective it should look to Hugs as a pure function - due to input argument. If this is correct then currentSecond dummyInput = cheat expression involving dummyInput and unsafePerformIO from my previous example should be, by extension, also safe to use. Correct? Or are there some lurking surprises that I am not aware of? Not that I like cheating though :-) Jan
Re: updating file
On Fri, 28 Apr 2000, Fergus Henderson wrote: > > > > This is all fine and dandy if `currentSecond' is within `where' > > clause, because it will be always evaluated afresh. > > It might happen to work with current Haskell implementations, > but I don't think there's any guarantee of that. Thanks Fergus for pointing this out. I was playing by ear: "Does it work in Hugs?" I rarely use (if ever) "unsafePerformIO" in any of my code, but this time the application demanded such a heavy usage of time stamps that a "lightweight" method of IO unwrapping seemed to be quite handy. It turned out not to be :-) Jan
RE: updating file
Erik: > You have discovered the essence of monads, ie the difference between the bad > and ugly world of side-effecting computations and the nice and clean world > of pure functions. And even using my favourite example (*)! Let's put it in other words: I knew the difference, I was just not careful enough. What I often do when in a midst of debugging is to move a local definition temporarily to the left margin, just for debugging. This time I got badly bitten. I thought that this was such a spectacular example that I decided to share it with the world :-). > > You say the currentSecond has type Int, so it is a pure value. However, when > you assume that, you can prove that True equals False. It is not without > reason that unsafePerformIO is called *unsafe*PerformIO! Well, I said the same in my post. > > You said, "To my distress the clock stopped after the first call to > `currentSecond'". Well, it is not the clock that stopped, but Haskell that > assumes that it only has to look at the clock once to compute currentSecond, > and thereafter immediately return that value everytime currentSecond is > needed. "To my distress the clock stopped .." supposed to be a joke. Friendly, Jan
Re: updating file
On 27 Apr 2000, Marcin 'Qrczak' Kowalczyk wrote: > Unless we are talking about unsafe extensions, which OTOH are very > useful too. Sometimes eliminating unsafePerformIO would require > huge rewrite of the whole program, making it less readable and less > efficient. But they should be clearly marked as unsafe. The safe > sublanguage should behave safely. Changing a course a little bit to describe some dangers related to usage of `unsafePerformIO' I am not very proud of what I did, but I will tell this story anyway, hoping that someone can learn from my mistake. "Unsafe perform" is just what it says :-) When writing DateTime module few days ago I stupidly entered this line of code, without even thinking about its signature: currentSecond = second $ unsafePerformIO localDateTime where `localDateTime' has been defined via primitive call to C: localDateTime :: IO DateTime To my distress the clock stopped after the first call to `currentSecond'. I took me much more than just few seconds to realize that the problem was not related to any bug in the C code, but in the signature of `currentSecond': currentSecond :: Int This is all fine and dandy if `currentSecond' is within `where' clause, because it will be always evaluated afresh. But being a top level function, as it was, it was always reporting a cached value. This all relates to the yesterday's subject "openFile :: String -> String" but it is even more spectacular in its side effect. Try to beat this! Jan
Re: updating file
Ralf and Sven: Thank you both for your answers. I knew that strictness was needed here, but I was seeking some elegant solution. I prefer your answer, Sven, a bit more. Could you elaborate on your `hack' a bit more? It seems to be a good topic for "how to be strict". Your dressed up, reusable version is attached below. Jan updateFile :: FilePath -> (String -> IO String) -> IO () updateFile file process -- -- `process' content of `file' -- and update it in place -- = readFile file >>= hyperHack >>= process>>= writeFile file where hyperHack txt | length txt >= 0 = return txt | otherwise = error "never happens" ---
updating file
Since we are in a mood for puzzles today .. How to update file "xxx" without making backup "yyy" first, as in: readFile "xxx" >>= writeFile "yyy" >>= readFile "yyy" >>= process >>= writeFile "xxx" ? Jan Skibinski
Re: openfile :: String -> String
Angus is right on the track. I would only modify it slightly: content_xxx :: String content_xxx = (unsafePerformIO . readFile) "xxx" From Hugs perspective content_xxx is a constant. Your may easily demonstrate it this way: :!echo blah > xxx content_xxx ==> "blah" :!echo Hello > xxx content_xxx ==> "blah" Jan
Fast-CGI Hugs server
Sources of the latest snapshot of Hugs serving some simple example application via Fast-CGI framework are available here: http://www.numeric-quest.com/haskell/bridge/index.html [I may consider giving access to my Hugs server for testing to those from this list that I know by their postings. But the installation is not so complex - it just takes some time.] Included are few HTML pages of documentation, and auxiliary modules: DateTime - this one really computes what it says Md5Digest - The server uses it for authentication but you can use it for other purposes too. The main module Bridge.hs provides low level interface to C, but its main strength is in presenting the application programmers with really simple model, which I shortly describe here: -- type Environment = [(Name, Value)] type Query = [(Name, Value)] type Request = (Environment, Query) serving_function :: Request -> IO () --- That's it! The request is just a glorified input, and no one has to worry about where it has come from, and in what form - POST, or GET, or whatever. Writing fancy gadgets is a responsibility of the application programmers, although I provide some examples here too. Aside from the basics, the Bridge.hs module provides many examples and also a snapshot of the simple application which is under development and testing as I write this. The application part requires some cleanup, but the rest is quite decently designed and documented. Enjoy, Jan
RE: Die Meisterstu:cke of software engineering
Correction: After closer examination of CGI directory in mod_haskell I found that the library is strictly bound to a single concept of using it as Apache loadable module. Another words, one cannot use it as is in other modes of operations, for example in fastCGI mode. Or did I miss something here? By fastCGI I understand either official one, or home grown solution which I can easily provide via pipes to runhugs or hugs. I can obviously modify your library it to suit my needs, but wouldn't it be better to provide a support for either approach and let us made our minds how we want to use it? I am sure everyone would benefit from such a clear separation of functionalities. Jan
RE: Die Meisterstu:cke of software engineering
On Fri, 7 Apr 2000, Erik Meijer wrote: > Probably you missed the announcement of mod_Haskell some time ago. > Anyway, mod_Haskell gives you a Haskell98 update of my CGI-library > integrated into Apache (yes, yes, that Linux-based webserver :-) No I did not. What I missed is that mod_Haskell does contain the upgraded version of CGI library, which is based on your paper I cited in my previous post. I looked at mod_Haskell before, I even recompiled the Apache server, but it failed miserably during the startup (the first frightful sign was that the memory usage reports went out of bounds - I suddenly became the owner of billions of megabytes). I do not know the reason yet, but I am a bit reluctant to try it again. There was probably some installation error I made, but yet.. I'll give it a try again in the future, but .. thank you, I will stay with fastCGI idea for now. This was the reason that I have not taken a good look inside the mod_Haskell to find more about CGI.hs. I owe you my thanks for this new version of CGI library. However, that does not invalidate two points that I made in my previous post: + Give us all a clear picture of current status of CGI. Available information on haskell.org pages is misleading. Make it clear (on your pages or wherever) that CGI.hs is upgraded and that it can be used in the classic way -- without fiddling with Apache. You see, you even did not make it clear in your last post here. + My second point was about lack of cooperation between different parties. If Andy's library is of any value (and I believe, it is) someone should make some concessions in here to make those two pieces compatible. We should work together towards common goals. I might be a bit naive here, though.. :-) As for the XMLambda - it looks very interesting, and I am sure I'll find some use for it later. Regards, Jan
Die Meisterstu:cke of software engineering
Die Meisterstu:cke of software engineering,
or "The crazy men in their magnificent flying
machines".
-
Once again I needed to quickly write few CGI programs.
Once again I did it in C. Once again I wished I could
use some ready to go Haskell modules instead.
And again I wonder: why don't we have anything as well
designed as the Perl CGI library?
Before anyone start protesting that there are few
Haskell CGI libraries around, I will count them
quickly myself: Erik Meijer's CGI library, Sven Panne's
modification of the former (both linked from
"haskell.org"), haskell_mod - a linkable library for
Apache server, htmllib - Andy Gill's HTML library
(somehow related) and few other variations on the
same original scheme of Erik that have been privately
reported to me.
The sad truth is that numbers do not count. Quality
does! There is the Erik Meijer's paper "Server Side
Web Scripting in Haskell" (ww.cs.uu.nl/~erik/)
that has good quality engineering thoughts in it.
I would be happy to finally see those ideas
implemented, and the old libraries removed from sight.
On Oct. 4, 1999, I enquired here about availability
of software described in that paper (Where is "Server
Side Scripting" code?) and Erik's answer was, loosely
speaking, "wait until I finish it". As far as
I can tell nothing has changed in this respect.
This time I decided to do some reverse engineering
of the ideas outlined in Erik's paper. I fixed many
bugs I found there, filled in missing pieces, clarified
concepts, organized it in user friendly fashion,
documented it according to self-imposed rules
that I was arguing for a while back on this list,
and I have it ready for anyone who wishes to receive
it via email.
But I do not want to pollute the Haskell-CGI name
space by publishing it on my web pages because I
still hope to see the official Erik's version really
soon.
And here is a real explanation of the subtitle of
my message: "The crazy men in their magnificent
flying machines". Ever seen this funny movie?
I just cannot help seeing the association between
some scenes from the movie and the situation here.
Here we have two marvellous masterpieces of engineering
(well, sort of :-)): one from Erik and one from
Andy Gill, but those pieces do not easily match.
I wished the two guys would sit down and compare
the notes. The CGI library is useless without
the form support. Why not to use Andy's HTML
library for this purpose, instead of redesigning
everything from scratch? The main problem is
in definition of HTML data structures. Erik
takes a straightforward approach:
data HTML = Text String
| Element Tag [(Name, Value)] [HTML]
Andy takes a more circuitous route:
data MarkupElement content =
= MarkupString String
| MarkupTag {
markupTag :: String,
markupAttrs:: [MarkupAttr],
markupContent :: content
}
data MarkupAttr = MarkupAttr String String
newtype Html = Html [MarkupElement Html]
-
How do you propose to match those? How would
you import Andy's widgets, such as:
checkbox :: String -> String -> Html -- Andy
to use them in Erik's framework?
checkbox :: (Name, Value) -> HTML-- Erik
[Name and Value are synonims for String].
Evidently, Erik's HTML is not the same as Andy's
Html and some ugly transformation is needed here.
What a dreadful idea! Translating from Haskell
to Haskell? Something of a sort as below?
-
import qualified Html as Andy
fromMarkup :: Andy.MarkupElement Andy.Html -> HTML
fromMarkup (Andy.MarkupString str) = Text str
fromMarkup (Andy.MarkupTag
{Andy.markupTag = str,
Andy.markupAttrs = attrs,
Andy.markupContent = (Andy.Html markups)
}) =
Element str [(n, v) | (Andy.MarkupAttr n v) <- attrs]
[fromMarkup m | m <- markups]
fromHtml :: Andy.Html -> HTML
fromHtml (Andy.Html markups) =
Element "nop" [] [fromMarkup m | m <- markups]
---
/\
|| See this clutch here?
Re: improving error messages
On Fri, 31 Mar 2000, S.J.Thompson wrote: > To help students I have compiled a list of messages and examples of code that > provoke them. In many cases a little effort would, I guess, lead to vastly > more informative error messages. I'd be interested to hear what you (and the > Hugs group) think. The catalogue of errors is at > > http://www.cs.ukc.ac.uk/people/staff/sjt/craft2e/errors.html To the maintainers of www.haskell.org pages: Would you consider linking to that page? Now that (I am so sorry about it!) wiki-wiki pages are permanently down some alternate mechanism for "howtos" or "faqs" is badly needed. Would you also consider salvaging some material from the wiki-wiki and making them available to public? Jan
Solid modeling in Haskell
Modules Solid, Solid_XML, Solid_tests and Solid_XML_tests are available at www.numeric-quest.com/haskell/solid/ Some blurb follows. Enjoy. Jan ... What we need from a solid modeler is its ability to help us with mundane computations of certain physical properties of solids, such as areas, volumes, masses, centers or gravity, moments of inertia, etc., and -- on the other hand -- help up visualize those computations somehow. ... This module does not concern itself with final graphical representation or animation of solids. However, it can be readily adapted to one of several existing graphic packages for Haskell, such as graphics from "Haskell School of Expression" or our module GD, which creates graphic files in PNG and JPEG formats. In fact, the latter was used to make the pictures found in attached Solid_tests module. Acompanying this module is module Solid_XML, which supplies a support for reading and writing solid objects in XML format. ...
Module GD
I would not take your time here if it were not for the fact that my log file shows some traffic to GD module in the last few days -- while I was still making changes to it. Since I have finished with it for now I might as well announce it here. GD module is a substitution for Gif module, which has been scrapped due to patenting issues (LZW compression algorithm). GD library, to which GD.hs interfaces, no longer suports GIF format and instead supports PNG and JPEG formats. Accordingly, I remade and renamed the package (Haskell module plus C driver) as GD. It is available here: www.numeric-quest.com/haskell/gd/index.html While I was at it, I made massive changes to function definitions (to improve their readability) and added a support for styles and brushes via a concept of Pen. All of this brakes some code in my other modules from www.numeric-quest.com/haskell/, and - I suppose - some of yours. I apologize for this. Jan
Re: HaskellDoc?
On Thu, 23 Mar 2000, Volker Wysk wrote:
> (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.
The viewing tasks that I listed before do not sound
simplistic to me at all. These are the things that I
need for daily programming. Frankly, I am not interested
in anything more than that.
I tried to put an idea across that we do not need any
tags whatsoever for any of those facilities.
I really mean it. Neither XML based nor home grown, such as
triple-dash suggested by Manuel or double stars of Sun - as
used in Java.
/**
*
* They say that the double star supposes to signify
* the importance of this comment for documentation.
*
*/
I say that any comment that is not properly positioned
in the module structure should be ignored. It is not
worthy of our attention; it either signifies an
implementation hack or its author's frivolity. We only need
one type of comments - good and important comments.
The rest is a trash. If you accept this, the double
star is gone. We just got rid of one tag.
As you well know, a Haskell module must conform
to a very specific structure -- as defined in Haskell
Report. No one complains that the import clause must
be positioned just after the module declaration.
Optional exports go in between. Definitions of infix
operators must be at the top of module too.
Now imagine that we all agreed on how we structure
the comments as well, and extended a module formal
definition to accomodate the (important) comments.
I see only a need for two or three types of comments.
Module comments just after exports. Function comments
just after the function signatures. Possible
class comments just after a class declaration.
Maybe data/newtype/type comments too...
I say "after", not "before". For Ross and Manuel
the "before" seems to be the obvious and natural
solution. For me it is not -- and for variety of
good reasons. One reason is logical: I am accustomed
to seeing a title of a book/work/program first, and
then the preface, summary, introduction, etc.
This translates to "formal definition/name first,
explanation later". If I do it other way around
then I find myself in a typical "C" trap:
/**
*
* Function: void fillToBorder (
* Point p,
* Color fillColor,
* Color borderColor);
*
* Formalized or very loose comment here: with or
* without special tags.
*
*/
void fillToBorder (
Point p,
Color fillColor,
Color borderColor)
{
...
}
My experience teaches me that more often than not
programmers change their mind and modify the
number of arguments to their functions. And they
often forget to modify the comments above their point
of focus. From then on the original comments are not
only useless but also misleading if extracted
as API.
The second reason for my preference to "after" approach
is informative. I can use the names of arguments to
write the clear comments:
void fillToBorder (
Point p,
Color fillColor,
Color borderColor)
{
//
// Flood a portion of the image with `fillColor',
// beginning at point `p' and stopping at
// `borderColor'.
//
}
Notice that if I change my mind to redefine the above
function, the next natural thing for me to do is to
change comments below the signature. No discrepancies!
The third reason for my preference to "after" approach
is purely technical. I can easily convince my parsing
tool to switch to "comment state" right after it
found the function signature. And if it cannot find any
comment here - there will be no comments in API
documentation. Tough luck!
How about Haskell version of the above?
fillToBorder :: Point -> Color -> Color -> IO ()
Contrary what some people think, the signature
itself does not tell the full story. Here I can guess
the kind of action
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, 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: 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?
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
Hugs on the orbit
Here is "How to convert Hugs into an Orbit server and supply it with a GUI client" www.numeric-quest.com/haskell/morehugs/index.html Jan
Re: deduced context
> The strongest objection I observed so far was that it agrees badly > with writing programs to link to the object libraries given without > sources. With overlaps, the interface module export types may start > to depend on the single `import A' declaration. > It will be harder to satisfy the linkage of this to the shared > library. > I consider such a case as esoteric, personally, fear to think of any > program without source: > how can one fix a bug in them, if their developers had quitted the > support? > And if one aims to link the program to object library and has not > the sources for this library, all right, avoid overlapping > instances. > > -- > Sergey Mechveliani > [EMAIL PROTECTED] Take a look at a simple example of extensibility of libraries: http://gerbil.org/tom/highlights/fastex1.shtml I do not have any opinion as yet about practicality of their solution. They claim that it works. I do not imply that something of this sort could apply to Haskell. But on the speculative level the answer is there. Jan
Tutorial on Hawk
Here is a tutorial on Hawk, which I prepared in December 1999 as a demo presentation for V3 Semiconductor in Toronto. It consists of four tutorial units, with 10 literate Haskell modules and a lot of introductory material about Haskell proper. Among other things you will find here a copy of a chapter about I/O from Haskell Companion and an abridged html-ized version of the paper "State in Haskell" by J.Launchbury and S.L.Peyton-Jones. Module "SymbolicMachine" from Unit 3 of this tutorial contains several examples of concrete and symbolic simulation of microprocessor models. Some examples included there were giving me some trouble I described today in another thread. To run this module you do not need Hawk library: all what you need can be found in this directory. Of all four units only the last one (specifically - module "Super") needs the support from the Hawk library. It describes the model of P6-like superscalar, out-of-order, register-renaming microprocessor. Most of the credit goes to the Hawk team, of course. I am just a presenter, for better or for worse. I am posting this tutorial as it was prepared in a hurry before the lecture in Toronto. It badly needs further editing, but since I opened a can of worms today: here you are! If you want to run it, do not forget to make symbolic links "html->lhs", or rename the files apropriately. Enjoy! www.numeric-quest.com/haskell/hawk/index.html Jan
RE: Help! Is there a space leak here?
[Prompted by Sergey's message about the strange dates: The mess in my headers is entirely my fault. I have not had a chance to properly finish the upgrades to this machines: internationalization and the rest. Please forgive me for this mess] On Tue, 22 Feb 2000, Mark P Jones wrote: > Jan: I don't think you're being very fair. I stand corrected. But my remarks were out of love to Hugs, not otherwise, you know! :-) > Do you really > know that the failures you demonstrated were due to a bug > in Hugs? Is it possible that they might have been caused > by bugs in the program that you were running? No I don't know it. I had barely enough time to put all those pieces together in a nice tutorial fashion, so I could not examine them properly before the demonstration I was giving. But this program came from a reputable source, akin to Hugs itself, after all! :-) I did not have any reason to suspect major problems there. > Or perhaps > you simply didn't have Hugs configured with a big enough > heap for the size of the bigger problems that you tried? I run the examples first on one of my resourceless machines here and fiddling with the heap size would not help. Later, the demo was being run on a 256Mb machine where I had a comfort to set a heap size to quite a large value. Yet, it did not help. > If it truly was a bug in Hugs, I hope that you reported > it so that the Hugs maintainers could do something to fix > it? No Mark, I did not. I got caught up in some other problems and forgot all about it. One of these days I am going to re-examine it again. This particular program is quite big and I remember one other curious thing about it: evaluation of simple expressions (2*3, say) under Hawk prompt were significantly slower than under Hugs prompt. Jan
Re: Help! Is there a space leak here?
On Sun, 6 Feb 2000, Joe English wrote: > This turns out not to be the case; testing with Hugs > invariably fails with a "Garbage collection fails to > reclaim sufficient space" on even moderately sized > documents (5000 nodes or so). If I remember correctly, one of the past postings explained that the current version of Hugs does not properly handle the tail optimizations. You will probably get a good explanation of this from someone else. The reason I am answering your post is such that I run into similar problems when executing one of the examples from Hawk distribution. It deals with the concrete and symbolic simulation of one of the intel microprocessors. It supposed to simulate an evaluation of a sequence of instructions, such as the implementation of multiplications via additions. In the concrete case it boils down to evaluation of "7 * n", in a symbolic case it is "i * n", where "n" is a running counter. Although it looks quite simplistic here, the implementation of those simulations is highly recursive. Both simulations run fine for small values of counter "n" but fail badly when "n" becomes big, 40,000 say. I happened to have a presentation on the subject of Hawk about two months ago, and the audience was not much impressed when they saw Hugs failing on such simple (in their view) examples. I knew beforehand what would happen for large "n" and I tried to restrict my presentation to small n's, but unfortunately the audience was very inquisitive. You see, those people are accustomed to running their tests for hours a time, so it was natural for them to ask for some big values of n. Not a good publicity for Hugs, unfortunately. Jan
Re: subscribe haskell
On Fri, 18 Feb 2000, Avril Hardy wrote: > I am very new to the Haskell environment and to this list. I have > just started studying Haskell at University and have had problems > downloading Haskell or Hugs to my PC; I wondered whether it had > anything to do with the options set in the ini file in the Installation > guide html. [cut] Nothing wrong with your setup. Standard version of Hugs for Linux does not have menus. Your installation at work must have been modified somehow from sources to give you those extra perks. Hugs in Linux uses the "ncurses" library when "readline" support is compiled in. "Readline" gives you line editing and history capability. I guess someone at your university took advantage of ncurses and went one step further to add menu support. And if both versions for Linux and NT look similar he/she must have done quite a good job. I do not run Windows or NT version of Hugs, but I have seen somewhere a picture of windows interface with menus. I think it is called WinHugs. Look at the section "Special items for Win 32 platform", at http://www.cse.ogi.edu/PacSoft/projects/Hugs/downloading.htm But it does not mean that your menus at home will be exactly the same as those at work. Jan P.S. Since I am already standing on a soap box.. If anyone out there uses Lynx and have trouble reading Haskell Companion in its frames and tables version - I recommend little known but crafty Lynx mutant from Czech Republic, called "Links". This is another good example what you can do with ncurses. Escape key shows you a menu and all the setup is menu based. This package is missing some features (like bookmarks) but the basics -- including image support for external viewers -- are well implemented. http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/links/
Re: drop & take [was: fixing typos in Haskell-98]
> All the proposals break this law as well, so I this argument is weak (if > not insane :-)) > > -Alex- IMHO, a consistency is the most important rule here. I do not have any problems with any of those proposals, providing that I can apply similar reasoning to other functions as well. I do not wish to be forced to remember that "drop" and "take" are somehow special in treatment of (illegal/legal?) negative arguments. Jan
Re: On Haskell and Freedom
On Fri, 14 Jan 2000, Michael T. Richter wrote: > At 06:48 AM 1/13/00 , Jerzy wrote: > > Modifying source codes of your development tools is clearly a > > pathology if not a perversion. It diverts you from your principal > > task which should *exploit* those tools. > > I'm glad to finally find someone saying this in this forum. I was very > close to unsubscribing from the Haskell list because it looked an awful lot > like it was turning into an FSF soapbox. As usually, there are two sides of the same coin. It's hard not to notice all the advantages of the open source delivery and of the bazaar-type collaboration in software development - Linux and internet being just the two good examples. I have been a taker and a giver in this scheme over the years, and I am glad it exists. On the other hand, lack of any serious quality control seems to me the biggest menace in this scheme. Poor, outdated or meaningless documentation and never ending upgrades with never ending lists of new bugs force a casual user to become an expert in each and every piece of software that she/he intends to compile, install or use. [It does not mean that all commercial programs are any better in this respect. Some are, many are not.] And here I agree with Jerzy that - in a name of a private or public progress - we should not have to be bothered with fixing somebody else's bugs, no re-invent some basic algorithms, such as "line drawing algorithm", over and over again. I do not want to become an expert in all those updates of Mozilla or GTK, I just want to use one of their reasonably stable version if I can. I am grateful that someone does it for me, and I try to repay it somehow to the best of my ability. But the reality is sometimes not so rosy. If anyone is interested, I have prepared a lengthy hair-raising example that documents the above: http://www.numeric-quest.com/haskell/cleaner.html A conclusion is that before we start glowing in glory of our own achievements we should clean our own work first. And that applies to FSF as well, as shown in the example. Jan
Re: Scientific uses of Haskell?
> I spoke about the dataflow-style languages, the "circuit builders": > Simulink, Scilab/SciCos, WiT, Khoros, IBM Data Explorer (Now Open > Source) a diagrammatic layer in MathCad, LabView, etc., (+ the defunct > Java Studio). > And, of course, the notorious Visio used by some Haskell gurus > around, for example by Eric Meijer. It is worth mentioning Visual Hawk (in Haskell). It also uses Visio. It seems that PacSoft/OGI do not advertise it yet; I found this page by a pure chance: http://www.cse.ogi.edu/PacSoft/projects/VisualHawk/ I have not inspected it yet but the basic Hawk makes much sense to me and it seems visually tractable. There is a brand new version of Hawk 2.2 available at: http://www.cse.ogi.edu/PacSoft/ > If the block present themselves as "objects", not functions on > the screen, their re-using consists in packaging smaller modules > in a bigger one, and you will end up with a large hierarchy, which > might to be difficult to code manually. > So, I disagree, the 2-dimensional, graphical programming has a nice > future, although the dataflow languages like Lucid won't ever > become very popular. Visual programming was (is?) also a part of the Smalltalk culture. I do not think that a large hierarchy was there of any problem. The problem was, in my private opinion, that -- although it was all advertised as a non-brain package(s) -- the user still had to know something about programming. All that linking of the components was fine for standard usage (say, connect a telephone book to Btrieve) but for non-trivial combination and usage of components one had to go back to text mode anyway to fill in the gaps. Too simplistic for programmers, too complex for casual users. Jan
RE: RE to Rene Grognard (2)
On Tue, 30 Nov 1999, Eduardo Costa wrote: [About the scientific skepticism, pointers to literature re. mechanical arm an other goodies]. Thanks, Eduardo, for your pointers - this is much better :-). To clarify my previous message: I did not question scientific achievements of anybody in particular and I send my best wishes to dr. Alcimar in his work. Seems very interesting. I'd also like to thank him in advance for his internal report to be sent to me. Regards, Jan
RE: RE to Rene Grognard (2)
On Sun, 28 Nov 1999, Eduardo Costa wrote: [About several promissing signs of usage of FP for scientific applications]. Far from pouring cold water on anybody's enthusiasm regarding the usage of FP to scientific problems (I would really like to see Haskell fit for such tasks), I just want to point out that there is often a long way from claims to reality. I have seen enough magic algorithms for voice processing, published in well acclaimed scientific journals, which have never passed any tests that I have undertaken on my, then sophisticated, Masscomp development station, nor when implemented as real-time algorithms in hardware. Wiener, or not Wiener, LSM or not, this stuff is really computationally intensive and just could not be run as claimed: fast, in small space, producing clean voice output for a claimed baud rate. And all of this was either C or assembler based, so the basic speed (relative to what was available 10 years back) was not an isssue. Please, let us avoid heresays and stick to well proven facts. Where are the sources of the information you were talking about? I could not find any single reference to a name Paschoarelli, Soarez only matches with Alcimar Barbosa Soares (not two persons as you seem to suggest) in context of the Clean discussion list, Edimburg University somehow does not match with mechanical arm, or arm of any sort, I could not find anything related to prof. Malaquias'es publications (aside from his correspondence to Clean list) etc., etc. Surely all those famous people have already published at least something related to the claims you mentioned? Jan
Module Collection
Our module Collection is now available at http://www.numeric-quest.com/haskell/Collection.html It is based on Chris Okazaki's "BinaryRandomAccessList", but with a twist and plenty of changes and additions. An excerpt from the summary is appended below. Jan === Datatype Collection can be used almost anywhere where List is used, but it also supports reasonably fast lookup and update operations, and fast append operation. While the latter is equivalent to the head-oriented operation on standard lists, it also brings one additional benefit: if a collection grows up by element appending rather than by up-front insertion we do not have to worry about the re-enumeration of the existing indices every time we add a new element to the collection. This is important for database applications. New class Container, defined here, exemplifies portability between certain class of functions from List and Collection. Most of them have familiar names, such as: length, take, foldl, etc. We have ported so far certain group of List functions that seems to be useful for one of our applications that uses Collection datatype, but we will be revising this module in the days to come and more functionality common to List and Collection is to be expected.
Re: Module Tensor
New version removes most of the previous limitations
(no limits on ranks, works for other dimensions than 3)
makes Tensor an instance of class Eq and Num and
introduces few operations for multiplication:
(*) - outer product
(<*>) - inner product with one bound ("sqeezed" multiplication)
(<<*>>) - inner product with two bounds
Jan
On Sat, 9 Oct 1999, Jan Skibinski wrote:
>
> I have posted a sketchy design of module Tensor:
> http://www.numeric-quest.com/haskell/Tensor.html
>
> It has some limitations, which are clearly listed, but
> it works well for 3D space. I would appreciate your
> comments for improvements.
>
> Jan
>
Module Tensor
I have posted a sketchy design of module Tensor: http://www.numeric-quest.com/haskell/Tensor.html It has some limitations, which are clearly listed, but it works well for 3D space. I would appreciate your comments for improvements. Jan
Re: Referential Transparency (was Re: OO in Haskell)
Here are some comments about the prevailing view that the concept of the World or the Universe is safe to use in any kind of arguments related to referential transparency. I would be quite cautious here. I am not an expert on these issues in relation to FP, but I have seen enough tough examples in physics that make me a bit sceptical here. I am not fighting the concept itself, but I would like to see it well described first to know exactly the limits of its applicability. In my view, once I have introduced the idea of the outside Universe into my model I am bound to complicate things quite dramatically, because now I need to consider the interactions between the two subsystems A and B (Universe). And they are often not so simple.. To rigorously describe, and -- what is much more difficult -- to solve such a system one has to treat the compound A+B as a whole. There are many such examples in physics, where it is absolutely necessary to think globally. We cannot, for example describe the system of two interacting electrons via individual (interfering or not) waveforms: psi(x1) and psi(x2). We have to use a function psi(x1,x2), which is an amplitude of probability that one (we do not know exactly which one) electron is at x1 and another at x2. But physics also teaches us how to simplify things by isolating the subsystem A from B -- as long as such simplification makes practical sense. It is not always possible though, and often not quite acurate. When you describe the free fall of a mass "m" in the Earth gravitational field you do, in fact, simplify the rigorous model by replacing the two-body problem by the one-body problem. Knowing that the gravitational pull of mass "m" has practically no effect on the movement of Earth mass "M", you can just ignore the Earth as such and instead introduce "one-way" gravitational force into your model. This methodology of removing constraints and replacing them by reaction forces (and/or torques) dates back to Newton and is the first thing to do in solving countless problems of classical mechanics. You can also apply it to a quantum model of the hydrogen atom, because the proton is much, much heavier than the electron. But you cannot exactly apply it to the model of helium, because now you deal -- in addition to heavy nucleus -- with two electrons of the same mass. I think that the monadic IO provides us with such a simplification. As long as we realize what are its limitations and as long as we stay within reasonable limits of the concept we should be fine here. The operative word here is "realize". Do we really know those limitations? I have seen engineers nondiscriminantly applying simplified engineering formulas to problems where such simplifications were not valid at all. You know, formulas of the sort "beam bending moment", taken from some engineering handbook. Such formulas had been, of course, derived from some basic theory -- but with a lot of simplifying assumptions: linearity, isotropy, small deflections, limits put on ratio of dimensions, etc. But, by the time the formula hit the handbook, all those assumption have been long forgotten. I am afraid that once we start taking the monadic concept too far we are bound to find some obstacles (philosophical or practical) sooner or later. Same applies to the concept of the Universe, because we often do not know what is exactly our model of Universe. How do we model interactions of unknown or imprecise nature? Jan
Re: CPP is not part of Haskell
If a good pre-processor is still a valid option, would not something similar to Camlp4 be better than the plain CPP? Camlp4 ===> http://pauillac.inria.fr/camlp4/ "Camlp4 is a Pre-Processor-Pretty-Printer for Objective Caml. It offers syntactic tools (parsers, extensible grammars), the ability to extend the concrete syntax of Objective Caml (quotations, syntax extensions), and to redefine it from scratch." If such a Haskell-specific tool existed and had the ability to support any syntactic extensions to Haskell then people would not have to worry too much about syntactic incompatibilities, would they? Jan
Where is "Server Side Scripting" code?
Erik Meijer, in his paper "Server Side Scripting in Haskell", FFP, Jan 98 (www.cs.uu.nl/~erik/) claims that his Haskell/CGI library is a part of the standard Hugs distribution. He also thanks the teams from Yale and Nottingham for including it as one of the demos in the standard distribution (of Hugs). I could not find it there though, nor on Erik's site. What is available from haskell.org are two much outdated versions of CGI library: one by Erik himself and one modified (and adopted to Haskell 98) by Sven Panne. By outdated I mean that they both are based on Erik's earlier work and much predate the refined and simplified concepts, quite nicely described in the paper. So where is the code in question? Is it still available to public and if yes - who is a keeper? Jan
Re: Sets of IOErrors?
On 29 Sep 1999, Marcin 'Qrczak' Kowalczyk wrote: > Wed, 29 Sep 1999 11:43:06 +0200, George Russell <[EMAIL PROTECTED]> pisze: > > > When that happens in my code it counts as a bug! Therefore error > > is appropriate. If you are in some larger Haskell universe calling > > component Haskell code it is unfortunate if a single error calls the > > entire universe to collapse, so you do need some way of recovering, > > I agree to both of the above. > > I only don't like the details about IOError. It's not extensible > and Dynamic is still not nice. I have no idea how to make it > better. Probably some general way of making extensible datatypes. I think anyone involved in this and other related threads should really take a serious look at O'Haskell. Johann does not brag too much about it, so someone has to do it for him :-). I am one of those who support "small is beautiful" idea and therefore I do not particularly like extensions to existing systems - unless such extensions are deemed absolutely necessary for practical reasons, especially if they seem to fit well into the parent's base and do not look as ad hoc decorations but as well thought off concepts. Regardless of all sorts of constraints, Haskell has achieved a lot in its current form. Working with restrictions can be fun and intellectually stimulating but nevertheless it can be sometimes frustrating. It's like writing a book without using one of the letters of the alphabet, which can be really challenging if you choose not to use the most frequent vowel, as "e" in English. (*) O'Haskell seems to take a stance: "Let's admit that we need objects. Instead of peaking and poking here and there i/o-wise why don't we start from scratch and let them be as the first-class entities in Haskell?" But referential transparency still holds, even though the dreaded "x := x + 1" syntax is bravely exposed for state updating in objects. O'Haskell is able to extend hierarchies of entities via two orthogonal mechanisms: - subclassing, as in Haskell - subtyping This way one can easily generalize on existing abstractions. Building superclasses on a top of existing classes was a challenge for me in Smalltalk or Eiffel. Not in O'Haskell! Jan P.S. (*) This is called lipography. A lipogram is a piece of text written under the constraint that one or more letters are not allowed to be used at all. Two examples: - A e-less novel "Gatsby" by obscure Californian Ernest Vincent Wright, written in late 1930's. - An excentric novel "La disparition" by French writer Georges Perec, written in French (again without letter "e") in 1969. This is a 26-volumed book (corresponding to the fact that there are 26 letters of alphabet), with volume 5 missing. Source: Le Ton beau de Marot: In praise of the Music of Language, by Douglas R. Hofstadter, ISBN 0-465-08643-8, Basic Books, 1997
Re: Cryptarithm solver - Haskell vs. C++
On Tue, 21 Sep 1999, D. Tweed wrote: > Sometimes the problem that you're working on requires such > a lot of computation (e.g., typical image processing stuff) that no > savings from reduced writing time can by a machine fast enough to > compensate for the slow-down. I agree. The arguments "you are saving on development time by using _the_ language" or "buy better equipment instead" are quite old actually. I've heard them first time in relation to perceived slowness of Smalltalk. Nothing has changed over the years in this perception, even though computers have become faster and Smalltalk itself has been significantly improved speed-wise; the competing languages have simply taken the same advantage of hardware. Besides, our apetites grow up too and the problems to solve become much more complex than before. What used to be considered an acceptable limitation is not such anymore. The speed is a relative concept: comparing to what? If I compete against delivery time than it matters to me whether I will get my results in 6 versus 12 hours. Just 50% difference, but it counts when impatient client wants it done for "yesterday". And it counts even more if he comes with another bright idea of changing the input a bit and asks me to rerun it again and again. If I use a top of the line commercial software, which has no practical competion (say Ansys), then buying faster equipment obviously helps. But not if I have written my own staff, say in Haskell, which supposes to compete with similar programs written in C. Jan
Re: Haskell Companion
[Most common concepts and definitions of functional language Haskell] The new official URL of the above overrides the previous unofficial experimental pointer, which is no longer useful. I think I found some sort of a stable working mode, so now I can publish a stable format and location, I think. Here is the new URL: http://www.numeric-quest.com/haskell/hcompanion/index.html Content-wise, nothing much has been added but just a handful of new entries. Presentation-wise, it now uses both frames, tables (supported by "file include" mechanism) so three diffent views of the same stuff are possible - with minimal editing on my part: - tutorial organization - tutorial + glossary - glossary alone Jan
Re: Implementation of type classes
On Sat, 11 Sep 1999, Heribert Schuetz wrote: > > Most of this is probably well-known stuff and written down in papers. > Which ones? The Haskell report concentrates on the static semantics of > classes and instances. It looks like the dynamic semantics is expected > to be already understood by the reader or intuitively clear. Are the > references [6] (Jones: A system of constructor classes: overloading and > implicit higher-order polymorphism) and [11] (Wadler/Blott: How to make > ad hoc polymorphism less ad hoc) of the report available on the Web? > Have you read "Typing Haskell in Haskell" by Mark P. Jones? (written not so long ago, available on Web and to be presented in Haskell Workshop 1999). It might help you with some of your questions. Jan
Re: Haskell Companion
Since I have received several similar suggestion, mainly
related to formatting of the above document, I decided
to post my reponse publicly. Sorry for the noise.
Firstly, about the robots and the strange URL I posted.
I am not paranoic, just experienced. Our Haskell directory
has been already indexed anyway, but this document
is fresh and I would like to keep it sort of anonymous
for a time being. See below.
> You could use the robots exclusion standard to achieve this.
Some robots ignore "robots.txt", especially those without
symbolic names (with numerical IPs only); some would
even take over my (slow) server for hours a time - and going
where they are not invited at all. Blindly copying..
I could place the page with keys in a publicly accessible
directory but restrict access to files with text proper -
thus eliminating indexing noise and random ways of accessing
this document. Good robots would respect this, but bad ones
would not care.
I worry about noise because documents like this one have
by their nature plenty of possible keywords for indexing.
Although comparing people's intents with the result of their
search (referer logs vs. access logs) is sometimes
quite joyful but I do not care for random users at all.
But I care for Haskell users, of course.
I still do not have clear idea about the future of
this document and thus I am trying to keep very low
profile for now. The options are: abandon, continue more
or less as is, change the format, move it to Wiki,
move it to haskel.org, etc. Your input is really needed,
because - short of the option 1 - the stuff will be soon
indexed anyway.
> Some immediate comments: it's generally easier to read documents set
> in a narrower measure, so for this sort of thing, if you want to use
> frames, it would be better to split the page vertically with most of
> the width for the text. This is a bit clumsy for the contents, but
> one typically spends less time reading that.
Frames are the easiest to implement since they do not need any
special support from JavaScript or Java.
With the former I could implement some fancy features, such
as buttons instead of plain links to help the user with
navigation ("this button pressed - you are here!").
But I do not dare to use it at the moment because
I have seen so many broken scripts due to all sorts of
incompatibilities among browsers and versions of JavaScript.
I'd rather not use Java -- at least for a moment.
Visualization of the contents seems to me of the primary
importance. Grouping some related items, but not those in the
parent-child relation, on one horizontal line looks also as a good
idea. Having enough space for code exmples printed in fixed
font supports this choice too. Managing screen estate
by choice of very short keywords puts extra restraint and
reduces readability. These were the reasons why I have chosen
the horizontal split this time.
But I will think about how to accomodate those with
different "endianess" preferences. :-)
> Making the frame [width/hight] adjustable would be a help, too.
I played with this idea too, but my Netscape browser seemed
to ignore the hints. I forgot that reloading the page with
"frameset" definition would not do a job - for this I need
to retry it in a separate window. Now it works! I have updated
the hcompanion-frame.html file. But what I have read about it -
this might not work for MS Explorer. Sorry if this is a case and
let me know if this breaks the Explorer.
> Splitting the sections into smaller html parts would be a help too --
> over a phone line the types section takes a while to download, and if
> one only wants to read part of it, it would be nice to be able to save
> that time.
This is a very valid observation; I simply got carried away
with editing and one of the files is definitely too big!
I'll try to break the text into smaller chunks -
each grouping entries belonging to the same major section.
But be aware that some definitions are reused in different
places and I do not guarantee that entries in a single file
will be organized in some logical hierarchy.
>
> Another thing that would be helpful would be a link from each section
> to the next and back.
A lot of typing, but I will try to add it too.
Thanks for your input so far.
Jan
Haskell Companion
Here is my first attempt in putting together a set of common Haskell concepts and definitions - organized in tutorial fashion. This is just a subset of what I think is badly needed. So far it deals with types (existential including) only. Motivations, excuses and so on are in the Introduction. I do not want it yet (if ever) to be a subject of robot indexing, therefore I'll show its URL in two stages: http://www.numeric-quest.com/haskell/ -- directory name filename: hcompanion-frame.html -- if you like to see it in two Netscape frames. filename: hcompanion-keys.html -- if you prefer to use two separate pages for viewing. Tested only via Netscape browsers. If it breaks in other browsers it might be due to a somewhat risky usage of >, < within tags. Let me know if that happens. Let me also know whether the contents and presentation make sense or not. Jan
Re: Licenses and Libraries
Several respondents pointed out to me my unfortunate choice of words, which implied that H/Direct is either related to MS-specific tools or MS-specific applicability. I apologize for this. But H/Direct focuses _also_ on COM, and for this a specific approach and choice of tools has been made. At least - this is what I understood from a series of articles on the subject. Nothing wrong with that save the resulting complexity of the product. I really do not need any interface to Cobol or any other exotic language language but C. This would solve most of _my_ problems and for this I would heartily welcome anything simpler than H/Direct - no matter whether it came from one camp or another. Jan
