Re: ghc-6.6 mac intel binary bundle
On Oct 13, 2006, at 6:23 PM, Adam Megacz wrote: I'm grateful to whoever prepared the binary bundle for ghc-6.6 on MacOS/Intel, but the instructions for installing it are missing/wrong. In particular, make install doesn't do much, and the only binary in the bundle called ghc appears to need additional configuration options (-B), so it seems to need some sort of installation procedure. The INSTALL file is not useful. make install won't do much by itself because the target directories (/usr/local/*) are writable only by root; you need to use sudo. The following worked fine for me: ./configure make sudo make install I also edited the post-install-script to leave the system libreadline library (really libedit) alone, and only install GNU readline in /usr/ local/*. GHC still works fine with that configuration, and the original Mac OS X libreadline is left around. That way you can still build software that runs on a stock Mac OS X installation (instead of unintentionally introducing a dependency on GNU readline). You can do the same thing by commenting out the three lines in post- install-script that touch /usr/lib/libreadline and /usr/include/ readline/*. As far as I can tell they're not needed. However, if you're not concerned about this issue (e.g. you always require GNU readline for any software you build) you can leave the post-install- script as is, and GHC will work fine. Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 mac intel binary bundle
Deborah Goldsmith [EMAIL PROTECTED] writes: ./configure make sudo make install Ok, sorry. When I noticed that there was no source code in the bundle, I didn't see the need for running configure/make. I have to admit, I still find it a bit strange... perhaps standard unix-style binary package ought to be precompiled source tree with the source code removed. Thanks for the help! - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 candidate Win32 installer
On 14.10 10:20, Ross Paterson wrote: On Fri, Oct 13, 2006 at 04:05:49PM -0700, Sigbjorn Finne wrote: Afraid I have to disappoint you (again :-( ) wrt OpenAL/ALUT. A bit too late, but _if_ there's a wider agreement that including a package such as this would be generally useful, I'd be happy to do something about it the next time around. cabal-get + hackage.haskell.org really ought to be the distribution channel for not-quite(-yet?)-mainstream packages though. That would be fine for pure Haskell packages (when hackage is ready), but Cabal can't handle packages that require non-trivial configuration (like OpenAL and ALUT) on Windows without MSYS. If people are interested I have NSIS scripts that make it trivial to create windows binary installers for many Haskell packages (for GHC). I would be interested in creating a repository of windows binary packages but I lack the space for hosting such a thing. - Einar Karttunen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.6 for Windows crashes my program on exit
Hi, Has anyone else come across this crash with ghc 6.6 on Windows? The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0). First-chance exception at 0x7c90eb74 in main.exe: 0xC008: An invalid HANDLE was specified. Unhandled exception at 0x7c90eb74 in main.exe: 0xC008: An invalid HANDLE was specified. The program has this form: main = do display_graphics_window_and_run_message_loop -- window has now been closed putStrLn Finished\n getChar and has been working perfectly with ghc 6.4.2. The only changes I had to make to compile it with ghc 6.6 were minor tweaks to deal with the changes to the ByteString api. When I run the ghc 6.6 compiled version, the window is displayed and works as usual, then when I dismiss the window, Finished is written to the console. It is only when I press return in the console that the program crashes on exit with that error message. I'm running the program from within MS Visual Studio (the graphics window is written as a C DLL that's called from Haskell). If I just run the program directly from the desktop the program exits silently . If I run the program from a command shell nothing unusual happens either: no error is printed out but the crash-on-exit is presumably still happening. From just looking at the error message, it looks to me like it might be that the rts exit code has somehow held onto the handle of the window's thread after this thread no longer exists, but of course this is only a wild guess. Alternatively, which file(s) in the ghc source distro would be the place to start looking to see what happens between the time the thread for the window has exited and the thread for main.exe exits? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 candidate Win32 installer
Hi Einar, If people are interested I have NSIS scripts that make it trivial to create windows binary installers for many Haskell packages (for GHC). I am working on such a project myself for Haskell programs (haddock/alex etc) but not libraries. Can you give more details about your proposal, so I don't end up doing something already solved? My plan is to reuse the WinHugs installer for Yhc, WinHugs, Hat and Cabal generated programs (Haddock, Alex, Happy). I would be interested in creating a repository of windows binary packages but I lack the space for hosting such a thing. This is exactly the thing that haskell.org should be used for! Perhaps you might want to look at hackage as well, and see if you can integrate with that. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Visual Haskell 2005?
Are there any plans to make a version of Visual Haskell that works with Visual Studio 2005? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs patch: initial, very incomplete tags generator (and 16 more)
Hi, since you both only mention hasktags as an alternative, I wonder how ghctags relates to :ctags/:etags in ghci? http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html Doco suggests that this code is just calling hasktags. How would I know for sure? Norman: adding a standalone-tool will be nice, but I hope that ghctags and :[ce]tags are using the same codebase, providing the same functionality with different user-level frontends? Once I can get stuff working, I'll see about coupling it into ghci. But at present performance troubles make it unusable. Norman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: darcs patch: initial, very incomplete tags generator (and 16 more)
Hello nr, Saturday, October 14, 2006, 12:30:54 AM, you wrote: The ultimate goal is to replace hasktags with a tags generator based on GHC-as-a-library. is this working at this time? how i can download/use it? It works, but there are two serious problems: 1. Incorrect emacs tags file when source-line directives are used (ctags might be OK). 2. Performance problems make it unusable on large programs. The performance problems appear to be lurking behind the GHC API, and I'm not competent to correct them, so I've asked SS for help. Once that's out of the way and I can do some real testing, I'll correct the other problems. If you're currently building a compiler, it's in the utils/ghctags directory. If not, I can put source code on the web, though I'd sort of prefer to have the bugs fixed. hasktags is over-simplified utility, having a really parsing alternative to it will be great Indeed. Norman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Call for Contributions - HCA Report (November 2006 edition)
Dear Haskellers,
it is nearly time for the eleventh edition of the
Haskell Communities Activities Report
http://www.haskell.org/communities/
Submission deadline: 6 November 2006
(please send your contributions to hcar at haskell.org, in
plain ASCII or LaTeX format)
This is the short story:
* If you are working on any project that is in some way related
to Haskell, write a short entry and submit it to the me.
* If you are interested any project related to Haskell that has not
previously been mentioned in the HCA Report, please tell me, so
that I can contact the project leaders and ask them to submit
an entry.
* Feel free to pass on this call for contributions to others that
might be interested.
More detailed information:
The Haskell Communities Activities Report is a bi-annual overview of
the state of Haskell as well as Haskell-related projects over the
last, and possibly the upcoming 6 months. If you have only recently
been exposed to Haskell, it might be a good idea to browse the
June 2006 edition -- you will find interesting topics described as well
as several starting points and links that may provide answers to many
questions.
Contributions will be collected until the beginning of November. They
will be compiled into a coherent report which will appear sometime
near the end of November. As always, this is a great opportunity to
update your webpages, make new releases, announce of even start new
projects, or to point at some developments you want every Haskeller to
see!
As the purpose of the report is to collect recent or current
activities, I encourage you to update all existing summaries and
reports. I will probably drop any topics that have not had any
activity for the past year, i.e., since November 2005, but I would
very much prefer you to present an updated description of the
topic. Of course, new entries are more than welcome. Reports should
generally be kept brief and informative, ranging from a few sentences
to a few hundred words, to keep the whole report reasonably sized.
Looking forward to your contributions,
Andres (current editor)
--- topics
New suggestions for current hot topics, activities, projects, etc.
are welcome - especially with names and addresses of potential
contacts, but here is a non-exclusive list of likely topics
(see also http://www.haskell.org/communities/topics.html ):
General Haskell developments
Haskell implementations
Haskell extensions
Standardization (Haskell', ...)
Documentation
Libraries
Papers and Books
Feedback
Summaries of discussions in specialist mailing lists
Conference reports
Community activities
Other Haskell information channels (TMR, Sequence, HWN, ...)
Announcements
Upcoming Haskell events
Everything that's new or has had new releases
Ongoing projects
Reports on what's happening behind the scenes
Confirmations that projects are still maintained
Calls for contributions and contributors
Tutorials
Tools and Applications
Released and unreleased Haskell applications
Tools useful for Haskell programmers
Experiences with using Haskell for a project
Commercial uses of Haskell
Even if your topic is not listed in this list, there's a good chance
it has a place in the Report. Please get in touch with me.
If you want to see an entry that hasn't been there in the past, but
you are not the maintainer of the project, then please encourage the
maintainers to write an entry/update, or ask permission to write the
entry yourself.
-- what should I write?
That depends on your topic, but as a general rule, it shouldn't take
you long. A simple sentence or two about your use of Haskell could
go into the Individual Haskellers section. If you're a company,
or if you're working on a project using Haskell as the implementation
language, a paragraph on that could go into the Applications section.
A typical summary report about a tool/library/project/application/...
would be between 1 and 3 paragraphs of ASCII text (what's it about?
major topics and results since the last report? current hot topics?
major goals for the next six months?) plus pointers to material for
further reading (typically to a home page, or to mailing list
archives, specifications and drafts, implementations, meetings,
minutes, ...).
Browsing through previous editions should give you a good idea of
the variety of possibilities, ranging from very brief to extensive.
For those who prefer templates to fill in, the report is edited in
LaTeX, and an entry template might look something like this:
\begin{hcarentry}{(MYSTUFF)}
\report{(MY NAME)}
\status{(PROJECT STATUS IN ONE LINE)}
\participants{(PARTICIPANTS OTHER THAN MYSELF)}% optional
\makeheader
Re: [Haskell] Call for Contributions - HCA Report (November 2006 edition)
Kurze Story zu BPL? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Two things that i still can't understand in Haskell standard
Hello haskell-prime, first is the monomorphism restriction. why isn't it possible to check _kind_ of parameter-less equation and apply monomorphism restrictions only to values of kind '*'? so, this: sum = foldr1 (*) will become polymorphic because its kind is '*-*' while this exps = 1 : map (2*) exps will become monomorphic because its kind is * second is lack of support for prefix/postfix operations. why it is impossible to do in first pass only lexical analysis of Haskell program, then split it into sentences, extract all import/infix operations and only after processing of these operations, having all the information about operator types and precedence, do the syntax analysis? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
three syntax-sugar proposals
Hello haskell-prime, 1. allow to use '_' in number literals. its used in Ruby and i found that this makes long number literals much more readable. for example maxint = 2_147_483_648 2. allow to use string literals in patterns as head of matched list: optionValue (kb++n) = read n * 2^10 optionValue (mb++n) = read n * 2^20 this syntax already used in Erlang 3. writing kinds is very rare task, but i still don't like to count number of stars in something like '* - * - * - *'. i think that representing this as '' will be more readable -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Monomorphism restriction
Hello, On 10/14/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello haskell-prime, first is the monomorphism restriction. why isn't it possible to check _kind_ of parameter-less equation and apply monomorphism restrictions only to values of kind '*'? so, this: sum = foldr1 (*) will become polymorphic because its kind is '*-*' while this Kinds are use to classify _types_ and not _expressions_. In this case, the expression has the type a - a, with the constraint that a is a numeric type. This type is of kind *. In general, all the executable parts of a Haskell program have types that are of kind *. The things that have kinds like * - * are type constructors. On the other hand, you might wonder why not use the _type_ of an expression in the monomorphism restriction (MR) and only monomorphize expressions of a non-functional type. The reason this would not work is that the MR is used to avoid repeated evaluation of overloaded expressions when they are instantiated to the same types, but the type of an expression does not tell us if the expression is already evaluated. Remember that in a functional language functions are values like any other, and so we might have to do computation to evaluate them. This is why the MR uses a syntactic heuristic. Having said that, many people find the MR weird because it is kind of implementation specific. Even without the MR, a compiler could perform an optimization that notices that a value is being instantiated with the same dictionary multiple times and avoid the repeated evaluation. The MR is especially weird if we consider the fact that the Haskell report does not even require implementations to have sharing (e.g., call by name semantics are OK), so implementation may duplicate evaluation at will... -Iavor ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Two things that i still can't understand in Haskell standard
You don't mean checking kind, but checking type. The same argument that can be made for the monomorphism restriction at base type can be used for function types too. There is nothing impossible about prefixpostfix operator. Haskell just happens not to have them. They could be added. -- Lennart On Oct 14, 2006, at 10:57 , Bulat Ziganshin wrote: Hello haskell-prime, first is the monomorphism restriction. why isn't it possible to check _kind_ of parameter-less equation and apply monomorphism restrictions only to values of kind '*'? so, this: sum = foldr1 (*) will become polymorphic because its kind is '*-*' while this exps = 1 : map (2*) exps will become monomorphic because its kind is * second is lack of support for prefix/postfix operations. why it is impossible to do in first pass only lexical analysis of Haskell program, then split it into sentences, extract all import/infix operations and only after processing of these operations, having all the information about operator types and precedence, do the syntax analysis? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Re: optimization help
Hello apfelmus, Thursday, October 12, 2006, 4:42:14 PM, you wrote: A better solution would be to begin output before the the whole input is read, thus making things more lazy. This can be done the following way: from the input, construct a lazy list of (date,line) pairs. Then, let foldM thread a map from dates to corresponding output file pointers through the list and, at the same time, use the file pointers to output the line in question via appendFile. This way, every line consumed is immediately dispatched to its corresponding output file and things should only require memory for the different dates, besides buffering. In a setting without IO, the task corresponds to the Optimization Problem discussed at length in September on this list. The problem here is that writeFile currently cannot be interleaved lazily, this has to be simulated with appendFile. We can read files lazily but we cannot output them lazily. Can this be remedied? Can there be a version of writeFile which is, in a sense, dual to getContents? this can be solved in other way. here is a program that reads stdin and puts to stdout lines starting with '' and to stderr the rest. note that our main processing function is pure: main = do a - getContents let b = map (processing stdout stderr) (lines a) mapM_ (\(file,line) - hPutStrLn file line) b processing file1 file2 line = if `isPrefixOf` line then (file1,line) else (file2,line) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Howto Haskell in PocketPC?
Hi. Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: optimization help
Paul Hudak wrote: In fact avoiding space leaks was one of the motivations for our moving to an arrow framework for FRP (now called Yampa). Arrows amount to a point-free coding style, although with arrow syntax the cumbersomeness of programming in that style is largely alleviated. I think that's an entirely different thing. You changed representation of signal transformers from newtype SF a b = SF ([a] - [b]) to data SF a b = SF (a - (b, SF a b)) By enforcing a synchronous processing, you avoid leaking Signals. The latter cannot be isomorphic to a function type (Signal a - Signal b) for an appropriate Signal, so this implies a point-free style as there is no way to hold stuff of type (Signal a) in variable bindings. This does not mean that there is no point-wise syntax for arrows, it just means that point-wiseness cannot be achieved via variables in the context of function application, i.e. via lambda abstraction. In fact, the main point about Arrows is not that they are an abstraction for computations but that they allow a point-wise syntactic sugar (which stems from their computational being, of course)! The optimization problem here uses (almost) one and the same representation (pure (a - b), sometimes packed in (a - IO b)) and point-free turns out to be space friendlier than point-wise. That's very puzzling and i think ghc -O2 should eliminate this. Regards, afpelmus PS: IMHO the semantics of (SF a b) need a real cleanup. (Time - a) - (Time - b) is too crude, because these map transformers even cannot be made an instance of ArrowChoice. Also, Dirac-like peaks (that is Events) do not fit in. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: [GHC] #939: Possible bug building wxhaskell
Hi Jason, Jun Mukai aka. jmuk already tried and successed to build wxhaskell on GHC 6.6. Here is his install log. http://sequence.complete.org/node/214 And I made patch for ghc 6.6 from it. Attached solves a few problem ... but you must be careful to your permission. This patch solve package's interface problem with separated build and install process support. And make (make all) depend on installing wxcore. So you have to use sudo other than Windows. I don't know what is the best approach. But advantage is We can make binary (easy install) package for Windows and Mac OS X user. http://www.haskell.org/pipermail/glasgow-haskell-users/2006-September/011043.html You can build binary package following command. make make before-dist make bindist Note that attached fix only GHC 6.6 problem, doesn't fix other - no GHC 6.6 reason - problems. If you will failure to build from other problems, you must see this page first. http://www.haskell.org/haskellwiki/WxHaskell/Install Best Regards, On Sat, 14 Oct 2006 09:29:45 +0900, Jason Dagit [EMAIL PROTECTED] wrote: I reported the following bug and received the response below. Any wxhaskell hackers up to the challenge? I'd really love to see the makefiles go away and see wxhaskell just use cabal but I don't know if that's possible given the wxhaskell build requirements. Any help is much appreciated. Thanks Jason -- Forwarded message -- From: GHC [EMAIL PROTECTED] Date: Oct 13, 2006 5:21 PM Subject: Re: [GHC] #939: Possible bug building wxhaskell To: [EMAIL PROTECTED] #939: Possible bug building wxhaskell -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.6 Severity: normal| Resolution: invalid Keywords:| Difficulty: Unknown Architecture: x86 | Os: Unknown -+-- Changes (by duncan): * resolution: = invalid * status: new = closed Comment: It's not a GHC bug. It's a problem with the way wxHaskell is built. Admitidedly this is due to a slight change in the way GHC manages packages but it's not a bug as such, wxHaskell just needs fixing. What needs to happen is that the packages must be registered locally before they get used in other packages. Also, instead of importing the modules from the other package directly from the directory with -i foo/, it must be via -package foo. So you'll need to get in contact with someone who knows enough about wxHaskell's build system to fix it. Try asking on the ghc-users or haskell-cafe mailing lists. The bug report: I appologize if this isn't a GHC bug but since it started happening after a GHC upgrade I suspect it's a GHC bug. After upgrading to ghc6.6 on windows (using the release binary) I tried to install the current wxhaskell release found here: http://wxhaskell.sourceforge.net/download.html (version wxhaskell-src-0.9.4-1.zip) I have used wxhaskell on this machine before with older version of ghc (including ghc6.5, specifically visual haskell) so my environment for building the wxhaskell source was already setup. When I first got the error below I thought maybe my version of wxhaskell was messed up so I redownloaded the above zip file and unzipped a fresh copy. I unziped the source then I typed: configure make Things went along fairly smoothly for a while then suddenly I got this error message: ghc -c wx/src/Graphics/UI/WX/Types.hs -o out/wx/imports/Graphics/UI/WX/Types.o -iout/wx/imports -odir out/wx/imports -hidir out/wx/imports -fvia-C -package-name wx -iout/wx/imports wx/src/Graphics/UI/WX/Types.hs:94:0: Bad interface file: out/wx/imports/Graphics/UI/WXCore/Types.hi Something is amiss; requested module wx:Graphics.UI.WXCore.Types differs from name found in the interface file wxcore:Graphics.UI.WXCore.Types make: *** [out/wx/imports/Graphics/UI/WX/Types.o] Error 1 -- shelarcy shelarcycapella.freemail.ne.jp http://page.freett.com/shelarcy/ fix_building_ghc-6.6.diff Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: [GHC] #939: Possible bug building wxhaskell
On Sat, 2006-10-14 at 20:32 +0900, shelarcy wrote: Hi Jason, Jun Mukai aka. jmuk already tried and successed to build wxhaskell on GHC 6.6. Here is his install log. http://sequence.complete.org/node/214 And I made patch for ghc 6.6 from it. Attached solves a few problem ... but you must be careful to your permission. This patch solve package's interface problem with separated build and install process support. And make (make all) depend on installing wxcore. So you have to use sudo other than Windows. Ah, that's shame. I was being lazy and hoping someone would provide a fix that we can use for distro packages. :-) At the moment it looks like -- in Gentoo at least -- wxHaskell is going to be the only package left behind in the transition to GHC-6.6. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: function result caching
G'day all. Carl Witty wrote: Instead of using an infinite list, you can use an infinite binary tree, with a cached result at every node. Quoting [EMAIL PROTECTED]: This, also known as patricia tree, is indeed the canonical answer. A Patricia tree is but one infinite tree data structure. There's another (which is actually an infinite list of balanced binary trees) at http://haskell.org/hawiki/MemoisingCafs Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Automatic fixity allocation for symbolic operators
Hi - I'm wondering if it is possible to construct a methodical procedure to assign a fixity to symbolic operators so that we could get rid of the need for user defined fixites. User defined fixities are an enormous problem for an interactive editor, because it is not possible to construct a parse tree of some code if you don't know what the fixities are, and an editor must be able to do something useful with a code fragment without having to look inside other modules (because the other modules may not yet have even been written!). Also, the programmer or reader of code needs to be able to understand each code fragment independently as well. From the Haskell98 report, the Prelude defines: infixr 9 ., !! infixr 8 ^, ^^, ** infixl 7 *, /, `quot`, `rem`, `div`, `mod` infixl 6 +, - infixr 5 :, ++ infix 4 ==, /=, , =, =, infixr 3 infixr 2 || infixl 1 , = infixr 1 = infixr 0 $, $!, `seq` Suppose we ignore the varid operators and just consider the symbolic ops. What I'm trying to find is a systematic way to assign fixities to all other possible sequences of symbol characters that is consistent with what we've already got in the Prelude. As a first step, we could say that mirrored operators must share the same precedence ie: == For associativity, we could assign each character an associativity weight: -1 left associative 0neutral 1right associative and say that the associativity is simply the sign of the sum of the associativity weights of the characters thus: -1 =0 1 =0 + 1 + 1ie infixr Note that I don't care about non-associative ops since the non-associativity of something should be a question for the type checker not the parser imho - ideally we should be able to create a parse tree for any possible operator expression. To form the precedence, we could assign each character a precedence value eg: 9 .! 8^ 7*/ 6+- 5: 4= 3 2| 1 0$ A first attempt might be to say that the precedence is simply the decimal expansion of the precedence values eg = has precedence 1.14 and $! has precedence 0.9. However, as noted above, mirrored ops must share the same precedence so an alternative is to create some ordering of characters such that when the set of characters in an operator is sorted according to this ordering, the decimal expansion of the precedence digits will give the same relative ordering for operator precedences as the Prelude. For example, using $ | + - * / ^ . ! : = as the ordering, we'd get: infixr 9 .!! 99.9 infixr 8 ^, ^^, **8 8.87.7 infixl 7 *, /,77 infixl 6 +, -6 6 infixr 5 : , ++ 56.6 infix 4 ==, /=, , =, =, 4.4 7.4 11.41.41 infixr 3 3.3 infixr 2 ||2.2 infixl 1 , =1.11.14 infixr 1 =1.14 infixr 0 $, $!00.9 Although most existing ops get a similar precedence (eg ^ ^^ and ** are all still in the same group relative to the other ops despite the fact that within the group there is now an ordering) the main problem seems to be that = = get precedences that bind too loosely and /= is totally wrong. This problem aside, the above algorithm would give sensible precedences for such things as: :: 5.1 +*6.116.11 where the use of neutralizes the associativity contribution of or respectively (since (-1) + 1 == 0), giving us the intuitive associativity we'd expect from the interesting character in the middle. (The problem of /= getting 7.4 could be solved by putting / after = in the order, to get 4.7, but unfortunately this would mean that since must be before =, would be before / so / would get the wrong precedence compared to *) Another issue is that there is no assignment of associativity weights such that * is infixl but ** is infixr (ditto + and ++) so perhaps we'd need to associate each character with an associativity function. Similar to precedences, we then define an associativity ordering and let the resulting associativity be the sign of the composition of the sorted functions applied to 1 eg: ^ const (-1) * \x - x * (-1) = id const (-1) (+1) (+ (-1)) Then *(\x - x * (-1)) 1===-1 ie left ** (\x - x * (-1)) . (\x - x * (-1)) $ 1 === +1 ie right = = (+ (-1)) . (+ (-1)) . id$ 1 === -1 *-- remember ordering
Re: [Haskell-cafe] Howto Haskell in PocketPC?
This has been around for some time already. It used to work with PPC2003, hopefully it'll still do: http://www.comp.nus.edu.sg/~luzm/ppchugs/ Enjoy it :) On 14/10/2006, at 8:24, Iván Pérez Domínguez wrote: Hi. Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Howto Haskell in PocketPC?
Hi, Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC? If you want to port Yhc [1] it shouldn't take more than a couple of hours. Thanks Neil 1: http://www.haskell.org/haskellwiki/Yhc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
Robert Dockins [EMAIL PROTECTED] writes: slowFunctionCacheList= [slowFunction (i) | i -[0..500]] and use slowFunctionCacheList !! i instead of slowFunction (i) Not much different in principle, but better in practice - you could use an array rather than a list. O(1) lookups should make things (a lot) faster. Well, this is true only if the range of the domain function is small and fairly dense. I don't think so. With 500 elements, you're looking at allocating about 20Mb of memory On the other hand, the lists allocates the 20Mb of pointers, *and* another 20Mb of cons cells for the lists. to hold pointers to closures_ and then allocating and filling out 500 closures, all before you get down to doing any real work! If I interpret you correctly, you want to make the array's contents strict? Not a good idea when the domain is sparse, but on the other hand it would let you unbox the contents, which means you'd only need to store the actual values. For boolean values, I think GHC stores one bit per value, i.e. less than a MB for this range. Little-endian patricia trees [...] Yes, sure, if you can't afford a 20Mb index. On the other hand, changing the function to use an array is a very small modification, and probably more than good enough in many cases. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
Brian Hulley wrote: infixr 9 .!! 99.9 infixr 8 ^, ^^, **8 8.87.7 infixl 7 *, /,77 infixl 6 +, -6 6 infixr 5 : , ++ 56.6 infix 4 ==, /=, , =, =, 4.4 7.4 11.41.41 infixr 3 3.3 infixr 2 ||2.2 infixl 1 , =1.11.14 infixr 1 =1.14 infixr 0 $, $!00.9 Ouch. Really, the first priority in the language should be human readability. Looking up a fixity isn't that hard, but remembering a rule like this is pretty awful. You also restrict the freedom of library designers for no good reason. Precedences aren't usually random ... As far as editors go I have little sympathy. I also see nothing wrong with forcing a coder to have at least a module stub that defines its interface and the operator precedences, to make the parsing work reliably. You'll have to deal with the case where parsing fails anyway, and it shouldn't be too hard between failures due to unsufficient information (which shouldn't be tagged as errors, but maybe give some other indication) and real errors. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
On Saturday 14 October 2006 13:13, Ketil Malde wrote: Robert Dockins [EMAIL PROTECTED] writes: slowFunctionCacheList= [slowFunction (i) | i -[0..500]] and use slowFunctionCacheList !! i instead of slowFunction (i) Not much different in principle, but better in practice - you could use an array rather than a list. O(1) lookups should make things (a lot) faster. Well, this is true only if the range of the domain function is small and fairly dense. I don't think so. With 500 elements, you're looking at allocating about 20Mb of memory On the other hand, the lists allocates the 20Mb of pointers, *and* another 20Mb of cons cells for the lists. True, but only if you access deeply into the tail of the list. If one access only the first several hundred elements, say, then you'll only allocate the space needed for those. Of course, if you only want to access a small portion at the begining, then why create such a big list in the first place? Moral: lists will lose this contest in almost all cases. to hold pointers to closures_ and then allocating and filling out 500 closures, all before you get down to doing any real work! If I interpret you correctly, you want to make the array's contents strict? Not a good idea when the domain is sparse, but on the other hand it would let you unbox the contents, which means you'd only need to store the actual values. For boolean values, I think GHC stores one bit per value, i.e. less than a MB for this range. No, I didn't suggest that the elements be strict. That would involve precomputing the entire table. You _could_ do that if you anticipate a LOT of access to sufficient to outweigh the initial cost. But that seems unlikely for a sparse domain, as you mentioned. However, even non-strict arrays are created all at once (ie, they are strict in their _structure_), and the closures have to be allocated as the array is being created. Creating a closure isn't terribly expensive, but creating 500 closures might take awhile and cost a lot of memory if the closure has a large number of free variables (which depends on the function definition and the exact details of the lambda lifter). Also, large arrays tend to play havoc with GHC's garbage collector; it has to scan all elements on every major GC, IIRC. That alone may offset any advantages won. In the end, the only way to be sure which method is best is to test it against your usage profile. My guess is that the array method will have enough overhead that it will lose against a tree. However I may be wrong, especially if the program will have a very long runtime and if a warm-up period is acceptable. Little-endian patricia trees [...] Yes, sure, if you can't afford a 20Mb index. On the other hand, changing the function to use an array is a very small modification, and probably more than good enough in many cases. I completely agree; it is good for many cases, and can be a very useful technique. I just don't think it will be good for _this_ case (large, sparse domain where f(n) doesn't depend on all f(m) where m n). That probability is positively correlated with the size of the domain. Again, the only way to really know is to implement and benchmark. Thankfully, caching techniques are completely local and can be changed easily. -k -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
Perhaps the editor could assume a default precedence when the user-defined precedence is not yet available. Preferably, the editor would also somehow yell at the user to indicate that it is making such an assumption. I think it's unreasonable to tie programmers' hands for the sake of off-loading rather trivial tasks to editors. Nick On 10/14/06, Bertram Felgenhauer [EMAIL PROTECTED] wrote: Brian Hulley wrote: infixr 9 .!! 99.9 infixr 8 ^, ^^, **8 8.87.7 infixl 7 *, /,77 infixl 6 +, -6 6 infixr 5 : , ++ 56.6 infix 4 ==, /=, , =, =, 4.4 7.4 11.41.41 infixr 3 3.3 infixr 2 ||2.2 infixl 1 , =1.11.14 infixr 1 =1.14 infixr 0 $, $!00.9 Ouch. Really, the first priority in the language should be human readability. Looking up a fixity isn't that hard, but remembering a rule like this is pretty awful. You also restrict the freedom of library designers for no good reason. Precedences aren't usually random ... As far as editors go I have little sympathy. I also see nothing wrong with forcing a coder to have at least a module stub that defines its interface and the operator precedences, to make the parsing work reliably. You'll have to deal with the case where parsing fails anyway, and it shouldn't be too hard between failures due to unsufficient information (which shouldn't be tagged as errors, but maybe give some other indication) and real errors. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
On 10/14/06, Nicolas Frisby [EMAIL PROTECTED] wrote: Perhaps the editor could assume a default precedence when the user-defined precedence is not yet available. Preferably, the editor would also somehow yell at the user to indicate that it is making such an assumption. Perhaps it could even assume the fixity that is specified in the prelude for operators without fixity declarations, thus behaving exactly like the compiler would: Any operator lacking a fixity declaration is assumed to be infixl 9 (4.4.2) I agree that changing the language in such an unintuitive way - breaking existing code in the process - to suit an editor is counterproductive and ridiculous. /g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What's going on in our courses?
Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Indeed, I'd be interested as well. I'm actually looking for a good textbook for a concepts of programming language course. All the books I can find tend to emphasize OO or imperative programming too much for my taste. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What's going on in our courses?
monnier: Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Indeed, I'd be interested as well. I'm actually looking for a good textbook for a concepts of programming language course. All the books I can find tend to emphasize OO or imperative programming too much for my taste. You might want to look at : http://cgi.cse.unsw.edu.au/~cs3161/docs/references.php We use: Bob Harper's book, Programming Languages: Theory and Practice http://www-2.cs.cmu.edu/~rwh/plbook/ and Types and Programming Languages, Benjamin Pierce Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What's going on in our courses?
dons: monnier: Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Also, http://haskell.org/haskellwiki/Haskell_in_education -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error detection in GLR Happy grammar
Hi! I'm trying to detect parse errors in a happy GLR grammar, but I can't! I insert the special token 'error', and call the error function when an error is found. However, the program prints no error messages, and simply returns a ParseError at the end. Does any of you have an good example of a GLR parser with error detection and, if possible, error recovery as well? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
thank you for all the answersi was aware lists are is not the best solution, but i was too keen to see the actual result I'll do some tests though using different variants, because i have the feeling that in my next program I'll face the strong form of this problem. On 10/13/06, Silviu Gheorghe [EMAIL PROTECTED] wrote: it does, thank you very much for the quick answer, unfortunately as I understand it, it doesn't work well on ints :(for just now i created a list slowFunctionCacheList= [slowFunction (i) | i -[0..500]] and use slowFunctionCacheList !! i instead of slowFunction (i)it helped alot (i mean i stoped the program after 3 hours still working and got the result in 2 minutes :)) i am still curious about a better method (and a general one), because this is ugly, and it only works on ints as i see it.but then again thank you for telling me it doesn't do it, because i had the false impresion it does and i wouldn't stop it otherwise On 10/13/06, Tom Phoenix [EMAIL PROTECTED] wrote: On 10/12/06, Silviu Gheorghe [EMAIL PROTECTED] wrote: I'd like to know if the results are cachedby the compiler Hardly ever, as I understand things. if they are not I'd like to know what is the best way to cache them manually, and where can I read more about this, and the optimizations the compiler does, because I've searched the web before and i found very little on this topic.You need to search for the word memoize (or memoise). Here's apage about a memo function for GHC. http://www.haskell.org/ghc/docs/6.4.2/html/hslibs/memo-library.htmlHope this helps!--Tom Phoenix ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
On 10/14/06, Brian Hulley [EMAIL PROTECTED] wrote: User defined fixities are an enormous problem for an interactive editor This is the second or third time you've proposed a language change based on the editor you're writing. I don't think this is a fruitful avenue. There are three ways to change Haskell's lexical structure: 1. DIY on an open-source compiler/interpreter of your choice. 2. Write your own compiler/interpreter. 3. Get the change into Haskell''. If the Haskell'' procedure is like the Haskell' procedure, you'll have to do 1 or 2 before you do 3. It's possible that you will convince someone that your syntax changes are worth doing, and that this person will do step 1 or step 2 for you, but I don't think so. I haven't done the research myself, but I think if you look at the source control logs for Your Favorite Haskell Compiler/interpreter and the HCAR, you will find very few commits/projects devoted to syntax. I think this is because Haskellers are much more interested in semantics. Proposing changes that break existing code or segment the Haskell code base just doesn't seem like a win. Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error detection in GLR Happy grammar
Hello, error isn't implemented yet in GLR mode - it is ignored. Note that yacc-style error handling can't be transplanted directly into GLR, since the nature of parse errors is not the same. In LR(k) errors mean that the single parse can't continue and hence some remedial action is needed. In GLR, it could mean this (when following one unique parse), or with multiple parses that some are being dropped because further input has ruled them out. Recovery on the latter probably isn't correct - they should be discarded. I might try allowing an explicit error token which acts only when one parse is live, and follow standard Happy behaviour for this. If you have an example to test on, it might be useful. Note that for failed parses, you are given a list of unconsumed tokens and the partial parses constructed so far, so some diagnosis is possible. Paul ps. I've almost fixed the module header problem you mentioned before. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [off-topic / administrative] List Reply-to
Antti-Juhani Kaijanaho wrote: Robert Dockins wrote: I think (pure speculation) the haskell.org mail server is set up to omit people from mail it sends if they appear in the To: or Cc: of the original mail. Yes, this is a feature of recent Mailmans. Finally, I agree that reply-to munging is a bad idea, but I don't think appealing to a definition of 'reasonable mailer' that doesn't match a large portion of mail clients currently in the wild is a good way to argue the point. Gnus might have been the first one to have it, but mutt (very popular in hackerdom) was perhaps the one that popularized it. I am currently using Mozilla Thunderbird, for which it is available as an extension (unfortunately, it also requires a patch for Thunderbird; but Debian sid has already applied it). KMail (at least in KDE 3.5.4) has it, too. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: optimization help
Hello, Yet, I'm a bit astonished. I thought that when compiling with -O2, cosmetic changes should become negligible. Perhaps the strict foldl' has an effect? Perhaps... but I doubt that is the main reason. At the moment I have no idea why there is such a discrepancy between the heap usages... A big part of why the solutions you crafted work so efficiently is that they take advantage of the fact that the rows will be written out exactly as they are read in. I wanted to see if a more general code could maintain the same efficiency. Here is some code to read in a file, write out a file, and do selections-- the idea is that CSV files are internally represented and manipulated as [[ByteString]]. readCSV file = do v - B.readFile file return $ map (B.split ',') $ B.lines v writeCSV file tbl = do h - openFile file WriteMode let writeRow = mapM_ (B.hPut h) . (++ [nl]) . intersperse comma mapM_ writeRow tbl hClose h where comma = B.singleton ',' nl = B.singleton '\n' select targs test (cols : rows) = map narrow (cols : passTest rows) where myFilter = map snd . filter fst passTest = myFilter . map (\row - (runReader test (zip cols [0..], row), row)) narrow = myFilter . zip (map (`elem` targs) cols) col x = do (cols,row) - ask let Just i = lookup (B.pack x) cols return $ row!!i This code runs reasonably fast-- around 13 seconds to read in a 120MB file (~75 rows), select half the columns of around 22000 rows randomly distributed throughout the input table, and write a new CSV file. It takes around 90 seconds to just remove some columns from every row in the table and write a new file. So the slow part of the program is probably the writeCSV function. Do you think these times can be improved upon? -Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
