[Haskell-cafe] Case studies, step two
I want to thank everyone who provided pointers for the last question about this. They were a big help. We're now trying to narrow things down a bit. If you have either converted part of a business project from a language like ruby or python to Haskell, or have a business project that integrates Haskell with such a language and are willing to take a short survey about it, could you get back to me? Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
On Wed, Oct 2, 2013 at 5:18 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: Are there examples where application programmers would like there so be some f, a and b such that a == b but f a /= f b (efficiency concerns aside)? I can't think of any obvious ones. Yes, and we already handle it properly: Prelude let f = (1.0 /) Prelude let (z, negz) = (0.0, -0.0) Prelude z == negz True Prelude f z /= f negz True This is *not* an IEEE Floats are weird thing. Application programmers want 0.0 to equal -0.0, but -Infinity to not be equal to Infinity. Of course, given how many IEEE Floats are weird things there are, you can reasonably consider ignoring this example. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for numbers to support using haskell
The fpcomplete case studies are similar to what I'm looking for. Anyone have more of them? Maybe a blog post or comparison they've written? Thanks, mike On Mon, Sep 23, 2013 at 5:05 PM, Eric Rasmussen ericrasmus...@gmail.comwrote: Hi Nick, FP Complete has a lot of good resources on this topic, including some case studies: https://www.fpcomplete.com/business/resources/case-studies/ I believe part of their aim is making the business case for Haskell (meaning many of the resources are geared towards management), which I realize is not exactly what you asked for. But hopefully you'll find something there that can help. Best, Eric On Mon, Sep 23, 2013 at 12:13 PM, Nick Vanderweit nick.vanderw...@gmail.com wrote: I'd be interested in more studies in this space. Does anyone know of empirical studies on program robustness vs. other languages? Nick On 09/23/2013 11:31 AM, MigMit wrote: The classical reference is, I think, the paper “Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity” On Sep 23, 2013, at 9:20 PM, Mike Meyer m...@mired.org wrote: Hi all, I'm looking for articles that provide some technical support for why Haskell rocks. Not just cheerleading, but something with a bit of real information in it - a comparison of code snippets in multiple languages, or the results of a study on programmer productivity (given all the noise and heat on the topic of type checking, surely there's a study somewhere that actually provides light as well), etc. Basically, I'd love things that would turn into an elevator pitch of I can show you how to be X times more productive than you are using Y, and then the article provides the evidence to support that claim. Thanks, Mike ___ 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 ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FP Complete competition clarification
I got some clarification on what unpublished means for FP Complete competition entries. Basically, you can enter code that you've already published, providing it has an appropriate license (or can be republished with such a license). The tutorial/description/documentation that shows how to use it must be unpublished. So, if you're looking for a good excuse to document an existing project, how about a chance to win $1000 by doing so? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking for numbers to support using haskell
Hi all, I'm looking for articles that provide some technical support for why Haskell rocks. Not just cheerleading, but something with a bit of real information in it - a comparison of code snippets in multiple languages, or the results of a study on programmer productivity (given all the noise and heat on the topic of type checking, surely there's a study somewhere that actually provides light as well), etc. Basically, I'd love things that would turn into an elevator pitch of I can show you how to be X times more productive than you are using Y, and then the article provides the evidence to support that claim. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson s...@scientician.net wrote: On 2013-09-21 06:16, Mike Meyer wrote: The single biggest gotcha is that two calculations we expect to be equal often aren't. As a result of this, we warn people not to do equality comparison on floats. The Eq instance for Float violates at least one expected law of Eq: Prelude let nan = 0/0 Prelude nan == nan False Yeah, Nan's are a whole 'nother bucket of strange. But if violating an expected law of a class is a reason to drop it as an instance, consider: Prelude e 0 True Prelude 1 + e 1 False Of course, values not equal when you expect them to be breaking equality means that they also don't order the way you expect: Prelude e + e + 1 1 + e + e True So, should Float's also not be an instance of Ord? I don't think you can turn IEEE 754 floats into a well-behaved numeric type. A wrapper around a hardware type for people who want that performance and can deal with its quirks should provide access to as much of the types behavior as possible, and equality comparison is part of IEEE 754 floats. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Sep 21, 2013 9:17 AM, Bob Hutchison hutch-li...@recursive.ca wrote: On 2013-09-21, at 4:46 AM, Stijn van Drongelen rhym...@gmail.com wrote: I do have to agree with Damodar Kulkarni that different laws imply different classes. However, this will break **a lot** of existing software. You could argue that the existing software is already broken. I'd argue that it's not all broken, and you're breaking it all. If we would do this, only Eq and Ord need to be duplicated, as they cause most of the problems. Qualified imports should suffice to differentiate between the two. import qualified Data.Eq.Approximate as A import qualified Data.Ord.Approximate as A main = print $ 3.16227766016837956 A.== 3.16227766016837955 As soon as you start doing computations with fp numbers things get much worse. Exactly. The Eq and Ord instances aren't what's broken, at least when you're dealing with numbers (NaNs are another story). That there are pairs of non-zero numbers that when added result in one of the two numbers is broken. That addition isn't associative is broken. That expressions don't obey the substitution principle is broken. But you can't tell these things are broken until you start comparing values. Eq and Ord are just the messengers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net wrote: On 2013-09-21 23:08, Mike Meyer wrote: Exactly. The Eq and Ord instances aren't what's broken, at least when you're dealing with numbers (NaNs are another story). That there are pairs According to Haskell NaN *is* a number. Trying to make something whose name is Not A Number act like a number sounds broken from the start. Eq and Ord are just the messengers. No. When we declare something an instance of Monad or Applicative (for example), we expect(*) that thing to obey certain laws. Eq and Ord instances for Float/Double do *not* obey the expected laws. I just went back through the thread, and the only examples I could find where that happened (as opposed to where floating point calculations or literals resulted in unexpected values) was with NaNs. Just out of curiosity, do you know of any that don't involve NaNs? Float violates the expected behavior of instances of - well, pretty much everything it's an instance of. Even if you restrict yourself to working with integer values that can be represented as floats. If we're going to start removing it as an instance for violating instance expectations, we might as well take it out of the numeric stack (or the language) completely. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 11:17 AM, damodar kulkarni kdamodar2...@gmail.com
wrote:
Ok, let's say it is the effect of truncation. But then how do you explain
this?
Oh, it's a trunaction error all right.
Prelude sqrt 10.0 == 3.1622776601683795
True
Prelude sqrt 10.0 == 3.1622776601683796
True
Here, the last digit **within the same precision range** in the
fractional part is different in the two cases (5 in the first case and 6 in
the second case) and still I am getting **True** in both cases.
Because you're using the wrong precisision range. IEEE floats are
stored in a binary format, not a decimal one. So values that differ by 2 in
the last decimal digit can actually be different values even though
values that differ by one in the last decimal digit aren't.
And also observe the following:
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.0
False
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.002
True
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.003
False
Prelude (sqrt 10.0) * (sqrt 10.0) == 10.001
True
Prelude
Ok, again something like truncation or rounding seems at work but the
precision rules the GHC is using seem to be elusive, to me.
(with GHC version 7.4.2)
Here's a quick-and-dirty C program to look at the values. I purposely
print decimal digits beyond the precision range to illustrate that,
even though we started with different representations, the actual
values are the same even if you use decimal representations longer
than the ones you started with. In particular, note that 0.1 when
translated into binary is a repeating fraction. Why the last hex digit
is a instead of 9 is left as an exercise for the reader. That this
happens also means the number actually stored when you enter 0.1 is
*not* 0.1, but as close to it as you can get in the given
representation.
#include stdio.h
union get_int {
unsigned long intVal ;
doublefloatVal ;
} ;
doubleCheck(double in) {
union get_int out ;
out.floatVal = in ;
printf(%.20f is %lx\n, in, out.intVal) ;
}
main() {
doubleCheck(3.1622776601683795) ;
doubleCheck(3.1622776601683796) ;
doubleCheck(10.0) ;
doubleCheck(10.001) ;
doubleCheck(10.002) ;
doubleCheck(10.003) ;
doubleCheck(0.1) ;
}
But more importantly, if one is advised NOT to test equality of two
floating point values, what is the point in defining an Eq instance?
So I am still confused as to how can one make a *meaningful sense* of the
Eq instance?
Is the Eq instance there just to make __the floating point types__
members of the Num class?
You can do equality comparisons on floats. You just have to know what
you're doing. You also have to be aware of how NaN's (NaN's are float
values that aren't numbers, and are even odder than regular floats)
behave in your implementation, and how that affects your
application. But the same is true of doing simple arithmetic with
them.
Note that you don't have to play with square roots to see these
issues. The classic example you see near the start of any numerical
analysis class is:
Prelude sum $ take 10 (repeat 0.1)
0.
Prelude 10.0 * 0.1
1.0
This is not GHC specific, it's inherent in floating point number
representations. Read the Wikipedia section on accuracy problems
(http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems) for
more information.
Various languages have done funky things to deal with these issues,
like rounding things up, or providing fuzzy equality. These things
generally just keep people from realizing when they've done something
wrong, so the approach taken by ghc is arguably a good one.
mike
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystery of an Eq instance
On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni kdamodar2...@gmail.com wrote: This seems a good step forward, removing the Eq instance altogether on floating point types would be much better; (unless as pointed out by Brandon, you have a very clever representation that can store (floats) in terms of some operation like sin(x) or ln(x) (with infinite precision)) Please don't. The problem isn't with the Eq instance. It does exactly what it should - it tells you whether or not two floating point objects are equal. The problem is with floating point arithmetic in general. It doesn't obey the laws of arithmetic as we learned them, so they don't behave the way we expect. The single biggest gotcha is that two calculations we expect to be equal often aren't. As a result of this, we warn people not to do equality comparison on floats. So people who don't understand that wind up asking Why doesn't this behave the way I expect? Making floats not be an instance of Eq will just cause those people to ask Why can't I compare floats for equality?. This will lead to pretty much the same explanation. It will also mean that people who know what they're doing who want to do so will have to write their own code to do it. It also won't solve the *other* problems you run into with floating point numbers, like unexpected zero values from the hole around zero. Given that we have both Data.Ratio and Data.Decimal, I would argue that removing floating point types would be better than making them not be an instance of Eq. It might be interesting to try and create a floating-point Numeric type that included error information. But I'm not sure there's a good value for the expression 1.0±0.1 0.9±0.1. Note that Brandon was talking about representing irrationals exactly, which floats don't do. Those clever representations he talks about will do that - for some finite set of irrationals. They still won't represent all irrationals or all rationals - like 0.1 - exactly, so the problems will still exist. I've done microcode implementations of floating point representations that didn't have a hole around 0. They still don't work right. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] World's First Commercial Haskell IDE and Deployment Platform, FP Haskell Center Launches Today
On Tue, Sep 3, 2013 at 2:25 PM, Tommy Thorn tt1...@yahoo.com wrote: This is interesting and I wish them luck, but it seems surprising that the below link doesn't have as much as a screenshot (for an IDE, you kind of expect to see what it looks like). If you follow the link that says Product Highlights, you get to https://www.fpcomplete.com/business/haskell-center/fp-haskell-center-highlights/ , which includes links to a PDF for each highlight, which have a number of screenshots.They tend to be covered by explanatory text, or only partial shots of the window, etc. The other option is to use the Free Trial link and just see it live. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Embedded haskell?
I've been working with open source rc aircraft transmitter software, and in looking at the shortcomings of one of them, started thinking about embedding a language. There are a number of options that can work here, like FORTH or a basic. But then I realized that Haskell - or similar functional language - could well be a good fit. The software is meant to let the end user express how the various inputs - joysticks, switches, trims, knobs - are mapped to values the radio sends on the various control channels. All the key values are immutable - you either read them from hardware once in the process of building a frame to transmit, or you fill them into a frame and transmit it, then start over for the next frame. You just need to let the end user express the functions to go from one to the other. The other restraint is that you need to be able to change the code in the field, with the only computer available being the embedded one. You might have a touch-screen, or you might just have cursor keys. Either way, actually inputting a program could be interesting. Similarly, the entire system: compiler, interpreter, whatever - needs to run on the embedded computer. A quick google turns up Hume, which seems to be designed for this kind of thing, though not with the in the field restrictions. Anyone have any other suggestions of software that might fit here? Experience with any of that software? Other suggestions? Thanks, mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Embedded haskell?
On Wed, Feb 20, 2013 at 4:01 PM, Jeremy Shaw jer...@n-heptane.com wrote: Another option would be to use Atom. I have successfully used it to target the arduino platform before. Running the entire OS on the embedded system seems dubious. Assuming you are using something the 9x family of transmitters -- they are slow and have very little internal memory. Plus trying to programming using a 6 buttons would be a royal pain. If you really want in-field programming, then you might at least using a raspberry pi with a small bluetooth keyboard and have it upload to the transmitter. Atom does look interesting. Thanks for the pointer. The target transmitter is the Walkera Devo line. These have much more capable CPUs than the various 9x boards: 32 bit ARMs at 72MHz with comparable amounts of storage. Some have 9x-like screen/button combos, others have touch screens. The deviationTx software runs on all of them. Settings are stored in a FAT file system that can be accessed as a USB drive. I'm thinking that a traditional configuration interface on the transmitter, storing the config information as program text. The only actual programming would be done by replacing the virtual channel/switch feature with expressions or short programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Wed, 2 Jan 2013 13:48:07 +0400 MigMit miguelim...@yandex.ru wrote: On Jan 2, 2013, at 10:52 AM, Mike Meyer m...@mired.org wrote: MigMit miguelim...@yandex.ru wrote: But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program. Well, you can call that a theory, for sure. But I think it's usually called an observation. An observation is what you make to decide if a theory is true or not. In order to make the observation (at least for theories about helping programmers) you need an implementation so you can observe people using it. I always thought the theory is something that allows us to develop some new knowledge. Yup. Deciding whether or not the theory is true *is* a development of new knowledge. I can say for a certainty that the documentation aspect of DbC makes me more productive. The testing aspect of it needs more testing (sorry). Just stating that comfortable chairs make programmers more productive doesn't constitute a theory. Well, it's not very rigorous, and I can think of some counterexamples. On the other hand, if you reparaphrased (sic) it as Chairs that encourage good posture make programmers more productive, then you have a honest-to-goodness theory. Better yet, it's one that's been thoroughly tested in ergonomics labs around the world. At this point, we're arguing about the semantics of the word theory. On Wed, 2 Jan 2013 13:41:54 +0400 MigMit miguelim...@yandex.ru wrote: I don't know about DbC in general, but it's implementation in Eiffel seems to be nothing more than a few ASSERT macros, for some weird reason embedded into the language. Either you used a particularly poor implementation of Eiffel, or you didn't look at the implementation beyond writing them out. Every Eiffel system I've used included tools that computed the contracts on a method or class (remember, class invariants apply to subclasses, etc.) and displayed them. Those are just as much part of DbC as the assert macros. If you ignore that usage, you've correctly described things. At least as well as saying that a function call implementation is a goto that records a return address, for some weird reason embedded into the language. Or higher level construct is just implementation method, for some weird reason embedded into the language. The weird reason is pretty much always the same: the construct in question carries more semantic meaning than the implementation method. Functions capture the notion of a distinct, reusable chunk of code, that can have properties all it's own. This is a major step up from just having a goto variant with an otog that undoes it. Likewise, pre and post (and invariant) conditions capture the notion of a contract. They express the terms of the contract implemented by some specific bit of code. The contract is part of the interface to that code. If you're actually doing DbC, it's no less important than the rest of the interface. Like, for instance, the type signature. Personally, I don't believe in turning off the conditions, for much the same reason I don't believe in turning off array bounds checking. I think it's better to get the right answer later than to get the wrong answer now. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
[Context destroyed by top posting.] MigMit miguelim...@yandex.ru wrote: But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program. And by hack I meant not the presence of pre/postconditions, but the fact that they don't affect anything else. Strip all of them away, and you'll have the program which is, essentially, the same (and, in fact, pre/postconditions are supposed to be removed in the final version of the program). Compare this to Haskell types, for example: an untyped version of Haskell won't be able to choose between two class instances, so, that would be an entirely different language. Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all of them away and have essentially the same program. Personally, I think the answer is no, and for the same reason. We add type signatures to top level functions because it helps document the function, and to help isolate type errors during compilation. They makes *programming* easier, even if they don't change the program at all. Pre and Post conditions (and class invariants - they're also part of DbC!) serve pretty much the same function. They help document the classes and methods, and tools that generate class/method documentation from source always include them. They're as important as the type signature. They also help isolate bugs, in that you get told explicitly that routine foo passed in an invalid parameter to bar rather than an exception somewhere deep in the guts of bar that you have to work back from to find foo. As I said before, I'm not sure I agree that the latter is worth the cost of using them for anything complex. The bugs they uncover are as likely to be in the pre/post conditions as in the code proper. The documentation benefit is unquestionable, though. And if some condition is worth documenting, then having it as executable documentation means it gets tested with the rest of the code, so you know the documentation is correct. Which means that just adding conditions to a language misses most of the benefit of DbC. You need to fix the documentation system as well. This is the kind of theory that you'll find in OOSC: why the features that are there help make programming easier. Not theories about how they make the resulting program better. Those two have a lot in common, though. Anything that makes witing correct code easier generally results in a better program. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 7:46 AM, Strake strake...@gmail.com wrote: Disclaimer: My own experience with OO is limited. Mine isn't quite so much... On 30/12/2012, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though. ... I thought it could be good to me (as a programmer) to learn C/C++. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life. So my questions for you all are: * Is it really worthwhile for me to learn OO-programming? Likely. Some code is most readily written in objective style. Learning a new paradigm is almost always a good idea. It gives you a new set of tools for approaching programming problems. Of course, the single worst thing you can do is try and force a paradigm onto a language that isn't meant for it. * If so, where should I start? There are plenty of functional programming for OO programmers but I have never seen OO programming for functional programmers. Smalltalk. That's a good functional start. Personally, I'd go with Eiffel, because it means you can use Meyer's (no relation) Object Oriented Software Construction as a text. Unfortunately, you'll have to buy a dead trees copy of that text. It not only covers OO programming, but explains why things are the way they are, why the way C++ is is wrong, and provides an introduction to design-by-contract as well. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
On 12/17/12, Ketil Malde ke...@malde.org wrote: I would use copying to mean verbatim cut-and-pasting, which is something else. I feel I should point out that, while that's currently a common definition of copying, it's not the legal definition. Copyright law predates the ability to mechanically create copies of a work. The closest you could come was the printing press, which started with what was at the time a handmade mirror image of the work you were going to print copies of. Back then, the only way to create a copy of a printed page (or anything else that wasn't created with the express purpose of being duplicated) was to read the original, and transcribe it into a copy. There was no cut-n-paste or copy command - just reading and creating another copy by hand. Changes made along the way that depended on the original - adding illustrations or illuminations, setting it to music, re-arranging it into a script for a play, or translating it to another language - were all considered derived works, and hence infringing. IANAL, but I've been studying copyright law since before the US signed the Berne treaty. Generally, copyright law in the US has been getting stricter, not more permissive - largely because the only people who cared were the large copyright holders. In general, new media brought under the purview of copyright is treated as strictly as the law can be interpreted. In the US, most radio stations pay a license fee in order to play music. Bars and restaurants (and even the Girl Scouts!) are required to pay a license fee for public performances if they play live or recorded music. If you buy media capable of recording music or video, part of the cost is used to compensate the copyright holders of the presumably infringing copies you're going to make onto them. If I took a picture of my living room, I'd technically be in violation of a slew of copyrights (images of the statuary on the mantelpiece, paintings hanging on the wall, etc.) but chances are that nobody would care unless I included images from a FOX television show. Personally, I think this is silly, but it's the law. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Ketil Malde ke...@malde.org wrote: Mike Meyer m...@mired.org writes: Niklas Larsson metanik...@gmail.com wrote: 2012/12/15 Mike Meyer m...@mired.org: Only if Tanenbaum documented the internal behavior of Linux before it was written. Tannenbaum wrote Minix, the operating system that Linus used (and hacked on) before he did Linux. Minix contained lots of features that was reimplemented in Linux. Ah, Minix isn't documentation. And it has a radically different architecture The point is that Linux read the source code to Minix before implementing similar things - quite likely using the same algorithms, for instance. So if containers is a translation of FXT, then surely Linux is a translation of Minix. Since they are both C, the concept of translation doesn't enter into that case at all. I never said that containers was a translation of FXT. I said that translations are considered to be derived work requiring permission to copy. This is deeply embedded in copyright law, and the GPL *depends* on it working for software. Otherwise, a distribution of GPL' d software translated to another language (say as asm from the compiler, or a linkable object, or even an executable) wouldn't be a derivative work and could be distributed without having to obey the license. The point is that containers being in haskell isn't a defense against copyright violation. It doesn't mean that it *is* a translation, merely that it might be. That the author of containers said it was derived from FXT opens the possibility that his version is actually GPL'ed, so using it opens up the possibility of a lawsuit. It may not stand up in court, but the lawyer objecting is trying to avoid just that possibility. That makes a successful lawsuit unlikely The point of the point is that neither of these are translations of literary works, there is no precedence for considering them as such, Actually, there *is* a precedent for considering them such. The clean-room implementations of the IBM PC bios were done because a judge ruled that translating from asm to binary was an infringing copy. If you have a precedent that translating from one programming language to another is *not* the creation of a derived work, I'd be interested in hearing about it. Without such a precedent, then a case can be made that such a translation is a derived work (and you're the only person I've ever heard claim otherwise) which opens up the possibility of a lawsuit, which is what the problem is. and that reading somebody's work (whether literary or source code) before writing one's own does not imply that the 'somebody' will hold any rights to the subsequent work. This is correct. Reading a copyrighted work does not prove that some subsequent creation is a copy of that work. It does, however, make it *possible* that such a work is a copy and needs the appropriate permissions. Translations in software is what compilers do, not reimplementing specific algorithms. Translation in a copyright case is a term of law, and has *nothing* to do with the behavior of compilers (other than the precedent that what a compiler does is considered a translation for copyright purposes). Reimplementing an algorithm may or may not be a copyright violation. Depends on whether or not the reimplementation involved creation of a work derived (in the legal sense) from the original. Access to the original is required for that to happen. The two being in the same language is *not* required for that to happen. Access to the original and working in the same language is *not* sufficient for that to happen. it'll never go to court, so there isn't an infringement. Tannenbaum isn't going to sue Linus. So either he doesn't believe there is an infringement (I suspect this is likely, as he has had access the source and would probably have at least said something if he thought there was an infringement) or doesn't care enough to go to court. Until a judge tells Linus he's infringing, he isn't. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Ketil Malde ke...@malde.org wrote: In particular when copyright is concerned, I believe that verbatim copying in many cases will require a license to the original work, but merly examining the original work to make use of algorithms, tricks, and structures from it will not. If you don't actually copy any of the text in the latter case, that would be correct. But there's an incredible amount of grey between those two extremes of black and white, and it's possible that you've unintentionally recreated significant bits of the original. The Oracle/Google lawsuit was all about those shades of grey - some of the API's in Dalvik were implemented by people who had read the Java sources. Oracle claimed as much as possible was derivative, Google that none of it was. The judge ruled that some uses were infringing and some uses were not. This was a technically literate judge - he ruled that one of the cases was non-infringing because he could trivially implement the function in Java himself. The lawyer who pointed out the possible infringement here isn't really worried about losing such a lawsuit - there are lots of ways to deal with that short of actually releasing any sources they consider proprietary. They want to avoid the lawsuit *at all*, as that will almost certainly be more expensive than losing it. At least, that's what I hear from clients who ask me not to include GPL'ed software. mike -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Ketil Malde ke...@malde.org wrote: Clark Gaebel cgae...@uwaterloo.ca writes: I just did a quick derivation from http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 A copyrighted work, you say? The work is copyrighted, the snippets are placed in the placed in the public domain. This is old hat - you can copyright a collection of non-copyrightable objects. I think this is wrong, copyright does not cover algorithms, and reverse engineering is not literary translation. As it's commonly understood, reverse engineering doesn't involve looking at the code. That's why it's called reverse engineering instead of copying. If you never had access to the code, you couldn't have copied it. Of course, you can't produce a literary translation of it, either. The implications of anything else would be draconian Calling the current state of copyright law in the US draconian might be going a little far. But only a little. simply documenting a program would be a breach of its copyright Documenting code has run into copyright issue before. That's why *both* volumes of the Lion's book were pulled from publication. Documenting codes behavior as a black box or how you use it isn't a problem. If you say function F finds the highest one it in it's argument or call f(x) to find the highest one bit in x and I then write a function f that behaves that way, there can't have been a copyright violation, because I never saw the source to f. If you *give* me that source, and I translate the code to another language, then I've created a derived work, which means copyright law applies. If you give me the source to f, and I write a function that does the same thing - then I may or may not have copied it. This means I *could* wind up in court over the thing, which is exactly the possibility that the lawyer is trying to avoid. Tanenbaum would hold the copyright to Linux. Only if Tanenbaum documented the internal behavior of Linux before it was written. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Niklas Larsson metanik...@gmail.com wrote: 2012/12/15 Mike Meyer m...@mired.org: Only if Tanenbaum documented the internal behavior of Linux before it was written. Tannenbaum wrote Minix, the operating system that Linus used (and hacked on) before he did Linux. Minix contained lots of features that was reimplemented in Linux. Ah, Minix isn't documentation. And it has a radically different architecture than either Linux or Unix (which it copied features from). That makes a successful lawsuit unlikely should Tanenbaum pursue one - but you can't say for certain until after a court rules on it. Which is the bottom line in such cases: if the copyright holder doesn't care, it'll never go to court, so there isn't an infringement. Same thing with Stallman, do you think he never saw the Unix sources? Did he ever write anything that was copied from Unix? The Hurd used a completely different architecture than Unix. Emacs predated Unix. By the time he got around to writing a c compiler, there were more from people other than ATT than from ATT. And gcc drew more from the lisp community than from the Unix compilers. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
On Wed, 12 Dec 2012 17:27:03 +0100 Vo Minh Thu not...@gmail.com wrote: I'm not sure what your point is. Re-implementing an algorithm is not a copyright infringement (nor is a propagation of the original work). Algorithms are not covered by copyright. While algorithms aren't covered by copyright, *code* is. A translation of a copyrighted work into another language is considered a derived work of the original. If not, then simply translating a source program into some computer's binary language would release it from copyright, and it could be freely distributed. That would pretty much kill the GPL. Once someone has read an algorithm in some programming language, it opens the question of whether they are copying the algorithm or the code if they produce a copy of the algorithm. The generally accepted solution is the one taken here - a clean-room re-implementation by people who haven't read the code (ok, sort of taken here). It might be small enough to get by on a fair use clause. The prior art and obvious exceptions stated on this thread are for patents, and don't apply to copyright. But that's all irrelevant. The reason company lawyers object to having GPL'ed code in the company code base is that it opens them up to the possibility of a lawsuit. That the original author said it was derived from GPL'ed code was sufficient to cause at least one lawyer to believe that a case existed. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)
On Thu, 13 Dec 2012 08:58:07 +1100 Ramana Kumar ramana.ku...@cl.cam.ac.uk wrote: On Thu, Dec 13, 2012 at 5:36 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: A GPLed containers forces the library user to somehow get a way of complying to the license. The language here needs some clarification: the GPL (or other free copyleft license) only forces someone to do something under very particular circumstances, which could be characterised as: 1. They are planning on distributing non-free software, and, Or using a free license that isn't compatible with the GPL, or incorporating software that is covered by such a license. You can find a list of these licenses at: http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses and following, which lists licenses used for open source but aren't considered free licenses by the GNU folks. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Niklas Larsson metanik...@gmail.com wrote: 2012/12/12 Niklas Larsson metanik...@gmail.com: There is no copied code from FXT (which can be said with certainty as FXT is a C library), hence the there can be copyright issue. Gah, I should proofread! NO copyright issue, of course. Um, no. Copyright *includes* translations. A translated copy of a work is based on the original and requires copyright permissions. This makes it a modified work according to the definitions in the GPL. You're all thinking about this as if logic and the law had something in common. The relevant question isn't whether or not the GPL applies, but whether or not a case can be made that the GPL should apply. Clearly, that case can be made, so if you include the containers code without treating it as GPL'ed, you risk winding up in court. I suspect that's what the lawyer is really trying to avoid, as it would mean they'd actually have to work. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tie-knot library
David Thomas davidleotho...@gmail.com wrote: ... and OS X and iOS are clearly a win for the FLOSS community? Yes. The parts of it that are willing to use BSD-licensed software, anyway. Apple does release sources to some of their toys. They released all of OS X below the GUI level, for instance. Grand Central Dispatch should be checked out by anyone doing concurrent programming, but you may have to apply the language patches Apple released, or upgrade you language to their version. Etc. Smart developers will give back only things they don't consider critical to their business, even if they have to morph their architecture to comply with the license. Look at Tivo - they use Linux, but last time I looked their FLOSS releases were far less interesting than what we got from Apple. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Heinrich Apfelmus apfel...@quantentunnel.de wrote: Christopher Howard wrote: Concerning a university education, there are two approaches 1. I want to learn as much as possible 2. I want to learn just enough to get a high-paying job There's actually a third approach ( and probably more): 3. I want to learn to do this job as well as possible. On the other hand, approaching university from the second point of view usually does not justify the cost for the little benefit you obtain this way. Unfortunately, it seems to me that the tuition costs in the U.S. strongly suggest the second approach. To avoid this, I recommend to either go abroad or become very good and acquire a scholarship. That really depends on the job at in question. When I was looking for entry level programming jobs, not having a degree meant you never got past the hr department. Getting a degree (pretty much any degree) was required to get the high-paying job. I'm willing to believe that's no longer the case for programmers, because academia has consistently failed to deliver sufficient quality programmers to meet industry needs. On the other hand (watching my sons deal with the job market), the litmus test for you've got what it takes to survive in the system is now a masters, not a bachelors, so maybe you're wrong about that. The other thing to consider is what your long-term goals are. Do you want to be a code monkey all your life? Or do you aspire to more? What are the requirements for that more? Getting a degree now may well avoid doing it later. Finally, with approach #3, you really need a mentor who can tell you whether or not you're doing a competent job. You're much more likely to find that in a university environment than trying to learn things by yourself. Joining an open source project might get it for you. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)
On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins g...@gregorycollins.net wrote: If you have a hard real-time requirement then a garbage-collected language may not be appropriate for you. This is a common meme, but frankly, it isn't true. When writing real-time code, you just need to make sure that everything that happens takes a known maximum amount of time. Then, you can sum up the maximums and verify that you do indeed finish in the real-time window of the task. GC is a problem because it's not predictable, and may not have a maximum. However, it's no worse than a modern version of the C function malloc. Some of those even do garbage collection internally before doing an OS call if they're out of memory. The solution is the same in both cases - make sure you don't do GC (or call malloc) in the critical region. Both require knowing implementation details of everything you call, but it isn't impossible, or even particularly difficult. Lazyness, on the other hand ... I haven't thought about. I suspect you need to force the evaluation of everything you're going to need before you start the critical region, but I wonder if that's enough? Has anyone out there investigated this? Thanks, mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
Jacques Carette care...@mcmaster.ca wrote: On 22/11/2012 11:52 AM, Brandon Allbery wrote: On Thu, Nov 22, 2012 at 7:56 AM, Jacques Carette care...@mcmaster.ca mailto:care...@mcmaster.ca wrote: On 20/11/2012 6:08 PM, Richard O'Keefe wrote: On 21/11/2012, at 4:49 AM, c...@lavabit.com mailto:c...@lavabit.com wrote: Well, I don't know. Would it save some time? Why bother with a core language? For a high level language (and for this purpose, even Fortran 66 counts as high level) you really don't _want_ a direct translation from source code to object code. You want to eliminate unused code and you want to do all sorts of analyses and improvements. It is *much* easier to do all that to a small core language than to the full source language. Actually, here I disagree. It might be much 'easier' for the programmers to do it for a small core language, but it may turn out to be much, much less effective. I 'discovered' this when (co-)writing a partial evaluator for Maple: You're still using a core language, though; just with a slightly different focus than Haskell's. I already mentioned gcc's internal language, which similarly is larger (semantically; syntactically it's sexprs). What combination is more appropriate depends on the language and the compiler implementation. Right, we agree: it is not 'core language' I disagreed with, it is 'smaller core language'. And we also agree that smaller/larger depends on the eventual application. But 'smaller core language' is so ingrained as conventional wisdom that I felt compelled to offer evidence against this bit of folklore. I don't think you're evidence contacts that bit of folklore. But as stated it's vague. In particular, is smaller relative to the full source language, or is it absolute (in which case you should compile to a RISC architecture and optimize that :-)? Since the latter seems silly, I have to ask if your core language for Maple was larger than Maple? -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal failures...
On Tue, Nov 20, 2012 at 7:34 PM, Albert Y. C. Lai tre...@vex.net wrote: On 12-11-20 08:20 PM, Johan Tibell wrote: This logic is flawed. More than 90% of computers having Windows doesn't imply that 90% of all computers in a given household runs Windows. What's the probability that your household has a Windows computer if you're a programmer that don't live with your parents? What if that programmer is an open source contributor. Surely not 90%. This counter-argument is flawed. Why limit oneself to one's own household? (Garage? Basement?) Get out more! Visit a friend. Talk to an internet cafe owner for a special deal to run one's own programs. Rent virtual machine time in the cloud. There are many creative, flexible, low-cost possibilities. The key word here is low-cost. None of them are as low as the cost of Linux, Solaris, *BSD, etc. Those are all free. There's even free VM software available for them so you don't have to dedicate a machine to it. This actually makes the argument running in the other direction more telling. It's less expensive for Windows users to get Unix/Linux than Unix/Linux users to get Windows. If you want a Haskell environment to work in, install VirtualBoxOSE (free) and a Linux distro (also free) and work on that. Of course, the real cost is that maintaining software that you aren't using on a regular basis - which includes software you do use on a platform you don't - is a PITA. Given that, why would anyone doing something for free want to spend money for (access to a) copy of Windows to build/test software they aren't going to use? Insert standard OSS rant about do it yourself here. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
Evan Laforge qdun...@gmail.com wrote: I wonder if people who like one giant window maybe don't use the REPL? I keep 3 windows open: one with the editor, one with ghci, and one with a shell. [...] I've tried with 3 terminals but I can never figure out what to do with the extra ones. Besides your two shells, I tend to have a documentation browser should I be using a library I'm not familiar with, and (once the project gets large enough) a second editor window for files with code that might interact with the code I'm working on. Of course, in an IDE (I use emacs), all of these things tend to be available as panes in one window. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
Colin Adams colinpaulad...@gmail.com wrote: I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen). I certainly don't use an 80-column limit any more. I use the rule: A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.) I don't think similar sized viewport begins to cover it. If the editor wraps long lines, then the lines will always be visible, no matter how long they are. Of course, lines wrapped around to the beginning of the next line in indented code are really, really ugly, so I'd prefer to avoid that. This is one of the cases where it's more important that there be a standard than what the actual value is. Personally, I like roughly 80 columns, but I've been dong this long enough to have used the things that the 80-column console format was copied from. That screens are now bigger isn't really relevant. They are also windowed - no matter how hard Windows, Linux and Mac apps try and pretend they own the entire screen - and multitasking, so it's unreasonable to format code as if the editor were going to be the only visible window. On the other hand, readable cross-platform text formatting always seems to be a lost cause, as this mail and the referenced blog posting demonstrate. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
On Tue, 16 Oct 2012 21:55:44 +0200 Alexander Kjeldaas alexander.kjeld...@gmail.com wrote: There are variants of this, but the meta-problem is that at the point in time when you call forkProcess, you must control all threads, ensuring that *all invariants hold*. Thus no locks held, no thread is in the C library, no foreign calls active etc. As an example, if one thread is in the C library doing some stdio, then the invariants in that library will not hold, and you cannot expect stdio to work in the child. This means that the only thing you can really do in the child process is call exec. Further, you can only call exec if you make sure that the exec correctly reverts everything back to a state where those invariants hold. Mostly, this is automatic as resources get freed on exec and do the right thing. Locks on file descriptors that aren't closed on exec will leave dangling locks, and locks on files that are closed on exec will unexpectedly close them in the parent. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
