[Haskell-cafe] Re: Problems with building haskell-jvm-bridge-0.3.RC1
In article <[EMAIL PROTECTED]>, Dmitri Pissarenko <[EMAIL PROTECTED]> wrote: > I'm trying to build Haskell-JVM bridge (http://sourceforge.net/projects/jvm- > bridge/) under Windows (cygwin) and with Java 1.5. > > I can execute "configure" without errors. > > When I execute make, I get a lot of errors. I'm not really supporting Windows myself, but Thomas Pasch is responsible for getting it to work on Windows. See Building.win32. His email address is <[EMAIL PROTECTED]>. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: File path programme
On 2005-01-31, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Peter Simons <[EMAIL PROTECTED]> writes: > >> http://cryp.to/pathspec/PathSpec.hs > >> There also is a function which changes a path specification >> into its canonic form, meaning that all redundant segments >> are stripped. > > It's incorrect: canon (read "x/y/.." :: RelPath Posix) gives "x", > yet on Unix they aren't equivalent when y is a non-local symlink > or doesn't exist. True, but most people want x when they construct x/y/.., in makefiles, install scripts, etc. It's not "OS thinks is the same", and shouldn't be marketed as such, but it is useful as "what people generally want to refer to". -- Aaron Denney -><- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: File path programme
Sven Panne writes: > OK, but even paths which realpath normalizes to different > things might be the same (hard links!). Sure, but paths it normalizes to the same thing almost certainly _are_ the same. ;-) That's all I am looking for. In general, I think path normalization is a nice-to-have feature, not a must-have. > IMHO we can provide something like realpath in the IO > monad, but shouldn't define any equality via it. You are right; Eq shouldn't be defined on top of that. And couldn't even, if normalization needs the IO monad anyway. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: File path programme
Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) will find it. Here is the BUGS listing from 'man realpath' on my system: Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing memory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. > My interpretation is that two paths are equivalent iff they > point to the same target. You might do better (on *nix) to check if two paths terminate in the same filesystem and then see if the inode numbers match (with some stat variant). Even that may break down for networked filesystems or FAT wrappers or other things that may lie about the inode number. You could also unravel the path manually, but that seems error-prone and unportable. This strikes me as yet another case of a simple-seeming operation that simply cannot be implemented correctly on file names. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: File path programme
Peter Simons wrote: Sven Panne writes: > Hmmm, I'm not really sure what "equivalence" for file > paths should mean in the presence of hard/symbolic links, > (NFS-)mounted file systems, etc. Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) will find it. OK, but even paths which realpath normalizes to different things might be the same (hard links!). This might be OK for some uses, but not for all. My interpretation is that two paths are equivalent iff they point to the same target. [...] This would mean that they are equal iff stat(2) returns the same device/inode pair for them. But this leaves other questions open: * Do we have something stat-like on every platform? * What does this mean for network file systems, e.g. in the presence of the same files/directories exported under different NFS mounts? I don't have enough books/manual pages at hand to answer this currently... * What does this mean if the file path doesn't refer to an existing file/directory? IMHO we can provide something like realpath in the IO monad, but shouldn't define any equality via it. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: File path programme
Sven Panne writes: > Hmmm, I'm not really sure what "equivalence" for file > paths should mean in the presence of hard/symbolic links, > (NFS-)mounted file systems, etc. Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) will find it. My interpretation is that two paths are equivalent iff they point to the same target. You (and the others who pointed it out) are correct, though, that the current 'canon' function doesn't accomplish that. I guess, I'll have to move it into the IO monad to get it right. And I should probably rename it, too. ;-) Ben Rudiak-Gould writes: > The Read and Show instances aren't inverses of each > other. I don't think we should be using Read for path > parsing, for this reason. That's fine with me; I can change that. > I don't understand why the path ADT is parameterized by > segment representation, but then the Posix and Windows > parameter types are both wrappers for String. No particular reason. I just wanted to make the library work with a simple internal representation before doing the more advanced stuff. It is experimental code. > It seems artificial to distinguish read :: String -> > RelPath Windows from read :: String -> RelPath Posix in > this way. I think it's pretty neat, actually. You have a way to specify what kind of path you have -- and the type system distinguishes it, not a run-time error. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: mathematical notation and functional programming
On Mon, 31 Jan 2005, Chung-chieh Shan wrote: > (Is Lemming the same person as Henning Thielemann?) Yes. :-) > > For the expression '1+x' I > > conclude by type inference that 'x' must be a variable for a scalar > > value, since '1' is, too. But the expression '1/O(n^2)' has the scalar > > value '1' on the left of '/' and a set of functions at the right side. > > Type inference fails, so my next try is to make the operands compatible > > in a somehow natural way. > > It seems to me that your classification of certain notations as "wrong" > and others as "right" assumes a certain type inference system that > allows adding a number to a placeholder but disallows dividing a > function by a set of functions. Let's see if we share a common interpretation of notation before discussing who uses it consistently and who does not. :-) For me 1, x and + are identifiers. The strings "1", "x" and "+" are not mathematical objects. But '1' denotes a unique mathematical object. Only almost, because depending on the underlying explanation it may be identified with the natural number 1, with the rational number 1, with the real 1, with the complex 1, you will probably need a different representation. Further this representation depends on how you represent natural numbers, reals and so on, e.g. by sets. '+' also denotes a mathematical object, more precisely a function, and again we have ambiguities like that for '1', since '+' might be the natural addition, the rational one or even a mixed one. 'x' denotes no special mathematical object but it may be replaced by one, and the special thing is, that within a certain scope all occurences of 'x' must be replaced with the same mathematical object. Functions are special, in the sense that if I write "1+2" I don't want to consider this as the sequence of three objects denoted by "1", "+", "2" but I want that the function denoted by "+" is applied on the values denoted by "1" and "2". So I imagine a layer of notation and a layer of mathematical objects. Do you share this interpretation? What are consequences of this interpretation? "2+2" and "4" denote the same object. A function has only access to the value (the mathematical object) but not to the generating expression. So how can I define e.g. differentation with respect to a variable? I can't, but I don't miss it because I can define it for functions, and yes Jerzy :-), also for other objects. For me differentiation was introduced by limits. The definition of limits don't need expressions as mathematical objects, the differentation of functions don't need them, too. But later we got used to differentiate expression (e.g. x^2 + y^2 is turned into 2*x * dx + 2*y * dy), but no-one defined what that is. What are the consequences of treating expressions as mathematical objects, too? "2+2" and "4" are different expressions. I guess we would still ask for a value, thus we need a mathematical function which maps expressions to values. I think Mathematicas Evaluate is made for this purpose. If mathematical functions can transform expressions - is it possible that they change my writing? ;-) Indeed, I really like this separation: On the one side expression, on the other side mathematical objects. Simplifications of expressions are nothing I allow a mathematical function. But if I simplify an expression I must assert that the denoted mathematical object remains the same. Differentation of a function is possible if you only know its graph, but a computer algebra system can find an expression for the derivation if you have an expression for the function. There are many functions that can be integrated, but a computer algebra system cannot find an expression without the Integrate function for it. When a pupil says "the function can not be integrated" he means that he couldn't find an expression for the integrated function without the integral sign. When a professor teaching calculus says "the function can not be integrated" he means that there is some divergence. It seems to me that in this case the pupil considers expressions as mathematical objects and the professor does not. > Lambda notation also involves much ambiguity and many implicit > conversions. Following the interpretation above I like to see lambda as a notation instead of an mathematical operator. lambda expressions denote functions. I can replace every occurence of lambda expressions textually. If "\A -> B" occurs I can also write "f" and "where holds \forall A f(A)=B". So lambda notation involves no more ambiguities than the rest of the notation. > > You use 'ask' twice in the second expression. Does this mean that there > > may be two different values for 'ask'? If this is the case your second > > interpretation differs from my second interpretation. > > No -- when I use "ask" I mean the one defined in Control.Monad.Reader. Sorry for my imprecise question :-) What I meant was that 'ask' somehow injects a value into the mathematical operation, I w
Re: [Haskell-cafe] Re: File path programme
This is a very good summary, and I'm interested to see what you come up with. robert dockins wrote: 1) File names are abstract entities. There are a number of ways one might concretely represent a filename. Among these ways are: a) A contiguous sequence of octets in memory (C style string on most modern hardware) b) A sequence of unicode codepoints (Haskell style string) b') A sequence of octets (Haskell style string, in real life) 4) In practice, the vast majority of file paths are portable between the various forms; the forms are "nearly" isomorphic, with corner cases being fairly rare. I don't think they're so rare. I have files on my XP laptop which can't be represented in the system code page. It's easy for me to tell which programs are Unicode-aware and which aren't. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
On 9006 day of my life Victor Snezhko wrote: >> You haven't seen the book in DjVu format :) BTW, DjVu can contain > > I saw such books, but didn't have enough time to find good viewers. > I viewed them with IE plugin, and didn't like it. http://sourceforge.net/projects/windjview >> PS/PDF generated from LaTeX is even better than DjVu, but it is very >> difficult to produce -- lot of hand work. > > Do you mean creation of TeX sources? LaTeX is macropackage for TeX; then yes :) -- Ivan Boldyrev "Assembly of Japanese bicycle require great peace of mind." ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
On Mon, Jan 31, 2005 at 09:56:45AM -, Simon Peyton-Jones wrote: > Matthew > > Yes, I'm happy for you to OCR the book, but can I ask that whatever you get > be made accessible from my web site, so there's one place people can go to > find everything that's available? > > What would OCR buy us? Searching, I guess, which is a fantastic plus. > Anything else? > > Thanks very much for offering to help. I've replied to haskell-cafÃ, so > everyone knows what's up, but we can now save everyone's bandwidth by > narrowing the thread to Ivan, Marnie (who did the original work), you, and > me. If anyone else wants to join in, do yell. An OCRed version might help with my publishing the book via cafepress. The basic problem is that in order to create a pdf from the tiffs, I end up embedding the raw bitmap data (at a very high resolution for decent printing) and end up with a pdf that is way to big for cafepress to handle (even with bitmap compression). I have had some luck with autotrace and other tools to turn bitmaps into outlines, but not any that produced readable output of a suitable size. if the text were OCRed, then I could use outline fonts and considerably improve the printed quality and keep the file size down. I am not sure how easy it will be to integrate the output of the OCR software into an appropriate pdf, but I can try. John -- John Meacham - ârepetae.netâjohnâ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: File path programme
Peter Simons <[EMAIL PROTECTED]> writes:
> http://cryp.to/pathspec/PathSpec.hs
> There also is a function which changes a path specification
> into its canonic form, meaning that all redundant segments
> are stripped.
It's incorrect: canon (read "x/y/.." :: RelPath Posix) gives "x",
yet on Unix they aren't equivalent when y is a non-local symlink
or doesn't exist.
Also, "x/." is not equivalent to "x": rmdir can be used with "x"
but not with "x/.".
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: File path programme
Peter Simons wrote: >The module currently knows only _relative_ paths. I am still >experimenting with absolute paths because I have recently >learned that on Windows something like "C:foo.txt" is >actually relative -- not absolute. Very weird. "\foo.txt" is also relative on Win32. And "con.txt" is absolute. >There also is a function which changes a path specification >into its canonic form, meaning that all redundant segments >are stripped. So although two paths which designate the same >target may not be equal, they can be tested for equivalence. Again, while this transformation may be useful in some cases, it is not a canonicalization operation. "foo/../bar" and "bar" do not in general refer to the same file, and "foo" and "foo/." are not in general equivalent. We shouldn't encourage these misconceptions in the library, even if we do provide a path-collapsing transformation along these lines. Other comments: The Read and Show instances aren't inverses of each other. I don't think we should be using Read for path parsing, for this reason. I don't understand why the path ADT is parameterized by segment representation, but then the Posix and Windows parameter types are both wrappers for String. It seems artificial to distinguish read :: String -> RelPath Windows from read :: String -> RelPath Posix in this way. In general, this library doesn't seem to deal with any of the hard cases. The devil's in the details. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: File path programme
Peter Simons wrote: [...] There also is a function which changes a path specification into its canonic form, meaning that all redundant segments are stripped. So although two paths which designate the same target may not be equal, they can be tested for equivalence. Hmmm, I'm not really sure what "equivalence" for file paths should mean in the presence of hard/symbolic links, (NFS-)mounted file systems, etc. Haskell's stateless (==) function doesn't really make sense IMHO, but perhaps I've missed something in this epic discussion... :-] Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typing in haskell and mathematics
On Mon, 31 Jan 2005 [EMAIL PROTECTED] wrote: > Now: > > Please don't abuse the examples based on differentiation in order to point > out the difference between 'expressions with variables' and 'functions'. > This is simply NOT TRUE that only functions can be differentiated. The > differentiation is an ALGEBRAIC procedure, people acquainted with the > differential algebra know that. Ok, then generalize 'function' to other mathematical objects you like. E.g. polynomials are a good example. For a polynomial p (a tuple) I can define D point-wise as D p = (p_1, 2*p_2, 3*p_3, ..., n*p_n) Then D fulfills the Leibnitz rule D (p0*p1) = D p0 * p1 + p0 * D p1 this is probably what you mean. But I still doubt that it is necessary to accept 'expressions' as mathematical objects. > The differentiation (derivation) operator is a linear operator which > fulfils the Leibniz rule when acting on products. Linearity of D means for me: D (k*p) = k * D p D (p0+p1) = D p0 + D p1 But what is the linearity of an operator acting on an _expression_? For instance the Simplify function, which is rather an Identity function, is not linear with respect to expression: Simplify [3*4] = 12 but if it were linear with respect to expressions it had to be Simplify [3*4] = 3 * Simplify[4] Simplify [3*4] = 3 * 4 > Math is not a question of notation, but of structure. Notation _is_ written structure. As my examples should show there is a benefit if notation matches the structure of the considered problem. > The double ordering: a < b < c > is a very well known contraption in Icon. The operator "<" may confirm > the inegality or FAIL. The failure is something which propagates across > all embedded expressions until it is caught. If it succeeds, then it returns > the SECOND argument. In such a way, going from left to right, "<" gives the > correct result. This is not 'functional' but I like it. I also use this short-cut, but I don't expect that to make it work in a programming language, because you need a lot of explanation to make it work, thus making the compiler and source code processors more complicated. All that just for sticking to a habit! By the way there is a nice functional implementation of a < b < c: zapWith :: [a -> a -> b] -> [a] -> [b] zapWith fs xs = zipWith3 id fs xs (tail xs) usage: and zapWith [ (<), (<) ] [a,b,c] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: mathematical notation and functional programming
(Is Lemming the same person as Henning Thielemann?) On 2005-01-30T21:24:24+0100, Lemming wrote: > Chung-chieh Shan wrote: > > Wait a minute -- would you also say that "1+x" has no meaning at the > > first glance, because "x" is a variable whereas "1" is an integer, so > > some lifting is called for? > For me 'x' is a place holder for a value. But you can only adds two *numbers* to get a number. It makes no sense to add a number to a placeholder. So it makes no sense to write "1+x", no? > For the expression '1+x' I > conclude by type inference that 'x' must be a variable for a scalar > value, since '1' is, too. But the expression '1/O(n^2)' has the scalar > value '1' on the left of '/' and a set of functions at the right side. > Type inference fails, so my next try is to make the operands compatible > in a somehow natural way. It seems to me that your classification of certain notations as "wrong" and others as "right" assumes a certain type inference system that allows adding a number to a placeholder but disallows dividing a function by a set of functions. > Since mathematical notation invokes many > implicit conversions, it's sometimes no longer unique or obvious what > implicit conversion to use. Many users of O(n^2) seem to consider it as > a placeholder for some expression, where the value of the expression is > bounded by n^2. Lambda notation also involves much ambiguity and many implicit conversions. In particular, "x" can mean the identity function from integers to integers as well as the identity function from booleans to booleans, as well as a function that maps an integer-boolean pair to the integer of the pair, as well as a function that maps an integer-boolean pair to the boolean of the pair, and so on. > > Right; they are control operators in the sense that call/cc is a control > > operator. > So they seem to be operators that work on expressions rather than > values. In this respect they are similar to the lambda operator, aren't > they? Yes. > You use 'ask' twice in the second expression. Does this mean that there > may be two different values for 'ask'? If this is the case your second > interpretation differs from my second interpretation. No -- when I use "ask" I mean the one defined in Control.Monad.Reader. > Church style, System F(-omega), alpha-conversion, lambda calculus, eta > reduction, currying - Where can I find some introduction to them? What > about Haskell Curry? What about Bourbaki? - I have heard they worked > hard to find a unified notation. (I'm sure that other people would have better suggestions, but I rather like Benjamin Pierce's book "Types and programming languages".) Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig War crimes will be prosecuted. War criminals will be punished. And it will be no defense to say, "I was just following orders."' George W. Bush, address to the nation, 2003-03-17 http://www.whitehouse.gov/news/releases/2003/03/20030317-7.html signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Typing in haskell and mathematics
On Fri, 28 Jan 2005, Jacques Carette wrote: > > > First, consider a syntax for other component-wise function application? > > > For example, it would be convenient to > > >have > > > (f,g) @ (x,y) > > > be (f x, g y). In some languages [with dynamic typing], one can even do > > > (f,g) (x,y) :-) > > I am not sure what you mean, but you can define exactly that (except > > for the @ sign which is special syntax already): > > (f,g) `ap2` (x,y) = (f x, g y) > > [I should have looked harder for better syntax] > I meant to > a) overload application > b) do it for all tuples at once > Building all of Nat into the names of my functions does not appeal to me... There was some similar discussion about allowing function application notation for other objects than functions, e.g. FiniteMaps. This would be rather like treating polynomials like functions, a problem you pointed out in my slides. I don't feel good about such implicit liftings. Haskell already allows in many cases to factor out common work, but letting it do that automatically creates a lot of new problems, you can't estimate currently. I've worked with MatLab which does not distinguish between scalar values, single element vectors and 1x1 matrices - it's just awful, because earlier or later you start writing functions to workaround MatLabs automatisms just to get a consistent behaviour for 1 dimensional vectors and 1x1 matrices. > Expressions with free variables as first-class values is indeed an > obvious 'next' thing to want, if one is to parallel mathematics. Like the expressions which D and Lim and Plot in Mathematica require as arguments? I think they are responsable for all the mess in Mathematica and Maple. > > This is pretty much the idea with dynamic typing. I find the > > restrictions of static typing very convenient (well most of the time > > :-) as they capture "stupid' errors. > > I disagree. I wrote tens of thousands of lines of code in a (decent) > dynamically typed language. Now I am writing > thousands of lines of code in Haskell. I also appreciate all my "stupid" > errors being caught - this is a welcome > advantage, and I rather like it. But I really really hate having to > duplicate code for really dumb reasons. So what > I want is not dynamic typing, just more powerful static typing. At this point I wonder why it is necessary to have these features in Haskell. Aren't there other languages which are closer to what you want? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typing in haskell and mathematics
A comment of a long text... Henning Thielemann writes: ... some examples of transparency of notation based on 2+2=4 ... I like to have this behaviour for derivation, too. So of what type must be the parameter of 'derive'? A scalar expression with a free variable or a function expression? The designers of Mathematica and Maple decided for the first alternative. But the derivation function D breaks the constraint of free combineability. If x=4 then D[x,x] is 0 or an error (I can't check it currently), if x is not bound to a value it is 1. What I suggest is that derivation should be limitted to functions. If two expressions denote the same function, then D will derive two expressions, that may not be equal but denote the same function. Indeed, the implementation of D must know the expression of the function to give the result as a formula, but if it only knows the set of argument-value-pairs it would work, too. This is the view on functions which Fourier brought to us. Now: Please don't abuse the examples based on differentiation in order to point out the difference between 'expressions with variables' and 'functions'. This is simply NOT TRUE that only functions can be differentiated. The differentiation is an ALGEBRAIC procedure, people acquainted with the differential algebra know that. The differentiation (derivation) operator is a linear operator which fulfils the Leibniz rule when acting on products. If the underlying algebra (a ring, a field, etc.) fulfils some other constraints, if it has some topology, this is ALL. People who do the so called 'automatic differentiation' know that thanks to this it is possible to differentiate formally the numerical programs WITHOUT any symbolic manipulation of the program text; a "variable" 'x' is a GENERATOR of an appropriate differential algebra. In such a way you can write in Haskell - what I did some years ago - a program which differentiates purely numerical infinite lists, representing a value of an expression followed by a tower of all its relatives wrt. a specified generator. Math is not a question of notation, but of structure. And - please - stop (this is not addressed to Henning) calling this or that "stupid". Sometimes thing you don't like inspire people to find some nice implementable solutions, even if outside a classical typed framework. The double ordering: a < b < c is a very well known contraption in Icon. The operator "<" may confirm the inegality or FAIL. The failure is something which propagates across all embedded expressions until it is caught. If it succeeds, then it returns the SECOND argument. In such a way, going from left to right, "<" gives the correct result. This is not 'functional' but I like it. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typing in haskell and mathematics
On Fri, 28 Jan 2005, Jacques Carette wrote:
> Henning Thielemann <[EMAIL PROTECTED]> wrote:
>
>> This seems to be related to what I wrote yesterday
>> http://www.haskell.org/pipermail/haskell-cafe/2005-January/008893.html
>
> Yes, very much. Except that rather than trying to tell mathematicians
> that they are *wrong*, I am trying to see which of their notations I can
> explain (in a typed way). There will be some 'leftovers', where the
> notation is simply bad.
I know that's problematically to say that a notation is "wrong" since
no-one is authorized to say, what's "right". Though, if notation is
contradictory, I don't know what's wrong with calling it wrong.
Let me motivate a bit more, why I'm interested in mathematical notation.
I (and certainly every mathematician) learnt that for instance equations
are a powerful tool to solve problems. You can model many problems with a
mathematical equation, you can transform the equation using some accepted
rules and eventually you get some simplified equation like 'x=2'. The
problem is abstracted, you do the transformations without thinking about
an interpretation in the real world. You know that you can trust the
rules. If someone shows you that the simplified equation is wrong you know
that you have applied some rule in the wrong way or you invented an
improper rule.
There are many tools in the past which have been introduced to make
mathematics more convenient, more safe, somehow better. Arabian numbers
almost replaced Roman numbers because they are more convenient for
computations. Variables and formulas were introduced as a more precise
alternative to phrases in natural languages. Axioms replaced intuitive
definitions. But there are still issues which are unsatisfying. E.g. on
the one hand calculus and functional analysis "degrades" functions to
ordinary objects of mathematics, thus reaching a new level of complexity,
but on the other hand the notation is not as properly developed as the
theory itself, in my opinion.
Let me give an example:
The teacher says, solving a simple linear equation is rather easy by
using separation of variables. Then he transforms a differential equation
formally by some rules he don't explain in detail and I'm curios whether
there _is_ a good explanation:
y' = y
y' / y = 1 | integrate
C + ln y = x
ln y = x-C
y = exp (x-C)
The student thinks: That's nice, let's try it with some problem I couldn't
solve recently:
cos x = x^2| differentiate
-sin x = 2*x
So, x=0 is an obvious solution to the second equation but not to the first
one. The student concludes: If the teacher applies the method, it's
right, if I apply it, it's wrong. :-( Then he asks the teacher why the
method fails for cos x = x^2 . The teacher says, of course what you did
cannot work because y' = y is a differential equation and cos x = x^2 is
not. Does this answer help the student? Why doesn't the formula show this
difference? What means the difference between 'differential equation' and
'normal equation' essentially?
The technique of differentation led to lots of notations. I think this is
so because many of the existing notations don't model the idea of
differentation very well, thus new notations are introduced when the known
notations fail.
d x, \partial x, ', \dot{x}, f_x, D
I wonder if these notations can be unified, thus simplified. I wonder
what formalism I can trust. E.g. I'm sceptic about notations using
variables. What is the value of d x for certain values of x? What is the
difference between d x and d y? Is f_x(x,y) and f_x(y,x) the same?
My proposal: Consider the derivation as higher order function which maps
a function to a function. So in the Haskell notation it would be
derive :: (a -> a) -> (a -> a)
More generally if we have functions (b -> a) as vectors and want to derive
a function mapping from vector arguments to scalar values ((b -> a) -> a)
(also called functionals), it would have signature
deriveVector :: ((b -> a) -> a) -> ((b -> a) -> (b -> a))
E.g. deriveVector f x 1 evaluates the partial derivative of f with
respect to the first component at the point x. deriveVector f x is the
total derivative or gradient at point x. I know that after introducing
higher dimensional differentation using \partial x, \partial y, d x and d
y students are uncertain about what the total derivative actually is.
Let's turn back to the example and view it through the functional glasses.
The differential equation
y' = y
now means, that y is a function, (') is the differentation operator.
With liftF2 I lift (/) to function values and I divide both sides with the
lifted (/) by y, noting that this is only possible, if y is nowhere zero.
derive y= y
liftF2 (/) (derive y) y = liftF2 (/) y y
liftF2 (/) (derive y) y = const 1 | integrate c
(integrate fulfills
fint = integrate c f => fint 0 = c,
though it is problematic if the result has a singularity at 0)
(c1+) . ln
[Haskell-cafe] Re: File path programme
Robert Dockins writes: > 1) File names are abstract entities. There are a number of > ways one might concretely represent a filename. Among these > ways are: > >a) A contiguous sequence of octets in memory > (C style string on most modern hardware) >b) A sequence of unicode codepoints > (Haskell style string) >c) Algebraic datatypes supporting path manipulations > (yet to be developed) The solution I have in mind uses algebraic data types which are parameterized over the actual representation. Thus, you can use them to represent any type of path (in any kind of representation). In the spirit of release early, release often: http://cryp.to/pathspec/PathSpec.hs darcs get http://cryp.to/pathspec The module currently knows only _relative_ paths. I am still experimenting with absolute paths because I have recently learned that on Windows something like "C:foo.txt" is actually relative -- not absolute. Very weird. There also is a function which changes a path specification into its canonic form, meaning that all redundant segments are stripped. So although two paths which designate the same target may not be equal, they can be tested for equivalence. Suggestions for enhancement are welcome, of course. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Nature of Char and String
On Sun, Jan 30, 2005 at 07:58:50PM -0600, John Goerzen wrote: > On Sun, Jan 30, 2005 at 07:39:59PM +, Ben Rudiak-Gould wrote: > > > * If I use hPutStr on a string, is it guaranteed that the number of > > > 8-bit bytes written equals (length stringWritten)? > > > > Yes, if the handle is opened in binary mode. No if not. > > Thank you for the informative response. > > If a file is opened in text mode, what encoding does Haskell grok on > input? And what encoding does it generate on output? I'm assuming > it's UTF-8 on output, but I don't know for sure. The ghc standard libraries only work with latin1, however, there are quite a few libraries out there for reading/writing text in the current locale (or a set format like UTF-8) so ghcs limitations are not too bad in practice if you need unicode. Some are even drop-in replacements for the standard prelude IO functions. It should also be said that these are limitations of the current haskell tools and not the language itself, the language specifies unicode and leaves the details of IO up to implementations. John -- John Meacham - ârepetae.netâjohnâ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: UTF-8 BOM, really!? (was: Re: File path progr amme)
On 2005-01-31, Bayley, Alistair <[EMAIL PROTECTED]> wrote: >> From: Aaron Denney [mailto:[EMAIL PROTECTED] >> >> Better yet would be to have the standard never allow the BOM. >> >> Since some things can't handle it, on output we should never emit it, >> but still must handle it on input. Bah. > > > I don't see how banning it from input would help; as I understand it, it's > meant to be ignored anyway, so there's no loss or gain there. Backwards compatibility, e.g. Kernel looking for the two bytes '#!' at the beginning of a shell script. UTF-8 was supposed to be for backwards compatibility with ASCII with minimal fuss. Having to handle a BOM transparently at the beginning is no longer minimal fuss. -- Aaron Denney -><- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
On 9006 day of my life Simon Peyton-Jones wrote: > Matthew > > Yes, I'm happy for you to OCR the book, but can I ask that whatever > you get be made accessible from my web site, so there's one place > people can go to find everything that's available? Certainly. This is *your* book. I'm not going to put it somewhere else. > What would OCR buy us? Searching, I guess, which is a fantastic > plus. Anything else? As other already suggested, we can re-typeset you book with LaTeX. And produce even more compact and good-looking PDF document with searching, copy-pasting, printing, and so on. And you can use sources for new improved edition of the book. :) > Thanks very much for offering to help. I've replied to > haskell-café, so everyone knows what's up, but we can now save > everyone's bandwidth by narrowing the thread to Ivan, Marnie (who > did the original work), you, and me. If anyone else wants to join > in, do yell. It's going to be large project, what about creating new list? :) Can people at haskell.org help? P.S. I will upload DjVu version on Monday to Marnie's site. P.P.S. Perhaps, I can perform OCR myself if I will find a way to automate it. I will use high-res scans, which are much better than JPEGs for OCRing. Give me some days for experiments. I need help for converting to LaTeX and proofreading. -- Ivan Boldyrev ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Typing in haskell and mathematics
[My apologies for not seeing the related discussion yesterday on haskell-cafe, I was not subscribed until just now] Iavor Diatchki <[EMAIL PROTECTED]> wrote: On Fri, 28 Jan 2005 10:01:33 -0500, Jacques Carette <[EMAIL PROTECTED]> wrote: > The previous post on record syntax reminded me of some 'problems' I had noticed where Haskell and mathematics have >a > (deep) usage mismatch. It is interesting that my sentiment is exactly the opposite. Mathematicians (the applied kind, not the pure) tend to be quite sloppy about their notation relaying _a lot_ on the context and the fact that people know what they are talking about. I find that this makes their explanations harder to understand rather than easier. But every program you write in Haskell depends on a lot of context too! It depends on the (complete) semantics of the programming language, which includes quite a lot of type theory. And more to the point, it includes the context of all the builtin operators as well as the (large) set of functions in Prelude. That is a lot of context. The 'only' difference with mathematics is that Haskell forces you to use 'import' statements to bring in more context. > First, consider a syntax for other component-wise function application? For example, it would be convenient to >have > (f,g) @ (x,y) > be (f x, g y). In some languages [with dynamic typing], one can even do (f,g) (x,y) :-) I am not sure what you mean, but you can define exactly that (except for the @ sign which is special syntax already): (f,g) `ap2` (x,y) = (f x, g y) [I should have looked harder for better syntax] I meant to a) overload application b) do it for all tuples at once Building all of Nat into the names of my functions does not appeal to me... > Yes, I am aware that this untypeable in Haskell, because polymorphism is straight-jacketed by structural rules. What do you mean by this: ap2 :: (a -> b, c - d) -> (a,c) -> (b,d) I mean that you cannot have ap2, ap3, ap4, etc *and* apply all share the 'same' type. But shouldn't they? > 1) look at the type a -> b as being a *subtype* of b (though I have never seen it phrased that way in print) I don't think subtyping is what you are thinking of. Perhaps you are referring to the correspondance between b-expressions with a free a-variable, and functions a->b. In Haskell we don't have expressions with free variables as first class values. There might be some interesting things to work out for such beasts. Expressions with free variables as first-class values is indeed an obvious 'next' thing to want, if one is to parallel mathematics. But I really mean to look at any p-producing function as being of b-type, and that includes a -> b. > 2) to consider every 'natural transformation' available and use it (tuples of functions <-> obvious function on > tuples) Are you suggesting that natural transformations should be applied automatically? There are many problems with this: which operations should happen automatically? At least the ones that you get 'for free' for structural reasons. Type inference (if it works at all) will be hard to do, but perhaps these are technical details. Fundamentally the "sloppy" math notation assumes that what the author wrote is correct and should simply be given "the obvious" meaning. Haskell's type inference engine does the same thing -- it assumes that the code you wrote is meaningful, and thus gives it the *only* type that makes sense. Care has been taken so that in Haskell "the obvious" == "the only", which is certainly a good property to have. Mathematicians who are a bit careful with their notation, do the same. They make sure that "obvious" and "only" match when they drop sub/superscripts, some environment dependence, etc. This is pretty much the idea with dynamic typing. I find the restrictions of static typing very convenient (well most of the time :-) as they capture "stupid' errors. I disagree. I wrote tens of thousands of lines of code in a (decent) dynamically typed language. Now I am writing thousands of lines of code in Haskell. I also appreciate all my "stupid" errors being caught - this is a welcome advantage, and I rather like it. But I really really hate having to duplicate code for really dumb reasons. So what I want is not dynamic typing, just more powerful static typing. > Seeing a -> b as a subtype of b allows one to take any function f : b -> b -> c (like + ) and 'lift' it to > ff : (a -> b) -> (a -> b) -> (a -> c) > via the obvious definition > ff g h = \x -> f (g x) (h x) > This is done routinely in mathematics. The meaning of the expression (sin + cos) should be immediately obvious. > Such > 'lifting' is used even in first-year calculus courses, but not in Haskell. Apart from the fact that this does not seem like a good idea, you can already do things like this in Haskell: liftOp op f g x = f x `op` f x Of course. My point is that you need to explicitly use liftOp. I want it to be implicit. Note that this
Re: UTF-8 BOM, really!? (was: [Haskell-cafe] Re: File path program me)
On Mon, 31 Jan 2005 10:30:58 -0500, you wrote: >A BOM came to be permitted because it uses the identical code as NBSP >(non-breaking space). Not quite. It's the same code (U+FEFF) as ZERO WIDTH NO-BREAK SPACE. This is _not_ the same thing as NO-BREAK SPACE (U+00A0), which is what you frequently see in HTML as . Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: UTF-8 BOM, really!? (was: [Haskell-cafe] Re: File path programme)
On 2005 January 31 Monday 04:56, Graham Klyne wrote: > How can it make sense to have a BOM in UTF-8? UTF-8 is a sequence of > octets (bytes); what ordering is there here that can sensibly be varied? Correct. There is no order to be varied. A BOM came to be permitted because it uses the identical code as NBSP (non-breaking space). Earlier versions of Unicode permit NBSP just about anywhere in the character sequence. Unicode 4 deprecates this use of NBSP. If I read it correctly, Unicode 4 says that a BOM at the beginning of a UTF-8 encoded stream is not to be taken as part of the text. The BOM has no effect. The rationale for this is that some applications put out a BOM at the beginning of the output regardless of the encoding. Other occurrences of NBSP in a UTF-8 encoded stream are significant. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: File path programme
I have been ruminating on the various responses my attempted file path implementation has generated. I have a design beginning to form in the back of my head which attempts to address the file path problem as I lay out below. Before I develop it any further, are there any important considerations I am missing? Here is my conception of the file name problem: 1) File names are abstract entities. There are a number of ways one might concretely represent a filename. Among these ways are: a) A contiguous sequence of octets in memory (C style string on most modern hardware) b) A sequence of unicode codepoints (Haskell style string) c) Algebraic datatypes supporting path manipulations (yet to be developed) 2) We would like these three representations to be isomorphic. Unfortunately, this cannot be. In particular, there are major issues with the translations between the (a) and (b) forms given above. One could imagine that translations issues involving the (c) form are also possible. 3) Translations between (a) and (b) must be parameterized by a character encoding. Translations to and from (c) will require some manner of description of the path syntax, which differs by OS. 4) In practice, the vast majority of file paths are portable between the various forms; the forms are "nearly" isomorphic, with corner cases being fairly rare. 5) Translations between the various forms cost compute cycles and memory, and are not necessarily bijective. Therefore, translations should occur _only_ if absolutely necessary. In particular, if a file name passes through a program as a black box (it is not examined or manipulated) it should undergo no transformation. 6) Different OSes handle file names differently. These differences should be accounted for, transparently where possible. These differences, however, should be exposed to developers for whom the difference matter. 7) Using simple file names should be easy. We don't want developers to have to worry too much about character encodings, path separators, and generally bizarre path syntax just to open files. The complexities of correct file name handling should be hidden from the casual programmer. However, developers interested in serious portability/internationalization should be able to get down into the muck if they need to. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Nature of Char and String
On Sun, Jan 30, 2005 at 07:58:50PM -0600, John Goerzen wrote: > On Sun, Jan 30, 2005 at 07:39:59PM +, Ben Rudiak-Gould wrote: > > > * If I use hPutStr on a string, is it guaranteed that the number of > > > 8-bit bytes written equals (length stringWritten)? > > > > Yes, if the handle is opened in binary mode. No if not. > > Thank you for the informative response. > > If a file is opened in text mode, what encoding does Haskell grok on > input? And what encoding does it generate on output? I'm assuming > it's UTF-8 on output, but I don't know for sure. I don't think so, it still just treats the Char as an eight bit C character, the only difference is that if it's opened as text on windows, your newlines get mangled. (...or treated properly, depending on your opinion.) -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problems with building haskell-jvm-bridge-0.3.RC1
Hello! I'm trying to build Haskell-JVM bridge (http://sourceforge.net/projects/jvm- bridge/) under Windows (cygwin) and with Java 1.5. I can execute "configure" without errors. When I execute make, I get a lot of errors. Due to a limited size of my buffer, I can show you only the last lines of make's output: JVMBridge.cpp: In function `jboolean JVMBridge_CallNonvirtualBooleanMethodVL(JNIEnv*, _jobject*, _jobject*, _jmethodID*, void*)': JVMBridge.cpp:778: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:779: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:780: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:781: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:783: error: `CallNonvirtualBooleanMethodA' undeclared (first use this function) JVMBridge.cpp:785: error: `JVMBridge_DestroyValueList' cannot be used as a function JVMBridge.cpp: In function `jbyte JVMBridge_CallNonvirtualByteMethodVL(JNIEnv*, _jobject*, _jobject*, _jmethodID*, void*)': JVMBridge.cpp:793: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:794: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:795: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:796: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:798: error: `CallNonvirtualByteMethodA' undeclared (first use this function) JVMBridge.cpp:800: error: `JVMBridge_DestroyValueList' cannot be used as a function JVMBridge.cpp: In function `jchar JVMBridge_CallNonvirtualCharMethodVL(JNIEnv*, _jobject*, _jobject*, _jmethodID*, void*)': JVMBridge.cpp:808: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:809: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:810: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:811: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:813: error: `CallNonvirtualCharMethodA' undeclared (first use this function) JVMBridge.cpp:815: error: `JVMBridge_DestroyValueList' cannot be used as a function JVMBridge.cpp: In function `jshort JVMBridge_CallNonvirtualShortMethodVL(JNIEnv*, _jobject*, _jobject*, _jmethodID*, void*)': JVMBridge.cpp:823: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:824: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:825: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:826: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:828: error: `CallNonvirtualShortMethodA' undeclared (first use this function) JVMBridge.cpp:830: error: `JVMBridge_DestroyValueList' cannot be used as a function JVMBridge.cpp: In function `jint JVMBridge_CallNonvirtualIntMethodVL(JNIEnv*, _jobject*, _jobject*, _jmethodID*, void*)': JVMBridge.cpp:838: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:839: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:840: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:841: error: `DebugShowPointer' cannot be used as a function JVMBridge.cpp:843: error: `CallNonvirtualIntMethodA' undeclared (first use this function) JVMBridge.cpp:845: error: `JVMBridge_DestroyValueList' cannot be used as a function JVMBridge.cpp: At global scope: JVMBridge.cpp:850: error: parse error before `*' token JVMBridge.cpp:853: error: `object' was not declared in this scope JVMBridge.cpp:853: error: ISO C++ forbids declaration of `DebugShowPointer' with no type JVMBridge.cpp:853: error: redefinition of `int DebugShowPointer' JVMBridge.cpp:711: error: `int DebugShowPointer' previously defined here JVMBridge.cpp:853: error: initializer list being treated as compound expression JVMBridge.cpp:854: error: ISO C++ forbids declaration of `DebugShowPointer' with no type JVMBridge.cpp:854: error: redefinition of `int DebugShowPointer' JVMBridge.cpp:853: error: `int DebugShowPointer' previously defined here JVMBridge.cpp:854: error: initializer list being treated as compound expression JVMBridge.cpp:855: error: `methodID' was not declared in this scope JVMBridge.cpp:855: error: ISO C++ forbids declaration of `DebugShowPointer' with no type JVMBridge.cpp:855: error: redefinition of `int DebugShowPointer' JVMBridge.cpp:854: error: `int DebugShowPointer' previously defined here JVMBridge.cpp:855: error: initializer list being treated as compound expression JVMBridge.cpp:856: error: `vl' was not declared in this scope JVMBridge.cpp:856: error: ISO C++ forbids declaration of `DebugShowPointer' with no type JVMBridge.cpp:856: error: redefinition of `int DebugShowPointer' JVMBridge.cpp:855: error: `int DebugShowPointer' previously defined here JVMBridge.cpp:856: error: initializer list being treated as compound expression JVMBridge.cpp:857: error: redefinition of `jvalue*valueArray' JVMBridge.cpp:712: error: `jvalue*valueArray' previously defi
[Haskell-cafe] Re: UTF-8 BOM, really!?
Graham Klyne <[EMAIL PROTECTED]> writes:
> How can it make sense to have a BOM in UTF-8? UTF-8 is a sequence of
> octets (bytes); what ordering is there here that can sensibly be
> varied?
The *name* "BOM" doesn't make sense when applied to UTF-8, but some
software uses UTF-8 encoded U+FEFF it as a marker that the file is
encoded in UTF-8 rather than some other encoding. And Unicode seems
to support this usage, even if it doesn't recommend it.
I know only of Microsoft Notepad, and suspect other Microsoft tools
(Notepad assumes UTF-8 with the marker and the current Windows
codepage without). The HTML at http://www.microsoft.com/ begins with
a BOM, but other pages linked from there do not.
I think XML used to be silent about this, but later got amended to
explicitly say that optional U+FEFF at the beginning is allowed and
not treated as a part of document contents.
OTOH various other sofrware, in particular generic Unix tools, don't
treat UTF-8 BOM specially, and de facto implement the "non-standard"
UTF-8 without a BOM.
Technically in UTF-16/32 the BOM is handled in the translation between
encoding form (sequence of 16- or 32-bit code units) and encoding
scheme (these words serialized into bytes). I think it's supposed
to be the same in UTF-8, i.e. the analogous translation is *almost*
trivial - it translates bytes to the same bytes - except that initial
BOM must be stripped on decoding, and it must be added on encoding
when the first character of the contents is U+FEFF (and optionally in
other cases). I mean that it is supposed to happen on decoding UTF-8
on the level of bytes, not after decoding on the level of code points.
Anyway, on Unix it just doesn't happen at all, except in software
which explicitly handles it. iconv() doesn't handle UTF-8 BOM.
If I could decide about it, I would ban UTF-8 BOM at all. But perhaps
Unicode Consortium can be at least persuaded to recognize that some
software doesn't accept BOM in UTF-8, and could be conforming to the
variant of UTF-8 without the BOM rather than non-conforming at all.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
Ivan Boldyrev <[EMAIL PROTECTED]> writes: >> It's just more convenient to read OCRed books than raster ones. >> Zoom without interpolation, > > You haven't seen the book in DjVu format :) BTW, DjVu can contain I saw such books, but didn't have enough time to find good viewers. I viewed them with IE plugin, and didn't like it. > text, but I haven't learned proper spell yet :) I use free tools, so > it may be difficult or impossible. > > PS/PDF generated from LaTeX is even better than DjVu, but it is very > difficult to produce -- lot of hand work. Do you mean creation of TeX sources? > If we will gather large command it will be possible. I think even if we don't gather command that is large enough we should create the best version possible. It will be slower and more time-consuming, but who cares, the book is already 18 years old :) -- WBR, Victor V. Snezhko e-mail: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: UTF-8 BOM, really!?
"Bayley, Alistair" <[EMAIL PROTECTED]> writes: >> How can it make sense to have a BOM in UTF-8? > "Q: Where is a BOM useful? > A: A BOM is useful at the beginning of files that are typed as text, but for > which it is not known whether they are in big or little endian format..." I think the question is how a single byte can have a byte order. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
On 9006 day of my life Victor Snezhko wrote: > It's just more convenient to read OCRed books than raster ones. > Zoom without interpolation, You haven't seen the book in DjVu format :) BTW, DjVu can contain text, but I haven't learned proper spell yet :) I use free tools, so it may be difficult or impossible. PS/PDF generated from LaTeX is even better than DjVu, but it is very difficult to produce -- lot of hand work. If we will gather large command it will be possible. -- Ivan Boldyrev "Assembly of Japanese bicycle require great peace of mind." ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: UTF-8 BOM, really!? (was: [Haskell-cafe] Re: File path progr amme)
> From: Aaron Denney [mailto:[EMAIL PROTECTED] > > Better yet would be to have the standard never allow the BOM. > > Since some things can't handle it, on output we should never emit it, > but still must handle it on input. Bah. I don't see how banning it from input would help; as I understand it, it's meant to be ignored anyway, so there's no loss or gain there. Whether or not to emit the BOM on output should be a user choice, surely? > From: Graham Klyne [mailto:[EMAIL PROTECTED] > > How can it make sense to have a BOM in UTF-8? UTF-8 is a sequence of > octets (bytes); what ordering is there here that can > sensibly be varied? >From http://www.unicode.org/faq/utf_bom.html#BOM : "Q: Where is a BOM useful? A: A BOM is useful at the beginning of files that are typed as text, but for which it is not known whether they are in big or little endian format..." i.e. it helps when you need to guess what the encoding of a given file might be. Alistair. - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
UTF-8 BOM, really!? (was: [Haskell-cafe] Re: File path programme)
At 23:39 30/01/05 +0100, Marcin 'Qrczak' Kowalczyk wrote: Aaron Denney <[EMAIL PROTECTED]> writes: >> It provides variants of UTF-16/32 with and without a BOM, but >> UTF-8 only has the variant with a BOM. This makes UTF-8 a stateful >> encoding. > > I think you mean "UTF-8 only has the variant without a BOM". No, unfortunately. Unicode standard section 3.10 defines encoding schemes: - UTF-8(witha BOM) - UTF-16BE (without a BOM) - UTF-16LE (without a BOM) - UTF-16 (witha BOM) - UTF-32BE (without a BOM) - UTF-32LE (without a BOM) - UTF-32 (witha BOM) It says about UTF-8 BOM: "Its usage at the beginning of a UTF-8 data stream is neither required nor recommended by the Unicode Standard, but its presence does not affect conformance to the UTF-8 encoding scheme." IMHO it would be fair if it had two variants of UTF-8 encoding scheme, just like it has three variants of UTF-16/32, so it would be unambiguous whether "UTF-8" in a particular context allows BOM or not. I haven't been following this thread in detail, so I may be missing something, but... How can it make sense to have a BOM in UTF-8? UTF-8 is a sequence of octets (bytes); what ordering is there here that can sensibly be varied? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] File paths and internationalization/localization
I don't offer any answers, but the problems raised on this list concerning file paths using local language characters would appear to have some parallels in the world of URIs. Martin Duerst and others at W3C have been working on the problem of internationalization (I18N) of URIs, and their proposals were recently published as a Proposed Standard RFC [1]. If this area is being considered in the design of Haskell libraries, there may be some lessons there to be copied. #g -- [1] ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes: > Matthew > > Yes, I'm happy for you to OCR the book, but can I ask that whatever > you get be made accessible from my web site, so there's one place > people can go to find everything that's available? > > What would OCR buy us? Searching, I guess, which is a fantastic > plus. Anything else? It's just more convenient to read OCRed books than raster ones. Zoom without interpolation, possibility to convert to whatever format you like without much effort, etc. > Thanks very much for offering to help. I've replied to > haskell-café, so everyone knows what's up, but we can now save > everyone's bandwidth by narrowing the thread to Ivan, Marnie (who > did the original work), you, and me. If anyone else wants to join > in, do yell I would be happy to participate in the process too. -- WBR, Victor V. Snezhko e-mail: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes: > What would OCR buy us? Searching, I guess, which is a fantastic > plus. Anything else? - The ability to cut and paste passages into e.g. e-mail. - Availability for text-only access - e.g. for the vision impaired, or people on low bandwidth connections. - Possibility of re-typesetting it with e.g. LaTeX, to make nice-looking reprints on a laserprinter in your neighborhood. Basically, making the text (and not just pictures of it) available empowers its users in a general way -- not unlike publishing the source code to e.g. GHC. (I'm going to have to read it, just on principle :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages"
Matthew Yes, I'm happy for you to OCR the book, but can I ask that whatever you get be made accessible from my web site, so there's one place people can go to find everything that's available? What would OCR buy us? Searching, I guess, which is a fantastic plus. Anything else? Thanks very much for offering to help. I've replied to haskell-café, so everyone knows what's up, but we can now save everyone's bandwidth by narrowing the thread to Ivan, Marnie (who did the original work), you, and me. If anyone else wants to join in, do yell. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ivan | Boldyrev | Sent: 31 January 2005 06:48 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] Re: ocr'ed version of "The implementation offunctional languages" | | On 9005 day of my life Matthew Roberts wrote: | > I have just embarked on creating a ocr'ed version of the jpeg images | > that have been made available for "The implementation of functional | > languages". | | I have high-resolution scans of this books. If Simon permits, I will | create OCR from these scans. But I think, we must obtain author's | permission before OCR'ing. | | PNG version of scans will be released soon. While size of page is | same, quality is much better, probably it will improve speed of | scanning. | | And compact DjVu version will be released too. Perhaps I could use | OCR'ed text for creating searchable version of DjVu? | | > However, my ocr software is clunky at best and (not surprisingly) it is | > slow going. | | What kind of software do you use? | | -- | Ivan Boldyrev | |Assembly of a Japanese bicycle requires greatest peace of spirit. | | ___ | 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
