Re: [Haskell-cafe] Logo
Ashley Yakeley wrote: I rather like the fact that the Haskell Platform logo is distinct from the Haskell logo. I think it helps prevent confusion (even though the Platform logo is based on one of the Haskell logo competition entrants). http://haskell.org/haskellwiki/Haskell_Platform Well, I disagree. Even though I do not like the new haskell logo, I prefer consistency. I like the black/gold version proposed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Jochem Berndsen schrieb: Deniz Dogan wrote: 2009/6/13 Jochem Berndsen joc...@functor.nl: Keith Sheppard wrote: Is there any reason that sum isn't strict? I can't think of any case where that is a good thing. Prelude sum [0 .. 100] *** Exception: stack overflow It is useful if the (+) is nonstrict; although I cannot think of any useful mathematical structure where (+) would be nonstrict. I remember needing a non-strict sum at least once, but I do not remember the exact application. But imagine having a (very) long list of numbers and you want to do A if the sum exceeds a small number, otherwise B. if sum [0..10] 10 then A else B However, this idea didn't work, because of strictness. You can only do such things if you know that all entries of your list are nonnegative. That requires a custom solution anyway (not to mention the fact that to determine whether x 10 or not, we need to explicitly compute x). http://hackage.haskell.org/packages/archive/non-negative/0.0.5/doc/html/Numeric-NonNegative-Chunky.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Logo
Hey all, On 15 jun 2009, at 08:39, Ashley Yakeley wrote: Thomas Davie wrote: We had a lot of fun deciding Haskell's new logo, and while I don't agree with the final result, it would be nice if we could now start consistently using it. With that in mind, I realised that the Haskell Platform's logo is totally different, and did a quick mock up of a version reflecting the current Haskell logo. It needs someone with the original vector graphics to have a play and improve it a little bit, but hopefully you'll se a concept you like. I rather like the fact that the Haskell Platform logo is distinct from the Haskell logo. I think it helps prevent confusion (even though the Platform logo is based on one of the Haskell logo competition entrants). For new users, when they install Haskell they will install the Haskell Platform. I don't think we need to have a big distinction between that. Therefore, I think that the Haskell Platform should share the Haskell logo. I think the Haskell platform is an excellent name for internal communication, but to the outside world, it *is* Haskell. This is what you get when you install Haskell. Otherwise it will probably only confuse users. I think a typical new user would do something along the following lines: I want to play around with Haskell. I'll google for install Haskell or download Haskell (here, the Haskell Platform download page should be the #1 hit). There, the user sees the Haskell logo and doesn't have to know *anything* about the platform effort, cabal, ghc or whatever. Therefore, I think it should have the Haskell logo, not the platform logo. -chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Mon, 15 Jun 2009, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. I can wrap an accumulator lazily: data Accum a = Accum a Then foldl' using (Accum a) instead of 'a' would be non-strict, again. Thus foldl' is not always strict. I think this 'seq' function is broken and there should have been a Seq class. Then you can choose the required depth of strictness. Btw. for lazy Peano numbers, sum would be better a foldr rather than foldl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 14/06/2009 05:56, Judah Jacobson wrote: On Sat, Jun 13, 2009 at 8:41 PM, Shu-yu Guos...@rfrn.org wrote: Hello all, It seems like getDirectoryContents applies codepage conversion based on the default program locale under Windows. What this means is that if my default codepage is some kind of Latin, Asian glyphs get returned as '?' in the filename. By '?' I don't mean that the font is lacking the glyph and rendering it as '?', but I mean 'show (head (getDirectoryContents C:\\Music))' returns something that looks like like ?? . This is a problem as I can't get the filenames of my music directory, some of which are in Japanese and Chinese, some of which have accents. If I change the default codepage to Japanese, say, then I get the Japanese filenames in Shift-JIS and I lose all the accented letters. I have filed this as a bug already, but is there a workaround in the meantime (I don't know the Win32 API, but didn't see anything that looked like it would help under System.Win32 anyways) that lets me gets the list of files in a directory that's encoded in some kind of Unicode? Try taking a look at the code in the following module, which uses FFI to access the Unicode-aware Win32 APIs: http://code.haskell.org/haskeline/System/Console/Haskeline/Directory.hsc Care to submit a patch to put this in System.Directory, or better still put the relevant functionality in System.Win32 and use it in System.Directory? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 16 Jun 2009, at 05:18, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. The only change here needs to be either claus' suggestion of generalizing functions over their application operator, or providing a strict sum'. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Tuesday, June 16, 2009, 3:30:31 PM, you wrote: Care to submit a patch to put this in System.Directory, or better still put the relevant functionality in System.Win32 and use it in System.Directory? Simon, it will somewhat broke openFile. let's see. there are 3 types of filenames - 1) english (latin-1) only 2) including local (ansi code page) chars 3) including any other unicode chars now getDirectoryContents return ACP (ansi code page) names so openFile works for files 1) and 2) with such change getDirectoryContents will return correct unicode names, so openFile will work only with names in first group the right way is to fix ALL string-related calls in System.IO, System.Posix.Internals, System.Environment -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 16/06/2009 12:42, Bulat Ziganshin wrote: Hello Simon, Tuesday, June 16, 2009, 3:30:31 PM, you wrote: Care to submit a patch to put this in System.Directory, or better still put the relevant functionality in System.Win32 and use it in System.Directory? Simon, it will somewhat broke openFile. let's see. there are 3 types of filenames - 1) english (latin-1) only 2) including local (ansi code page) chars 3) including any other unicode chars now getDirectoryContents return ACP (ansi code page) names so openFile works for files 1) and 2) with such change getDirectoryContents will return correct unicode names, so openFile will work only with names in first group the right way is to fix ALL string-related calls in System.IO, System.Posix.Internals, System.Environment You're right in that we really ought to fix everything. However, I'm happy to just fix some of these things, even if it introduces some inconsistencies in the meantime. We already have much of System.Directory working with Unicode FilePaths, so there are already inconsistencies here. Thanks for reminding me that openFile is also broken. It's easily fixed, so I'll look into that. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Simon Marlow wrote: Care to submit a patch to put this in System.Directory, or better still put the relevant functionality in System.Win32 and use it in System.Directory? Bulat Ziganshin wrote: now getDirectoryContents return ACP (ansi code page) names so openFile works for files 1) and 2). With such change getDirectoryContents will return correct unicode names, so openFile will work only with names in first group. The right way is to fix ALL string-related calls in System.IO, System.Posix.Internals, System.Environment. You're right in that we really ought to fix everything. However, I'm happy to just fix some of these things, even if it introduces some inconsistencies in the meantime. We already have much of System.Directory working with Unicode FilePaths, so there are already inconsistencies here. +1 for integrating Unicode file paths. Thanks, Bulat! I think the most important use cases that should not break are: o open/read/write a FilePath from getArgs o open/read/write a FilePath from getDirectoryContents There's not much we can do about non-Latin-1 ACP file paths hard coded in Strings. I hope there aren't too many of those in the wild. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Tuesday, June 16, 2009, 4:34:29 PM, you wrote: Thanks for reminding me that openFile is also broken. It's easily fixed, so I'll look into that. i fear that it will leave GHC libs in inconsistent state that can drive users mad. now at least there are some rules of brokeness. when some functions will be unicode-aware and some ansi codepaged, and this may chnage in every version, this unicode support will become completely useless. it will be like floating Base situation when it's impossible to write programs against Base since it's each time different also, i think that the best way to fix windows compatibility is to provide smth like this: #if WINDOWS type CWFilePath = LPCTSTR -- filename in C land type CWFileOffset = Int64 -- filesize or filepos in C land withCWFilePath = withTString -- FilePath-CWFilePath conversion peekCWFilePath = peekTString -- CWFilePath-FilePath conversion #else type CWFilePath = CString type CWFileOffset = COff withCWFilePath = withCString peekCWFilePath = peekCString #endif and then systematically rewrite all string-related OS API calls using these definitions how much meaning will be to have openFile and getDirContents unicode-aware, if deleteFile and even getFileStat aren't unicode-aware? i've attached my own internal module that makes this job for my own program - just for reference -- Best regards, Bulatmailto:bulat.zigans...@gmail.com Win32Files.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 16/06/2009 13:46, Yitzchak Gale wrote: Simon Marlow wrote: Care to submit a patch to put this in System.Directory, or better still put the relevant functionality in System.Win32 and use it in System.Directory? Bulat Ziganshin wrote: now getDirectoryContents return ACP (ansi code page) names so openFile works for files 1) and 2). With such change getDirectoryContents will return correct unicode names, so openFile will work only with names in first group. The right way is to fix ALL string-related calls in System.IO, System.Posix.Internals, System.Environment. You're right in that we really ought to fix everything. However, I'm happy to just fix some of these things, even if it introduces some inconsistencies in the meantime. We already have much of System.Directory working with Unicode FilePaths, so there are already inconsistencies here. +1 for integrating Unicode file paths. Thanks, Bulat! Excuse my ignorance, but... what Unicode file paths? I think the most important use cases that should not break are: o open/read/write a FilePath from getArgs o open/read/write a FilePath from getDirectoryContents There's not much we can do about non-Latin-1 ACP file paths hard coded in Strings. I hope there aren't too many of those in the wild. The following cases are currently broken: * Calling openFile on a literal Unicode FilePath (note, not ACP-encoded, just Unicode). * Reading a Unicode FilePath from a text file and then calling openFile on it I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents. Also currently broken: * calling removeFile on a FilePath you get from getDirectoryContents, amongst other System.Directory operations Fixing getDirectoryContents will fix these. I don't know how getArgs fits in here - should we be decoding argv using the ACP? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Could FFI support pass-by-value of structs?
It's not usual, but it is allowed to have values of
structs passed between functions directly instead of
using pointers:
/*/
struct ex {
int x;
int y;
int z;
};
ex example_functions (ex p)
{
(...)
}
/*/
Would it be possible to allow that in Haskell FFI
by, say, allowing any instance of Storable to be
used in a 'foreign' declaration? Like:
--
data Ex = (...)
instance Storable Ex where
sizeOf _ = ...
alignment = sizeOf
(...)
foreign import ccall example_functions exampleFunction
:: Ex - IO Ex
--
Thanks,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Tuesday, June 16, 2009, 5:02:43 PM, you wrote: Also currently broken: * calling removeFile on a FilePath you get from getDirectoryContents, amongst other System.Directory operations Fixing getDirectoryContents will fix these. no. removeFile like anything else also uses ACP-based api I don't know how getArgs fits in here - should we be decoding argv using the ACP? well, the whole story: windows internally uses Unicode for handling strings. externally, it provides 2 API families: 1) A-family (such as CreateFileA) uses 8-bit char-based strings. these strings are encoded using current locale. First 128 chars are common for all codepages, providing ASCII char set, higher 128 chars are locale-specific. say, for German locale, it provides chars with umlauts, for Russian locale - cyrillic chars 2) W-family (such as CreateFileW) uses UTF-16 encoded 16-bit wchar-based strings, which are locale-independent Windows libraries emulates POSIX API (open, opendir, stat and so on) by translating these (char-based) calls into A-family. GHC libs are written Unix way, so these are effectively bundled to A-family of Win API Windows libraries also provides w* variant of POSIX API (wopen, wopendir, wstat...) that uses UTF-16 encoded 16-bit wchar-based strings, so for proper handling of Unicode strings (filenames, cmdline arguments) we should use these APIs my old proposal: http://haskell.org/haskellwiki/Library/IO -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PEPM'10 - First Call for Papers
=== CALL FOR PAPERS ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 === IMPORTANT DATES: * Paper submission:Tue, October 6, 2009, 23:59, Apia time * Author notification: Thu, October 29, 2009 * Camera-ready papers: Mon, November 9, 2009 To facilitate smooth organization of the review process, authors are asked to submit a short abstract by October 1, 2009. SUBMISSION CATEGORIES: * Regular research papers (max. 10 pages in ACM Proceedings style) * Tool demonstration papers (max. 4 pages plus max. 6 pages appendix) SCOPE: The PEPM Symposium/Workshop series aims to bring together researchers and practitioners working in the areas of program manipulation, partial evaluation, and program generation. PEPM focuses on techniques, theory, tools, and applications of analysis and manipulation of programs. The 2010 PEPM workshop will be based on a broad interpretation of semantics-based program manipulation and continue previous years' effort to expand the scope of PEPM significantly beyond the traditionally covered areas of partial evaluation and specialization and include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to reach out to practitioners, there is a separate category of tool demonstration papers. Topics of interest for PEPM'10 include, but are not limited to: * Program and model manipulation techniques such as transformations driven by rules, patterns, or analyses, partial evaluation, specialization, program inversion, program composition, slicing, symbolic execution, refactoring, aspect weaving, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as abstract interpretation, static analysis, binding-time analysis, dynamic analysis, constraint solving, type systems, automated testing and test case generation. * Analysis and transformation for programs/models with advanced features such as objects, generics, ownership types, aspects, reflection, XML type systems, component frameworks, and middleware. * Techniques that treat programs/models as data objects including meta-programming, generative programming, deep embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including experimental studies, engineering needed for scalability, and benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, resource-limited computation, and security. We especially encourage papers that break new ground including descriptions of how program/model manipulation tools can be integrated into realistic software development processes, descriptions of robust tools capable of effectively handling realistic applications, and new areas of application such as rapidly evolving systems, distributed and web-based programming including middleware manipulation, model-driven development, and on-the-fly program adaptation driven by run-time or statistical analysis. PROCEEDINGS: There will be formal proceedings published by ACM Press. In addition to printed proceedings, accepted papers will be included in the ACM Digital Library. Selected papers may later on be invited for a journal special issue dedicated to PEPM'10. SUBMISSION GUIDELINES: Papers should be submitted electronically via the workshop web site. Regular research papers must not exceed 10 pages in ACM Proceedings style. Tool demonstration papers must not exceed 4 pages in ACM Proceedings style, and authors will be expected to present a live demonstration of the described tool at the workshop (tool papers should include an additional appendix of up to 6 additional pages giving the outline, screenshots, examples, etc. to indicate the content of the proposed live demo at the workshop). Authors using Latex to prepare their submissions should use the new improved SIGPLAN proceedings style (sigplanconf.cls). PROGRAM CO-CHAIRS: * John Gallagher (Roskilde University, Denmark, and IMDEA Software, Spain) * Janis
Re: [Haskell-cafe] Re: Wiki user accounts
On Mon, Jun 15, 2009 at 12:38:02PM -0700, Ashley Yakeley wrote: Magnus Therning wrote: Philippa Cowderoy wrote: On Mon, 2009-06-15 at 13:52 -0400, Gwern Branwen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Jun 15, 2009 at 1:18 PM, Ashley Yakeley wrote: For requesting accounts: who would receive the email, and which person would create the account? Why not just list everyone's email and let the requester pick who to send the request to? A mailing list, possibly attached to a ticketing/queue system, seems a good idea? If it's just a list, admins should ack when they've added someone to avoid duplicated effort. That seems like a good, simple solution! OK, so who wants to create accounts? What are your haskell.org usernames? I'm byorgey on haskell.org and on the wiki. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
tom.davie: On 16 Jun 2009, at 05:18, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. The only change here needs to be either claus' suggestion of generalizing functions over their application operator, or providing a strict sum'. Are the legitimate uses more common than the illegitimate uses? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Tuesday, June 16, 2009, 7:30:55 PM, you wrote: Actually we use a mixture of CRT functions and native Windows API, gradually moving in the direction of the latter. so file-related APIs are already unpredictable, and will remain in this state for unknown amount of ghc versions -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 16/06/2009 16:44, Bulat Ziganshin wrote: Hello Simon, Tuesday, June 16, 2009, 7:30:55 PM, you wrote: Actually we use a mixture of CRT functions and native Windows API, gradually moving in the direction of the latter. so file-related APIs are already unpredictable, and will remain in this state for unknown amount of ghc versions Sometimes fixing everything at the same time is too hard :-) In fact there's not a lot left to convert in System.Directory, as you'll see if you look at the code. Feel like helping? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] slow code
briand: I have included a new and improved version. Just to make the comparison a little more reasonable I re-wrote the program using ML and ran it with SMLNJ eal 0m3.175s user 0m0.935s sys 0m0.319s Here's the compiled haskell (ghc -O2 foo.hs -o foo): real 0m16.855s user 0m9.724s sys 0m0.495s OUCH. I verified to make sure they were both writing valid data files. I'm trying to learn how to fish, so I'm truly interested in finding out _how_ to optimize using profiling and other such tools. Here's the header of the foo.prof file: total time =9.44 secs (472 ticks @ 20 ms) total alloc = 2,171,923,916 bytes (excludes profiling overheads) 2GB of allocation ??? with a base size of 131k. that seems excessive, which gets me back to the , I don't think I'm interpreting profiling stuff correctly. This line is a little more interesting: COST CENTRE MODULE no.entries %time %alloc %time %alloc mainMain 178 1 98.7 99.198.7 99.1 So even though getData should be doing all of the allocation, main's using a lot of time and effort. I figured it was the show's that were slowing things up (how do I get profiling to show that detail ?), so I had it output just \n. Well that finishes in no time at all. And yea, verily, the output of the .prof file. total time =0.14 secs (7 ticks @ 20 ms) total alloc = 65,562,824 bytes (excludes profiling overheads) So I guess it's the show's, but I can't seem to find more efficient float output. FFI to sprintf ? yuch. Is your SMLNJ using lazy lists? :) Try hmatrix or uvector. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Tuesday, June 16, 2009, 7:54:02 PM, you wrote: In fact there's not a lot left to convert in System.Directory, as you'll see if you look at the code. Feel like helping? these functions used there are ACP-only: c_stat c_chmod System.Win32.getFullPathName c_SearchPath c_SHGetFolderPath plus may be some more functions from System.Win32 package - i don't looked into it -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Wiki user accounts
I'm hearing reports of people having difficulty obtaining accounts on the Haskell wiki, without which it is impossible to make edits. Currently, account creation is disabled as an anti-spam measure, and the idea is for people to mail the admin and request an account. (...) Maybe OpenID could help with spam problems without the need for manual intervention: http://www.mediawiki.org/wiki/Extension:OpenID Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Wiki user accounts
Maurício wrote: Maybe OpenID could help with spam problems without the need for manual intervention: http://www.mediawiki.org/wiki/Extension:OpenID Nope, can't install it on this version. http://haskell.org/haskellwiki/Special:Version -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wiki user accounts
[sent to the list as well this time] On Tue, 2009-06-16 at 14:26 -0300, Maurício wrote: I'm hearing reports of people having difficulty obtaining accounts on the Haskell wiki, without which it is impossible to make edits. Currently, account creation is disabled as an anti-spam measure, and the idea is for people to mail the admin and request an account. (...) Maybe OpenID could help with spam problems without the need for manual intervention: http://www.mediawiki.org/wiki/Extension:OpenID I doubt it - I know LiveJournal has a problem with spambots gaining free accounts, and it provides OpenID. They may not be exploited for the OpenID account yet, but I imagine they will be sooner rather than later - OpenID is more useful to tie in people's existing identities. -- Philippa Cowderoy fli...@flippac.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Tuesday, June 16, 2009, 5:02:43 PM, you wrote: I don't know how getArgs fits in here - should we be decoding argv using the ACP? myGetArgs = do alloca $ \p_argc - do p_argv_w - commandLineToArgvW getCommandLineW p_argc argc - peek p_argc argv_w - peekArray (i argc) p_argv_w mapM peekTString argv_w = return.tail foreign import stdcall unsafe windows.h GetCommandLineW getCommandLineW :: LPTSTR foreign import stdcall unsafe windows.h CommandLineToArgvW commandLineToArgvW :: LPCWSTR - Ptr CInt - IO (Ptr LPWSTR) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] BostonHaskell: Next meeting - June 23rd at MIT CSAIL Reading Room (32-G882)
I'm pleased to announce the second meeting of the Boston Area Haskell Users' Group. The meeting is scheduled for Tuesday, June 23rd from 6:30pm - 8:30pm (*). It will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). We have the following two talks scheduled (each intended to be 30-45 minutes each): Automagic Font Conversion with Haskell Typeclasses by Frank Berthold Intermediate Language Representations via GADTs by Nirav Dave As in the last meeting there will be a break between the talks for discussion and mingling. As we are an informal, unsponsored group, there are no current plans to provide refreshments during the break, but I encourage people to volunteer to provide them (please contact me at r...@bluespec.com so I can keep track of what to expect). I'll make sure to appropriately thank any refreshment volunteers at the meeting. If you have any questions about the meeting please send them to the BostonHaskell mailing list: bostonhask...@googlegroups.com or contact me directly. I look forward to seeing many Boston area Haskellers next Tuesday! - Ravi Nanavati (*) I interpreted the silence in response to my previous email proposing June 23rd as assent. If this was a bad time or date to pick, please send your scheduling comments to the BostonHaskell list (i.e. bostonhask...@googlegroups.com) so we can do a better job of picking a date and time in the future. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wiki user accounts
On Tue, Jun 16, 2009 at 11:58 AM, Philippa Cowderoy fli...@flippac.orgwrote: [sent to the list as well this time] On Tue, 2009-06-16 at 14:26 -0300, Maurício wrote: I'm hearing reports of people having difficulty obtaining accounts on the Haskell wiki, without which it is impossible to make edits. Currently, account creation is disabled as an anti-spam measure, and the idea is for people to mail the admin and request an account. (...) Maybe OpenID could help with spam problems without the need for manual intervention: http://www.mediawiki.org/wiki/Extension:OpenID I doubt it - I know LiveJournal has a problem with spambots gaining free accounts, and it provides OpenID. They may not be exploited for the OpenID account yet, but I imagine they will be sooner rather than later - OpenID is more useful to tie in people's existing identities. On that topic, as a future enhancement of the haskell wiki I would love to be able to use OpenID. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Fellow Haskelleers, I'm pleased to report that I feel I have now completed the first milestone in my GSoC project for haskell-src-exts: Full Code Support. This means I feel ready to take that scary leap that means to drop the safe 0.x version numbering (experimental) and finally make the first stable release, version 1.0.0. But before I take that leap I want the library to be thoroughly tested, so I can with confidence say that it truly *is* stable. Therefore, I hereby announce the release on hackage of haskell-src-exts-0.5.2, which I consider (almost) a release candidate for 1.0.0. * Via cabal: cabal install haskell-src-exts * On Hackage: http://hackage.haskell.org/package/haskell-src-exts-0.5.2 * Via darcs: darcs get http://code.haskell.org/haskell-src-exts I would be delighted if as many as possible would consider testing it on their code, even those of you who feel that you may not have any immediate use of the library, just to cover as much code base as possible in the hunt for potential bugs and misfeatures. Testing it is really easy, four simple steps: cabal install haskell-src-exts [...] ghci [...] Prelude :m Language.Haskell.Exts Prelude Language.Haskell.Exts parseFile YourFileHere.(l)hs If you get a parse error on a file that you feel should have been accepted, let me know! If the parser gives you an AST result for a file that you feel it shouldn't have accepted, let me know! Here's the bug tracker: http://trac.haskell.org/haskell-src-exts/report/1 The reason I say it is almost a release candidate is that while I consider the functionality to be in place, I will tidy up the exports, add a few more convenient functions to export, and add a lot of documentation, before I make the actual release. If you have a request for a particularly conventient function to add to the list of exports from the package, it's thus not too late to get it into 1.0.0. :-) What's cool in haskell-src-exts-0.5.2: * Support for all syntactic extensions supported by GHC, with two exceptions: UnicodeSyntax and NewQualifiedOperators. These will likely be added in the next feature release. Exclusive support for the newly registered XmlSyntax and RegularPatterns extensions. No support (yet) for Hugs-specific extensions (RestrictedTypeSynonyms, ExtensibleRecords, HereDocuments). No support for CPP. Also does not support the GHC-specific relaxation of layout in do-blocks, which is an unregistered extension (that should be registered!). * Support for parametrising the parsing on what extensions it should recognise. With no extensions given, it assumes Haskell98. Note that 'parseFile' will look for language pragmas in your source file to decide what extensions to use when parsing. If you want to be explicit, you can use 'parseFileWithExts', or 'parseFileWithMode' that lets you set a few other things as well. I intend to add some convenient names of extension groups, such as 'ghcExtensions' and 'glasgowExts', this is one area where I would particularly welcome suggestions. * Support for correct fixities of infix operators. By default it uses the fixities defined in the Prelude, as well as in the current document (including local let-bound fixities). Use 'parseFileWithMode' to set a different set of fixities. Language.Haskell.Exts.Fixity defines preludeFixities and baseFixities (all fixities defined in the base package), as well as combinators for defining your own sets. Much thanks to Neil Mitchell for the meat of this code. * No (known) bugs! :-) Special note for users of HaRP/HSP: I've uploaded a new version of hsx, hsx-0.5.0, that works with haskell-src-exts-0.5.2. There is one known bug in this version though, it cannot handle 'proc' entities from the Arrows extensions, I'm still considering how to fix that. In the mean time you can use it just fine, as long as your files don't contain any 'proc' blocks (which the old version couldn't handle anyway). Cheers and happy Haskelling, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
On 15 Jun 2009, at 7:54 pm, Luke Palmer wrote: One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. If he so claims, maybe you can challenge him by asking for a proof? He claims that the burden is on my end. Such a proof would probably only involve asymptotics, since it's very hard to prove anything when actual raw speed is involved. If that's the case, you can use Okasaki to back yourself up (or back him up; I am not familiar with the results in this area). He is aware of Okasaki's book, about which he was somewhat offensive. One thing that's clear is that he _isn't_ talking about asymptotics. I've now done some benchmarks myself in C, Java, and Smalltalk, comparing imperative versions of leftist heaps with functional ones. For what it's worth, on a 2.16GHz Intel Core 2 Duo Mac, the coefficient in front of the log(n) part was C JavaST(A) ST(B) Imperative40 70 150 1123 Functional 240 126 290 1895 where ST(A) was a native-code Smalltalk and ST(B) a byte-code one. The C/Functional case used the Boehm collector, untuned. Times are in nanoseconds. Values of n ranged from 2 to 100; the correspondent was saying that small sizes were important. It seems that a factor of 2 for *this* problem is credible; a factor of 10 is not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Wiki user accounts
I wrote: OK, so who wants to create accounts? What are your haskell.org usernames? Anyone else? Gwern? Philippa? -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
He sounds like a bit of a troll, but I agree the question itself is an interesting one and I'd be interested to see if anyone has an answer (although given the lack of criteria, it'll be hard to address his points exactly) On Tue, Jun 16, 2009 at 6:50 PM, Richard O'Keefeo...@cs.otago.ac.nz wrote: On 15 Jun 2009, at 7:54 pm, Luke Palmer wrote: One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. If he so claims, maybe you can challenge him by asking for a proof? He claims that the burden is on my end. Such a proof would probably only involve asymptotics, since it's very hard to prove anything when actual raw speed is involved. If that's the case, you can use Okasaki to back yourself up (or back him up; I am not familiar with the results in this area). He is aware of Okasaki's book, about which he was somewhat offensive. One thing that's clear is that he _isn't_ talking about asymptotics. I've now done some benchmarks myself in C, Java, and Smalltalk, comparing imperative versions of leftist heaps with functional ones. For what it's worth, on a 2.16GHz Intel Core 2 Duo Mac, the coefficient in front of the log(n) part was C Java ST(A) ST(B) Imperative 40 70 150 1123 Functional 240 126 290 1895 where ST(A) was a native-code Smalltalk and ST(B) a byte-code one. The C/Functional case used the Boehm collector, untuned. Times are in nanoseconds. Values of n ranged from 2 to 100; the correspondent was saying that small sizes were important. It seems that a factor of 2 for *this* problem is credible; a factor of 10 is not. ___ 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: Wiki user accounts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jun 16, 2009 at 7:16 PM, Ashley Yakeley wrote: Anyone else? Gwern? Philippa? As usual, I am User:Gwern. On the side-topic of a mailing list - I really think that is too heavy-weight. We want people to create a login (for the ML) and go through the ML, just to get wiki access? A view I've long held is that wikis only work because they are easy to contribute to. When you ask someone for a favor, you don't make them jump through hoops. Even trivial extra steps cut down the # of people willing to do it. There must be methods that put as little a burden on eager would-be newbie editors. Just posting the emails of people with account-creation abilities is the easiest way I can think of. - -- gwern -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAko4MWIACgkQvpDo5Pfl1oKtagCfQNTxtn5dnTqwXxD5YP5zTO+w TjwAn2JAu09ackQs8xY44qPoe2p2g6v5 =oGcB -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
Am Mittwoch 17 Juni 2009 00:50:45 schrieb Richard O'Keefe: One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. If he so claims, maybe you can challenge him by asking for a proof? He claims that the burden is on my end. Certainly not. He claims X is provable, so he has to either provide a proof himself (a sketch may suffice), or tell you where you can find a proof. The burden of proof is always on the claimant. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need some help with an infinite list
Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
* Via cabal: cabal install haskell-src-exts Thanks a lot to Brian Lewis for catching the first bug - cabal install doesn't even work for 0.5.2! The problem is that the cabal test machinery can't find the Language.Haskell.Exts modules, unless haskell-src-exts is already installed first... At any rate: I'm pleased to announce haskell-src-exts-0.5.3! Everything else from above still applies. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
One (rather ugly) option is: tail . map (\y - showIntAtBase 26 (\x - chr (x + 96)) y ) $ [0..] but I'm sure there's a prettier one out there :) On Tue, Jun 16, 2009 at 8:28 PM, GüŸnther Schmidtgue.schm...@web.de wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
Here's a way using list comprehensions: Prelude Data.List take 1000 $ concat.concat $ [ [ replicate n c | c - ['a'..'z'] ] | n - [1..] ] abcdefghijklmnopqrstuvwxyzaabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvw wxxyyzzaaabbbcccdddeeefffggghhhiiijjjkkklllmmmnnnooopppqqqrrrssstttuuuvvvwwwxxxyyyzzzabcdefghijklmnopqrstuvwxyzaabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzzaaabbbcccdddeeefffggghhhiiijjjkkklllmmmnnnooopppqqqrrrssstttuuuvvvwwwxxxyyyzzzabcdefgh -Ross On Jun 16, 2009, at 8:39 PM, Daniel Peebles wrote: One (rather ugly) option is: tail . map (\y - showIntAtBase 26 (\x - chr (x + 96)) y ) $ [0..] but I'm sure there's a prettier one out there :) On Tue, Jun 16, 2009 at 8:28 PM, GüŸnther Schmidtgue.schm...@web.de wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
letterCombos = map (:[]) ['a'..'z'] ++ concatMap (\c - map ((c++) . (: [])) ['a'..'z']) letterCombos Not hugely efficient, if you generate the strings in reverse then you can use (c:) rather than ((c++) . (:[])), but that may not be useful to you. Bob On 17 Jun 2009, at 02:28, Günther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ 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: Need some help with an infinite list
Günther Schmidt gue.schmidt at web.de writes: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] If you're happy to have a before the a, you can do this as a fairly cute one-liner in a similar style to this list of Fibonacci numbers. fib = 0:1:[m + n | (m, n) - zip fib (tail fib)] Regards, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
this appears to work: alphabet=map (\x-x:[]) ['a'..'z'] series=alphabet++[x++y|x-series,y-alphabet] On Tue, Jun 16, 2009 at 8:28 PM, GüŸnther Schmidt gue.schm...@web.dewrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ 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: Need some help with an infinite list
Dear Ross, thanks for your post, you got it almost right, I needed something like aa, ab, ac ... It seems that Thomas has figured it out. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Need some help with an infinite list
Hi Thomas, thanks, it seems you found it. I find it a bit embarrassing that I was unable to figure this out myself. Günther Thomas Davie schrieb: letterCombos = map (:[]) ['a'..'z'] ++ concatMap (\c - map ((c++) . (:[])) ['a'..'z']) letterCombos Not hugely efficient, if you generate the strings in reverse then you can use (c:) rather than ((c++) . (:[])), but that may not be useful to you. Bob On 17 Jun 2009, at 02:28, GüŸnther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Need some help with an infinite list
Oh sorry about that, misread the problem. -Ross On Jun 16, 2009, at 9:16 PM, Günther Schmidt wrote: Dear Ross, thanks for your post, you got it almost right, I needed something like aa, ab, ac ... It seems that Thomas has figured it out. Günther ___ 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: Need some help with an infinite list
Hi Tom, thanks for that. I remembered reading about that in my earliest haskell days, couldn't find it again and couldn't get it right by myself either. Günther Tom Pledger schrieb: Günther Schmidt gue.schmidt at web.de writes: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] If you're happy to have a before the a, you can do this as a fairly cute one-liner in a similar style to this list of Fibonacci numbers. fib = 0:1:[m + n | (m, n) - zip fib (tail fib)] Regards, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
On 16 Jun 2009, at 11:49 am, Bertram Felgenhauer wrote: What about decreaseKey in a purely functional setting? I suppose it's O(log n), based on the intuition of trees with limited branching factor. Fibonacci heaps can do it in O(1), which makes a difference for Dijkstra's algorithm, for example. The original poster in the Erlang thread on the subject didn't ask for decreaseKey. The problem with delete and decreaseKey is that they require a way of identifying en entry _within_ a priority queue. This is easy enough to do in C or Java: just hand out pointers to the internal nodes. It's less easy in a language where nodes don't _have_ identities, such as Haskell or Erlang. The Brodal and Okasaki paper suggests using an extra dictionary data structure for this purpose, roughly doubling the size of the whole thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] slow code
On Jun 16, 2009, at 8:58 AM, Don Stewart wrote: So I guess it's the show's, but I can't seem to find more efficient float output. FFI to sprintf ? yuch. Is your SMLNJ using lazy lists? :) strictly speaking : no. Try hmatrix or uvector. uvector is _probably_ the long term answer even after I solve the double - string problem. However, I would like to reiterate that it's the double - string which is really the time/memory sink. I verified this by printing a simple string based on the value (to make sure the value was evaluated) and it runs fast enough for me. Is there an efficient way to output double - binary ? I typically write my data files as binary anyway, because it's faster for graph and the like to handle them anyway. Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
On 17 Jun 2009, at 12:28 pm, Günther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Let me change this slightly. [0,1,...,9,00,01,..,99,000,...999,...] Does that provide a hint? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Need some help with an infinite list
Hi Ross, no problem at all, I certainly appreciate it. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
My solution attempted to exploit this using Numeric.showIntAtBase but failed because of the lack of 0 prefixes in the numbers. If you can find a simple way to fix it without duplicating the showIntAtBase code, I'd be interested! On Tue, Jun 16, 2009 at 10:01 PM, Richard O'Keefeo...@cs.otago.ac.nz wrote: On 17 Jun 2009, at 12:28 pm, GüŸnther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Let me change this slightly. [0,1,...,9,00,01,..,99,000,...999,...] Does that provide a hint? ___ 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: Need some help with an infinite list
Hi Richard, I'd have to guess here :) Maybe, what you have in mind, is: generate an infinite list with numbers from [1 ..], map it to base 26? Günther Richard O'Keefe schrieb: On 17 Jun 2009, at 12:28 pm, GüŸnther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Let me change this slightly. [0,1,...,9,00,01,..,99,000,...999,...] Does that provide a hint? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Performance of functional priority queues
Hi Richard, just a wiiild guess on this, but anyway. Maybe Oleg has something to say on this, in particular when it comes to his domain, ie. delimited continuations. As I said, just a wild guess. Günther Richard O'Keefe schrieb: There's a current thread in the Erlang mailing list about priority queues. I'm aware of, for example, the Brodal/Okasaki paper and the David King paper. I'm also aware of James Cook's priority queue package in Hackage, have my own copy of Okasaki's book, and have just spent an hour searching the web. One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. I think he's cuckoo. But I'd like to have some numbers to back me up. Can anyone point me to some actual benchmark results comparing priority queue performance *with* mutation and priority queue performance *without* mutation, in the same functional or mostly-functional language? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Wiki user accounts
OK, the people listed here have been given the ability to create accounts: http://haskell.org/haskellwiki/?title=Special%3AListusersgroup=createaccount I'm willing to hand this ability out to pretty much anyone who seems unlikely to be a spammer. To create an account, go to the login page. http://haskell.org/haskellwiki/Special:Userlogin You should see five text boxes instead of two. Enter the desired username, and the person's email, and click on the by email button. You do not need to enter a password. Rules for usernames are the same as rules for particle titles, so the first character cannot be a lower-case letter (actually, it will get folded to upper-case). But spaces are OK. If you want to let people know that you can do this for them, add your email address here: http://haskell.org/haskellwiki/HaskellWiki:New_accounts -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] slow code
On Tue, Jun 16, 2009 at 6:47 PM, brian bri...@aracnet.com wrote: On Jun 16, 2009, at 8:58 AM, Don Stewart wrote: So I guess it's the show's, but I can't seem to find more efficient float output. FFI to sprintf ? yuch. Is your SMLNJ using lazy lists? :) strictly speaking : no. Try hmatrix or uvector. uvector is _probably_ the long term answer even after I solve the double - string problem. However, I would like to reiterate that it's the double - string which is really the time/memory sink. I verified this by printing a simple string based on the value (to make sure the value was evaluated) and it runs fast enough for me. You might want to look at the source and see if you can find a faster way to convert it: http://haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-Float.html#showFloat Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
Thomas Davie wrote: letterCombos = map (:[]) ['a'..'z'] ++ concatMap (\c - map ((c++) . (: [])) ['a'..'z']) letterCombos Not hugely efficient, if you generate the strings in reverse then you can use (c:) rather than ((c++) . (:[])), but that may not be useful to you. Bob I think the following version increases the sharing between the generated strings, and so might be more space-efficient for consumers which hold on to a significant number of them: number :: [a] - [[a]] number digits = expand [[]] where expand xss = expanded ++ expand expanded where expanded = concatMap (\d - map (d:) xss) digits binary = number ['0'..'1'] decimal = number ['0'..'9'] alpha = number ['a'..'z'] Regards, Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
On 17 Jun 2009, at 2:01 pm, Richard O'Keefe wrote: On second thoughts, let strings = : [pref++[last] | pref - strings, last - ['a'..'z']] in tail strings seems more Haskellish than the stupidly clever counting-based code I had in mind. With this it's much easier to see what it's up to. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
At 4:25 PM +1200 6/17/09, Richard O'Keefe wrote: On 17 Jun 2009, at 2:01 pm, Richard O'Keefe wrote: On second thoughts, let strings = : [pref++[last] | pref - strings, last - ['a'..'z']] in tail strings seems more Haskellish than the stupidly clever counting-based code I had in mind. With this it's much easier to see what it's up to. And here's a version along similar lines that avoids (++) for greater sharing and efficiency: let sss = [] : [ [ c:s | c - ['a'..'z'], s - ss ] | ss - sss ] in concat (tail sss) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
On Wed, Jun 17, 2009 at 02:28:55AM +0200, Gü?nther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] I'm surprised everyone is giving clever recursive solutions rather than concatMap (\n - replicateM n ['a'..'z']) [1..] Regards, Reid ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
On Wed, 17 Jun 2009 00:45:56 -0400, you wrote: And here's a version along similar lines that avoids (++) for greater sharing and efficiency: let sss = [] : [ [ c:s | c - ['a'..'z'], s - ss ] | ss - sss ] in concat (tail sss) Sheer genius! I just inverted it since I like to see the main idea first. letterCombos = concat (tail sss) where sss = [] : [ [ c:s | c - ['a'..'z'], s - ss ] | ss - sss ] -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Android and Haskell
Hello, I was just reading a Linux Mag article on Android and scripting. The underlying OS is Linux? Python is one of the scripting languages. http://code.google.com/p/android-scripting/ ... Is Python one of the supported languages simply because it (I think) has JVM bindings? My bottom line question is what is preventing Haskell98 from running on Android if Python can? Regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
