Re: [Haskell-cafe] Is there something better than tags?
On 02/22/2011 12:26 PM, Marc Weber wrote:
learn about gd and gD those are not perfect though.
Also keep in mind that # * start searches on words.
They all are not language aware so they are only bad replacements for
what you're looking for.
When we are talking about such simple helpers then you may want to check
out:
Mark : Highlight several words in different colors simultaneously.
http://www.vim.org/scripts/script.php?script_id=2666
I also like showmarks to highlight interesting places:
ShowMarks : Visually shows the location of marks.
http://www.vim.org/scripts/script.php?script_id=152
2. Retrieve type information for local defintions ('let', 'where',
'do'), and ideally also for sub expressions (like ':t filter (== 1)'.
I believe haskellmode uses GHCi to get the type information out, but
I only know about scion which comes closest to what you ask for.
(http://github.com/MarcWeber/scion-backend-vim)
Is this a correct summary?
* can load cabal components (all files of the component)
* can do type checking on buffer write
* can show type of any symbol under cursor if the file type checks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there something better than tags?
On 02/22/2011 11:45 AM, Magnus Therning wrote:
1. Fully functional go-to-definition. With that I mean that
go-to-definition is aware of local definitions introduced in 'let' and
'where' clauses and ideally also for names bound in 'do' clauses.
I've found there are several ways to generate a tags file, GHCi can
generate them, and there are two tools for it, hasktags and
hothasktags. haskellmode currently uses GHCi to generate tags.
However, the limitation seems to be inherent in the tags format
itself. AFAICS there is no way to get a fully functional
go-to-definition with that format.
Last time I checked (about a year ago), the file scope was the smallest
scope supported by vim in tag files. So you are out of luck here. You
would need to extend vim (either by extending the tag file format or by
your own scripts handling this separately) and also your favourite tags
generator.
2. Retrieve type information for local defintions ('let', 'where',
'do'), and ideally also for sub expressions (like ':t filter (== 1)'.
I believe haskellmode uses GHCi to get the type information out, but
it is only able to get it for top-level definitions.
This is because ghci shows you this information only for the top level
symbols (the ones available in :browse). Ghci would need to be extended
first. Maybe it is there in GHC 7.0?
I hope I'm wrong somewhere and it could be done somehow more easily.
Peter.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Weekly News: Issue 155 - October 20, 2010
On 10/22/2010 09:37 AM, wren ng thornton wrote: On 10/21/10 5:38 AM, Ketil Malde wrote: I'm always getting two copies of everything in haskell@, since everything is cross-posted to -cafe. Are there actually people subscribed to -cafe, but *not* to hask...@? And if so, why? I am. In part because I don't want to get two copies of everything, but in part because I'm lazy. This is my case too. As for as the amount of messages, who cares. Get it through NNTP. You will download only the headers. Bodies will be downloaded only for messages you read. You can check only the threads you consider interesting. There is not much new threads. "Mark newsgroup read" is a quick operation. I do not think HWN should not be posted to haskell-cafe. If you decide so I do not really care but post a message to haskell-cafe list that you are switching HWN to haskell list only (so I can subscribe there too). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to browse code written by others
On 06/20/2010 11:05 AM, Claus Reinke wrote: I think Luke means that if you use qualified names then hothasktags can give you better location information than current ghci ctags. GHCi :ctags doesn't output tags for qualified names (though it probably should), but that isn't enough for proper handling of qualified imports. I believe hothasktags is meant to output multiple tags per target, one for each module referencing the target. I understand it that way too. But that would rely on scoped tags. By scoped tags, I understand tags valid only in the given scope (which is a file for the sake of qualified imports) which is the same as static tags which are supposed to be valid inside a file too ... but they are not as I found out from your example later :-( I discussed this with Luke before and I sumarrized what would need to be done to imporove ghci ctags to support qualified names better. Here is the post which explains it with an example: http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/73116 The problem with that example is that all occurrences of B.x point to b.hs and C.x always points to c.hs, so it doesn't test the scoping aspect of static tags. For instance, if you are in b.hs, and try ':tag C.x', you'll still be sent to c.hs, even though that isn't in scope (see also ':help tag-priority'). Yes, but this is the way vim works. Vim jumps even when given tag is not in scope. C.x is not in scope in b.hs (not as a static nor as a global symbol) so vim gives as static tag in a different file which matches exactly. Which looks like a reasonable feature for non-hierarchical symbols (maybe one is missing an include/import). Well, maybe not so much for jumps to tags but definitely usefull in :tselect. If we would use hierarchical names for tags then this is not so good and it works poorly (if I can say it works at all) for tag completions (^X^]). If I add a file d.hs that is the same as a.hs but with the qualifiers exchanged: module D () where import qualified B as C import qualified C as B localAct = do print B.x print C.x and try to add corresponding scoped tags by hand, then I don't see the scoping being taken into account (though my Vim is old 7.2 from August 2008). Depending on sort order of the tags file, either all B.x point to b.hs or all B.x point to c.hs. So, one either gets the wrong pointers in a.hs or in d.hs. You are correct. I thought this works well. Thanks for pointing it out. It does not work for me in my vim too, version 7.2 too. This looks to me like a vim bug. Though vim developers may not think so since it is not documented anyway. So it is really questionable how much do the qualified tags make sense in vim. I'm much less of a supporter of scoped tags now :-/ Looks like it is not worth the effort. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to browse code written by others
Hi Claus, On 06/15/2010 05:57 PM, Claus Reinke wrote: If you go this route, I will shamelessly promote hothasktags instead of ghci. It generates proper tags for qualified imports. What do you mean by "proper" here? I think Luke means that if you use qualified names then hothasktags can give you better location information than current ghci ctags. I discussed this with Luke before and I sumarrized what would need to be done to imporove ghci ctags to support qualified names better. Here is the post which explains it with an example: http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/73116 With this addition, I believe, ghci tags would at least as good as hothasktags. That said I do not try hothasktags. Do hothasktags do analyzes deep enough that the information provided is always correct? I did not go to add this to ghci ctags since I barely ever use qualified names so it is a non-issue for me. Also propper support for scoped tags would include some vim macro which (on ^] key-press) tries to find a qualified name first and only after a failure it would try to find plain name without qualification. So if one wants to use it well he/she needs first select the name in visual mode and only then pres ^]. (Or one should use full ex commands for navigation like :tselect.) but in Vim 7.2 the help file still says http://vimdoc.sourceforge.net/htmldoc/tagsrch.html#tags-file-format The only other field currently recognized by Vim is "file:" (with an empty value). It is used for a static tag. If Vim somehow started supporting that extended file: format without updating its docs, that would be good to know (what version of Vim? where is this documented?). I did not find it documented but it looks like a filename can be used in place of . If provided then the validity of the tag is limited to the filename. Your suggested use-case for such a feature is interesting, but we're getting into an area where "live" calls to a scope resolution tool might make more sense. Och I would like to have a "vim" with full incremental parser for Haskell ... with things like AST being drawn in a pane, intellisense and completion on symbols but also on grammar/syntax, re-factoring options and all the goodies this could provide. It will not be a vim any more. Probably won't happen in my lifetime either but I can dream :) Peter. PS: Thanks for your vim support. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announce: hothasktags
On 04/08/2010 01:09 AM, Luke Palmer wrote: On Wed, Apr 7, 2010 at 1:23 AM, Evan Laforge wrote: Derive.PitchDeriver Derive/Derive.hs98;"file:Cmd/Cmd.hs Derive.PitchDeriver Derive/Derive.hs98;"file:Cmd/Play.hs Derive.PitchDeriver Derive/Derive.hs98;" file:Cmd/ResponderSync.hs ... [ 20 more ] ... The vim tag documentation says these are "static" tags, and implies they are meant to apply to symbols only valid within the same file, but this is clearly not the case. Actually, the vim doc implies that only "file:" is defined, and doesn't talk about "scoped tags" so I'm not sure what is going on. Anyway, whenever I go to a tag I have to first step through a message that says "1 of 25" or so. There's one for each reference in the tags file, even though those are references in other files. Hmm odd, I don't get that behavior. Is that with the sorted annotation? What version of vim? I get the correct behavior (no additional selection is needed). My vim version is 7.2.385. I did not use sorted annotation but I doubt it has anything to do with it. What's going on? I even checked the current docs at vim.org and they don't mention a file:xyz form either. I think I saw it documented *somewhere*, but now that I look again I can't find it anywhere. Maybe it was in a dream. I hope a newer version of vim didn't remove the support or something... Even if it is not documented it makes sense. When "file:" is present then it limits the tag to the file which is the argument of "file:". If "file:" does not have any argument then the argument defaults to the file in which the tag is defined. That would mean that exported symbols should be generated without "file:", non-exported symbols should be generated with "file:" which does not have argument. In addition to this qualified symbols should be generated with the qualification and with "file:" where is the file name where the symbol is imported as qualified. Ghci's :ctags does not support qualified symbols :-/ Just to clarify it for myself. That would mean that the tags file should look like this: B.xb.hs/^x = 5 :: Int$/;"vfile:a.hs B.xb.hs/^x = 5 :: Int$/;"vfile:c.hs C.xc.hs/^x = B.x+1$/;"vfile:a.hs localActa.hs/^localAct = do$/;"vfile: xb.hs/^x = 5 :: Int$/;"v xc.hs/^x = B.x+1$/;"v ... for these files: === file a.hs === module A () where import qualified B as B import qualified C as C localAct = do print B.x print C.x === file b.hs === module B (x) where x = 5 :: Int === file c.hs === module C (x) where import qualified B as B x = B.x+1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announce: hothasktags
On 04/07/2010 09:23 AM, Evan Laforge wrote: On Thu, Apr 1, 2010 at 1:46 PM, Luke Palmer wrote: VIm only for now, since I don't know if emacs tags format supports scoped tags. I am aware that it is not perfect -- patches and bug reports welcome. This program generates a tag for each reference to a symbol: Derive.PitchDeriver Derive/Derive.hs98;"file:Cmd/Cmd.hs Derive.PitchDeriver Derive/Derive.hs98;"file:Cmd/Play.hs Derive.PitchDeriver Derive/Derive.hs98;" file:Cmd/ResponderSync.hs ... [ 20 more ] ... The vim tag documentation says these are "static" tags, and implies they are meant to apply to symbols only valid within the same file, but this is clearly not the case. Actually, the vim doc implies that only "file:" is defined, and doesn't talk about "scoped tags" so I'm not sure what is going on. Anyway, whenever I go to a tag I have to first step through a message that says "1 of 25" or so. There's one for each reference in the tags file, even though those are references in other files. What's going on? I even checked the current docs at vim.org and they don't mention a file:xyz form either. As far as I know, there is nothing like "file:xyz" only "file:". This is to support static tags which I would not call "scoped tags" because they know only one scope: the file scope. Between, ghci can generate tags file for you with static tags too in ghc 6.12.1. The ticket which discusses this feature and also discusses emacs support for static tags is here: http://hackage.haskell.org/trac/ghc/ticket/3434 Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskellers hate GUIs!!
On 04/02/2010 10:15 PM, Dominic Espinosa wrote: On Fri, Apr 02, 2010 at 06:11:52PM +0100, Stephen Tetley wrote: On 2 April 2010 17:53, Dominic Espinosa wrote: I ended up rewriting it in another language (due to time pressure) and I'm a little wary of attempting to use Haskell again for developing such an application. Out of curiosity what language did you choose instead? Some algol-like language purporting to have cross-platform GUI support, widely used by others in our department. I think the name started with "J". I did not enjoy the rewrite. The Haskell code was a lot nicer (and shorter). May you tell us how much (a percentage) shorter the Haskell code was? Maybe, you can even specify the project size better. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Documentation design
I like your proposal. Few notes below. On Sun, 05 Jul 2009 23:45:31 -0400, Isaac Dupree wrote: > My dream situation: both haddock-pages and hscolour-pages would be > super-hyperlinked and super-readable. For example, haddock would list > all a module's definitions, not just its exports. In HsColoured source, > every identifier would link to its definition or the haddockumentation > of its definition. and so forth. It would be so much easier to generate > and browse this in HTML, than to get an IDE working, and it would be so > much more readable than a mere text-editor (even with syntax hilighting) > and quicker clicking on hyperlinks than grepping for everything. You do not need to resort to grep for navigation of your source code from your text editor. At least not with vim. It has tags and stack of tags. Generate tags for your source code and use Ctrl-] to navigate to the definition (or Ctrl-W} to open the definition in preview window). Any jump to definition done with Ctrl-] is stored in the stack of tags. You can return to the previous position in the stack with Ctrl-T or return to the last next position with :tag. You can check how the tag stack looks like with :tags. This way you can navigate the stack of tags comfortably and the stack of tags can correspond to the lexical (creation) stack as it would exist during execution. The only problem with this is that it works so nicely only for me currently since I have a patch applied to ghci which makes ghci to include also the non-exported symbols to the tags file. I would like to add the patch to ghci but so far there is only small support for it. If you (or anybody else) would like it drop me a note or comment on the glasgow haskell users list: http://www.haskell.org/pipermail/glasgow-haskell-users/2009- June/017399.html The :ctags improvement patch gives you a substitute for intellisense in vim. I have ":inoremap ^] ^[^W}a" in .vimrc so when I start to type a function name I can finish it with some completion, and (while still being in the insert mode) I can get help for it to the preview window with Ctrl-]. > The ideal haddockumentation-formatting for this purpose isn't quite > obvious though. For example, sometimes you want to think about a module > in terms of its abstract interface, but sometimes you want to figure out > how it's implemented (without reverting completely to text based code > browsing). Maybe a compromise of some sort would be good. so... > > Here's a proposal, for a new mode (`haddock --all-internal`?, to be > invoked by `cabal haddock --internal` rather than --internal's current > effect of ignore-all-exports) : > > Files with no explicit export list can be treated as-is anyway. > > For all files that have an explicit export list, generate the > synopsis-of-exports near the top, as usual. But have the index link, > generally, to where functions are originally defined (modulo being from > a non-internally-documented separate package, where it should link to > the appropriate place), and have the fuller documentation below be a > compilation of the identifiers *defined* in this module. I like it but some notes to the new synopsis part: You mean the index link for a symbol should go to the haddock help page not to the HsColour source page. Right? I would like some annotations aligned to the right which would indicate whether the symbol is defined locally or it is reexported. There should be also an annotation or different font to indicate whether the symbol in synopsis is exported or not (in addition to nonexported symbols being is a separate section). This is so that one can easily see what part of the help is shown. > Actually that would need some revision because the sections and > subsections -- *, -- **, etc. defined in the export-list in the .hs, > actually are displayed > 1. above the table of contents, linking to places in 2. the full list of > definitions. Which might be defined in the module in a different order > than they're listed in the export list. Why not add the sections into > the synopsis? In this case, instead of adding them to the main doc > section. But hmm... in ordinary non-internal documentation, would it be > nice to *additionally* have the sections marked in the synopsis (in > addition to in the Contents and in the main docs section)? Not sure I understand this part well. I assume by main document part you mean the part with detailed description and source code links. I want the contents preserved with the added last section with name "Nonexported symbols", or something named like that. Adding the section names to synopsis seems like good idea to me. In such a case it could be removed from the main doc part but I would rather keep it there. But I do not really mind either way. I assume the main doc part would contain only the symbols defined in the given module (not the re-exported ones). But the synopsis part would contain the names of re-exported symbols with links to the appropr
[Haskell-cafe] Re: GHC 6.10.2 compatible problem.
Andy Stewart wrote: I saw GHC release new version now, and fix some bug. I want to know below pacakges whether works fine with GHC-6.10.2 before i upgrade it: cabal, gtk2hs, xmonad, yi, leksah Gtk2hs does not work with ghc 6.10.2 yet: http://permalink.gmane.org/gmane.comp.lang.haskell.gtk2hs/1497 Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to catch error in array index when debugging
Colin Paul Adams wrote: "Adrian" == Adrian Neumann writes: Adrian> You can use the ghci debugger >> http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci- Adrian> debugger.html Adrian> it can set breakpoints on exceptions. So i tried adding the -fbreak-on-error flag. It made no difference - it still exited: : Error in array index : interrupted : warning: too many hs_exit()s IIRC, this is because you are catching exceptions at some higher level where you actually find out that this kind of an exception is not handled and give up. If your application is Gtk2Hs then this library will do the catching you do not like in this case. Try to use -fbreak-on-exception instead of -fbreak-on-error. If you try this you may need to set break-on-exception late enough in the execution (use some breakpoint) so that you are not stopping at places which are ok (are correctly handled in an exception handler). In addition to other solutions mentioned here you can also setup conditional breakpoints in GHCi because GHCi breakpoints can be scripted. This is what I mostly use. Most of my debugging is done by writing GHCi debug scripts. Some ideas how to do it are here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16270 It does not work well for interactive command line applications now, but it will work well for them when GHC 6.10.2 is out (the three most critical patches were merged). This alternative may have steep learning curve for such a simple thing but once mastered it works well. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Wolfgang Jeltsch wrote: Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek: So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking script are OK too I think, it’s technically not possible to let your Haskell application use another library version when you just have the .o and .hi files of the new library version. The .hi files typically contain code which is inlined by the application, so you have to be able to recompile the application. Or am I misunderstanding you? You may be right. I do not know. Compiler authors would know. But if the *only* problem is the inlined functions then it may not be that bad. Depends whether the depth of inlining has some limit and whether a change of code which is not inlined any more results in failure to link correctly too. The point is that inlining itself is not a problem simply the code which is inlined represents the interface and you need to provide an option to upgrade to a newer library with the same interface only. The same problem is with shared objects in C. The header files may contains macros (which are inlined) and you are not forced to provide source code of your app despite the fact that compilation inlines some code from the LGPL library used. Simply that code is part of the interface and changing it changes the interface. The acceptable size of inlined fuctions for a C code is about 10 lines. I did not read any info how it would be for Haskell. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Peter Verswyvelen wrote: On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek wrote: * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine... I think so. If you acknowledge them as legitimate users and you distribute the free program then you must allow them to upgrade the LGPL library. With Haskell this may mean releasing the source code. I'm vary about this part though. *.o and *.hi may be enough since: * GHC is not LGPL but some kind of BSD * only the gmp and gtk2hs are LGPL * so you do not need to make sure ghc can be upgraded * you need to make sure gmp can be upgraded and gtk2hs can be upgraded but forcing users on the same version of ghc * requirement to allow upgrade is there only while the LGPL library does not change interface The above should allow to distribute only *.o and *.hi files. If user wants to to upgrade GMP or GTK2HS they can do it and recompile with the old version of GHC (the one for which you provided *.o and *.hi files. So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking script are OK too As for as Google: That is a different case. The GPL/LGPL limitations kick in *only* when you redistribute your program. Goolge is not redistributing their search engine! They only provide you a service over internet! That is very different. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Wolfgang Jeltsch wrote: I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library Of course there is a difference and a *significant* one. * A GPL library will force commercial users of the library to release their code under GPL. * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. The users of the commercial program maybe be forbidden to redistribute the application source code as well as modifying the application source code e.g. to avoid licensing restrictions imposed on them by the application seller (the LGPL library user). The commercial program owner does not even need to distribute the source code with the application by default. It just needs to provide an easy way to obtain the source code for all licensed customers (those who bought it) and let them prominently know (maybe in the about box of the application) where to get the source for the purpose of recompilation with a newer version of the LGPL libs. Providing source code without any other rights than to recompile with a newer version of a LGPL lib should not be such a big deal ... that is if the commercial application author's business model does not depend on some super secret process in the code or does not have something fishy stuff to hide :) The above does not represent a difference only when you assume that all your users are crooks which will redistribute everything without a bit of hesitation. Then it is up to you whether you wan to sue them :) Am I missing something? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
wren ng thornton wrote: Lacking a wiki account, ~wren From HWN: HaskellWiki Accounts. Ashley Yakeley can [12]create a HaskellWiki account for anyone who wants one (account creation has been disabled as a spam-fighting measure). http://article.gmane.org/gmane.comp.lang.haskell.general/16846 Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Ann: Progress with IDE
Duncan Coutts wrote: I've seen this occasionally. If you check gtk2hs-confg.h near the bottom of the file you'll likely find something like #def _GLIB_MAJOR_VERSION () rather than #def _GLIB_MAJOR_VERSION (2) It is ./configure that generates the gtk2hs-confg.h from gtk2hs-confg.h.in based on tests in configure.ac. I've never been able to reproduce it and when others have helped me investigate we did not find a solution or indeed a cause. If you'd like to do some digging it'd be much appreciated. I'm cc'ing the gtk2hs-users list just in case someone else has already diagnosed this. I had such (or very similar) problem when I was building gtk2hs on windows. The reasons of not finding the version numbers were problems with carriage return character (CRLF<->LF). Unfortunately I cannot verify this for you since I switched to linux. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GHCi debugger question
Galchin, Vasili wrote: I have a collection of functions .. but no "main" function. I am reading "Step Inside the GHCi debugger" from Monad.Reader Issue 10 by Bernie Pope. If I don't have a "main" function can I still use the ghci debugger? (I tried to set a breakpoint on one of my functions but it didn't work). It does not matter you do not have main function, just start debugging whatever function you have e.g. by: :step ... Setting breakpoints works too without main. Actually, I'm aware only of one thing which does not work without main. It is :main command. But that command does not seem to do much, looks like it only sets program arguments and calls main. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Arch Haskell News: Jan 11 2009
Hi, Any idea why ghc 6.10.1 is still in Testing repository on archlinux? Peter. Don Stewart wrote: Arch Haskell News: Jan 11 2009 <--cut--> ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type question in instance of a class
David Menendez wrote: On Sun, Nov 16, 2008 at 7:09 PM, Luke Palmer <[EMAIL PROTECTED]> wrote: On Sun, Nov 16, 2008 at 5:06 PM, Peter Hercek <[EMAIL PROTECTED]> wrote: ... and the only value the function can return is bottom. Is there any type system which would have more than one value which inhabits all types? Well something like lazy C# might; i.e. every value has a _|_ (nontermination) and null (termination but undefined). For that matter, Control.Exception allows you to distinguish exceptional values from each other. OK, thanks for responses. I'm not sure I understand it well so I try to summarize: Control.Exception is an extension, also it probably cannot catch "error :: String -> a" since the report says so: http://www.haskell.org/onlinereport/exps.html#sect3.1 So Haskell'98 has only one value of all types (the bottom). But Haskell with Control.Exception extension has more values of all types since they can be thrown and later caught and investigated at that place. Maybe the last sentence of section 2.1 (_|_ Bottom) of "Haskell/Denotational semantics" should be clarified better. http://en.wikibooks.org/wiki/Haskell/Denotational_semantics#.E2.8A.A5_Bottom So when trying to use Curry-Howard isomorphism for something in Haskell, one sould be pretty carefull what features of are being used. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type question in instance of a class
Bulat Ziganshin wrote: Hello J., Monday, November 17, 2008, 12:56:02 AM, you wrote: class MyClass r where function :: r -> s As Bulat said, your type signature is equivalent to: function :: forall r s. r -> s only function :: forall s. r -> s (r is fixed in class header) ... and the only value the function can return is bottom. Is there any type system which would have more than one value which inhabits all types? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: mailing list choices?
Did Yahoo & Google groups add support for NNTP yet? In past this did not work. If it still does not work then this would be one reason to prefer something which works with gmane. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell stacktrace
Justin Bailey wrote: 2008/9/9 Pieter Laeremans <[EMAIL PROTECTED]>: What 's the best equivalent haskell approach ? thanks in advance, Pieter The preferred approach is to look at your code, figure out where you are using tail (or could be calling something that uses tail) and use the "trace" function to output logging info. To find the specific tail call: http://haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-options-debugging check the description for option -xc Btw, is there any chance ghci debugger would ever print stack. It would be fine to see it in the same way as it exists when executing code ... I'm not interested in the stack as it would look if the program would not be lazy. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Windows console
Andrew Coppin wrote: (Ignore all references you see to enabling ANSI.SYS in your config.sys file; this applies only to 16-bit MS-DOS programs, *not* to 32-bit Windows programs.) You can add interpretation of ansi escape sequences to any win32 program by launching the application through ansicon: http://www.geocities.com/jadoxa/ansicon/index.html Works on 32 bit windows. Works on 64 bit windows when running a 32 bit application. Does not work for 64 bit application (since 64 bit windows does not allow hooking of win64 api calls IIRC). For support of 32 bit programs on win64 you may need to apply a patch I sent to Jason. He probably did not apply it (he did not respond to my email). Check with me if you want it. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Prototype of a syntax reference
Maurício wrote: • It should show the complete syntax of everything, not the most common. For instance, ‘case of’ should show the use of guards; • It should be an example of valid code, not good one. The idea is to show what can be done, not what should :) This can help you when you will generate all the options. It can also help you when analyzing whether your options are right, or (for example) when looking where are all the places some language construct can be used in. Enable java script for the page and try to click on all the places where you see "hand" cursor: http://www.hck.sk/users/peter/HaskellEx.htm The page above is the one I used when learning Haskell. I'm curious whether you can fit it on one A4 page. Probably depends on font size :) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Documenting the impossible
Andrew Coppin wrote: <-- cut --> When compiled without optimisations, the pragma just causes an exception to be thrown, rather like "error" does. When compiled with optimisations, the whole case alternative is removed, and no code is generated for it. (And if the impossible somehow happens... behaviour is undefined.) So if the compiler optimizes otherwise well you save how much? Something like: * one load from cache (since the next is the pointer which will be needed anyway later and moreover it was created just few insturctions before); almost always should be in L1; so lets say 2 or 3 ticks; moreover this applies only when you do not tag pointers (which can be done for Maybe) * run test instruction on it; 1 tick * conditional jump; should be doable so that it is predicted correctly by default - so you get 1 tick here probably too So you want to save somewhere about 2 to 5 ticks (which with a bit of luck can be shared with other instructions) but you get unsafe execution. Does not sound right to me. There should be other optimizations which can be done and which save more. If it is ever done I hope it will be possible to switch it off. Or the compiler must prove that what I think is impossible is really impossible and then it can do it :-D Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Design your modules for qualified import
Andrew Coppin wrote: Until very recently, it was not at all clear to me that there is actually a very simple solution to this problem: import Text.ParserCombinators.Parsec as P Now I only have to write "P.runPaser", which is much shorter. This fact probably needs to be mentioned more loudly - I'm sure I'm not the only person to have overlooked it... I have one efficient way to find all the needed language features without reading the specification from the start to the end or waiting till my questions get answered. The point is that common sense will indicate you where the required features should be logically located in the language grammar. E.g. if you want something related to imported modules it is logical to check all the alternatives available in import declaration. Then I check the grammar how the production for import declaration (impdelc) looks like (where it can be used etc.). Mostly it is enough sometimes I need to check the language specification since it is not obvious from the grammar. The result is that when I learn a new language the first thing I'm looking for is the formal grammar. Luckily most languages have it available. Some languages (like Haskell) are obsessed with shortcuts and the result is that their grammar is a bit cryptic; others (like VHDL) have it just great - production names clearly indicate what they actually do. On the other side haskell has nice online report :-) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [ANNOUNCE] git-darcs-import 0.1
Aaron Denney wrote: On 2008-06-04, apfelmus <[EMAIL PROTECTED]> wrote: <-- cut --> Or the next->topic path relies on features from next that are not present in master . But then, you're screwed anyway Yep. Well not really, depends what kind the dependency is, this kind of rebase is useful when "topic" depends only syntactically (as you pointed later) on "next" or when the semantic dependency is only on a small part of "next". Git rebase allows you get the syntax or the small part of semantics to the rebased "topic" by asking you for (manual) conflict resolution. This would correspond to commuting darcs patches which depend on each other (again possible by providing manual conflict resolution). Of course this happens only when it was anticipated that upstream merge of "next" happens before "topic", but then the upstream maintainers decided that "topic" should go upstream first. So, not often. and should merge some parts from next into master so as to advance the point where master and next fork. That's one solution. Of course, darcs doesn't have semantic dependency, but syntactic dependency. (You can add extra dependencies to model semantic dependencies, but you can't take away the syntactic dependencies.) Another solution, if there's syntactic, but not semantic dependencies, is to manually use patch and diff to get 90% there, and then cleanup and record. OK, so I think this is what I expected for such a case. Thanks for the explanation of the meaning of "merging patches prior head". Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [ANNOUNCE] git-darcs-import 0.1
Aaron Denney wrote: This is drifting off-topic, but... On 2008-06-03, Peter Hercek <[EMAIL PROTECTED]> wrote: Aaron Denney wrote: <--- cut ---> Darcs patches are pretty much an implicit rebase. You cannot push patch B if it depends on patch A without also pushing A. And darcs currently does not alow you to reorder B before A True. This is a *feature* not a bug. You shouldn't be able to do this automatically, because it can't be done right. You need to do this sort of thing manually. If you don't, the heuristics used will bite you at some point. When they do commute, there is no problem. Sorry, I did not intend to indicate it should be done without doing the reordering first (by providing manual conflict resolution). Git rebase works quite well even in cloned repositories. Meh. It can, if you're really really lucky. Actually you are probably right, I needed to use a non-complicated workaround once (but I did it only about two times!). I might have been just lucky. I liked though that it did tell me what was wrong, in contrast to mercurial queues which just replicated both original branch and the rebased branch (so I finished with two copies on both sides at the end :-( ). <--- cut ---> Rebasing is doable in git as a one-repository operation because each repository has multiple branches. As darcs has one repo per branch, it fundamentally needs to be done in multiple repos. There are naturally two repos, upstream, and your-feature-development. your-feature-development has a patch A that you want to rebase. What you should do is pull upstream into new-tracking, then pull patch A from your-feature-development into new-tracking. If it applies with no problem, great: mv your-feature-development your-feature-development-old; new-tracking your-feature-development. Of course, in this case, you could have just pulled into your-feature-development. If there weren't any other patches to save in the old your-feature-development, you can delete it instead of moving it. When there is a conflict, then you need to handle it somehow. Neither git nor darcs can do it automatically. You can just record the merge conflict and your resolution. This keeps repos that pulled from you valid, but this won't give you the "clean history" that you presumably want. So you need to combine the merger and cleanup into a new patch with the same log message, etc. It's true that git does make *this* process very nice. Ok, in such a simple case darcs can preserve the message too if the repository is not cloned (and you indicated that it does not really work with cloned repositories in git - I'm not an experienced git user). Just pull to the original repository and use amend-record to resolve the conflict and the message will be preserved. So I would tell that for *this* *simple* case darcs is better. But what about this git rebasing option? How to do it more easily (than the solution I know and I described it later) in darcs? using "git-rebase --onto master next topic" to get from: o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic to: o---o---o---o---o master |\ | o'--o'--o' topic \ o---o---o---o---o next This is the reason why I mentioned reordering depending patches AB to BA (with manual conflict resolution) would be needed in darcs to support (I believe a better) alternative to git rebase. I do not know how to do this in darcs (without doing manual addition of "topic" changes with gnu patch utility in a new darcs repository clone which would not have "topic" changes (and "next" changes as well) pulled in and throwing avay the old one at the end). There is one thing that git rebase does easily (and correctly) that darcs doesn't do nicely: rewriting history by merging commits "prior" to the head. I put prior in quotes, because darcs doesn't preserve history in the first place. I don't find that a compelling use, as opposed to maintaing topic branches. I do not know what you mean here. Can you point me to some example? I hope that this is not too off-topic for haskell cafe ... and so far I believe this is not a flame war :-) I just like that Bertram's code exists and I think it (as well as git) should not be dismissed, since AFAIK there is more than performance to git as well as there is more to darcs than it not imposing patch order on us (which is the darcs feature I like). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [ANNOUNCE] git-darcs-import 0.1
Aaron Denney wrote: On 2008-06-03, Peter Hercek <[EMAIL PROTECTED]> wrote: Loup Vaillant wrote: 2008/6/3 Darrin Thompson <[EMAIL PROTECTED]>: <--cut--> What's the appeal of this? I personally love git, but I thought all the cool kids at this school used darcs and that was that. Disclaimer: I'm no expert, this is what I've heard. Anyone please confirm or deny the following? Basically, git is waaay faster than Darcs on a number of use cases. Other reason can be "git rebase". Of course there is a question how good practice it is ... but it is being used. Darcs patches are pretty much an implicit rebase. You cannot push patch B if it depends on patch A without also pushing A. And darcs currently does not alow you to reorder B before A (which is what git rebase actually does). Git rebase works quite well even in cloned repositories. See: http://bugs.darcs.net/issue891 Some discussin about it is also here: http://lists.osuosl.org/pipermail/darcs-users/2008-February/011564.html When the issue is fixed then darcs will be really patch based and will become the ultimate DSCM :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [ANNOUNCE] git-darcs-import 0.1
Loup Vaillant wrote: 2008/6/3 Darrin Thompson <[EMAIL PROTECTED]>: <--cut--> What's the appeal of this? I personally love git, but I thought all the cool kids at this school used darcs and that was that. Disclaimer: I'm no expert, this is what I've heard. Anyone please confirm or deny the following? Basically, git is waaay faster than Darcs on a number of use cases. Other reason can be "git rebase". Of course there is a question how good practice it is ... but it is being used. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Grokking monads by not overlooking concatMap
Achim Schneider wrote: -- That's the one I've been looking for. Remember that -- return e = [e] f = concatMap (\x -> concatMap (\y -> concatMap (\_ -> [(x,y)]) (if x*y == 8 then [()] else [])) [2..8]) [1..4] Morale: Premature term elimination is the root of all misunderstanding. Haskell wins the wickedness of design contest by using [()] and [] as truth values. Maybe you wanted to say: "... by using [()] as True value and [] as False value" ... which does not seem that wicked (at least to me). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Grokking monads by not overlooking concatMap
Achim Schneider wrote:
Peter Hercek <[EMAIL PROTECTED]> wrote:
Haskell wins the wickedness of design contest by using [()] and []
as truth values.
Maybe you wanted to say: "... by using [()] as True value and [] as
False value" ... which does not seem that wicked (at least to me).
Strangely enough, it reads exactly the same to me. IMHO, not working
like filter is the thing that makes this wicked: guard doesn't care
about what is returned, you could as well say (\_ -> [("foo","bar")])
Right, should be a list with one element in it to represent True.
So maybe it is a bit worse than C since list with two elements
gives you two True values :-D
On the other side it is nice that guard works the expected way
(using the same implementation) with other MonadPlus-es too.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Grokking monads by not overlooking concatMap
Peter Hercek wrote: Achim Schneider wrote: Haskell wins the wickedness of design contest by using [()] and [] as truth values. Maybe you wanted to say: "... by using [()] as True value and [] as False value" ... which does not seem that wicked (at least to me). Oops sorry, missed you say "truth" and not "true" :-D Still not more wicked as 0 meaning False and non-zero meaning True in C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GC'ing file handles and other resources
Abhay Parvate wrote: I am not saying that it should claim it as soon as it is unused; all I am saying that as soon as a priority object becomes unreferenced, it should be the first choice for collecting in the next collect. Further I was under the impression (I may be wrong) that it uses a generational GC and therefore scans allocated memory incrementally; not the whole at a time. Please correct me if I am wrong. It would be hard to separate memory collection from handle collection. But what could be done is start GC not only when memory consumption reaches some threshold but also when handle consumption reaches some (other) threshold. I'm curious whether it would work :-) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ghc
Cetin Sert wrote: Is GHC required to be installed on the target OS I compile Haskell binaries for in order for these binaries to run? I need a quick answer on that! No. Well possibly yes if you use GHC api (e.g. for compiling a haskel code from your haskell application) but for common applications it is not required. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Doing without IORef
Jinwoo Lee wrote: Is there any way in which I can do without IORef in tabHandler and commandLoop (written in red and bold, if you can see)? You could just always redefine the key binding for \t with a new closure which contains the updated "pwd" value (or the whole state if you like it more that way). I suppose readline supports key binding redefinition (???). But I do not think I like it more that IORef, I rather use IORefs with imperative interfaces :-) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why functional programming matters
Tim Chevalier wrote: On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote: Other things did not seem that great for me from the beginning. For example: referential transparency - just enforces what you can take care not to do yourself ...if you never make mistakes, that is. (e.g. in C# you just cannot be sure some function is referentially transparent even when comment claims so - which of course sucks because programmers are not disciplined). But if that's the point you're trying to make, I agree that a lot of programmers seem to think they don't make mistakes, and thus might not be receptive to the siren song of referential transparency :-) What I wanted to say is that focusing on referential transparency will not appeal that much to an imperative programmer especially when he needs to overcome Haskell learning curve. What may appeal, though, are the consequences of it like: * easier to repeat test cases for bugs * easier to do automated tests (like quickcheck) since state space is not that big (provided I count automatic vars on stack/heap as state) * makes laziness to work which allow easier and efficient expression of producer - consumer type of code * easy undo (no need for memento pattern etc) * allows monads to work which adds options like built-in user logging or error recovery * better changes for compilers to find parallelize automatically * safe STM ... and probably a lot of more goodies On the other side there are downsides like what to do instead of reactive GUIs? GUI is a big part for a lot of applications. A lot of efficient algorithms we have are state based. And again probably more. If referential transparency by itself would be that important for imperative languages then it would be already added to IDEs* in some form like a popup menu item with name "check function purity". In some cases you could actually decide that the function is pure (especially if you would go deeper analyzing and annotating your objects with purity flags in your IDE). * and IDEs like visual studio or eclipse are incredibly good compared to the stuff Haskell has; anyway IMHO all IDEs are not good enough - they could be much better Anyway I'm not that qualified to discuss this (I hope this is my last post to this thread :) ). I just wanted to point out what could be a point of view of an imperative programmer based on what I remember from times I was getting more involved with functional programming. The reason I started with functional programming is sure not common - sometimes I may need to actually prove some program features. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why functional programming matters
Here are things I liked most (compared with standard imperative languages) when I started to learn functional programming: * algebraic types with pattern matching work nicely as "tagged unions"; doing a tagged union manually in C/C++/C# is a pain (there is no automatic tag (provided you dismiss rtti over objects)) * lambda expressions, lexical scoping, closures; doing this in C++ is just incredible amount of typing; it is a bit better in C# but still not good enough I happen to have nice examples of code like: map (\x->x*2) [1,2,3] -- but with an array in C/C++/ML/C#. Each written as natively as possible. They are attached. Other things did not seem that great for me from the beginning. For example: referential transparency - just enforces what you can take care not to do yourself (e.g. in C# you just cannot be sure some function is referentially transparent even when comment claims so - which of course sucks because programmers are not disciplined). Or another example: nontrivial higher order functions looked more damaging than helping because understanding usage/interactions is harder. Not mentioning monads (user level understanding of uniqueness typing with all the annotations is easier than monads). I found ML/Clean/Haskell much more appealing than the common imperative languages an even Prolog (with which I could produce usably quick code only after actually using intimate knowledge of the inference and sprinkling cuts around, but that does not feel declarative to me any more then). Peter. functions_as_values.tgz Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] bug in all about monads tutorial
Hi, About 3 weeks ago I reported this bug to Jeff Newbern. But I got no response - maybe I got filtered out as spam :) Since it was not fixed I'm trying once more here. Maybe there is somebody here who has access to the web site http://www.haskell.org/all_about_monads and cares enough to fix it. On page http://www.haskell.org/all_about_monads/html/writermonad.html there is "listens" defined like this: listens f m = do (a,w) <- m; return (a,f w) ... but it should be like this: listens f m = do (a,w) <- listen m; return (a,f w) ... or maybe a less strict option (as ghc libs have it): listens f m = do ~(a,w) <- listen m; return (a,f w) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: US Homeland Security program language security risks
Mads Lindstrøm wrote: Andrew Coppin wrote: Human kind has yet to design a programming language which eliminates all possible bugs. ;-) And we never will. See http://en.wikipedia.org/wiki/Halting_problem . If you limit usage of general recursion (and rather favor structural recursion) then you can mitigate the halting problem. But there always will be specification bugs (when one implenetes something else than what was needed). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Basic question concerning data constructors
Joost Behrends wrote: We read data Pair a b = Pair a b in YetAnotherHaskellTutorial. And that is all ! If we omit "data" here, this would be a silly pleonasm. And no single word about this strange behavior of "data" in every tutorial i read. When learning a language, I find it useful to consult grammar to find out the relevant part of the syntax; then I can check the Haskell online report for explanations. For example you presented: ... searching for data in http://www.hck.sk/users/peter/HaskellEx.htm ... gives you http://www.hck.sk/users/peter/HaskellEx.htm#topdecl ... and from there you can quickly find relevant part of Haskel report: http://www.haskell.org/onlinereport/decls.html#sect4.2.1 Haskell has a nice html specification online (thanks for it!). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
Luke Palmer wrote: There was a thread about this recently. In any case, if you load the code interpreted (which happens if there is no .o or .hi file of the module lying around), then you can look inside all you want. But if it loads compiled, then you only have access to the exported symbols. The reason is because of inlining optimizations; you know about the encapsulation of the module when you compile it, and you can optimize the memory and code usage based on compiling functions that are not exported differently. That's my weak understanding, at least. Luke Great. Cleaning before loading into ghci works. Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OOP'er with (hopefully) trivial questions.....
Thomas Davie wrote: Take a look at the Typable class. Although, pretty much any code that you can compile can be loaded into ghci without modification, and that's by far the easier way of finding the types of things. Is there a way to make ghci to know also the symbols which are not exported? My problem is that :t reports undefined. Is there a way to make :t working without first exporting and then reloading the module in ghci and asking with :t again? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: #haskell works
Tim Chevalier wrote: On 12/15/07, Peter Hercek <[EMAIL PROTECTED]> wrote: Tim Chevalier wrote: Try the -Rghc-timing flag. Interesting, that one does not work in my program compiled with ghc 6.8.1 (looks like ghc runtime does not consume it but passes it to my haskell code). +RTS -tstderr works but its usability is limited since it provides only elapsed time and not the process cpu times. Sorry, my mistake -- it's an RTS option, so: ./program +RTS -Rghc-timing -RTS and I guess you have to compile with -prof. I guess it is just buggy in 6.8.1. That option does not seem to work, not even as an RTS option and even when I compile with "-prof -auto-all". But the user guide states that the result should be the same as with "+RTS -tstderr" and if so then it is not that interesting (since cpu times are missing). Btw, "+RTS -tstderr" works without -prof too, which is nice :) I liked the idea that ghc generated exe can report its times too (I meant also cpu times and not only the elapsed time) but external programs work well for this too, so never mind. Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: #haskell works
Tim Chevalier wrote: Try the -Rghc-timing flag. Interesting, that one does not work in my program compiled with ghc 6.8.1 (looks like ghc runtime does not consume it but passes it to my haskell code). +RTS -tstderr works but its usability is limited since it provides only elapsed time and not the process cpu times. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: #haskell works
Andrew Coppin wrote: (I suppose I could try writing a nop program and timing it. But personally I don't have any way of timing things to that degree of accuracy. I understand there are command line tools on Unix that will do it, but not here.) You can try for example this one http://www.pc-tools.net/win32/ptime/ to measure times better on windows. I tried the above prg few years ago and it seemed to work. If you do not mind installing cygwin then you can get time command from it. The only problem is that both ptime and cygwin time do not add times of child processes to the result. Unix tools do that by default (since child accounting info is added to parent process if the child is waited for). If you want to add children time to your result you probably need to write your own utility for win32 timing. It should be something like 100 lines of C code. See QueryInformationJobObject win32 api function to start. I know only one commercial tool which can take children time into account on windows. If you would write it and decide to release it under a free license, let me know :) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Annoying (windows only?) related GHCi "problem"?
Peter Verswyvelen wrote: When I start a windowed program (e.g. GLUT or GTK2Hs) from within GHCi, my application’s window does not become the foreground window. Is this on purpose? This is just a guess, I do not really know :-) Maybe your problem is focus stealing prevention, which is a feature of windows OS. well, provided that you have the problem on ms windows. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Building Haskell stuff on Windows
Simon Peyton-Jones wrote: | > Windows and Haskell is not a well travelled route, but if you stray of | > the cuddly installer packages, it gets even worse. | | But it shouldn't. Really it shouldn't. Even though Windows is not my | preferred platform, it is by no means different enough to warrant such | additional complexity. Plus, GHC is developed at Microsoft, and the | currently most featureful Haskell IDE is on Windows... We build GHC on Windows every day. I use MSYS with no trouble. Are there any reasons to use mingw+msys instead of mingw+cygwin? Last time I needed a quick build of gtk2hs (summer of this year?), I run in so many problems with msys (too old versions of tools in it) that I rather patched gtk2hs build system to make it work with cygwin. Well this may not be an issue any more since I see a newer version of msys is available from September. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why can't Haskell be faster?
The site claims it is quite up to date: about Haskell GHC The Glorious Glasgow Haskell Compilation System, version 6.6 Examples are compiled mostly in the middle of this year and at least -O was used. Each test has a log available. They are good at documenting what they do. Peter. Peter Verswyvelen wrote: Are these benchmarks still up-to-date? When I started learning FP, I had to choose between Haskell and Clean, so I made a couple of little programs in both. GHC 6.6.1 with -O was faster in most cases, sometimes a lot faster... I don't have the source code anymore, but it was based on the book "The Haskell road to math & logic". However, the Clean compiler itself is really fast, which is nice, it reminds me to the feeling I had with Turbo Pascal under DOS :-) I find GHC rather slow in compilation. But that is another topic of course. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why can't Haskell be faster?
Add to that better unbox / box annotations, this may make even bigger difference than the strictness stuff because it allows you to avoid a lot of indirect references do data. Anyway, if Haskell would do some kind of whole program analyzes and transformations it probably can mitigate all the problems to a certain degree. So the slowness of Haskell (compared to Clean) is consequence of its type system. OK, I'll stop, I did not write Clean nor Haskell optimizers or stuff like that :-D Peter. Peter Hercek wrote: I'm curious what experts think too. So far I just guess it is because of clean type system getting better hints for optimizations: * it is easy to mark stuff strict (even in function signatures etc), so it is possible to save on unnecessary CAF creations * uniqueness types allow to do in-place modifications (instead of creating a copy of an object on heap and modifying the copy), so you save GC time and also improve cache hit performance Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why can't Haskell be faster?
I'm curious what experts think too. So far I just guess it is because of clean type system getting better hints for optimizations: * it is easy to mark stuff strict (even in function signatures etc), so it is possible to save on unnecessary CAF creations * uniqueness types allow to do in-place modifications (instead of creating a copy of an object on heap and modifying the copy), so you save GC time and also improve cache hit performance Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
OK, if somebody wants to speculate (and if it even makes sense for
such a microbenchmark) here are some more data.
Except different OS and C++ compiler also processor is different.
On my side it was AMD Athlon 64 X2 4800+ (2.4GHz, 2x1MiB L2 cache
non-shared; C&Q was not switched off during the test). The system has
2GiB RAM. The C++ version had working set about 1.7 MiB, ghc version
had it about 2 times bigger.
Peter.
Dusan Kolar wrote:
Hello all,
just to compare the stuff, I get quite other results being on other OS.
Thus, the result of C++ compiler may not be that interesting as I do not
have the one presented below.
My machine:
Linux 2.6.23-ARCH #1 SMP PREEMPT Mon Oct 22 12:50:26 CEST 2007 x86_64
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
Compilers:
g++ --version
g++ (GCC) 4.2.2
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6.1
Measurement:
compiled with ghc -O2
time ./mainInteger
real0m4.866s
user0m4.843s
sys 0m0.020s
compiled with ghc -O2
time ./mainInt64
real0m2.213s
user0m2.210s
sys 0m0.003s
compiled with ghc -O2
time ./mainInt
real0m1.149s
user0m1.143s
sys 0m0.003s
compiled with g++ -O3
time ./mainC
real0m0.271s
user0m0.270s
sys 0m0.000s
I don't know what is the reason, but the difference between Int, Int64
and Integer is not that dramatic as in example below, nevertheless, the
difference between GHC and GNU C++ is very bad :-\
Dusan
Peter Hercek wrote:
Derek Elkins wrote:
Try with rem instead of mod.
(What the heck is with bottom?)
The bottom was there by error and I was lazy to redo
the tests so I rather posted exactly what I was
doing. I do not know the compiler that good to be
absolutely sure it cannot have impact on result
... so I rather did not doctor what I did :-)
Ok, rem did help quite a bit. Any comments why it is so?
Here are summary of results for those interested. I run
all the tests once again. Haskell was about 13% slower
than C++.
MS cl.exe options: /Ox /G7 /MD
ghc options: -O2
C++ version: 1.000; 0.984; 0.984
Haskell version specialized to Int: 1.125; 1.125; 1.109
Haskell version specialized to Integer: 8.781; 8.813; 8.813
Haskell version specialized to Int64: 9.781; 9.766; 9.831
The code:
% cat b.hs
module Main (divisors, perfect, main) where
import Data.Int
divisors :: Int -> [Int]
divisors i = [j | j<-[1..i-1], i `rem` j == 0]
perfect :: [Int]
perfect = [i | i<-[1..1], i == sum (divisors i)]
main = print perfect
% cat b.cpp
#include
using namespace std;
int main() {
for (int i = 1; i <= 1; i++) {
int sum = 0;
for (int j = 1; j < i; j++)
if (i % j == 0)
sum += j;
if (sum == i)
cout << i << " ";
}
return 0;
}
%
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Rodrigo Queiro wrote: Why do you expose perfect and divisors? Maybe if you just expose main, perfect and divisors will be inlined (although this will only save 10,000 function entries, so will probably have negligible effect). I exposed them so that I can check types in ghci. Hiding them does not seem to have noticeable effect. Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Derek Elkins wrote:
Try with rem instead of mod.
(What the heck is with bottom?)
The bottom was there by error and I was lazy to redo
the tests so I rather posted exactly what I was
doing. I do not know the compiler that good to be
absolutely sure it cannot have impact on result
... so I rather did not doctor what I did :-)
Ok, rem did help quite a bit. Any comments why it is so?
Here are summary of results for those interested. I run
all the tests once again. Haskell was about 13% slower
than C++.
MS cl.exe options: /Ox /G7 /MD
ghc options: -O2
C++ version: 1.000; 0.984; 0.984
Haskell version specialized to Int: 1.125; 1.125; 1.109
Haskell version specialized to Integer: 8.781; 8.813; 8.813
Haskell version specialized to Int64: 9.781; 9.766; 9.831
The code:
% cat b.hs
module Main (divisors, perfect, main) where
import Data.Int
divisors :: Int -> [Int]
divisors i = [j | j<-[1..i-1], i `rem` j == 0]
perfect :: [Int]
perfect = [i | i<-[1..1], i == sum (divisors i)]
main = print perfect
% cat b.cpp
#include
using namespace std;
int main() {
for (int i = 1; i <= 1; i++) {
int sum = 0;
for (int j = 1; j < i; j++)
if (i % j == 0)
sum += j;
if (sum == i)
cout << i << " ";
}
return 0;
}
%
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Don Stewart wrote: perfect :: [Int] perfect = [i | i<-[1..1], i == sum (divisors i)] This should be a little faster , as sum will fuse, perfect :: [Int] perfect = [i | i<-[1..1], i == sum' (divisors i)] where sum' = foldr (+) 0 sum' did not help. Times are about the same with Int type. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Peter Hercek wrote: MS cl.exe version 13.10.3077 (options /G7 /MD) And I had cl options wrong too - I need to start to optimize not only to set the optimization target. /G7 /MD -> 1.109; 1.125; 1.125 /Ox /G7 /MD -> 0.922; 0.984; 0.984 Still it does not change the results too much. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Don Stewart wrote:
C++ version times: 1.109; 1.125; 1.125
Int32 cpu times: 1.359; 1.359; 1.375
Int64 cpu times: 11.688; 11.719; 11.766
Integer cpu times: 9.719; 9.703; 9.703
Great result from ghc.
What Haskell program were you using for this test? The original
naive/high level implementation?
-- Don
Here it is (I played only with the types for divisors and perfect;
bottom is there from my previous tests, but it should not matter):
<---cut--->
module Main (bottom, divisors, perfect, main) where
import Data.Int
bottom = error "_|_"
divisors :: Int -> [Int]
divisors i = [j | j<-[1..i-1], i `mod` j == 0]
perfect :: [Int]
perfect = [i | i<-[1..1], i == sum (divisors i)]
main = print perfect
<---cut--->
and here is the C++ version:
<---cut--->
#include
using namespace std;
int main() {
for (int i = 1; i <= 1; i++) {
int sum = 0;
for (int j = 1; j < i; j++)
if (i % j == 0)
sum += j;
if (sum == i)
cout << i << " ";
}
return 0;
}
<---cut--->
OS winxp 64 bit
ghc v. 6.6.1 (optins -O2)
MS cl.exe version 13.10.3077 (options /G7 /MD)
Peter.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Peter Hercek wrote: C++ version times: 1.125; 1.109; 1.125 Int32 cpu times: 3.203; 3.172; 3.172 Int64 cpu times: 11.734; 11.797; 11.844 Integer cpu times: 9.609; 9.609; 9.500 Ooops, my results ware wrong (nonoptimizing ms cl compiler used and I used -O instead of -O2 in ghc). C++ version times: 1.109; 1.125; 1.125 Int32 cpu times: 1.359; 1.359; 1.375 Int64 cpu times: 11.688; 11.719; 11.766 Integer cpu times: 9.719; 9.703; 9.703 Great result from ghc. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: newbie optimization question
Daniel Fischer wrote: What perpetually puzzles me is that in C long long int has very good performance, *much* faster than gmp, in Haskell, on my computer, Int64 is hardly faster than Integer. I tried the example with Int64 and Integer. The integer version was actually quicker ... which is the reason I decided to post the results. C++ version times: 1.125; 1.109; 1.125 Int32 cpu times: 3.203; 3.172; 3.172 Int64 cpu times: 11.734; 11.797; 11.844 Integer cpu times: 9.609; 9.609; 9.500 Interesting that Int64 is *slower* than Integer. On the other side the C version is not that much quicker. I guess the Haskell version is using generic versions of mod and sum (since they are from a library) which would mean indirect calls. The Haskell version probably also creates the list nodes ... even when they get almost immediately garbage collected. Thanks for pointing out Int64 sucks so much :) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Existential types (Was: Type vs TypeClass duality)
apfelmus wrote: -+- Since ∀ and ∃ are clearly different, why does Haskell have only one of them and even uses ∀ to declare existential types? The answer is the following relation: ∃a.(a -> a) = ∀b. (∀a.(a -> a) -> b) -> b So, how to compute a value b from an existential type ∃a.(a -> a)? Well, we have to use a function ∀a.(a -> a) -> b that works for any input type (a -> a) since we don't know which one it will be. More generally, we have ∃a.(f a)= ∀b. (∀a.(f a) -> b) -> b Is that by definition or (if it a consequence of the previous formula, is that one by definition)? Because it kind of makes sense but that does not mean much. If the formulas are not by defininition, any pointers to explanation why they are valid? Why it is not only like this? ∃a.(f a)= ∀b. (∀a.(f a) -> b) - Exercise 2: ∀ can be lifted along function arrows, whereas ∃ can't. Explain why String -> ∀a.a = ∀a.String -> a String -> ∃a.a =/= ∃a.String -> a Since ∀ can always be lifted to the top, we usually don't write it explicitly in Haskell. I do not see why forall can be lifted to the top of function arrows. I probably do not understand the notation at all. They all seem to be different to me. String -> ∀a.a a function which takes strings a returns a value of all types together for any input string (so only bottom could be the return value?) ∀a.(String -> a) a function which takes strings and returns a values of a type we want to be returned (whichever one it is; in given contexts the return value type is the same for all input strings) String -> ∃a.a a function taking strings and returning values of some type but we do not know anything about the type (in the same contexts and for each different input string the output type can be different) ∃a.(String -> a) a function taking strings and returning values of some type; for each different input string there is the same output type Any pointers to explanations? Thanks for one of the more informative posts on this subject. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Yes, htmls are better than pdfs (more lightweight, easier to work with if exact page layout is not important). I just wanted to point out that it is possible to link into some particular place of a pdf document. So the linking availability should not be the argument by itself. I would prefer html too but if pdf is required otherwise, it would be nice if link suppliers would provide more precise links. To spread the information that they can do so is the main reason I responded. Peter. Jon Fairbairn wrote: Peter Hercek <[EMAIL PROTECTED]> writes: Jon Fairbairn wrote: > A hyperlink of the form href="http://.../long-research-paper.html#interesting-paragraph";> interesting bit is far more useful than one of the form http://.../long-research-paper.pdf";>look for section 49.7.3. It may not seem significant, but when one is attempting to learn some new part of Haskell it's really off-putting. Pdfs are not that bad. No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? The above definitely works OK on windows, not sure about linux pdf viewers. Works perfectly on my Fedora 7 systems. While this would be a definite improvement over having to search through the pdf, the delay and the fact that pdfs aren't as good as html for on-line viewing are still enough of an overhead that it's discouraging. If I'm using PHP (an execrable language), I can type the name (or something like the name) of any function into the search box on the PHP manual webpage and get useful (albeit often extremely irritating from a Haskell programmer's point of view) results straight back. Even including my language designer's distaste for PHP, this can make writing a wee bit of PHP a less onerous event than writing the same thing in Haskell -- definitely not what we want! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Polymorphic (typeclass) values in a list?
Brandon S. Allbery KF8NH wrote: On Oct 19, 2007, at 12:11 , Sebastian Sylvan wrote: On 19/10/2007, Kalman Noel <[EMAIL PROTECTED]> wrote: data ExistsNumber = forall a. Num a => Number a I'm without a Haskell compiler, but shouldn't that be "exists a."? The problem is that "exists" is not valid in either Haskell 98 or any current extension, whereas "forall" is a very common extension. But you can simulate "exists" via "forall", which is the thrust of these approaches. When 'exists' is not a keyword, why 'forall' is needed at all? Isn't everything 'forall' qualified by default? ... or are type variables sometimes 'exists' qualified by default depending on context? That would be confusing though... I do not understand why 'forall' keyword is needed. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Jon Fairbairn wrote: > A hyperlink of the form href="http://.../long-research-paper.html#interesting-paragraph";> interesting bit is far more useful than one of the form http://.../long-research-paper.pdf";>look for section 49.7.3. It may not seem significant, but when one is attempting to learn some new part of Haskell it's really off-putting. Pdfs are not that bad. You can hyper link into them too. It would look like: http://.../long-research-paper.pdf#page=45";> ... to open the pdf a position you on page 45 of it or like: http://.../long-research-paper.pdf#anchorName";> ... to open the pdf and position you on anchor anchorName You can do it from command line too: acrord32 /A page=45 long-research-paper.pdf acrord32 /A anchorName long-research-paper.pdf This of course requires the source to give you more precise link. But here there is no difference from html only ... possibly ... more people know about html linking than pdf linking. The above definitely works OK on windows, not sure about linux pdf viewers. Unfortunately I cannot find now how you can look at all anchors defined in a pdf (so that you can use something better than page=). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell89 grammar extended with links to online report
Hi, I extended the hyperlinked Haskell 98 grammar so that each production now contains also links to all the sections in the online report which explicitly name it. I needed it few times myself so I added it. Some people expressed interest so they may want to check out the update. Javascript must be enabled to have the links functional (both the backward links from a production head to all the usages and also the links to the online report). Here it is: http://www.hck.sk/users/peter/HaskellEx.htm Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Space and time leaks
Ronald Guida wrote: Now for the hard questions. 1. How do I go about detecting space and time leaks? 2. Once I find a leak, how do I fix it? 3. Are there any programming techniques I can use to avoid leaks? I'm hard time to believe I'll write something you do not know but I had similar problem and it was not hard to fix (despite some stories that it is very hard in Haskell). If you use ghc then skim over this, otherwise do not mind. Check also GHC User Guide. The options are described, well not very well but better than nothing. add 1) Here are few options I found most useful. compile with: -prof -auto-all run with: +RTS -p -hc -RTS ... to see what functions are creating leaks and which functions take the most time. Check out the .prof and .hp (the numbers in .hp correspond to stack traces in .prof (the no. column)). run with: +RTS -hr -RTS ... to see what is still keeping references to your data The stack traces corresponding to the numbers in .hp are in .prof. The stuff which is keeping the references are typically the routines which are creating closures and pass them around in their results instead of forcing computation and returning the processed data (which are hopefully much smaller than the input data processed). run with: +RTS -s +RTS ... and check your .stat to see if your time problem is not actually a space problem leading to very poor GC performance. use hp2ps to look at the .hp files add 2) Add ! to your data types at places from the result data structure to the final/leaf data structures which will keep the processed data. This is provided you do not need laziness on some places. If you do (e.g. so that you do not compute data fields which are not mostly used or when you actually require it for efficient processing (like foldr with function nonstrict in second arg)) then you need to use seq or preferably $! on the code paths which need to be strict and leave the rest of code paths lazy. Idea is that you need strictness somewhere so that your huge input data are compacted to the small output data on the fly instead at the very end when you ask for some result. add 3) There is something on the haskell wiki. Search for stack overflow and something about tail recursion and when it is a "red herring". I just looked for the data with google and there is enough of them. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GHC 6.7 on Windows / containers-0.1 package?
Stefan O'Rear wrote: You said 0% CPU. That's *very* important. It means that you are using the threaded runtime (GHCi?), and that you triggered a blackhole. You should be able to handle this by compiling your program with -prof (do *not* use -threaded!), and running with +RTS -xc. With luck, that will give you a backtrace to the infinite loop. PS. blackholes are a serious dark corner of GHC's execution model, chances are better than even that if you try to use the debugger for this you will discover a new and (for you) crippling bug. I wouldn't recommend it. Hi Stefan, I do not understand. Do you mean you would not recommend to try the debugger to check this problem? I had something which looked similar but the problem was that my gui (gkt2hs) application is also printing to console and there was an active selection in the console, so the printing was suspended :-) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: let and fixed point operator
Jules Bean wrote: I have no idea what you're talking about. It works fine on multiple lines: f x = g . transform displacement . scale factor $ x is perfectly valid. Yes, it is. It is not an issue if you prefer to indent based on previous line instead of "always by the same small amount of spaces". And then problem happens when the amount of spaces is less than 5. E.g. this does not work: h x = x f x = let g x = h . (+ 5) . (* 2) $ x in g x I do not like to indent based on previous lines since it should be re-indented when the previous lines change (e.g. because of identifier rename). So I indent based on previous lines only when it adds a LOT to readability. Of course fixed amount indentation by big enough number of spaces would do but then your code gets too wide if more blocks are nested and I like to be withing 110 chars at worst (preferably 80). This is probably not a problem for "where" keyword then the next longest from the "let", "where", "do", "of" set is "let" which would mean that 5 should be enough, not that bad, but looks much for me. Other option is to leave "let" keyword alone on the line and then indent "g x" by one and the function body by two indentation units from the "let" keyword. So from my point of view the point free style is great if it fits on one line well ... otherwise it depends. Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: let and fixed point operator
Chaddaï Fouché wrote: But, even more trivial... You use this all the time when you define recursive function, you know ? You would need to add a "rec" keyword to the language if you disallowed this. Great and new reason too. Trying to make a difference based on presence of formal argument would be bad since point-free is useful too. Well, in my opinion, only to a certain degree since from some point on it is more understandable to name intermediate results (points). Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: let and fixed point operator
Derek Elkins wrote: On Thu, 2007-08-30 at 18:17 +0200, Peter Hercek wrote: Hi, I find the feature that the construct "let x = f x in expr" assigns fixed point of f to x annoying. The reason is that I can not simply chain mofifications a variable like e.g. this: f x = let x = x * scale in let x = x + transform in g x The common answer is that such code is considered ugly in most circumstances. Nevertheless, one solution would be to use the Identity monad and write that as, f x = runIdentity $ do x <- x*scale x <- x + transform return (g x) This is nice but more complicated. The goal should be to have it as simple as possible. Haskell is lazy, we can have (mutually) recursive values. The canonical example, fibs = 0:1:zipWith (+) fibs (tail fibs) Slightly more interesting, karplusStrong = y where y = map (\x -> 1-2*x) (take 50 (randoms (mkStdGen 1))) ++ zipWith (\x y -> (x+y)/2) y (tail y) This is very nice argument! Thanks. I actually used it myself, but did not realize it when I was looking for the pro/contra arguments. This with the fact that it is not that good style to use the same name for intermediate results might be worth it. However, the real point is that you shouldn't be naming and renaming the "same" thing. Going back to your original example, it would be nicer to most to write it as, f = g . transform displacement . scale factor or pointfully f x = g (transform displacement (scale factor x)) with the appropriate combinators. Essentially the same idea as the one from Brent Yorgey. Works fine till the operations can fill easily on one line. Then it does not scale that well since when it needs to be on more lines it interferes with automatic insertion of curly braces and semicolons by the layout rules (which are influenced by the context). Of course when there are more transformations it makes sense to name the intermediate results differently, but even few transformations may not fit easily when identifier names are long. Thanks, Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: let and fixed point operator
1 f x = 2let x = x * scale in 3g x Hmmm ... just assume that the scope of the x on line 3 (which hides the x from the higher level scope is extended from line 3 to the beginning part of line 2 (from line start to the equal sign). OCAML does it. "Let before" in Clean does it too. Does not sound bad to me either. So this sounds to me like weak argument compared to disadvantages. There should be something else (I'm missing) there too... Thanks, Peter. Dan Piponi wrote: On 8/30/07, Peter Hercek <[EMAIL PROTECTED]> wrote: f x = let x = x * scale in let x = x + transform in g x Why are you trying to call three different things by the same name 'x' in one tiny block of code? That's very confusing and makes it hard to reason equationally about the code. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] let and fixed point operator
Hi, I find the feature that the construct "let x = f x in expr" assigns fixed point of f to x annoying. The reason is that I can not simply chain mofifications a variable like e.g. this: f x = let x = x * scale in let x = x + transform in g x When one is lucky then it results in a compile error; in worse cases it results in stack overflow in runtime. The annoying part is figuring out new and new variable names for essentially the same thing to avoid the search/evaluation of the fixed point. I suppose Haskell was designed so that it makes sense. The only usage I can see is like this: let fact = \x -> if x == 0 then 1 else x * fact (x-1) in ... but that is not any shorter than: let fact x = if x == 0 then 1 else x * fact (x-1) in So the question is what am I missing? Any nice use cases where fixed point search is so good that it is worth the trouble with figuring out new and new variable names for essentially the same stuff? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: hyperlinked haskell 98 grammar
Hi Neil, For haskell-cafe members: This is what we are talking about: http://www.hck.sk/users/peter/ I'm glad somebody liked it. I do not understand what you mean by the extension request. Would you want to see the number of references of a production head even without opening the popup list box? If you meant that the pop-up list box should always display all backward links directly (without a scroll bar) then it would not work for a very big number of such links (in theory there can be hundreds there). If you do not like the default of 5 then change the nMaxRowCount "constant". Anyway, if it is complicated to describe, let it be. I do not expect to play with the java script code much. Only the most trivial things have a chance to be implemented by me. I have written the java script code few years ago and I do not really like java script ... Just wanted to give back something to the community - so I added the Haskell specific data. As for as putting it on the Haskell org I do not mind if somebody else does it. Although I'm not that sure if it would require license change. If I would believe giving it into public domain would make more grammars browsable like this one then I would do it. I do not really expect heavy loads. From my experience most language users never ever look at the grammar nor they care about it. And those who consult it a lot will take a local copy and tweak it anyway. Looking at the munin server loads, looks like you and Esa are the only ones who actually checked it out :-D Anyway, sending this to haskell cafe too (as recommended). I expect a discussion (if any) will continue there. Sorry about GHC user list abuse. Peter Hercek. Neil Mitchell wrote: Hi In addition, perhaps this should be relocated to haskell.org, if your server is not suitable for a large volume of users. I think it should also be integrated somewhere (perhaps a link from the HTML report, and certainly on the wiki) Thanks Neil On 8/16/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: Hi Peter, A nice application. One suggestion: I would have implemented it so that a maximum on one backward hyperlink menu could be visible at once - try clicking on two RHS's and you'll get too "menus" visible at the same time. You also might want to mail this out on haskell-cafe - which is more appropriate for "general haskell" things, ghc-users is more for direct issues with GHC (although haskell-cafe can also be used for those) Thanks Neil On 8/16/07, Peter Hercek <[EMAIL PROTECTED]> wrote: Hi, I was improving my Haskell knowledge lately and I created a small dhtml application which allows browsing of Haskell 98 grammar. I contains both forward and backward hyperlinks. By backward hyperlink I mean that you can click on an a production head and you get a popup list box where you can navigate to any production using the nonterminal. If you like it please save and use your local copy since the server cannot handle much load. http://www.hck.sk/users/peter/ Peter. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
