Re: [Haskell-cafe] List comprehensions with Word8
On Thu, 16 May 2013 23:15:33 +0200, you wrote: Hello everyone, I was playing with Word8 and list comprehensions and the following examples came up. I have to admit the behavior looks quite strange because it does not seem to be consistent. Can someone shed some light on reason behind some of these outputs? When you say some positive integer :: [Word8] what you're effectively saying is some positive integer `mod` 256 because that's what fits into a slot that's 8 bits wide. So: 1000 `mod` 256 = 232 1 `mod` 256 = 16 and so on. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
On Thu, 29 Dec 2011 16:10:03 +1300, chris...@gmail.com wrote: In fact, this is required behavior according to the Haskell Report: Implementations should enforce as far as possible, at least locally to the Haskell process, multiple-reader single-writer locking on files. That is, there may either be many handles on the same file which manage input, or just one handle on the file which manages output. The second sentence somewhat contradicts the first. The first sentence says, multiple-reader single-writer which implies multiple readers AND at most one writer (i.e., at the same time). This is pretty typical file-locking behavior, and, from the symptoms, appears to be the way that Framemaker opens the file. The second sentence, on the other hand, implies that there can be multiple readers OR one writer, but not both (which appears to be the way that GHC operates). I guess on Windows, as far as possible means locking it across the whole system. Windows does allow finer-grained control (including byte-range locking), but most applications don't bother. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
On Fri, 16 Dec 2011 11:17:20 -0500, Brian Hurt bh...@spnz.org wrote: I think the truck-factor implications of the programming language as dwarfed by the implications of everything else in the project. Any project of any significant size is going to have a huge amount of project-specific information tucked up inside the programmers head. It doesn't matter if there are a million other programmers who know the language you used, or only a dozen- if you're the only one who knows how things were done, and more importantly, why they were done that way, and you get hit by a truck, then your boss has a big problem. Whether there are millions of candidate replacement programmers, or only dozens, none of them had the project-specific knowledge you had. Finding a replacement who knows the language is the least of his problems. I believe that you're absolutely right. I also believe that corporate decision makers rarely, if ever, think that way. And that's the problem: You have to deal with the perception, not the reality. So, that's the real question that needs to be answered: How do you deal with the _perception_ that hiring a Haskell developer instead of a Rails, etc. developer will result in more chaos when said developer is hit by a bus? -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considerednotentirelygreat?
On Tue, 27 Sep 2011 09:23:20 -0700 (PDT), you wrote: I think it's more than reasonable to expect [0.1,0.2..0.5] == [0.1,0.2,0.3,0.4,0.5] and that would make everyone happy, wouldn't it? [0.1,0.2..0.5] isn't the problem. The problem is coming up with something that not only works for [0.1,0.2..0.5], but also works for [0.1,0.2..1234567890.5]. A good rule of thumb: For every proposal that purports to eliminate having to explicitly take into consideration the limited precision of floating-point representations, there exists a trivial example that breaks that proposal. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considerednotentirelygreat?
On Tue, 27 Sep 2011 13:13:39 -0600, you wrote: On Tue, 2011-09-27 at 12:36 -0400, Steve Schafer wrote: [0.1,0.2..0.5] isn't the problem. The problem is coming up with something that not only works for [0.1,0.2..0.5], but also works for [0.1,0.2..1234567890.5]. A good rule of thumb: For every proposal that purports to eliminate having to explicitly take into consideration the limited precision of floating-point representations, there exists a trivial example that breaks that proposal. If by trivial you mean easy to construct, sure. But if you mean typical, that's overstating the case by quite a bit. There are plenty of perfectly good uses for floating point numbers, as long as you keep in mind a few simple rules: Your rules are what I meant by ...having to explicitly take into consideration the limited precision of floating-point representations. The problem, of course, is that people would rather not have to follow any rules, and that floating-point arithmetic would just work the way they think it ought to. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On Mon, 29 Aug 2011 08:40:45 +0100, you wrote: If you're doing, say, cryptography, then thousand-bit random integers that need to be serialised are fairly common... This is the part that makes no sense to me. Yes, you are absolutely correct that large, multiple-byte integers play a big role in cryptography. But those are invariably FIXED LENGTH multiple-byte integers. As I mentioned before, to the best of my knowledge, no one uses variable-size representations in those kinds of computationally-intensive applications. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On Sat, 27 Aug 2011 11:57:57 +0100, you wrote: I meant if you're trying to *implement* serialisation. The Bits class allows you to access bits one by one, but surely you'd want some way to know how many bits you need to keep? For fixed-size types (e.g., Int), I might use a simple byte-for-byte serialization. But these days, I tend to avoid binary serializations, and use string conversions for all types, taking advantage of whatever built-in conversions the language offers. There's obviously more overhead, but the advantages usually outweigh the disadvantages. For one thing, I can come back a couple of years later and still figure out what the data are supposed to be. Likewise, you say the standard PRNG can be used to generate random Integers, but what if you're trying to implement a new PRNG? I'm not aware of of any PRNGs that use variable-length types (and I would think that such a PRNG wouldn't be very efficient), so I'm still not sure that I understand the question. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On Fri, 26 Aug 2011 18:24:37 +0100, you wrote: I would usually want #3 or #4. Out of curiosity, what for? While I do occasionally need to get a logarithmic size estimate of a number (which is basically what #3 and #4 are), the specific requirements in each case tend to vary, enough so that it's unlikely that a single function (other than simply taking the logarithm) can handle the majority of applications. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On Fri, 26 Aug 2011 20:30:02 +0100, you wrote: You wouldn't want to know how many bits you need to store on disk to reliably recreate the value? I can't say that I have cared about that sort of thing in a very long time. Bits are rather cheap these days. I store data on disk, and the space it occupies is whatever it is; I don't worry about it. Or how many bits of randomness you need to compute a value less than or equal to this one? I'm not sure I understand this one. I generally don't need _any_ randomness to compute a value. On the other hand, if the desire is to take an integer n and generate a set of pseudorandom numbers ranging from 0 to n-1, that's easily done using the standard random number methods. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic Reference Counting
On Sat, 2 Jul 2011 16:51:53 +0100, you wrote: Apple recently announced a new static analysis in Clang called ARC (Automatic Reference Counting). The idea is to provide what GC provides (zero memory management code by the programmer), but not to incur the runtime penalty of having to have the GC run. It seems to be extremely effective in objective-C land. I was wondering if any of the compiler gurus out there could comment on the applicability of this kind of analysis to Haskell. Dropping the GC and hence stopping it blocking all threads and killing parallel performance seems like nirvana. Reference counting as a means of lifetime management has been around for a long time in Microsoft's Component Object Model. And in both (Microsoft) Visual Basic and (Borland/CodeGear/Embarcadero) Delphi, reference counting is automatic, in a way that appears to be essentially identical to what Apple is describing. So, the concept is nothing new; the new part is that it is being offerred in a C dialect. The one major problem that's still left with ARC is that it does not solve the retain cycle problem of reference counting. Programmers must insert a weak keyword to break cycles in their data graphs. Could even this analysis be automated statically? Could we put up with a language extension that added this annotation? For handling cycles, there are alternatives to weak references, but I don't know that any of them is better than weak references. Excluding weak references, I don't know of a way to deal with cycles that isn't computationally equivalent to what full-blown garbage collectors already do, so there's really nothing to be gained there. If there were a way to do static analysis, there would be no need for garbage collection as it is currently implemented--the compiler would be able to insert explicit object lifetime management directly into the code. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding of Haskell source files
On Mon, 4 Apr 2011 13:30:08 +0100, you wrote: Windows APIs use UTF-16... The newer ones, at least. The older ones usually come in two flavors, UTF-16LE and 8-bit code page-based. ...but the encoding of files (which is the relevant point here) is almost uniformly UTF-8 - though of course you can find legacy apps making other choices. If you're talking about files written and read by the operating system itself, then perhaps. But my experience is that there are a lot of applications that use UTF-16LE, especially ones that typically only work with smaller files (configuration files, etc.). As for Haskell, I would still vote for UTF-8 only, though. The only reason to favor anything else is legacy compatibility with existing Haskell source files, and that isn't really an issue here. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Examples for the problem
On Wed, 2 Mar 2011 14:14:02 +0100, you wrote: Thank you all for the responses. Here's an example: As I alrerady said, I tried to parse the MMIXAL assembly language. Each instruction has up to three operands, looking like this: @+4 (Jump for bytes forward) foo (the string foo '0'(1+2) etc. A string literal may contain anything but a newline, (there are no escape codes or similar). But when I add a check for a newline, the parser just fails and the next one is tried. This is undesired, as I want to return an error like unexpected newline instead. How is this handled in other parsers? Tillman's reply is absolutely correct. If a particular sequence of characters is invalid according to your grammar, then _all_ of the alternatives in scope at that point should fail to parse that sequence. If that's not happening, then there's something wrong with the way you've expressed your grammar. I don't know how much experience you have with language grammars, but it might be helpful to try to write down MMIXAL's grammar using EBNF notation, as a starting point. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple attoparsec question
On Tue, 01 Mar 2011 22:15:38 +0100, you wrote: The problem is, that attoparsec just silently fails on this kind of strings and tries other parsers afterwards, which leads to strange results. Can you give a concrete example of the problem that you're seeing here? (Basically, you're describing exactly how a parser is supposed to work, so it's not clear what the problem is...) -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] who's in charge?
On Wed, 27 Oct 2010 14:13:31 +0100, you wrote: They're just figureheads for a shadowy cabal :-D You mean the Haskelluminati? -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: All binary strings of a given length
On Fri, 15 Oct 2010 09:16:58 -0400, rgowka1 rgow...@gmail.com wrote: But genbin 32 gives an empty list.. works till 31. That's because Daniel uses values of type Int as intermediate storage during the computation, and Int values are only 32 bits long. By replacing Int with Integer (which does not have that limitation), you can make it work for larger numbers/longer strings: genbin n = map (showFixed n) [0..2^n-1::Integer] -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static computation/inlining
On Sun, 10 Oct 2010 18:51:59 -0700, Alexander Solla a...@2piix.com wrote: Although the list isn't huge, I would still rather get rid of the O(2*n) operation of turning it into maps at run-time. I usually handle this as follows: 1) I create my data file in some human-friendly format (such as your list of tuples), so that I can easily edit it later, as required. 2) I write a program, a sort of preprocessor, that (a) loads the data from the human-friendly format into a processing-friendly structure, and then (b) serializes that structure into a file that's efficient to load at run time. (So, for example, lookups from the name of a country to its ISO codes can be handled via a Patricia structure; a Patricia structure is tedious to construct, but once constructed, is easy to serialize and de-serialize.) 3) The file containing the serialized structure is then linked into the rest of the real program as a source unit, where the serialized structure is represented as a constant (usually a string, but sometimes an array of numbers, etc.). If your build environment has a reasonable make-like tool, then the whole process is pretty automatic; you just modify the human-friendly file as often as you want, and the preprocessor is invoked automatically, as needed. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pronouncing Curry and currying
On Fri, 8 Oct 2010 09:56:07 +0200, you wrote: Unfortunately, hurry is pronounced differently in British and US English [1], so again I was a little bit confused :-). [1] http://en.wiktionary.org/wiki/hurry#Pronunciation The US sample is correct for someone from California, but it's not the way a person from New York City would pronounce it (closer to the UK pronunciation). I grew up near San Francisco, where marry, merry and Mary all sound the same, as do our and are. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
On Thu, 07 Oct 2010 10:02:20 +0200, you wrote: I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) Considering them both used as nouns, I would say that in normal usage, there is a difference in their active/passive connotation. If you have a collection of things, they have an order, whether or not that order was imposed on them (it could be that they just fell out of the box in a certain order). On the other hand, if they possess an ordering, it implies that someone or something put them in that order; i.e., that it was a purposeful act. I think the reason for this conceptual distinction can be traced to the derivation of ordering as the gerund form of the verb order, in that it implies that an action has occurred (or is still occurring). -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I still cannot seem to get a GUI working under Windows.
On Fri, 01 Oct 2010 13:45:00 +0100, you wrote: I think that the issue is that making things better on Windows (and likely OS X as well) requires co-ordinated and agreed action across a number of areas. This means getting a moderate number of people, most of whom give up their time and effort for free, and for the good of the community, to agree on what is needed and to prioritize it in a co-ordinated way. The action needed by any individual might be relatively small, but without community agreement and action, the end goal cannot be achieved. Thank you. That's basically what I was trying to say: The project is too big for one person, or a small group of people. But it also can't happen unless there's a shared understanding of what is important and why it is important, and that's what seems to be lacking here. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I still cannot seem to get a GUI working under Windows.
On Sat, 2 Oct 2010 11:02:21 -0700, you wrote: I imagine someone looking at a lovely app and saying, Wow -- great interface! I bet it was programmed in Haskell. While I can agree with the sentiment...well, good luck with that. ;-) -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I still cannot seem to get a GUI working under Windows.
On Wed, 29 Sep 2010 20:08:07 +0200, you wrote: I think the problem is lack of Windows developers interested in GUIs, and that Windows is not so POSIXy-development-friendly as Linux or OS X. But mostly lack of people interested in that area, I think. There are lots of Windows developers interested in GUIs. On the whole, I'd say that Windows developers are far more focused on GUIs than non-Windows developers. (See, for example: http://mpt.net.nz/archive/2008/08/01/free-software-usability and http://daringfireball.net/2004/04/spray_on_usability for some discussion of attitudes.) The issue isn't that there aren't a lot of Windows developers who have an interest in Haskell+GUI development. The issue is that nearly every Windows developer who looks into Haskell+GUI says, This stuff sucks, and walks away, because they're interested in developing applications, not wrestling with GUI toolkits. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I still cannot seem to get a GUI working under Windows.
On Wed, 29 Sep 2010 20:44:22 +0200, you wrote: Yeah, but not liking wrestling with libraries isn't peculiar to Haskell developers. There just needs to be enough people that the probability of there being a person who will bother to wrestle with it is high enough. Hence, the issue is lack of interest. No, it isn't peculiar to Haskell developers; the problem is the one that is discussed in more detail in the two references I gave in my previous message: For the most part, developers who are attracted to open-source projects (and this certainly includes the majority of Haskell developers) simply don't think much of GUIs, and are consequently willing to release software with half-baked GUI support (at best). This is an attitude that just doesn't fly in the Windows world. Which is unfortunate, because the Windows market is HUGE compared to OS X, and STUNNINGLY HUGE compared to everything else. The fix isn't going to be to find a developer who's willing to do the work to make Haskell+GUI more seamless under Windows. The fix is for the Haskell community--as a whole--to wake up and realize what the wxWidgets folks did a while ago: Hey, you know what? This GUI stuff is _important_ if we want people to pay any attention to the software that we write! -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On Tue, 10 Aug 2010 18:27:49 -0300, you wrote: Nope. For example, suppose we have: int randomNumber(int min, int max); Equivalentely: randomNumber :: Int - Int - IO Int In Haskell if we say (+) $ randomNumber 10 15 * randomNumber 10 15 That's the same as let x = randomNumber 10 15 in (+) $ x * x If we had in C: return (randomNumber(10, 15) + randomNumber(10, 15)) That would not be the same as: int x = randomNumber(10, 15) return (x + x) I think you're misinterpreting what Martijn is saying. He's not talking about referential transparency at all. What he's saying is that in a language like C, you can always replace a function call with the code that constitutes the body of that function. In C-speak, you can inline the function. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell Platform 2010.2.0.0
On Fri, 23 Jul 2010 18:08:39 +0100, you wrote: Anybody have any theroes why Trend Micro Antivirus is reporting this as a confirmed fraud/attack site? Because someone somewhere has used the nyud.net distribution service to distribute malware. Since it's a free service, it's pretty much guaranteed that it will have been abused at some point. You can get the same warnings about tinyurl.com, for example, because people have used tinyurl.com to direct traffic to malicious web sites. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, 09 Jul 2010 10:07:06 -0400, you wrote: I don't think I've ever seen them *followed* by commas. Preceded, always. In American English, they're always followed by commas, and preceded by comma, semicolon, dash or left parenthesis, depending on the specific context. Examples from various online style guides: I am the big cheese, i.e., the boss. The department is unattached; i.e., it is not administered by one of the schools or colleges. Most committee members-i.e., those who were willing to speak out-wanted to reject the plan. Most committee members (i.e., those who were willing to speak out) wanted to reject the plan. See also: http://www.videojug.com/film/how-to-use-ie-and-eg -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, 9 Jul 2010 17:14:31 +0200, you wrote: One of the nice things about English is that there is often never an always. See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a discussion. Well, that page pretty much confirms what I said. In AMERICAN English, they're always followed by commas. The two sources mentioned on that page that suggest omitting the commas (Fowler's and Oxrford) are both based on UK English. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vague: Assembly line process
On Wed, 16 Jun 2010 18:30:47 +0200, you wrote: Then I thought, what if I replace the (*) and (+) operations which are applied when I multipy the matrix with a vector (i.e. a vector if inputs or outputs) by something more general. So I replaced (+) by function application and my matrix was now a matrix of functions. But then I got lost trying to find a way to invert such a matrix. You'd have to have a general way of finding the inverse of a function, which doesn't exist (many functions aren't invertible at all, for example). -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vague: Assembly line process
On Tue, 15 Jun 2010 19:23:35 +0200, you wrote: When I know my supplies I want to know what I can produce. When I know what I want to produce I want to know what supplies I need for that. Both kinds of questions should be answered by a singe Process thingy. I want to be able to chain processes and the whole thing should still act like a Process. This is a type of constraint network. If you have access to _Structure and Interpretation of Computer Programs_, there is a section therein devoted to constraint networks. See also: http://en.wikipedia.org/wiki/Constraint_programming Note that you need to be able to handle two kinds of chaining: compoundContraint = constraint1 AND constraint2 -- the compound constraint isn't satisfied unless you can satisfy -- both primary constraints compoundContraint = constraint1 OR constraint2 -- the compound constraint is satisfied if either of the primary -- constraints is satisfied -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: US Patent for the idea ...
On Sat, 17 Apr 2010 23:33:48 +0100, you wrote: I think in all fairness to examiners that in a way they have an impossible job due to the fact that what is a clever idea to one programmer will be a trivial idea to another: the field is so huge and people have such different experiences. In US patent law, algorithms themselves were deemed unpatentable quite some time ago (I believe that European patent law is more liberal in that regard, but I don't know all of the details). So a lot of the discussion concerning software patents in this country has been on whether or not software can be considered to be an invention separate from the underlying algorithms used in its construction. Since those of us who work with software realize that software is often little more than a restatement of an algorithm in a way that is suitable for a computing device to understand, it's very difficult to draw a clear line between the two. People do occasionally come up with truly novel ideas about how to perform some software task, but it seems to me that unless the novelty involves some aspect that can be separated from the algorithmic approach used, it shouldn't be patentable. For example, quicksort, though certainly novel, is purely an algorithm, so it shouldn't be patentable--it is completely independent of any tangible implementation. But a sorting technique that is optimized for large datasets that can't be held entirely in volatile memory, and explicitly takes advantage of known characteristics of disk latency, etc., could very well be patentable. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage accounts and real names
On Tue, 06 Apr 2010 14:57:30 +0200, you wrote: I agree, and this is why I phased out apfelmus in favor of the pseudonym Heinrich Apfelmus. You mean your name isn't really Applesauce? Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there any female Haskellers?
On Sun, 28 Mar 2010 20:38:49 -0700, you wrote: * The difference between genders is smaller than the difference between individuals If only people would understand and accept the near-universality of this: The difference between any group you want to discriminate against and any group you want to discriminate in favor of is smaller than the difference between individuals. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there any female Haskellers?
On Mon, 29 Mar 2010 17:32:57 +0200, you wrote: What's evil in being different? The point is that people use _generic_ differences as a rationale for discrimination against _individuals_. For example, in the US, it has, until recently, been used as an argument against female firefighters, because women, in general, have less upper-body strength than men, and are therefore less able to manage the equipment used. But there are, of course, plenty of women who have upper-body strength significantly above average, as well as men whose upper-body strength is well below average. So the appropriate basis for discrimination is, Do you have the strength to manage the equipment? rather than Are you a man or a woman? So yes, there are generic differences between As and Bs (whatever categories A and B may represent), but that should not be used as a rationale for discrimination against individual As or Bs, because there is nearly always substantial overlap between the categories in whatever criterion it is that you're measuring. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
On Thu, 25 Mar 2010 18:16:07 +0100, you wrote: Yes counting the nesting level like Twan proposed will definitely solve the modularity problem. I do think we need to optimize the block and unblock operations in such a way that they don't need to use IORefs to save the counting level. The version Twan posted requires 2 reads and 2 writes for a block and unblock. While I haven't profiled it I think it's not very efficient. Wouldn't you be better off using real transaction processing (i.e., with rollback)? That preserves the greatest possible modularity, because the lower level operations don't have to worry about failures at all. You generally only care about atomicity at some outer, observable level; there is rarely any point in worrying about nested atomicity. Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Very imperfect hash function
I'm looking for some algorithmic suggestions: I have a set of several hundred key/value pairs. The keys are 32-bit integers, and are all distinct. The values are also integers, but the number of values is small (only six in my current problem). So, obviously, several keys map to the same value. For some subsets of keys, examining only a small portion of the key's bits is enough to determine the associated value. For example, there may be 250 keys that all have the same most-significant byte, and all 250 map to the same value. There are also keys at the other extreme, where two keys that differ in only one bit position map to different values. The data are currently in a large lookup table. To save space, I'd like to convert that into a sort of hash function: hash :: key - value My question is this: Is there any kind of generic approach that can make use of the knowledge about the internal redundancy of the keys to come up with an efficient function? 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: [Haskell-cafe] Language simplicity
On Thu, 14 Jan 2010 14:42:06 +, you wrote: All Lisps have special forms which are evaluated uniquely and differently from function application and are therefore reserved words by another name. For example, Clojure has def, if, do, let, var, quote, fn, loop, recur, throw, try, monitor-enter, monitor-exit, dot, new and set!. Yes, but the special forms are not distinguishable from user defined macros --- and some Lisp-implemantations special forms are another implementations macros. E.g. you can choose to make `if' a macro that expands to `cond' or vice versa. I do not know whether you are allowed to shadow the name of special-forms. You can in Scheme; syntactic-keyword bindings can shadow variable bindings, and vice versa: The following is given as an example in R5RS: (let-syntax ((when (syntax-rules () ((when test stmt1 stmt2 ...) (if test (begin stmt1 stmt2 ...)) (let ((if #t)) (when if (set! if 'now)) if)) Evaluating the above returns now. 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: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Fri, 18 Dec 2009 16:39:21 +1300, you wrote: My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. I wouldn't notice the difference between Preset and Present in either case. And in the latter example, my eyes would actually be drawn away from Preset/Present and towards Colour, noticing that it is spelled incorrectly... Count me in the prefers hyphens camp, by the way. 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
[Haskell-cafe] Haskell furniture?
Here is some furniture that ought to appeal to the Haskell afficionado: http://karl-andersson.se/view_product.asp?rangeId=39catId=2picture=2 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: [Haskell-cafe] Sugestion for a Haskell mascot
On Tue, 10 Mar 2009 21:08:15 +0100, you wrote: I found one on Amazon http://www.amazon.com/Plush-Sloth-Bear-Cuddlekin-12/dp/B000FBLP76 , but without the logo. But we would of cause need one with Haskell logo printed upon it. I could not find a place with user-definable textile printing (if that is the right term in english) on plush sloth bears. A sloth bear is a kind of bear, not a sloth. Amazon also has some sloth stuffed animals, too. If you get one that's reasonably large, then you can get a lambda-imprinted Cafe Press t-shirt in an infant size that would fit it. 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: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 15 Jan 2009 20:18:50 -0800, you wrote: Really. So the engineer who designed the apartment building I'm in at the moment didn't know any physics, thought `tensor' was a scary math term irrelevant to practical, real-world engineering, and will only read books on engineering that replace the other scary technical term `vector' with point-direction-value-thingy? I think I'm going to sleep under the stars tonight... As a rule, buildings are designed by architects, whose main job is to ensure that they follow the requirements set by the relevant building code (e.g., the International Building Code, used in most of the United States and a few other places). Of course, an experienced architect has most of that stuff in his/her brain already, and doesn't need to constantly refer to the code books. A jurisdiction may require that the architect's design be signed off by one or more engineers. This is almost always the case for public buildings and multi-unit housing, and almost always not the case for single-unit housing. But if the building is a run-of-the-mill design, then the engineer checking it is unlikely to use anything beyond simple algebra. It's only in case of unusual structures and one-offs (skyscrapers, most anything built in Dubai these days, etc.) that engineers will really get down and dirty with the math. And yes, most professional engineers would not be able to do that kind of work without some kind of refresher, not so much because they never learned it, but because they haven't used it in so long. Um, no. I try to avoid people as much as possible; computers at least make sense. Also anything else to do with the real world :) Well, that it explains it then... Again, do engineers know *what* stress is? Do they understand terms like `tensor'? Those things are the rough equivalents of terms like `monoid'. Stress, probably, at least in basic terms. Tensor, probably not. 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: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, 15 Jan 2009 13:21:57 -0800, you wrote: Where, in the history of western civilization, has there ever been an engineering discipline whose adherents were permitted to remain ignorant of the basic mathematical terminology and methodology that their enterprise is founded on? Umm, all of them? No one may be a structural engineer, and remain ignorant of physics. No one may be a chemical engineer, and remain ignorant of chemistry. Why on earth should any one be permitted to be a software engineer, and remain ignorant of computing science? Do you know any actual working structural or chemical engineers? Most engineering disciplines require a basic grasp of the underlying theory, yes, but not much beyond that. Pretty much everything else is covered by rules (either rules of thumb or published standards). Show me an electrical engineer who can explain the physics of a pn junction and how it acts as a rectifier, or a civil engineer who can explain why the stress/strain curve of a steel beam has the shape that it does, or a chemical engineer who can explain molecular orbital theory. Those kinds of engineers do exist, of course, but they are few and far between. If you aim your product only at the kinds of engineers who _can_ do those things, you will be reaching a tiny, tiny fraction of the overall population. 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: Names in Haskell (Was: [Haskell-cafe] Comments from OCaml HackerBr ian Hurt)
On Thu, 15 Jan 2009 17:16:04 -0500 (EST), you wrote: What I don't understand is why Monoid and Monad are objectionable, while Hash, Vector, Boolean, and Integer are (presumably) not objectionable. They all appear equally technical to me. I think the name issue is a red herring. The real issue is that, after being confronted by a concept with an unfamiliar name, it can be very difficult to figure out the nature of the concept. That is, it's not the name itself that's the problem, it's the fact that trying to understand what it means often leads you on an interminable Alice-in-Wonderland-esque journey that never seems to get anywhere. 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: [Haskell-cafe] Re: Computer time, independent of date
On Sat, 10 Jan 2009 15:04:36 +0100, you wrote: POSIX realtime extensions have been developed to be high reliable. I think people are missing the details here. Yes, the built-in real-time clocks have excellent long-term accuracy. They run UTC-based correction algorithms using NTP, and are thus traceable to TAI. However, they offer no guarantees on interval measurements, and the correction algorithms can cause the measurement of a time interval of an hour or so duration to be off by +/- 1 sec, especially within the first few hours after a cold boot. If you care about leap seconds, you should certainly care about that magnitude of error. 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: [Haskell-cafe] Re: Computer time, independent of date
On Fri, 09 Jan 2009 11:01:18 -0200, you wrote: I'm writing a program that will read medical signs from many patients. It's important to have a precise measure of the time interval between some signs, and that can't depend on adjustments of time. (Supose my software is running midnight at the end of a year with leap seconds. I would get wrong time intervals.) If you really need that level of accuracy, there is nothing available on an off-the-shelf machine that will do the job. You need an independent timekeeping source of some kind, one that is not subject to the vagaries of reboots and other upsets. Perhaps the simplest and least expensive of these is a computer-compatible GPS time receiver. Since GPS works on GPS time (which has a constant offset from International Atomic Time), rather than UTC, you avoid having to deal with leap seconds and the like. I haven't tried doing it myself, but I know that most recent-vintage GPS units have a computer interface over which you can download the current GPS time from the device. There are many other kinds of GPS time receivers available, including ones that plug directly into a PC slot. Here's one that I found using a Google search on GPS time receiver: http://www.franklinclock.com/gps_receivers.htm The prices range anywhere from a couple of hundred dollars for consumer-grade equipment to many thousands for high-reliability devices. The only drawback to this approach that I can think of is if the hospital is in an urban area with lots of tall buildings, it might be difficult to obtain a GPS signal of high enough quality. Some of the purpose-built GPS time receivers have better antennas than a consumer-grade GPS device. 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: [Haskell-cafe] Re: Computer time, independent of date
On Fri, 09 Jan 2009 09:28:49 -0600, you wrote: I'm not sure that the original question implied *that* level of need. I can't imagine being worried about leap seconds yet at the same time being willing to accept the potential vagaries of any of the built-in clocks. 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: [Haskell-cafe] Interesting new user perspective
On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote: No reason not to expose newcomers to Haskell to the thing it does best. This is precisely why newcomers flounder. Yes, there certainly should be a Haskell for experienced Java/C++ programmers : All of the advanced things you can do more easily than you ever thought possible. But that's not the way to attract Joe Programmer, who has never had to write a parser. Joe Programmer needs to be shown how Haskell can solve _his_ problems. That might mean that you need to start with an extremely non-idiomatic Haskell program, one that has some of the look and feel of what programmers from other languages are comfortable with. And then transform that program, step-by-step, into something that takes advantage of Haskell's strengths. 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: [Haskell-cafe] An interesting curiosity
On Thu, 18 Sep 2008 19:59:51 +0100, you wrote: Of course, C++ is that crazy language where *assignment* is actually an *operator*. Sick, sick people... That's really not all that strange. An (infix) operator is just a function with funny syntax, and assignment is a function (the identity function, in fact) that also has a side effect. 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: [Haskell-cafe] Re: Windows details
On Thu, 11 Sep 2008 20:24:24 +0100, you wrote: XN Resource Editor makes adding an icon child's play. (Interestingly, this also becomes the default window icon without any further action, which is nice.) That's how Windows works: If an EXE contains at least one icon, then the first icon is used by default. However, either XN nor Resource Hack are able to embedd correct version info. The VERSIONINFO resource is actually rather complicated internally. In particular, the value that we think of as the version number (e.g., 1.2.3.456) is stored in two different formats (binary integer and string) in at least four different places, depending on how many languages are supported in the resource (file version as integer, product version as integer, and one each of file version as string and product version as string for each language). I don't recall offhand which one of these is what you see reported in the Properties dialog, but it's quite possible that you're setting the value of the wrong one, and that's why you're not seeing what you expect. 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: [Haskell-cafe] Windows details
On Tue, 09 Sep 2008 18:13:50 +0100, you wrote: Under MS Windows, if you right-click on an executable file and select properties, sometimes there's a Version tab that tells you the version number of the program. And sometimes there isn't. (Most especially, GHC-compiled programs do not have this tab.) Anybody know how to go about adding this? Also, anybody know how to give a GHC-compiled program a custom icon? Version information and application icons are both stored in data structures called resources; these are appended to the executable portion of the application, inside the EXE file. There are a number of predefined resource types, such as the aforementioned version info and icon, which follow specific data formats, and you can also define custom resources to store just about anything you want. (For example, in an application I wrote recently, I used custom resources to embed a set of TrueType fonts into the EXE.) There are a gazillion resource editors available for modifying the resources linked into an EXE; go to the Wikipedia page for a reasonable starting point: http://en.wikipedia.org/wiki/Resource_(Windows) 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: [Haskell-cafe] Linker problems linking FFI import call in Windo ws
On Wed, 16 Jul 2008 10:22:46 -0600, you wrote: I do have the import library. It came with the DLL. It links properly when I use CCALL on the haskell import statements. Doesnt link when I use STDCALL. It looks for function name with something like '@4 or @8' tacked on at the end. Not sure what that is all about. This is known as name mangling. See the Wikipedia article for more info: http://en.wikipedia.org/wiki/Name_mangling 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: [Haskell-cafe] approximating pi
On Tue, 29 Apr 2008 22:12:28 -0700 (PDT), you wrote: I was thinking of how to represent this process graphically on a computer screen. The way to do this is to keep in mind that the display is only a _representation_ of the algorithm in action, it is not involved in the actual algorithm. The screen resolution is immaterial to the operation of the algorithm, which is just dealing with numbers. For every iteration of the algorithm, there should be a notification sent to the code that controls the display, and that code needs to know how to update the screen accordingly. For example, it could be that the algorithm point (0.31416,0.27183) maps to pixel (45,127) on the screen. The update code might examine that pixel and increment its intensity, or change its color, or any of a number of other things that would indicate that the pixel had been hit. Note that multiple algorithm points will necessarily map to the same screen pixel. 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: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 18:24:38 +0100, you wrote: I was actually thinking more along the lines of a programming language where you can just write head :: (n 1) = List n x - x tail :: List n x - List (n-1) x (++) :: List n x - List m x - List (n+m) x and so forth. How, then, is that any different from a general-purpose programming language? You're just drawing the line in the sand in a different place. You end up with a programming system where compilation is a side effect of executing the real program. 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: [Haskell-cafe] Filesystem questions
On Fri, 12 Oct 2007 18:21:07 +0100, you wrote: I notice that getDirectoryContents appears to return its results in alphabetical order. Is this behaviour actually guaranteed? This is a Windows thing. All of the NT-based operating systems list files in alphabetical order by default. You see the same thing if you use the DIR command from a command-line prompt. 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: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 13:03:16 -0700, you wrote: It's different because the property that (for example) head requires a nonempty list is checked at compile time instead of run time. No, I understand that. Andrew was talking about using type programming to do the things that a sane person would use ordinary programming to do. And he wanted to know if there were any efforts to create a type system syntax that better supported that. But it seems to me that when you do that, the language of the type system begins to look like a general-purpose programming language. And that just shoves everything up to the next meta level. Pretty soon, you're going to need a meta-type system to meta-type-check your type language, and so on. I'm all for enhancing the expressibility of concepts _related to typing_ within the type system, but I don't think that was the original point of this discussion. After all, Andrew's original message mentioned stuff the type system was never designed to do. 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: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 13:25:28 -0700, you wrote: I'm not sure what sanity has to do with it. Presumably we all agree that it's a good idea for the compiler to know, at compile-time, that head is only applied to lists. Why not also have the compiler check that head is only applied to non-empty lists? Again, that sort of practical application of type systems is not (as far as I know) what this discussion is about. This discussion was spawned by talk of using the type system to do truly bizarre things, such as solve the Instant Insanity puzzle. A while back, Dan Piponi posed the question of using the type system to solve one of the liar/truthteller logic problems. And so on. 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: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 21:51:46 +0100 (GMT Daylight Time), you wrote: Which is nevertheless the kind of power you need in order to also be able to prove precise properties. We're not talking about POWER, we're talking about SYNTAX. That the Instant Insanity problem _was_ solved using Haskell's type system is obviously proof that the power to solve that kind of problem, at least, is already there. However, the solution is convoluted and less than clear at first glance. The question is whether or not there is a way to allow such solutions to be expressed in a more natural way. To which my rejoinder is, To what end? To extend the _syntax_ of the type system in a way that allows such natural expression turns it into yet another programming language. So what have we gained? 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: [Haskell-cafe] Geometry
On Mon, 27 Aug 2007 19:05:06 +0200, you wrote: Where do I go wrong (I)? b is defined to be _half_ of the chord (the semichord, I suppose). You're assuming it to be the entire chord. 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: [Haskell-cafe] Geometry
On Mon, 27 Aug 2007 11:04:58 +1000, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I went camping on the weekend and a friend of mine who is a builder asked me many questions on geometry as they apply to his every day work - - most of which I could answer. However, there was one that I couldn't and I am having trouble googling a solution (for lack of keywords?). I'm hoping a fellow Haskeller could help me out (in Haskell of course). The problem is finding the unknown x from the two knowns a and b in the given image below (excuse my Microsoft Paintbrush skills). I may have misunderstood his problem (we were drawing in dirt) and actually, it is the straight line between the two points on the circumference that are known and not the specified 'b', but I figure I could derive one solution from another if I have misunderstood him. Here is my image: http://tinyurl.com/2kgsjy Thanks for any tips or keywords with which to google! So a is the radius of the circle, and b is half the length of the chord. From basic trigonometry: b = a * sin @ where @ is half of the angle between the two radii as drawn in the picture. Then: x = a * (1 - cos @) Using the trigonometric identity sin^2 @ + cos^2 @ = 1 and rearranging, we get: x = a - sqrt(a^2 - b^2) I don't know offhand if there's a straightforward way to arrive at this result without using trigonometry. By the way, I found http://www.1728.com/circsect.htm by Googling height chord. 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: [Haskell-cafe] Geometry
On Sun, 26 Aug 2007 21:30:30 -0400, you wrote: I don't know offhand if there's a straightforward way to arrive at this result without using trigonometry. Duh. Of course there is 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: [Haskell-cafe] monte carlo trouble
On Thu, 16 Aug 2007 00:05:14 +0200, you wrote: I'm not sure what you mean by with replacement With replacement means that you select a value from the source, but you don't actually remove it. That way, it's still available to be selected again later. 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: [Haskell-cafe] Problem with question 3 about knights and knaves onw ikipedia
On Thu, 9 Aug 2007 23:06:04 +0200, you wrote: Is still don't get it completely... Could you give me an extra hint? I'm getting crazy here, especially because I was really good at this stuff 20 years ago! :) Here's the reasoning The first answer could not be no because from that I can infer that John is a knight and Bill is a knave, which would mean the logician knows the answer. This leaves me with 3 possibilities: a) Both John and Bill are knights b) John is a knave and Bill could be anything Correct. But you forgot to recursively apply the hint. ;) The problem states that after John answers the second question, the Logician knows the solution. How can this be? What answer did John give that allows the Logician to solve the problem? 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: [Haskell-cafe] Indentation woes
On Fri, 27 Jul 2007 00:33:17 -0400, you wrote: What makes this a law? If you notice a pattern where beginners trip against this rule because they don't indent the arms of conditionals properly inside do blocks, should strict adherence to this principle take precendence over the intuition of prospective users of the language? What exactly are you proposing as an alternative rule? If you're suggesting that _any_ line at the same level of indentation as the previous line be treated as a continuation of that line, then how would one go about indicating that a line is _not_ a continuation of the previous line? On the other hand, if you're suggesting that only certain things be recognized as being a continuation of the previous line (e.g., guard clauses), then it seems to me that you're replacing a brain-dead simple and straightforward rule with one that is inherently more complex and thus more likely to cause angst among beginners. Or are you proposing to get rid of layout altogether and rely on punctuation? I just can't think of a rule that would be easier to understand (and quicker to assimilate) than the current one. 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: [Haskell-cafe] Producing MinimumValue
On Thu, 19 Jul 2007 10:55:19 -0700 (PDT), you wrote: The question suggests to use some functions defined in the section, and one of them is iSort. Aha. Well, that one certainly lends itself better to this particular proplen than either map or filter. minimumValue :: [Int] - Int minimumValue ns = head (iSort ns) If I were going to use a sort, then yes, that's the way I would do it. Of course, sorting isn't the best way to solve the problem, as sorting will always be at least O(n * log n), whereas a more straightforward algorithm would be O(n). The other question is to test whether the values of allEqual on inputs 0 to n are all equal. Again, I defined the method but not sure if its concise? allEqual :: [Int] - Bool allEqual xs = length xs == length (filter isEqual xs) where isEqual n = (head xs) == n Simple recursion is probably the most conceptually straightforward approach here. One little difficulty with this problem (and with minimumValue, too) is that the problem isn't completely specified, because we don't know what answer we're supposed to give when the list is empty. Let's assume that allEqual is supposed to return True on an empty list. In that case, we can write it like this: allEqual :: [Int] - Bool allEqual (x1:x2:xs) = ??? allEqual _ = ??? where the two ???s are left as an exercise for the reader. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Producing MinimumValue
On Thu, 19 Jul 2007 19:26:39 +0100, you wrote: Actually, since Haskell is lazy and only the first element is required for minimumValue, the above algorithm should be O(n). You're right (as long as the sort algorithm itself is sufficiently lazy, of course). 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: [Haskell-cafe] Producing MinimumValue
On Thu, 19 Jul 2007 12:30:06 -0700 (PDT), you wrote: I have defined the first line it seems right to me Close, but not quite. Think of the result that line would give on [1,1,2]. 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: [Haskell-cafe] Re: Frustrating experience of a wannabe contributor
On Wed, 18 Jul 2007 13:00:20 -0700, you wrote: You can even post via gmane. Tip: for more powerful searching, use Thunderbird + gmane's NNTP interface. I think people are missing the original poster's point. He's not looking for alternative ways to get from A to B; he's pointing out that a typical approach that one might try to get from A to B is broken. As an aside, this seems to be a prevalent issue, particularly with non-commercial technically-oriented communities. When a newcomer says, Hey, I tried this [intuitively obvious] way to do something, and it didn't work, the welcoming response is NOT, Oh, don't do that; do this other [less intuitive] thing instead. The welcoming response is to fix the damn thing so that the intuitive approach works! 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: Re[4]: [Haskell-cafe] In-place modification
On Sun, 15 Jul 2007 14:15:03 +0200, you wrote: ...a simple 10 minute benchmark to compare the computational speed... We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. - Donald Knuth (paraphrasing Tony Hoare) Haskell is about improving software quality. A meaningful benchmark would be one that compares end-to-end software development lifecycles, including not only runtime performance, but also development costs, debugging and maintenance time, reliability, etc. 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: [Haskell-cafe] Haskell monads for newbies
On Sun, 15 Jul 2007 00:21:50 +0100, you wrote: [quoting a generic attitude] basically everything I write programs for is mainly about I/O... It's funny how people always seem to think that, but if you look at what they're really doing, I/O is usually the least of their worries. Programming GUIs is about the only reasonably common I/O-related task that has any sort of complexity. Most everything else is reading or writing streams of bytes; the hard part is what happens between the reading and the writing. 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: [Haskell-cafe] Type system madness
On Thu, 12 Jul 2007 21:24:24 +0100, you wrote: Given that (IIRC) the BOM is just a valid unicode non-breaking space, your scripts really ought to cope... Choking on the BOM is probably just a symptom of a deeper problem. My bet is that removing the BOM would simply delay the failure until the first non-ASCII character was encountered. 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: [Haskell-cafe] Very freaky
On Thu, 12 Jul 2007 20:36:47 +0100, you wrote: How come the set of all sets doesn't exist? In naive set theory, the existence of the set of all sets leads to a logical paradox. Specifically, the set of all sets would have to contain as a member the set of all sets that are not members of themselves. Look up Russell's Paradox in Wikipedia. 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: [Haskell-cafe] Type system madness
On Wed, 11 Jul 2007 20:10:00 +0100, you wrote: When I tell the editor to save UTF-8, it inserts some weird BOM character at the start of the file - and thus, any attempt at programatically processing that file instantly fails. :-( Which means that your processor doesn't properly understand UTF-8. A BOM character isn't required for UTF-8 (it really only makes sense with UTF-16), but a UTF-8-aware processor should skip right over it if it's there. 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: [Haskell-cafe] function unique
On Wed, 11 Jul 2007 22:49:27 +0200, you wrote: Well, there's a fundamental reason it wont work for Haskell: we dont actually define the names of the parameters to the function! Yes, but you know the type, which is what really counts. And, taking that a step further, once you've entered something for the first argument, a real-time compiler might be able to narrow down the set of allowed types for the second argument, and so on. Of course, if you're in the habit of creating functions with type signatures like Int - Int - Int - Int - Int - Int, and you can't remember which Int does what, then you have only yourself to blame 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: [Haskell-cafe] What puts False before True?
On Thu, 31 May 2007 13:51:20 -0700, you wrote: I think it's mathematical convention more than the C convention Haskell is agreeing with. I think so, too. In Boolean algebra (which predates computers, much less C), FALSE has traditionally been associated with 0, and TRUE with 1. And since 1 0, TRUE FALSE. 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: [Haskell-cafe] What puts False before True?
On Fri, 01 Jun 2007 03:33:41 +0100, you wrote: The question, however, still remains: why False = 0 and True 1? I appreciate that it's so in boolean algebra but why? Why not True = 0 and False = 1? There is a correspondence between a Boolean algebra and an algebraic ring. If we identify 0 with FALSE and 1 with TRUE, then that correspondence leads to a natural identification of addition with EXCLUSIVE OR, and multiplication with AND: 0 + 0 = 0FALSE XOR FALSE = FALSE 0 + 1 = 1FALSE XOR TRUE = TRUE 1 + 0 = 1TRUE XOR FALSE = TRUE 1 + 1 = 0TRUE XOR TRUE = FALSE (carry is ignored) 0 * 0 = 0FALSE AND FALSE = FALSE 0 * 1 = 0FALSE AND TRUE = FALSE 1 * 0 = 0TRUE AND FALSE = FALSE 1 * 1 = 1TRUE AND TRUE = TRUE A Boolean value denotees veracity whereas an ordered value concerns magnitude (priority), indeed, order!! It is frequently desirable to enumerate things, even when those things don't have a well-defined order. In such cases, we have to impose an order, perhaps arbitrarily. Within a given programming context, it doesn't matter what we choose for our enumeration order, but it's generally best to go along with whatever de facto standard there is, if for no other reason than to avoid going insane. 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: [Haskell-cafe] Usage of . and $
On Wed, 7 Mar 2007 20:44:42 +1100, you wrote: It always irks me that you don't actually save any horizontal space using $. That is, (e) x has the same number of characters (incl spaces) as e $ x Parentheses require you to maintain a mental general-purpose push-down stack as you read the code. $, on the other hand, while it also requires you to maintain a sort of stack, it's a monotonic stack: you may need to push an arbitrary number of items, but you don't pop anything until you reach the end of the code. So the mental model required to read code containing $'s is simpler than that required for parentheses. 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: [Haskell-cafe] Re: Trouble with record syntax and classes
On Mon, 26 Feb 2007 23:41:14 -0600 (CST), you wrote: Here's my second attempt at the code: ... You've left out a bunch of constructors, and there are various other errors here and there. I think this will do what you want: data ISine = Sine Integer Integer Integer [Char] | MetaSine Integer Integer Integer [ISine] letter (Sine _ _ _ l) = l sub_sines (MetaSine _ _ _ xs) = xs period (Sine p _ _ _) = p period (MetaSine p _ _ _) = p offset (Sine _ o _ _) = o offset (MetaSine _ o _ _) = o threshold (Sine _ _ t _) = t threshold (MetaSine _ _ t _) = t on :: Integer - ISine - Bool on time iSine = (mod (time-(offset iSine)) (period iSine)) (threshold iSine) act :: Integer - ISine - [[Char]] act time (MetaSine p o t s) = if on time (MetaSine p o t s) then foldr1 (++) (map (act time) (sub_sines (MetaSine p o t s))) else [] act time (Sine p o t l) = if on time (Sine p o t l) then [letter (Sine p o t l)] else [] But note that you have to write the equations for period, offset and threshold twice. If you want to avoid that, you can move the Sine/MetaSine discrimination into the tail of the data structure, something like this: data ISineTail = SineTail [Char] | MetaTail [ISine] data ISine = ISine Integer Integer Integer ISineTail letter (ISine _ _ _ (SineTail l)) = l sub_sines (ISine _ _ _ (MetaTail xs)) = xs period (ISine p _ _ _) = p offset (ISine _ o _ _) = o threshold (ISine _ _ t _) = t on :: Integer - ISine - Bool on time iSine = (mod (time-(offset iSine)) (period iSine)) (threshold iSine) act :: Integer - ISine - [[Char]] act time (ISine p o t (MetaTail s)) = if on time (ISine p o t (MetaTail s)) then foldr1 (++) (map (act time) (sub_sines (ISine p o t (MetaTail s else [] act time (ISine p o t (SineTail l)) = if on time (ISine p o t (SineTail l)) then [letter (ISine p o t (SineTail l))] else [] 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: [Haskell-cafe] A real Haskell Cookbook
On Fri, 23 Feb 2007 18:09:15 +, you wrote: Well, actually, I never cited the non-breaking space character as a problem. Well, actually, you did: Symbols such as the 160 used liberally in the Haskell wikibook are totally invisible to screen readers. #160; = NO BREAK SPACE Which is why I asked specifically about that. 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: [Haskell-cafe] Re: Channel9 Interview: Software Composability andth eFu ture of Languages
On Fri, 26 Jan 2007 22:00:11 +0100, you wrote: I agree, but I think it should be pointed out that primarily it is not Haskell which is hard, it is Programming which is. Haskell only reflects this better than the mainstream imperative languages. That's very true. Writing good software is hard, regardless of the choice of language. Perhaps what sets Haskell apart is that, unlike most languages, it also makes writing _bad_ software hard. ;) 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: [Haskell-cafe] Channel9 Interview: Software Composability and t heFu ture of Languages
On Fri, 26 Jan 2007 22:01:09 -0600, you wrote: You have a PhD in computer science from Princeton, so your measure of what's hard and what isn't in this regard is nearly worthless. I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard. I never said that people are lazy, only that they're not interested--they'd rather devote their time to other pursuits. That's not meant to be a criticism at all, it's an observation of The Way Things Work. And I certainly wasn't referring to the people who actually _complain_ about Haskell being too hard. After all, they're the ones who are in fact trying to learn, not the ones who simply don't care to. My comment was directed specifically at the notion that we can make Haskell more popular by somehow making it easier. _That's_ the argument that I believe is flawed, because the things that give value to Haskell are precisely the things that require effort to understand. To paraphrase Albert Einstein: make it as simple as possible, but no simpler. This is not just a progrmaming issue; I encounter the same phenomenon pretty much everywhere: I'm currently trying to build a house, and I've found that most of the people who are in the business of building houses don't want to try anything new, even if it might be a better way that has the potential to save them money and/or result in a better end product. They want to continue building houses the way they've always built houses. The fraction of house builders who do want to learn new and possibly better ways of building is, and always will be, a small one. Again, it's not a criticism, just an observation, something that one needs to be aware of when embarking on a house-building project. I'm reminded of when Java first appeared on the scene a little over ten years ago. There was a huge upswell in interest; all of the web developers out there were going to add Java applets to their web sites. Then the awful truth came out: Oops, you had to learn how to _program_ to create applets. Never mind; not worth it. And applets quickly and quietly faded away. By the way, to set the record straight, while I do have a Ph.D. from Princeton, it's in semiconductor physics, not computer science. And lest anyone were to misunderstand when I say Haskell is hard, while I do mean that it's hard for _me_, I think the evidence is pretty strong that I'm far from alone in my assessment. Whether or not it's hard for any particular person is up to that individual to judge, of course. I stick with Haskell because (a) I think it just might be worth it, and (b) I can't help myself--I have an insatiable craving for new knowledge. 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: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On Fri, 26 Jan 2007 17:13:43 - (GMT), you wrote: world. It also highlights some of the misconceptions that still exist and need to be challenged, e.g. the idea that Haskell is too hard or is impractical for real work. Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't be here, obviously. Haskell is hard in the sense that in order to take advantage of its ability to better solve your problems, you have to THINK about your problems a lot more. Most people don't want to do that; they want the quick fix served up on a platter. And even the intermediate camp, the ones who are willing to invest some effort to learn a better way, are only willing to go so far. My analogy for this is the Sams PHOTOFACT series (If you're not old enough to already know what these are, visit http://www.samswebsite.com/photofacts.html). With an appropriate Sams PHOTOFACT in hand, and some very basic skills with a voltmeter and maybe an oscilloscope, you can diagnose and repair your TV with virtually no understanding of electronics at all. The audience for programming languages like Haskell is always going to be small, because it appeals to those who want to understand how the TV works, perhaps to the extent of being able to modify an existing TV or even design one from scratch. And those kind of people are much fewer and farther between than those who simply want to localize the problem enough to be able to unplug the malfunctioning part and plug in a new one. It makes sense to publicize Haskell; you can't take advantage of something you've never heard of. But I think evangelical effort is largely wasted. The people who are going to gravitate towards Haskell are the ones who are already searching for something better (they just aren't sure what it is). The rest aren't really interested, and if at some future point they become interested, they'll find the way on their own. 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: [Haskell-cafe] Re: Seeking advice on a style question
been transformed to printable things but before there are distributed across pages. So the references cannot refer to page numbers, yet must be processed after transforming questions to rectangles? It's not until you get to the rectangles level that you can see the text and tokens that need to be replaced. Thanks for all of the discussion. I think I have a lot to ponder 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: [Haskell-cafe] Seeking advice on a style question
On Fri, 29 Dec 2006 18:39:04 +0100, you wrote: Why not generate Haskell code from such a graph? Well, that would indeed be a workable solution. But I don't have quite the resources to design Yet Another Visual Programming Language. And a textual representation of the graph would have exactly the same kinds of problems that the textual Haskell has 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: [Haskell-cafe] Re: Seeking advice on a style question
On Fri, 29 Dec 2006 09:01:37 -0800, you wrote: Steve Schafer wrote: I can easily rewrite it in point-free style: process1 = baz . bar . foo Not unless you have a much fancier version of function composition, like... http://okmij.org/ftp/Haskell/types.html#polyvar-comp Sorry; I obviously got a little carried away there: process1 x = let u = foo x; v = bar u; w = baz v in w process1 = baz . bar . foo 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: Re[2]: [Haskell-cafe] Re: Seeking advice on a style question
On Fri, 29 Dec 2006 14:23:20 +0300, you wrote: it force you to give names to intermediate results which is considered as good programing style - program becomes more documented. But that would imply that function composition and in-line function definition are also Bad Style. 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: [Haskell-cafe] Seeking advice on a style question
On Tue, 26 Dec 2006 20:21:45 -0800, you wrote: How would this example look if you named only multiply-used expressions? I'd like to see it in a more conventional pointful style with nested expressions. I'm still wondering whether the awkwardness results from your writing style or is more inherent. Showing the real variable names may also help also. This is what it looks like for real: process :: Item - MediaKind - MediaSize - Language - SFO process item mediaKind mediaSize language = let pagemaster = loadPagemaster item mediaKind mediaSize; questions = stripUndisplayedQuestions mediaKind $ appendEndQuestions item pagemaster $ coalesceParentedQuestions $ validateQuestionContent $ loadQuestions item; (numberedQuestions,questionCategories) = numberQuestions pagemaster questions; numberedQuestions' = coalesceNAQuestions numberedQuestions; (bands,sequenceLayouts) = buildLayout mediaKind language numberedQuestions'; bands' = resolveCrossReferences bands; groupedBands = groupBands bands'; pages = paginate item mediaKind mediaSize pagemaster groupedBands; pages' = combineRows pages; sfo = pages' sequenceLayouts; in sfo These are the function signatures: loadPagemaster :: Item - MediaKind - MediaSize - Pagemaster loadQuestions :: Item - [Question] validateQuestionContent :: [Question] - [Question] coalesceParentedQuestions :: [Question] - [Question] appendEndQuestions :: Item - Pagemaster - [Question] - [Question] stripUndisplayedQuestions :: MediaKind - [Question] - [Question] numberQuestions :: Pagemaster - [Question] - ([NumberedQuestion],[QuestionCategory]) coalesceNAQuestions :: [NumberedQuestion] - [NumberedQuestion] buildLayout :: MediaKind - Language - [NumberedQuestion] - ([Band],[SequenceLayout]) resolveCrossReferences :: [Band] - [Band] groupBands :: [Band] - [[Band]] paginate :: Item - MediaKind - MediaSize - Pagemaster - [[Band]] - [Page] combineRows :: [Page] - [Page] createSFO :: [Page] - [SequenceLayout] - SFO MediaKind, MediaSize and Language are simple enumerations; everything else is a complex structure. 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: [Haskell-cafe] Re: Seeking advice on a style question
On Wed, 27 Dec 2006 17:06:24 +0100, you wrote: But in general, it's futile trying to simplify things without knowing their meaning: names are *important*. I assume that your proper goal is not to structure pipeline processes in full generality, but to simplify the current one at hand. No, I'm looking for full generality. ;) I have dozens of these kinds of quasi-pipelines, all similar in overall appearance, but different in detail. Even if you wanted to simplify the general structure, I think you'd have to make the types of the different yk explicit. Otherwise, the problem is underspecified and/or one has to assume that they're all different (modulo some equalities implied by type correctness). Most of them are, in fact, different types (see my reply to Conal). Here's the essence of the problem. If I have this: process1 x y = let u = foo x y; v = bar u; w = baz v in w I can easily rewrite it in point-free style: process1 = baz . bar . foo But if I have this: process2 x y = let u = foo x y; v = bar u; w = baz v u in w then I can't avoid naming and using an intermediate variable. And that annoys me. The u in process2 is of no more value to me (pardon the pun) as the one in process1, but I am forced to use it simply because the data flow is no longer strictly linear. The reason I brought up monads as a possible means of managing this problem is that the State, Reader and Writer monads already handle certain specific shapes of nonlinear data flow, which suggested to me that maybe there was a monadic approach to managing nonlinear data flow in a more general way. Of course, if there is a non-monadic, purely functional way to do it, that would be even better, but I've never seen such a thing (short of doing lots of tupling and un-tupling). 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: [Haskell-cafe] Seeking advice on a style question
On Mon, 25 Dec 2006 09:52:47 -0800, you wrote: To my eye, your example code below looks less like an imperative program than like an intermediate form that a compiler would generate from an expression built up from nested function applications and a few lets. That's very true, but the same could be said for many other examples of the use of the State monad (and Reader and Writer as well). They frequently don't do anything that couldn't be done purely functionally. 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: [Haskell-cafe] Seeking advice on a style question
On Tue, 26 Dec 2006 10:28:22 -0800, you wrote: So I'm still doubtful that a monadic approach is going to simplify your code. Would you give a real example of some code you'd like to make more manageable? If you have real examples of State, Reader, and/or Writer monads that strike you as similar to your example, please share that also. I didn't mean to imply that a monadic approach would simplify the code, only that it was _conceivable_ to me that such a thing might be true. The code I showed _is_ a real example; I just changed the names of everything to focus on the structure. And the reason for focusing on the structure is that I'm looking for a _general_ principle to apply to make the code more manageable; the process that I showed is just one of many similarly-structured processes that are involved in the actual application. I think the essence of my question might have gotten lost, so I'll try a slightly different approach: I have a process that consists of a series of steps. If each step consumed _only_ the results of the previous step, I could of course describe the process like this: process = f14 . f13 . f12 But that isn't quite the case. Each step consumes not only the results of the previous step, but also some combination of the results of prior steps and/or the original inputs. One way to look at this is a directed graph, a sort of branching pipeline; see http://www.dendroica.com/Scratch/process.png. Now, the advantages of this kind of visual representation of the process are that it makes it perfectly clear what each step consumes and how the flow of the process occurs. Another big advantage (to me, anyway) is that the graphical representation is entirely point-free; the picture isn't cluttered with intermediate values whose only purpose is to hold onto things I need later, but not right now. So here's the (restated) question: Is there some way to represent the process in good ol' text form that preserves the elegance and conciseness of the graphical representation? 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: [Haskell-cafe] Seeking advice on a style question
On Tue, 26 Dec 2006 18:29:43 +, you wrote: -- process :: a - b - c - d - e process x1 x2 x3 x4 = let y01 = f01 x1 x2 x3 in ($ x1) (f02 f03 f04 f05 x1 y01 f06 x2 f07 y01 first f08 uncurry (f09 x2 x4) first (f10 f11 f12 x1 x2 x3 y01 f13) uncurry f14) This is like what I was looking for, although it does still require at least one temporary variable. I'll have to think about it a bit to see how applicable it is in general. Thanks. The tuples do make things a bit messy; they could easily be removed at the cost of introducing a few more steps: (y07,y08) = f07 y01 y06; would become y' = f07 y01 y06; y07 = f07a y'; y08 = f07b y'; where f07a = fst and f07b = snd. 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
[Haskell-cafe] Seeking advice on a style question
In my text/graphics formatting work, I find myself doing a lot of pipeline processing, where a data structure will undergo a number of step-by-step transformations from input to output. For example, I have a function that looks like this (the names have been changed to protect the innocent--and to focus on the structure): process :: a - b - c - d - e process x1 x2 x3 x4 = let y01 = f01 x1 x2 x3; y02 = f02 x1; y03 = f03 y02; y04 = f04 y03; y05 = f05 x1 y01 y04; y06 = f06 x2 y05; (y07,y08) = f07 y01 y06; y09 = f08 y07; (y10,y11) = f09 x2 x4 y09 y08; y12 = f10 y10; y13 = f11 y12; y14 = f12 x1 x2 x3 y01 y13; y15 = f13 y14; y16 = f14 y15 y11 in y16 As you can see, the process is somewhat imperative in overall appearance, with each intermediate function f01..f14 accepting some combination of the original input values and/or intermediate values and returning a new value (or, in some cases, a tuple of values). Obviously, not all of the steps need to be broken out this way. We can, for example, skip the second and third steps and directly write: y04 = f04 $ f03 $ f02 x1; Laying it out this way has a couple of advantages. It makes the steps in the process transparently clear, and if I discover at some point that I need to make a change (e.g., a new requirement causes f13 to need access to x2), it's perfectly obvious where to make the modifications. Nevertheless, it also looks like something that would be amenable to processing with a State monad, except for one thing: The shape of the state isn't constant throughout the process. At any given step, new information may be added to the state, and old information may be thrown away, if there is no further need for it. In principle, it could be managed with a bunch of nested StateT monads, but my attempts to do so seem to get so caught up in the bookkeeping that I lose the advantages mentioned above. Alternatively, I can wrap all of the state up into a single universal structure that holds everything I will ever need at every step, but doing so seems to me to fly in the face of strong typing; at the early stages of processing, the structure will have holes in it that don't contain useful values and shouldn't be accessed. So here's the question: Is there a reasonable way to express this kind of process (where I suppose that reasonable means in keeping with Haskell-nature) that preserves the advantages mentioned above, but avoids having to explicitly pass all of the various bits of state around? The (unattainable?) ideal would be something that looks like this: process = f14 . f13 . ... . f01 or process = f01 = f02 = ... = f14 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: [Haskell-cafe] Seeking advice on a style question
On Sun, 24 Dec 2006 10:39:19 -0500, you wrote: You might want to look at the following threads discussing how to make variable-state monad like structures. http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/17706 http://www.haskell.org/pipermail/haskell/2006-December/018917.html Thanks. I should have realized that Oleg would have had something to say about it. ;) 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 : [Haskell-cafe] A suggestion for the next high profileHaske ll project
On Tue, 19 Dec 2006 21:34:06 +0100, you wrote: Lazy semantics - equational reasoning ? I thought that : lack of mutable state - equational reasoning. For instance, I think to data flow variable in Oz (whcih I really don't know much / never used) : if a (Oz managed) thread attemps to read the value of an unbound (data flow) variable, it waits until another thread binds it. But the equational reasoning (referential transparency) remains (and the evaluation is eager by default). How about this: Lazy semantics encourages one to write code in a way that eases equational reasoning? The classic example of this is a problem that has a finite solution, but whose solution is most clearly expressed in terms of operations on infinite structures. 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: [Haskell-cafe] Picking out elements of a heterogenous list
To: Creighton Hogg [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Picking out elements of a heterogenous list From: Steve Schafer [EMAIL PROTECTED] Date: Tue, 05 Dec 2006 12:33:16 -0500 On Tue, 5 Dec 2006 11:08:07 -0600, you wrote: Hi Haskell-ers, So I think I understand the idea of creating a heterogenous list using typeclasses and existentials, but I don't see how to filter the list to retrieve elements of the list that are of only one type. More concretely, taking the example herehttp://haskell.org/haskellwiki/Existential_typehow could we take a list of shapes [Shape] and pull out all objects that are Squares? I don't see an obvious way this makes sense. Is there a way of doing heterogenous lists that would make this possible? Use filter, passing it a predicate that returns True for Squares and False otherwise: isASquare :: Shape - Bool isASquare (Square _) = True isASquare _ = False filter isASquare myShapes 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: [Haskell-cafe] Collection of objects?
On Fri, 17 Nov 2006 18:36:30 +0100, you wrote:
But I need something which is heterogeneous and non-fixed length. I'm
used do Java, and this switch to functional languages is very strange to
me. So, to be clear, I need something like LinkedListObject in java.
In an attempt to leverage your existing Java knowledge...
In Java, while the things in your list are heterogeneous at some
level, they are homogeneous at another: They are all instances of Object
(or a subclass thereof). You can't, for example, put an int in your
list. And in fact, that's a primary reason for the existence of the
Integer class--it makes your int look like an Object, so that you can
treat it like one. (And similarly for Character, Float, Double, etc.)
So you do the analogous thing in Haskell: First, you ask yourself, What
kinds of things do I want to put in my list? Once you have the answer
to that, you ask, Are these things homogeneous at some level? If they
are, then you make your list a list of those homogenous things
(actually, the compiler generally does it for you). If they aren't, then
you wrap them up in a homogeneous wrapper in exactly the same way as you
wrap your int in an Integer, your double in a Double, etc., in Java.
Some of the other replies have shown you how to declare this; it's
trivially simple:
data MyHomogeneousWrapper = Integer Int
| Character Char
| Float Float
deriving Show
Finally, constructing new instances of this homogenous wrapper in
Haskesll is just like it is in Java:
myList = [(Integer 42), (Character 'a'), (Float 3.14159)]
vs.
myList = new LinkedList();
myList.add(new Integer(42));
myList.add(new Character('a'));
myList.add(new Float(3.14159));
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
[Haskell-cafe] Decorating a list of strings
I have a list of text strings: [Alice, Bob, Cindy, Bob, Bob, Dave, Cindy] As you can see, some of the strings occur only once; others appear two or more times. I would like to end up with a new list, according to the following rules: 1) If a string occurs only once in the original list, then that string appears unchanged in the new list. 2) If a string occurs more than once in the original list, then each occurrences of that string is decorated with a numerical suffix indicating its relative position among its peers. In the case of the above list, the result of applying these rules would be: [Alice, Bob:1, Cindy:1, Bob:2, Bob:3, Dave, Cindy:2] So, how do we do this? The straightforward approach is to traverse the list twice, once to build a table of repeat counts for the different strings, and a second time to generate the new list, based on the old list plus the table of repeat counts. Of course, it's possible to streamline this into a single traversal by building up a list of thunks at the same time as the table of repeat counts is generated, and then to resolve those thunks by applying them in one fell swoop to the table. But while this does _conceptually_ streamline the problem, it doesn't offer any practical improvement; it takes at least as much processing effort to resolve the thunks as it would to make a second pass through the list. Can we do better? I can't think of a way to do better, and my gut feeling is that there isn't one (in general, it's impossible to know whether the first element of the new list will be Alice or Alice:1 until the entire original list has been traversed), but I thought I'd put the question out to the community to see if anyone had any brilliant insights. 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: [Haskell-cafe] Decorating a list of strings
On Thu, 02 Nov 2006 12:20:55 -0800, you wrote: It seems you only need a table of counts of the number of times the string has occurred previously, which you can have available on the first pass. e.g, import Data.List import Data.Map as Map mark strings = snd $ mapAccumL (\counts str - (Map.insertWith (+) str 1 counts, str++maybe (\n - ':':show n) (Map.lookup str counts))) Map.empty strings this works on your example, and also handles [Alice, Bob, Cindy, Bob, Bob, Dave, Cindy] ++ repeat Tim giving [Alice,Bob,Cindy,Bob:1,Bob:2,Dave,Cindy:1,Tim,Tim:1,Tim:2,...] No, you missed a part of the second rule: If there are multiple occurrences of a string, the _first_ occurrence has to be tagged, too, not just the second through n'th occurrences. The result of the above would have to be: [Alice,Bob:1,Cindy:1,Bob:2,Bob:3,Dave,Cindy:2,Tim:1,Tim:2,Tim:3,...] 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: [Haskell-cafe] Justification for Ord inheriting from Eq?
On Thu, 6 Apr 2006 21:31:24 +0100, you wrote: I've been wondering for a long time if there is a reason why Ord should inherit from Eq and not vice versa, or whether in fact there is any justification for making either Ord or Eq inherit from the other one. Support for the concept of equality/inequality does NOT imply the existence of an absolute ordering. For example, identical twins can be considered to be equal to each other, and not equal to any other person, while persons who are not half of an identical twin pair are not equal to all other persons. (For simplicity, I've ignored the existence of identical triplets, quadruplets, etc.) For an example that's perhaps a bit closer to home, consider modulo arithmetic (or any other cyclic group). Another example is the definition of NaN (not-a-number) comparisons in the IEEE floating-point arithmetic standard: If you have two operands, where at least one of them is a NaN, then ==, , , = and = all return False, while /= returns True. On the other hand, while I suppose it's conceivable to have a situation where there is an absolute ordering but no equality/inequality, it puts you in the awkward position of not being able to compare something to itself. 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: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewreque st)
On Wed, 1 Mar 2006 12:35:44 -, Brian Hulley [EMAIL PROTECTED] wrote: The only thing then is what happens when you type backspace or left arrow to get back out to a previous indentation? The Borland IDEs have long supported various smart indentation features, which can each be individually turned on or off (see the third one for the answer to your specific question): * Auto indent mode - Positions the cursor under the first nonblank character of the preceding nonblank line when you press ENTER in the Code Editor. * Smart tab - Tabs to the first non-whitespace character in the preceding line. If Use tab character is enabled, this option is off. * Backspace unindents - Aligns the insertion point to the previous indentation level (outdents it) when you press BACKSPACE, if the cursor is on the first nonblank character of a line. There are a number of other tab-related options as well. 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
[Haskell-cafe] List-to-outline
I have some lists of integers; e.g.,
[0,1,2,2,3,3,3,2,1,2,3,3,1]
Think of each integer value as representing the indentation level in a
hierarchical outline: e.g.,
0
1
2
2
3
3
3
2
1
2
3
3
1
I want to convert the list into a structure that better represents the
hierarchy. So, I first define a datatype to represent each node of the
new structure:
data Node = Nd Int [Node]
That is, a node consists of an Int representing the value of the node,
followed by a list of its immediate child nodes. (In principle, I can
deduce the value of a node simply from the nesting level, of course, but
in the real problem I'm trying to solve, each node contains other
information that I need to preserve as well.)
Next, I define some functions to perform the transformation
isChild :: Int - Node - Bool
isChild i (Nd j _) = (j i)
isChild _ _ = False
prepend :: Int - [Node] - [Node]
prepend i [] = [Nd i []]
prepend i ns = (Nd i f):s
where (f,s) = span (isChild i) ns
unflatten :: [Int] - [Node]
unflatten ns = foldr prepend [] ns
Finally, I add some code to display the result in an aesthetically
pleasing way:
showsNodeTail :: [Node] - String - String
showsNodeTail [] = showChar '}'
showsNodeTail (n:ns) = showChar ' '.shows n.showsNodeTail ns
showsNodeList :: [Node] - String - String
showsNodeList [] = showString
showsNodeList (n:ns) = showChar '{'.shows n.showsNodeTail ns
showsNode :: Node - String - String
showsNode (Nd i ns) = shows i.showsNodeList ns
instance Show Node where
showsPrec n = showsNode
This all works just fine, and when I enter
unflatten [0,1,2,2,3,3,3,2,1,2,3,3,1]
I get
[0{1{2 2{3 3 3} 2} 1{2{3 3}} 1}]
as expected.
The reason I'm posting this here is that I have a gnawing suspicion that
the unflatten/prepend/isChild functions, and possibly the Node data type
as well, are not the most elegant way to go about solving the problem,
and that I'm missing another more obvious way to do it.
Any suggestions?
Thanks,
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: [Haskell-cafe] Programming style and XML processing in Haskell
On Thu, 13 May 2004 17:45:25 +0100 (BST), MR K P SCHUPKE [EMAIL PROTECTED] wrote: I am not sure what application you intend this for, but I find most XML parsers completely useless. With my application programmers hat on, I do not want to validate against a DTD, I want to extract as much information as possible from bad XML... what I would like is a correcting parser - one which outputs XML in compliance, but will accept any old rubbish and make a best guess attempt to fix it up (based on a set of configurable heuristic rules)... Bear in mind that such a parser would not be in conformance with the XML specification. The XML Working Group applied the lessons of HTML and concluded that lax parsing rules lead to far more trouble than they're worth, and so the XML specification explicitly lists the kinds of well-formedness errors that might occur in an XML document and that are _required_ to be flagged by a conforming XML processor as fatal errors. (And also note that in XML-speak, valid and well-formed are not the same thing--an XML parser can be conforming without doing validation, and an XML document can be well-formed without being valid.) Obviously, you can do whatever you want in your own code, but I don't think you should hold your breath waiting for someone else to come up with that kind of pseudo-XML parser, since by definition it would be a special-purpose tool. Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a list
On Wed, 21 Apr 2004 14:57:57 +0100, you wrote: How about implementing a directly recursive solution? Simply accumulate the sum so far, together with the list elements you have already peeled off. Once the sum plus the next element would exceed the threshold, emit the accumulated elements, and reset the sum to zero. splitlist threshold xs = split 0 [] xs where split n acc [] = reverse acc: [] split n acc (x:xs) | x = threshold = error (show x++ exceeds threshold ) | n+x threshold = reverse acc : split 0 [] (x:xs) | otherwise = split (n+x) (x:acc) xs Thanks. Apart from a small off-by-one problem (the x = threshold test needs to be x threshold instead), it works fine. I had actually started along those lines, but got bogged down in the details of passing the accumulator around, and ended up painting myself into a corner, so I abandoned that approach (prematurely, as it turns out). And thanks to everyone else who replied--I don't want to clutter the list with a lot of individual replies. As you can probably tell, I've only recently begun playing with Haskell, and the process of reconfiguring my neurons into recursive loops has not yet been completed. -Steve ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
