[Haskell-cafe] Re: [Haskell] ANNOUNCE: GHC survey results
[moved to haskell-cafe] On Tue, 2005-06-28 at 14:46 -0700, John Meacham wrote: Unfortunatly hat suffers from the same problem that pretty much every non-trivial preprocessor does, as soon as you start using ghc's special or experimental features that have not been added to hat yet, they stop working. I agree this is a problem. [snip] I am not sure what the general solution would be. perhaps hat being integrated with ghc? I think it is preferable to keep them separate. Already a big effort was put into making hat independent of nhc98. There will always be more tools that Haskell could use, which must transform the source code one way or another. I'd rather not see them all be pushed inside ghc, or whatever other compiler was popular at the time. It's probably better for ghc's maintainability to keep these tools out of its source tree (pure speculation on my part though). or better yet would be a standard interface for ghc to call a preprocessor but at some intermediate level where most of the extensions have been sugared away but most of the original source structure still exists... the nice thing about a standard interface would be that jhc and other compilers could support it too. It wouldn't even need to be a plugin based thing, but rather an executable that ghc can run and pass commands to it on stdin and read results on stdout. Sounds nicer. Perhaps GHC-as-a-library might be close to what is needed. There is a danger that we won't be able to settle upon what is the right core language to use, and some tools will be left out, thus reverting to the solution employed by hat at the moment. Being able to just work on any unmodified program the compiler supports is a huge feature. Yes. The problem is that Haskell is being torn in two directions. One direction is a research vehicle. The other direction is a work-horse. GHC sits somewhere in the middle, and does an amazing job too. The trouble is that it has become a fast moving target. Overall I think Hat's solution is a reasonable compromise between the competing needs of the tool. If anything I would like to see the Haskell community produce a Haskell front end which was compiler neutral. That would facilitate many interesting projects, and that might even help with the need to support new extensions as they come along. There are already some candidates floating around, but it seems they are not widely adopted. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] matrix computations based on the GSL
Let me a bit elaborate on what I wrote yesterday. On Wed, 29 Jun 2005, Henning Thielemann wrote: I think matrices and derivatives are very different issues. I have often seen that the first derivative is considered as vector, and the second derivative is considered as matrix. In this spirit it is used like x^T * (D2 f)(x) * x It should be h^T * D2 f x * h (if at all the transposition notation is used) if the curvature of f at x is meant. but this is only abuse of the common multiplication definitions. A good interpretation and notation should seamless extend to higher derivatives. But the interpretation above does not work in higher dimensions. I like the following type for derivation. derive :: ((i - a) - b) - ((i - a) - (i - b)) Here i is the index type, (i - a) is the vector type, b is the type the vector function maps to. Its derivative has the same type of argument, but the result is a vector with indices of type i. You see that it is easy to repeat the application of 'derive', just replace b by say i-b. The second derivative yields vectors of type (i - i - b). This can be interpreted as matrix because it has two indices. But this is certainly not a matrix which represents a linear mapping as usual, but it is a matrix representing a bilinear form. The only thing we need is a multiplication to reduce one level of indices. mul :: (i - c) - (i - b) - b Though, what we still need is a general (overloaded?) definition of the scaling of b by c and a sum of b. That is b must be a vector space with respect to c. 'derive' in this form is a bundled partial derivative, but it can be identified with the total derivative. That is derive f x i is the partial derivative of f at x with respect to the i-th component derive f x is the total derivative of f at x. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] ANNOUNCE: GHC survey results
| If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted. Well, ghc -c -fext-core Foo.hs is a Haskell front end that produces System F code (External Core), in a file Foo.hcr. I'm not sure whether that was what you meant. However, External Core doesn't seem to have really caught on. Only 5% said it was essential, with another 16% saying nice to have. I'm sure there's room to improve the ExtCore route. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] ANNOUNCE: GHC survey results
On Thu, 2005-06-30 at 10:36 +0100, Simon Peyton-Jones wrote: | If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted. Well, ghc -c -fext-core Foo.hs is a Haskell front end that produces System F code (External Core), in a file Foo.hcr. I'm not sure whether that was what you meant. That is one option, but it wasn't really what I meant. I was thinking of plain old Haskell library code that implements Lexer, Parser, Desugar, Type Inference etc. All the bits that happen at the front of a Haskell compiler. This is what hatchet was supposed to be, and may one day become. I've tried in the past to pull the front end off ghc and nhc98 without much luck. Though it looks like ghc-as-a-library might be just what the doctor ordered. There is also the Programmatica project which seems to do a lot of what I'm thinking of already. However, External Core doesn't seem to have really caught on. One problem is that different tools will want different views of the code. External Core is probably too far away from the original source for something like hat. Only 5% said it was essential, with another 16% saying nice to have. I would hazard a guess that fewer than 5% of GHC's users are writing source transformation tools :) I'm sure there's room to improve the ExtCore route. You are right, and to be honest I haven't really given much thought to that route until now. Thanks for the pointer. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: GHC survey results
Simon Peyton-Jones [EMAIL PROTECTED] writes: | If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted. Well, ghc -c -fext-core Foo.hs is a Haskell front end that produces System F code (External Core), in a file Foo.hcr. I'm not sure whether that was what you meant. External Core is great for some purposes - if you want to play with new optimisation techniques for instance. A tracing system like Hat however wants to have lots of direct linkage back to the original source code. External core doesn't bear a terribly close resemblence to the source - it would require a significant amount of re-sugaring for presentation to the user of Hat. It also loses the actual location of expressions (line/column), although perhaps GHC-as-library would be better in this respect. The ideal front-end for a syntax-directed tool like Hat consists solely of a lexer/parser to an abstract syntax tree, with no desugaring whatsoever, and no typechecking. This is essentially what we have at the moment, but based on nhc98's front-end. For better coverage of language extensions, ghc's parser might be preferable. One can imagine that other tools would want to plug into the pipeline at differents points (after desugaring but before type-checking; after type-checking; etc.) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] programatica and haddock
Hi,
Bernard Pope wrote:
There is also the Programmatica project which seems to do a lot of what
I'm thinking of already.
Yes, programatica does a good job. We have switch from using Hatchet to
Programatica (and we may switch to the ghc frontend promised for ghc-6.6
that we would need to extend by formulas for specifications)
Programatica has an alternative way for producing html documentation
from Haskell sources. browse
http://www.cse.ogi.edu/~hallgren/Programatica/tools/pfe.cgi
I would like to see the advantages of both, programatica's documentation
generation and haddock, to be united. (programatica sources don't go
through haddock and have few type signatures that haddock could exploit,
and haddock comments are useless for programatica.)
Unfortunately, the markup used by both programs is different. {-+ in
programatica and {- | in haddock.
Is there any chance that both documentation approaches could be streamlined?
Christian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
On Wed, Jun 29, 2005 at 10:23:23PM +0200, Henning Thielemann wrote: More specific: You give two different things the same name. You write A*B and you mean a matrix multiplication. Matrix multiplication means finding a representation of the composition of the operators represented by A and B. But you also write A*x and you mean the matrix-vector multiplication. This corresponds to the application of the operator represented by A to the vector x. You see: Two different things, but the same sign (*). Why? You like this ambiguity because of its conciseness. You are used to it. What else? But you have to introduce an orientation of vectors, thus you discriminate two things (row and column vectors) which are essentially the same! What is the overall benefit? I just wanted to insert a few thoughts on the subject of row and column vectors. (And I'm not going to address most of the content of this discussion.) If we support matrix-matrix multiplication, we already automatically support matrix-column-vector and row-vector-matrix multiplication, whether or not we actually intend to, unless you want to forbid the use of 1xn or nx1 matrices. So (provided we *do* want to support matrix-matrix multiplication, and *I* certainly would like that) there is no question whether we'll have octavish/matlabish functionality in terms of row and column vectors--we already have this behavior with a single multiplication representing a single operation. There is indeed a special case where one or more of the dimensions is 1, but it's just that, a special case, not a separate function. If you want to introduce a more general set of tensor datatypes, you could do that, but matrix arithmetic is all *I* really need. I agree that when you add other data types you'll need other operators (or will need to do something more tricky), but starting with the simple case seems like a good idea, especially since the simple case is the one for which there exist fast algorithms (i.e. level 3 BLAS). There are good reasons when if I've got a set of vectors that I'd like to multiply by a matrix that I should group those vectors into a separate matrix--it's far faster (I'm not sure how much, but usually around 10 times faster, sometimes more). In fact, I'd think it's more likely that a general tensor library will be implemented using matrix operations than the other way around, since it's the matrix-matrix operations that have optimized implementations. In short, especially since the folks doing the work (not me) seem to want plain old octave-style matrix operations, it makes sense to actually do that. *Then* someone can implement an ultra-uber-tensor library on top of that, if they like. And I would be interested in a nice tensor library... it's just that matrices need to be the starting point, since they're where most of the interesting algorithms are (that is, the ones that are interesting to me, such as diagonalization, svd, matrix multiplication, etc). -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
On Thu, 30 Jun 2005, David Roundy wrote: If we support matrix-matrix multiplication, we already automatically support matrix-column-vector and row-vector-matrix multiplication, whether or not we actually intend to, unless you want to forbid the use of 1xn or nx1 matrices. So (provided we *do* want to support matrix-matrix multiplication, and *I* certainly would like that) there is no question whether we'll have octavish/matlabish functionality in terms of row and column vectors--we already have this behavior with a single multiplication representing a single operation. Of course, I only wanted a separate vector type (which also means a separate matrix-vector multiplication) and I argued against a further discrimination of row and column vectors. If you want to introduce a more general set of tensor datatypes, Did someone requested tensor support? At least not me. I used the tensor example to show that MatLab throws them all together with matrices and vectors and I wanted to give an idea how to make it better by separating them. In short, especially since the folks doing the work (not me) seem to want plain old octave-style matrix operations, it makes sense to actually do that. *Then* someone can implement an ultra-uber-tensor library on top of that, if they like. And I would be interested in a nice tensor library... it's just that matrices need to be the starting point, Matrices _and_ vectors! Because matrices represent operators on vectors and it is certainly not sensible to support only the operators but not the objects they act on ... Adding a vector type by a library that is build on top of a matrix library seems to me like making the first step after the second one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
On Thu, Jun 30, 2005 at 02:20:16PM +0200, Henning Thielemann wrote: On Thu, 30 Jun 2005, David Roundy wrote: If we support matrix-matrix multiplication, we already automatically support matrix-column-vector and row-vector-matrix multiplication, whether or not we actually intend to, unless you want to forbid the use of 1xn or nx1 matrices. So (provided we *do* want to support matrix-matrix multiplication, and *I* certainly would like that) there is no question whether we'll have octavish/matlabish functionality in terms of row and column vectors--we already have this behavior with a single multiplication representing a single operation. Of course, I only wanted a separate vector type (which also means a separate matrix-vector multiplication) and I argued against a further discrimination of row and column vectors. If you want to introduce a more general set of tensor datatypes, Did someone requested tensor support? At least not me. I used the tensor example to show that MatLab throws them all together with matrices and vectors and I wanted to give an idea how to make it better by separating them. I disagree. Vectors *are* tensors... and once you've added rank-1 tensors, you'll also be wanting to add support for rank-0 tensors. These are nice objects (and would be nice to support eventually), but they add considerable complexity. There's only one matrix-matrix multiplication, but there are two vector-vector multiplications, two vector-matrix multiplications. All four of these multiplications can be expressed in terms of the single matrix-matrix multiplication. I agree that if we introduce a vector type there's no reason to introduce separate row and column vectors, but I think we can get by quite well for many purposes without introducing the vector type, which adds so much complexity. I guess I've left out the .* pointwise multiply, probably because I'm a physicist and am tensor-biased, and it's not a tensor operation in the physics sense (it doesn't behave right under unitary transformations of its arguments). In short, especially since the folks doing the work (not me) seem to want plain old octave-style matrix operations, it makes sense to actually do that. *Then* someone can implement an ultra-uber-tensor library on top of that, if they like. And I would be interested in a nice tensor library... it's just that matrices need to be the starting point, Matrices _and_ vectors! Because matrices represent operators on vectors and it is certainly not sensible to support only the operators but not the objects they act on ... Adding a vector type by a library that is build on top of a matrix library seems to me like making the first step after the second one. No, matrices operate on matrices and return matrices. This is the wonderful thing about matrix arithmetic, why it's unique, and why I'd like to have a library that supports matrix arithemetic. Tensors are also nice, but are much more complicated, since most tensor multiplications change the rank of the tensor--and that complication is precisely what you want. You're taking an interperetation of what you mean by the math and wanting to encode it in the type system. Matrix arithmetic is entirely self-contained, and I'd like to have *that* reflected in the type system. -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
David Roundy and Henning Thielemann have been arguing about the nature of vectors and matrices, in particular saying: On Thu, Jun 30, 2005 at 02:20:16PM +0200, Henning Thielemann wrote: On Thu, 30 Jun 2005, David Roundy wrote: Matrices _and_ vectors! Because matrices represent operators on vectors and it is certainly not sensible to support only the operators but not the objects they act on ... Adding a vector type by a library that is build on top of a matrix library seems to me like making the first step after the second one. No, matrices operate on matrices and return matrices. This is the wonderful thing about matrix arithmetic, why it's unique, and why I'd like to have a library that supports matrix arithemetic. The really funny thing about that exchange is that you are *both right* ! You're just using different interpretations of the same objects. 1) Matrices represent linear operators which naturally act (via application) on vectors 2) Matrices of compatible sizes, almost form a non-commutative graded ring. It does not matter what a matrix represents here, this is true purely algebraically. [to be a proper ring, the ``compatible sizes'' condition would need to be dropped] There is a problem that the _types_ associated with both interpretations are quite different. But if you want 2 different products on vectors (inner and outer) represented as matrices, you have no choice -- the ``inner product'' will return a 1x1 matrix, not a real. The same thing is true for differential operators, BTW. They can either represent actions on spaces of smooth-enough functions, or represent elements of a Weyl Algebra (or Ore Algebra if you really want to be algebraic). You end up having the dichotomy of algebraic D-modules versus analytic D-modules, where they share a number of theorems, but the ``corner'' cases behave quite differently. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unicode.hs (was: RE: Re[2]: ANNOUNCE: GHC survey results)
Hi, Vadim Konovalov wrote: === that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC? === Clarifying on Unicode stuff in GHC I contributed: It is in CVS now, and I believe will be in 6.4.1 At least it shows up at: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/GHC/Unicode.hs?rev=1.14 (MAIN branch) But this module is just an interface to another module, WCsubst.c: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/WCsubst.c?rev=1.3 which in turn was produced from UnicodeData.txt (? I believe this is correct name of the file from www.unicode.org) by the shell script: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/ubconfc?rev=1.2 This API handles simple case conversions (Char - Char), and categorization of characters according to what is in the UnicodeData.txt file. Before (i. e. up to and including 6.4), Unicode stuff was handled through wc* locale based functions for wide chars conversion. Since not every installation of Unix (or some other OS) has this set up properly (mine was not: personal itch), this code was proposed for GHC and finally made it there. Hope this explains everything. In fact, Unicode.hs itself is not completely mine ;) PS: Autrijus (the guy who develops Pugs) included those files on his own because 6.4 was just out, and Unicode stuff was not there yet. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
Henning Thielemann wrote: I'm uncertain about how who want to put the different kinds of multiplication into one method, even with multi-parameter type classes. You need instances (*) :: Matrix - Matrix - Matrix (*) :: RowVector - Matrix - RowVector [many other instances removed.] Definitely not. You could do: Data Orientation = Row | Column Data Vector a = Vector Orientation [a] (well, the size should be in there too, but I'll skip that). That easily takes care of most of the complexity. And you can easily define operations that can choose to ignore Orientation if they wish (like inner product of vectors). I said that this design works. Of course, implementing it along the lines you suggested in this email would have been idiotic - there is a better way to do it. If you go back to my original email, the sheer complexity of all the combinations possible (several thousand) should have given you a clue that your proposal above was a complete and utter non-starter. Is the design discussion related to linear algebra for Maple documented somewhere? Unfortunately not. The design is documented, with some of the discussion captured, but those documents are still in internal papers to Maplesoft Inc. There is no profit to be made in publishing it (in their estimation), so that information remains internal. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell parser for java bytecode?
Jerzy Karczmarczuk asked: Why for goodness' sake, people interested in Haskell *should* worry about parsing of Java bytecode chunks? Are you asking why I'm interested in bytecode instead of source code, or are you asking why I'm interested in Java at all? One answer to the first question is: because java bytecode is a simpler problem domain than java source. For example, name resolution is trivial when working with bytecode (there's no ambiguity between package/class/variable names, inherited names are already resolved, overloaded functions are already resolved, etc). Also, many of the newer features of java disappear at the bytecode level: inner classes, generics, the new foreach statement, etc. Another answer to the first question is: because java bytecode can be used as a target for several languages these days, and by working with it directly, I can work with any language that compiles to the jvm, rather than restricting myself just to java. The answer to the second question is: because the rest of the world matters to some people. Kimberley Burchett http://www.kimbly.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
On Thu, 30 Jun 2005, Jacques Carette wrote: Henning Thielemann wrote: I'm uncertain about how who want to put the different kinds of multiplication into one method, even with multi-parameter type classes. You need instances (*) :: Matrix - Matrix - Matrix (*) :: RowVector - Matrix - RowVector [many other instances removed.] Definitely not. You could do: Data Orientation = Row | Column Data Vector a = Vector Orientation [a] In the first mail you wrote 9. There are row vectors and column vectors, and these are different types. You get type errors if you mix them incorrectly. I interpreted that you want to encode the information Row or Column into the type. This sounds reasonable to me because multiplying e.g. a column vector by a matrix is so obviously wrong that it should be detected statically. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
Henning Thielemann wrote: Data Orientation = Row | Column Data Vector a = Vector Orientation [a] In the first mail you wrote 9. There are row vectors and column vectors, and these are different types. You get type errors if you mix them incorrectly. I interpreted that you want to encode the information Row or Column into the type. This sounds reasonable to me because multiplying e.g. a column vector by a matrix is so obviously wrong that it should be detected statically. Sorry, I should have been more precise, I used too straightforward an encoding from Maple (which is dynamically typed) into Haskell. I should have used the usual type-trickery to encode the Orientation as 2 different types, to have ``types reflect values''. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
On Thu, 30 Jun 2005, Jacques Carette wrote: Henning Thielemann wrote: Data Orientation = Row | Column Data Vector a = Vector Orientation [a] In the first mail you wrote 9. There are row vectors and column vectors, and these are different types. You get type errors if you mix them incorrectly. I interpreted that you want to encode the information Row or Column into the type. This sounds reasonable to me because multiplying e.g. a column vector by a matrix is so obviously wrong that it should be detected statically. Sorry, I should have been more precise, I used too straightforward an encoding from Maple (which is dynamically typed) into Haskell. I should have used the usual type-trickery to encode the Orientation as 2 different types, to have ``types reflect values''. You mean phantom types? data Vector orient a = Vector [a] I'm excited to add lots of new orientations then! :-] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: haskell parser for java bytecode?
On Thu, Jun 30, 2005 at 11:02:47AM -0400, Kimberley Burchett wrote: Jerzy Karczmarczuk asked: Kimberley Burchett writes: I'm interested in using haskell to do static analysis of java bytecode. To my surprise, I wasn't able to find any existing haskell libraries for parsing java .class files. Why for goodness' sake, people interested in Haskell *should* worry about parsing of Java bytecode chunks? Are you asking why I'm interested in bytecode instead of source code, or are you asking why I'm interested in Java at all? Jerzy is asking why you are surprised. There's nothing wrong in being interested in Java/bytecode, but it's a bit strange to expect every language to have a library for reading Java bytecode. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: Re[2]: ANNOUNCE: GHC survey results
btw, in Pugs sources (http://search.cpan.org/CPAN/authors/id/A/AU/AUTRIJUS/Perl6-Pugs-6.2.7.tar.g z) there is Unicode.hs module wich can classify and convert full range of Unicode symbols under any OS. i don't understand - is this module already included in GHC 6.5? if not, it would be good addition that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell parser for java bytecode?
On Thu, 30 Jun 2005, Tomasz Zielonka wrote: Jerzy is asking why you are surprised. There's nothing wrong in being interested in Java/bytecode, but it's a bit strange to expect every language to have a library for reading Java bytecode. My apologies. I didn't mean to imply that there *should* be a library for this, or that the haskell community was in any way failing to live up to my expectations. I was just surprised that nobody had gotten around to doing it before me. Kimberley Burchett http://kimbly.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell parser for java bytecode?
Kimberley Burchett writes: Jerzy Karczmarczuk asked: Why for goodness' sake, people interested in Haskell *should* worry about parsing of Java bytecode chunks? Are you asking why I'm interested in bytecode instead of source code, or are you asking why I'm interested in Java at all? One answer to the first question is: because java bytecode is a simpler problem domain... The answer to the second question is: because the rest of the world matters to some people. === Actually, I didn't ask why *YOU* are interested in Java, sorry for the misunderstanding. You do whatever you wish, and I respect it. All is very fine, and far from any personal doubts. I reacted because you said that you *were surprised* that Haskell milieu did not elaborate libraries for parsing of Java code, as it were natural that everybody, who develops the support for pure functional languages should immediately think about parsing of Java code. I found it a bit preposterous. People interested in Haskell did not address you, but the developers of Haskell. Also, I underlined the word *should*. Had your question been formulated more modestly, in a less revindicative way, I wouldn't even open my mouth. That's all to it. The project of writing such a parser may be useful and interesting, but it is far from being the ultimate goal of haskellians... Of course, this is just my private opinion. Now, if YOU are really interested in programming in Haskell, and you need such parser, go ahead. Convince people reading this list - I do speak seriously - that there exists a fabulous application niche for Haskell, that they might become famous and rich doing such thing. All the best. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Dynamic binding / Scala paper
On Friday 24 June 2005 14:28, Andreas Rossberg wrote: Ralf Lammel wrote: I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Off-hand, I recall a paper by Martin Odersky and the Scala people discussing their approach to the Expression Problem, and a related paper by Jacques Garrigue, where he proposes to solve it using OCaml's polymorphic variants. Both should be easy to dig up with Google, and probably contain further pointers. Inspired by this post I read some of the available papers on Scala (among them the above). I find Scala very, very interesting. However, I am quite curious how the inventors of Scala managed to to write 100's of dense pages of papers, citing influences from 10's of other languages... ...and at the same time completely fail to even once mention Eiffel, which shares a lot of interesting features with Scala. The paper An overview of the Scala Programming Language lists allogether 10 Authors. Have really none of those 10 authors ever heard of Eiffel and its famous attitude of we are using multiple inheritance more often than loops? Ok, Eiffel has a few holes in its type-system, doesn't naturally integrate with Java/.Net, and doesn't support XML directly. And Eiffel does not support deferred types in class definitions. But: IIRC, Eiffel was the first OO-language that almost completely solved the multiple-inheritance problem, providing solutions very similar to ones in Scala. For instance, mixin-type inheritance is easily possible in Eiffel. Also, Eiffel provides the same kind of automatic replacement of deferred (expected) methods and attributes with concrete (implemented) ones. In a few places, Eiffel is even more general. For instance, in Eiffel you can even inherit two concrete methods with the same name. In order to resolve the name conflict you just rename one of them in your derived class. Furthermore, Eiffel does not distinguish between class and trait (although maybe the distinction is a good idea) without placing any restrictions on classes. Another nice feature of Eiffel is that access can be restricted in a very fine grained way, i.e. for each single method (or group of methods) you can give a list of classes that are allowed to call this method. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Dynamic binding / Scala paper
Benjamin == Benjamin Franksen [EMAIL PROTECTED] writes: Benjamin Ok, Eiffel has a few holes in its type-system, doesn't Benjamin naturally integrate with Java/.Net, and doesn't support In what way? Eiffel compilers target these systems successfully. Benjamin XML directly. How do you mean? What language DOES support XML directly? XSLT - yes (which is slightly more on topic here, as it is a pure functional language), but others? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
On Wednesday 29 June 2005 22:54, Henning Thielemann wrote:
On Wed, 29 Jun 2005, Dan Piponi wrote:
On Wed, 29 Jun 2005, Jacques Carette wrote:
Distinction of row and column vectors is a misconcept
Row and column vectors are sometimes worth distinguishing because
they can represent entirely different types of object. For example,
if a column vector represents an element of a vector space V over a
field F, then row vectors can be used to represent elements of the
dual space, V* = {f:V-F, f linear}. Quite different objects and in
some applications it makes sense to distinguish them.
If f is a function
f :: a - a
then, of course, the dual space is again a vector space. But it
contains functionals and they have very different type, namely
f' :: (a - a) - a
If dual spaces would represent the concept of transposition then the
dual space of the dual space should be original space. It is not, it
can even not be identified in many cases, only if the space is
reflexive. f'' :: ((a - a) - a) - a
has certainly a type very different from (a - a)!
IIRC, finite-dimensional spaces are always reflexive, as witnessed by
the identification of elements of the dual space f with the vector y in
f x = x,y (real scalars, here), where the identification is, of
course, with respect to a given basis. I bet you know all this very
well!
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Dynamic binding / Scala paper
On Thursday 30 June 2005 23:21, Colin Paul Adams wrote: Benjamin == Benjamin Franksen [EMAIL PROTECTED] writes: Benjamin Ok, Eiffel has a few holes in its type-system, doesn't Benjamin naturally integrate with Java/.Net, and doesn't support In what way? Eiffel compilers target these systems successfully. Which Eiffel compiler allows to use Java classes directly in your Eiffel code, just as if they were Eiffel classes? Benjamin XML directly. How do you mean? What language DOES support XML directly? XSLT - yes (which is slightly more on topic here, as it is a pure functional language), but others? Well, I was talking about a concrete language, didn't I? See http://scala.epfl.ch/docu/files/ScalaOverview.pdf Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
