Re: [Haskell-cafe] Is Excel a FP language?
I just had a thought... Why doesn't somebody implement a spreadsheet where Haskell is the formula language? 8-) http://sigfpe.blogspot.com/2006/11/from-l-theorem-to-spreadsheet.html may interest. ...ok, and now my head hurts... (Haskell seems to do that lots. I'm not sure why.) Well, check out http://www.mrtc.mdh.se/index.php?choice=projectsid=0041 This might ease the headache a little. It is basically the result of a MSc thesis project that a student did for me a couple of years ago. Björn Lisper PS. Also check out http://www.cs.kent.ac.uk/projects/vital/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Generalizing three programs
Queuing theory is a very large and mature area of research, with many important applications in industry. It is not a coincidence that a certain telephone company named a functional programming language after Erlang, the founder of queuing theory. Erlang actually stands for Ericsson Language. I think the alternative interpretation is intentional, though. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Excel the most used -- and fucntional -- programming lanuage on Earth?
Dan Piponi: On 1/30/07, Lennart Augustsson [EMAIL PROTECTED] wrote: Excel is what I like to call a 0:th order functional language, i.e., you can't even define functions, just values. :) Every cell with an expression in Excel is a function. The problem is that the domains and codomains of these functions don't usually contain functions. Maybe that makes it a first order functional language. Or maybe not. Yes, every cell in isolation contains an expression possibly with free variables, and so can be seen as a function in those variables. But these variables are not unbound since they are defined elsewhere in the spreadsheet. Thus, the sheet is rather a system of equations defining values, not functions. I think 0:th order is a good term :-) But...suppose we had a spreadsheet a little like Haskell where each cell has a static type, and the values can be Haskell functions. What interesting things could we do with it that we couldn't do with Excel? I had a MSc student doing something in this direction some years ago. He made a Haskell interface which was intended to work like a spreadsheet. In this interface, every declaration has a value window (if the entity declared has a showable type) and a declaration window. A designated button triggers a recompilation, and thus also a recalculation of all declared values - this, I think, captures the essence of spreadsheets which is to be able to make changes and quickly see the results. In order to support the kind of array omputations often done in spreadsheets, an extended array module was defined which declares a number of array functions and other conveniences. See http://www.mrtc.mdh.se/index.php?choice=projectsid=0041. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple matrix
Udo Stenzel: Bjorn Lisper wrote: - your definition of fromInteger will behave strangely with the elementwise extended operations, like (+). 1 + [[1,2],[3,4]] will become [[2,2],[3,5]] rather than [[2,3],[4,5]]. Array languages supporting this kind of overloading invariably have the second form of semantics. Don't call an array a matrix. If is named matrix, it should have matrix multiplication, addition, and they should obey the expected laws. But you still have the problem with the overloading of constants in your proposal. If you write 17 + a, where a is a matrix, what do people in general expect it to be? Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple matrix
I wrote: Here is one way to do it. First, you have to interpret operations on matrices as being elementwise applied. E.g, (*) is interpreted as zipWith (zipWith (*)) rather than matrix multiply, and similar for (+) etc. You then obtain a lazy semantics for the operations, where the extent of the resulting matrix is the intersection of the extents of the argument matrices. Second, you lift constants into infinite matrices containing the constant, that is: fromInteger n = repeat (repeat n). Now your examples will work as intended. Ah, should of course be fromInteger n = repeat (repeat (fromInteger n)). Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple matrix
Udo Stenzel: Bjorn Lisper wrote: Here is one way to do it. First, you have to interpret operations on matrices as being elementwise applied. E.g, (*) is interpreted as zipWith (zipWith (*)) rather than matrix multiply What's this, the principle of greatest surprise at work? Nonono, (*) should be matrix multiplication, fromInteger x should be (x * I) and I should be the identity matrix. Now all we need is an infinitely large I, and that gives: instance Num a = Num [[a]] where (+) = zipWith (zipWith (+)) (-) = zipWith (zipWith (-)) negate = map (map negate) fromInteger x = fix (((x : repeat 0) :) . map (0:)) m * n = [ [ sum $ zipWith (*) v w | w - transpose n ] | v - m ] There are pros and cons, of course. Using (*) for matrix multiply is well-established in linear algebra. But: - it breaks the symmetry. This particular operator is then overloaded in a different way than all the others, and - your definition of fromInteger will behave strangely with the elementwise extended operations, like (+). 1 + [[1,2],[3,4]] will become [[2,2],[3,5]] rather than [[2,3],[4,5]]. Array languages supporting this kind of overloading invariably have the second form of semantics. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple matrix
Here is one way to do it. First, you have to interpret operations on matrices as being elementwise applied. E.g, (*) is interpreted as zipWith (zipWith (*)) rather than matrix multiply, and similar for (+) etc. You then obtain a lazy semantics for the operations, where the extent of the resulting matrix is the intersection of the extents of the argument matrices. Second, you lift constants into infinite matrices containing the constant, that is: fromInteger n = repeat (repeat n). Now your examples will work as intended. Björn Lisper Atila Romero: Good point. And there is another problem: one could expect 10 * [[1,2],[3,4]] to be equal to [[10,20],[30,40]] and in this case 10 should be equal to [[10,0],[0,10]], instead of [[10,10],[10,10]] or [[10]]. I dont see how to fix this. Could be better to forget about fromInteger... Atila Jared Updike wrote: fromInteger x = [[fromInteger x]] Wouldn't you want the expression [[1,0],[0,2]] + 10 to yield [[11,10],[10,12]] instead of [[11]] ? I guess you would need some complicated machinery so this is one thing you have to ignore to keep your otherwise nifty instance nice and simple. Jared. ___ Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http://br.mobile.yahoo.com/mailalertas/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The values of infinite lists
Are the values of infinite lists _|_ (bottom)? No. _|_ represents total lack of information about the result, whereas in a lazy language like Haskell an infinite list contains a lot of information: you can observe arbitrary parts of such a list, access them, and compute with them. In section 1.3, the Haskell 98 report said as follows: Errors in Haskell are semantically equivalent to _|_. Technically, they are not distinguishable from nontermination, so the language includes no mechanism for detecting or acting upon errors. The formulation in the Haskell report is sloppy to say the least, and clearly misleading as witnessed by your mail. Nontermination is not the precisely the same as _|_. Only certain kinds of nontermination can be modeled by _|_ in a non-strict language. I think one should consider reformulating the paragraph above in future versions of the Haskell report. Therefore, the value of the following infinity is _|_. Right? data Nat = Zero | Succ Nat infinity = Succ infinity No. Consider the following function: f Zero = 0 f (Succ _) = 17 We then have f infinity = f (Succ infinity) = 17, whereas f _|_ = _|_. Thus, f distinguishes infinity and _|_, so they can not be the same. What about infinite lists? For example, is the value of [1 ..] also _|_? No, see above. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The values of infinite lists
Deokhwan Kim: Bjorn Lisper wrote: precisely the same as _|_. Only certain kinds of nontermination can be modeled by _|_ in a non-strict language. What kinds of nontermination are modeled by _|_ in Haskell? Nonterminating computations that never return anything. For instance, inf = inf Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numerical methods in Haskell
I finally got some time to answer Simon's posting: Simon P-J: | Between google searching and looking through the activity | report, I take it that no one has really developed serious | libraries for matrix manipulations, diff eqs, etc. | | Are there any practical reasons for this or is it just a | matter of the haskell community being small and there not | being many people interested in something so specialized? The latter I think, but it's just the sort of thing that a functional language should be good at. Two other difficulties (a) It's hard to compete with existing libraries. The obvious thing is not to compete; instead, just call them. But somehow that doesn't seem to be as motivating. Perhaps some bindings exist though? Hard to compete, yes. But on the other hand, the rewards can be high. Numerical library code (especially matrix libraries) tends to be highly optimized for the hardware architecture at hand. As a consequence a small change in, say, the cache architecture, might require a thorough rewrite of the library code to regain high utilisation of the hardware. This is since languages like Fortran and C force you to code so close to the hardware. A high-level language, with good optimizing compilation, would make also library code more portable across hardware architectures. N.b. these optimizations are non-trivial to say the least. (b) A concern about efficiency, because numerical computation is typically an area where people really care about how many instructions you take. It's a legitimate concern, but I don't think that it'll turn out to be justified. With unboxed arrays, and/or calling external libraries for the inner loops -- and the potential for aggressive fusion and/or parallelism, there is plenty of upward potential. I also want to work on nested data parallelism (a la NESL, and NEPAL) which fits right in here. The number of instructions is only one side of the coin. For high-performance computing, memory issues are at least as important: both the amount of memory used (e.g., will the computation fit into memory at all), and how the memory hierarchy is utilized (caches, TLB:s, virtual memory, ...). This is a really sweet spot of functional languages, and laziness adds to it. On the other hand, the increased abstraction of functional languages gives an optimizing compiler larger freedom to reorder computations and choose memory layouts of data structures like matrices. This is potentially very useful, since optimizing for memory hierarchy utilization typically involves both data layout and order of memory accesses. However, to achieve a good result, the compiler must be able to predict a great deal of the computing and the memory usage. For instance, dynamic memory handling of numeric data structures will surely kill any serious attempt to predict the cache behavior. To achieve good optimizing compilation, we need either very good program analyses, or a library of recursion patterns or templates for which the compiler knows how to allocate memory statically and order the computations well, or possibly both. Some encouraging examples: Sven-Bodo Scholz has achieved very good performance for the restricted functional matrix language SAC, using optimizations for cache. My former student Peter Drakenberg invented a restricted functional matrix language, with analyses to infer matrix sizes statically, and sharing analysis, to find opportunities to allocate memory statically and update in-place. He also got some good experimental figures. This leads me to believe that compilers in more general languages could do something similar, by recognizing certain patterns or through advanced program analyses. However, both these languages are strict, and I am not sure at all how to do this in a lazy language. In any case, this is nontrivial compiler work and considerable research efforts would be needed. Unfortunately, I don't see how to fund such research, since the high-performance computing community largely seems to have given up on functional languages since the demise of the data-flow languages. I'd love to see a little community of matrix manipulators spinning up. Yes. There might me a niche for high-level numerical coding, somehwere where MATLAB is today. MATLAB isn't exactly blazingly fast, still very widespread. On the other hand, MATLAB is already in that niche. The question to answer is what advantages a functional language like Haskell could offer in this niche. We need to come up with these answers, and then convince enough people outside our own community. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numerical methods in Haskell
David Roundy: On Mon, Feb 20, 2006 at 11:47:49AM +0100, Bjorn Lisper wrote: (a) It's hard to compete with existing libraries. The obvious thing is not to compete; instead, just call them. But somehow that doesn't seem to be as motivating. Perhaps some bindings exist though? Hard to compete, yes. But on the other hand, the rewards can be high. Numerical library code (especially matrix libraries) tends to be highly optimized for the hardware architecture at hand. As a consequence a small change in, say, the cache architecture, might require a thorough rewrite of the library code to regain high utilisation of the hardware. This is since languages like Fortran and C force you to code so close to the hardware. A high-level language, with good optimizing compilation, would make also library code more portable across hardware architectures. N.b. these optimizations are non-trivial to say the least. The only particularly relevant numerical libraries today (atlas and fftw) already do far better optimization than any compiler is going to acheive, and in the case of fftw can respond to changes in memory configuration at runtime. In both cases they're written in ANSI C (although the C code for fftw is written by an OCaml program... or at least some dialect of ML). In order to take advantage of cache behavior properly, it's necesary to allow adjustments in the actual algorithm used, which isn't something that a clever compiler is likely to accomplish. That's a valid point. You may want to change, e.g., the size of blocks in a block-oriented matrix algorithm to match the cache. This will, in general, require the use of algebraic laws like associativity and commutativity, which are not valid for floating-point arithmetics and thus can change the numerical behaviour, so a compiler shouldn't fiddle around with them unless under strict control of the programmer. Interestingly, the language invented by my aforementioned former PhD student contains a nondeterministic matrix decomposition primitive, which allows the partitioning of a matrix into a fixed number of blocks, but where block sizes can vary. This is exactly to let the programmer give an optimizing compiler this degree of freedom when deemed safe. Alas, he never got around to any serious experiments with this feature. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First steps in Haskell
Simon P-J: Daniel is right, by definition. He is a new user. He had difficulty. That much is incontrovertible. While he may seem unusual, perhaps he is only unusual in that he's told us about his experience rather than trying Perl instead. For which, much thanks, Daniel! Actually, I have sometimes wished that the various interactive Haskell interfaces had the possibility to enter also declarations interactively, as Daniel originally asked for. Lisp interpreters often support this to some extent, so it is not out of line for a newcomer to expect it also for Haskell. I often use hugs as a calculator, and sometimes it would be very convenient to be able to make one or a few short declarations while making some interactive calculations. It can be quite tedious to create and edit a source code file on the side and then load it, when all you want is a short declaration or two. Would it be that complex to have an interactive interface enter a declarations mode when it sees a declaration coming, and then let it create, compile and load a temporary module when the declaration is finished? Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First steps in Haskell
Simon: Me: | Actually, I have sometimes wished that the various interactive Haskell | interfaces had the possibility to enter also declarations interactively GHCi does. Ah, I see! Does it open a let-environment with a local definition? ghci let f x = hello ghci f True True Hmm, an interesting semantics for f given the declaration :-) But there's no editor -- it's strictly a one-line definition Which is useful enough in many situations. I'll try it out... Björn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some algorithm help with jhc
John Meacham I have started working on jhc more recently and have come across some places where I think my algorithms could be improved but was not sure exactly where to start so thought I would ask the list since perhaps someone here has some insight. After a long time of trying various methods of speeding up the fixpoint iteration of my points-to analysis (the current main bottleneck) I decided to step back and look at the basic problem again. It turns out I can express the problem as one of constraint satisfaction resulting in much smaller code (600 lines vs 2000) and 10fold speedups with my unoptimized first draft solver. It is much faster but still not as fast as I'd like. I don't know a lot about constraint problems, but my intuiton says this particular problem is of a type that should be particularly easy to solve but am uncertain where to start in my searching to find a fast algorithm. My constraints come in two types of rules. Hi, check out the book Principles of Program Analysis by Nielson, Nielson, Hankin (http://www2.imm.dtu.dk/~riis/PPA/ppa.html). It has quite some on constraint solving for program analysis. There are algorithms in that book for set constraint problems that look quite similar to your problem. Björn Lisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python?
Hi all, Finally I found some time to reply to this posting. A couple of years ago we did something called Data Field Haskell, which is Haskell extended with a generalized form of arrays called data fields. Much of the purpose was to investigate convenient and general syntax for array constructions. Data fields are semantically pairs of functions and bounds, where bounds represent sets of indices. Bounds can be pairs of integers representing intervals, but also general finite sets. Certain bounds represent infinite sets, which makes sense in a lazy language. Besides direct notation for creating data fields, Data Field Haskell has a construct forall x - t which defines a data field in a similar way to how lambda-abstraction \x - t defines a function. In addition, the data field defined by a forall-construct has a bound which is derived from the body of the expression. The semantics is derived from the view that data fields (and arrays) are partial functions whose domains do not exceed the index sets defined by their bounds. The forall-construct is intended to provide a simple and powerful syntax for operations on data fields. Let's see below how it matches Jerzy's desired features of an array language: Jerzy: Tim Rowe writes: On 5/11/05, Jerzy Karczmarczuk [EMAIL PROTECTED] wrote: Give me one single language where [3-d arrays are] natural and immediate. I don't know how Matlab does it, but I find the C++ standard library vectorvectorvectorfloat entirely intuitive (apart, perhaps, for the need for those two spaces)! Let's precise what I consider to be important in order to call it natural and immediate. And, in general, useful. 1. The definition of a concrete object, not just its type, but, say, the initialization with constants. Or/and, global initialization with zeros. Since Data Field Haskell is declarative, initialization and definition is the same. Constant data fields are easy to define, viz. forall x - 1, a data field filled with ones forall (i,j) - if i == j then 1 else 0, a unit matrix forall (i,j) - i + j, a Vandermonde matrix All these data fields are infinite, and the first is also dimension-polymorphic (through the usual polymorphism in Haskell). Data Field Haskell has an operator for explicit restriction of data fields, and a data field may also be implicitly restricted from the context where it occurs. 2. Easy synthesis of multi-dim matrices out of planes, of submatrices of lesser dimensions; Not directly expressible, but it is possible to define a binary operator to, say, concatenate a 2-D matrix on some given side of a 3-D matrix. it can be an 'overlay', like, say, making a colour image out of three R/G/B planes, or making a 3D surfaces, or aking tensors through external products. Say, an outer product of two vectors a, b: forall (i,j) - a!i * b!j 3. Easy indexing, and not only A[i][j][k], etc., but slicing, the extraction of sub-dimensional matrices, e.g., one column vector out of a 2D matrix in Matlab: A(3,:). Also, extracting parts (e.g. sub-images). A(3,:) is expressed as forall j - a!(3,j). Or, selecting a plane out of a 3D-matrix: forall (i,j) - a!(i,3,j). Or, selecting the main diagonal of a matrix: forall i - a!(i,i). Extracting parts is done with the explicit restriction operator \: a \ (3,3):(10,20), selecting submatrix of a a \ predicate (\(i,j) - a!(i,j) 0), selecting the subfield of a where it is strictly greater than zero (this is a sparse data field) Also, in mathematical context, intelligent indexing, e.g. treating a matrix as implicitly anti-symmetric. Here the CAS systems as Maple or Mathematica provide the adequate tools. C++ of course doesn't, unless you overload [] yourself. All representation issues are hidden in Data Field Haskell, so there is no direct counterpart. However, it is of course possible to define a data structure of your own and then wrap it up as a data field by providing a bound and a function from indices to values. 4. Readable iterators, perhaps something more compact than insipid do-loops. There are folds for data fields. These can be used for reduction operations over data fields. In a sense, forall-abstraction is also a kind of iterator (although parallel since it does not impose any order of evaluation between the elements of the data field). 5. If those matrices are used as mathematical objects: tensors, etc., I want to have some simple notation for inner multiplications/ contractions, etc. This is not just the syntax problem, but the existence of good libraries as well... You can use folds inside a matrix to, e.g., sum all rows in a matrix. Here is an example of a function that does one iteration in Jacobi's method for iteratively solving the linear equation system ax = b: jacobi_iter a b x = forall i - ((b!i) - dfSum ((forall j - a!(i,j)*(x!j)) \ predicate (\j - j /= i)))/a!(i,i) 6. Reshaping of those arrays. I thought that Matlab
Re: [Haskell-cafe] Integrating Haskell into a J2EE environment
I'm surprised that nobody has yet mentioned the ICFP2000 paper Composing Contracts: An Adventure in Financial Engineering by SPJ, Jean-Marc Eber, and Julian Seward. It seems to me that it could provide quite relevant reading. Björn Lisper Paul Hudak: I wouldn't write off Haskell so quickly. All of what Shoeb describes concerning DSL issues might be much more easily solved in Haskell, and will certainly be more flexible than a hard-wired approach. The J2EE interface might be ugly, but if the functionality needed is not too great it might not be too bad. Generally speaking, these kinds of apps -- in this case a DSL for high-level business rules -- sounds like just the sort of thing that Haskell is good for. -Paul Doug Kirk wrote: You're going to spend alot of time marshalling between Java and Haskell values, and you'll either have to do it via JNI or by using pipes [as in System.exec(haskellprogram param param param)], both of which are ugly for a Java app. Have you looked at Jython and JRuby? Jython is an implementation of a Python interpreter in 100% Java, and JRuby implements a Ruby interpreter in 100% Java. Those might get the job done faster than having to delve into the native layer. (Not to mention learning how to use Haskell in order to implement what you want--not a trivial task in itself!) Take care, --doug On Oct 5, 2004, at 4:33 PM, Bhinderwala, Shoeb wrote: Hi All, I am new to Haskell and this mailing list. We have a system that uses a custom high-level language to express high-level business rules. Expressions in the high-level language get compiled to Java bytecode. We express the grammar using BNF notation as required by the javacc parser tool. This is then converted to an AST using jjtree and from there we build the final Java code. Our language could be considered a domain-specific language (DSL) and is used by our business users to express very high-level business logic. The language currently is very limited - we support boolean logic, function invocations and if-then statements. We want to convert it into a more powerful scripting language so that even lower level business logic can be expressed in it. I came across a few papers that talk about writing a DSL with Haskell as the underlying support language. How is this done. Is it possible to create a sort of domain specific business scripting language easily. How does that then compile to Haskell code. And how can the Haskell code be invoked from Java. Essentially, I am thinking if I could use a Haskell like DSL language to express our business rule logic and then be able to integrate into and invoke the logic from a J2EE app server environment. Has anybody done anything like this with Haskell. -- Shoeb ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe This communication is confidential and may be legally privileged. If you are not the intended recipient, (i) please do not read or disclose to others, (ii) please notify the sender by reply mail, and (iii) please delete this communication from your system. Failure to follow this process may be unlawful. Thank you for your cooperation. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe -- Professor Paul Hudak Chair, Dept of Computer Science Office: (203) 432-1235 Yale University FAX:(203) 432-0593 P.O. Box 208285 email: [EMAIL PROTECTED] New Haven, CT 06520-8285 WWW:www.cs.yale.edu/~hudak ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: pet project - 7 Millennium Prize problemss
--- Keith Wansbrough [EMAIL PROTECTED] wrote: Christopher Milton [EMAIL PROTECTED] writes: I think Haskell can be used to solve several, if not all, of the seven problems. Now I have to decide which problem to tackle first. (a joke, I assume...) http://www.claymath.org/Millennium_Prize_Problems/ 1. Birch and Swinnerton-Dyer Conjecture 2. Hodge Conjecture 3. Navier-Stokes Equations 4. P vs NP 5. Poincare Conjecture 6. Riemann Hypothesis 7. Yang-Mills Theory Any ideas how to solve any of these, with Haskell or otherwise? module P where import Complexity_class(np) p = np :-) Björn Lisper ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: partial application
Cagdas Ozgenc: That's right. I was thinking of the following syntax. I orginally had the idea for C++, where you can't do partial application at all. f x y z=... f # 3 4 omitting the first parameter, and Array languages with true multidimensional arrays often have a this kind of syntax to extract subarrays, for instance A(*,J) or A(,J) to extract column J from the matrix A. Now, if you think about arrays as partial functions from indices to values, then row J of matrix A is precisely \I - A(I,J). This syntax can be very convenient for array computations. Björn Lisper ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Compiler error using IO
Zhanyong Wan: Here here. I think that the poor compiler error messages in Haskell are a very major hurdle to learning the language. Adrian Hey: Which compiler are you talking about? Bad error messages are not a valid critisism of the Haskell Language IMHO. But there are language features in Haskell that makes it hard to produce good error messages. Implicit typing, for instance: in an explicitly typed language it is clear where in the code a type error occurs, but with implicit typing there are often many possibilities and it is not always evident where the culprit is. (Haskell compilers seem simply to report the line where the unification fails. Am I right?) Furthermore, semantically distant expressions can be syntactically close in Haskell, so a syntax error actually gives a syntactically correct expression. Often this yields a type error instead, which then may show up as an error message for some totally different part of the code... Higher-orderness increases the risk. An example is inadvertently writing f g y for f (g y) which then is interpreted as (f g) y and will yield incorrect constraints on the types of f, g, and y. Is there any work being done on intelligent error messages for higher-order implicitly typed languages? One could perhaps come up with search strategies that tries to find a minimal number of program transformations (edit distance) that yields a syntactically correct and well-typed program. For instance, in the case of type errors one could try to search for the minimal number of definitions that have to be removed to make the remaining program well-typed, and then report the removed definitions as likely sources of the errors. Has anyone done this? Björn Lisper ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: A sample revised prelude for numeric classes
Tom Pledger: Brian Boutel writes: : | Having Units as types, with the idea of preventing adding Apples to | Oranges, or Dollars to Roubles, is a venerable idea, but is not in | widespread use in actual programming languages. Why not? There was a pointer to some good papers on this in a previous discussion of units and dimensions: http://www.mail-archive.com/haskell@haskell.org/msg04490.html The main complication is that the type system needs to deal with integer exponents of dimensions, if it's to do the job well. Andrew Kennedy has basically solved this for higher order languages with HM type inference. He made an extension of the ML type system with dimensional analysis a couple of years back. Sorry I don't have the references at hand but he had a paper in ESOP I think. I think the real place for dimension and unit inference is in modelling languages, where you can specify physical systems through differential equations and simulate them numerically. Such languages are being increasingly used in the "real world" now. It would be quite interesting to have a version of Haskell that would allow the specification of differential equations, so one could make use of all the good features of Haskell for this. This would allow the unified specification of systems that consist both of physical and computational components. This niche is now being filled by a mix of special-purpose modeling languages like Modelica and Matlab/Simulink for the physical part, and SDL and UML for control parts. The result is likely to be a mess, in particular when these specifications are to be combined into full system descriptions. Bjrn Lisper ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
