Re: [GHC] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets

[GHC]

#1496: Newtypes and type families combine to produce inconsistent FC(X) axiom 
sets
+---
Reporter:  sorear   |Owner:  simonpj   
Type:  bug  |   Status:  new   
Priority:  high |Milestone:  6.8 branch
   Component:  Compiler (Type checker)  |  Version:  6.7   
Severity:  critical |   Resolution:
Keywords:   |   Difficulty:  Unknown   
  Os:  Unknown  | Testcase:
Architecture:  Unknown  |  
+---
Comment (by Isaac Dupree):

 Replying to [comment:12 toms]:
 However, GADTs are definitely not functors.

 ...

 We can attempt to fix the situation by imposing conditions on the
 types involved in
 a newtype deriving:
   * generate the fmap code, and hence demand explicit Functor
 instances.
 We should be able to expect the compiler to eliminate any runtime
 overhead.

 From Frisby we have a data type that is a Functor and a GADT, but not a
 Functor in the way you and GHC expect:
 {{{
 data PE a where
 -- leaving out most of the constructors, but note especially PMap
 Char :: IntSet.IntSet - PE Char
 Failure :: PE a
 Not :: PE a - PE ()
 Then :: PE a - PE b - PE (a,b)
 PMap :: (a - b) - PE a - PE b

 instance Functor PE where
 fmap = PMap
 }}}

 Applying the `fmap`-option would make interesting, type-correct code be
 generated that could not be optimized away (so the dictionaries couldn't
 be shared).

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1496#comment:14
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version

[GHC]

#1802: proposal: fix comparison operations for base:Data.Version.Version
+---
  Reporter:  [EMAIL PROTECTED]  |  Owner: 
  Type:  proposal   | Status:  new
  Priority:  normal |  Milestone: 
 Component:  libraries/base |Version:  6.6.1  
  Severity:  normal |   Keywords: 
Difficulty:  Unknown| Os:  Unknown
  Testcase: |   Architecture:  Unknown
+---
 Proposal: that values of the type Data.Version.Version should compare
 equal, by ignoring trailing zeros.
 Thus 1.2.0 == 1.2, rather than 1.2.0  1.2

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1802
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1800: Template Haskell support for running functions defined in the same module

[GHC]

#1800: Template Haskell support for running functions defined in the same  
module
-+--
Reporter:  simonpj   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone:  _|_
   Component:  Template Haskell  |  Version:  6.6.1  
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Unknown   | Testcase: 
Architecture:  Unknown   |  
-+--
Comment (by guest):

 It would be interesting to note how the template-haskell end user copes
 with this problem to illustrate why the proposed feature is useful.

 I myself have had to face this problem when designing an embedded compiler
 for system design.
 Doe to the mentioned limitation I'm normally forced to push the
 arguments out of the splice.

 As a (simplified) example, in my System Modelling DSL I have to create
 system definition. That is done by providing the function Name together
 with the identifiers of its inputs and outputs.

 {{{
 inputs = [in1, in2]

 outputs = [out1, out2]

 f :: Signal Int - Signal Int - (Signal Int, Signal Int)
 f = ...
 }}}

 Since it is not possible to do

 {{{
 system :: SysDef
 system = $(mkSysDef 'f inputs outputs)
 }}}

 due to the limitation explained in this ticket. I'm forced to do:

 {{{
 system :: SysDef
 system = $(mkSysDef 'f) inputs outputs

 -- where mkSysDef :: Name - ExpQ
 }}}

 My solution does not solve the problem. It rather bypasses it.

 Furthermore, mkSysDef unfortunately cannot do static checking (for
 example, it cannot make sure that all the inputs and outputs have
 different identifiers). However, that's better than asking the user to
 create the system definitions and identifiers in different modules.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1800#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate

[Claus Reinke]

 adding more status/next action/deadline/actor fields would help, if trac
 supports that (could be simple free-form text
 fields, or selections),

FYI, Trac is bringing us customised workflows, which will allow us to do 
some of this:


http://trac.edgewall.org/wiki/WorkFlow

In particular we'll be able to add new ticket states to indicate that the 
ticket is waiting for feedback from the submitter, or some other 
dependency.  I wouldn't be in favour of just adding new fields to do this 
right now, we already have too many fields.


that looks promising. although the idea still seems to be to
have few states, leaving it to custom fields to specify details.

so there might be a single waiting state, with an action 
field specifying what one is waiting for (someone getting an

definite interpretation of a spec, someone contacting the gcc/
cygwin/whatever team, someone implementing a newer,
better language feature that will make the issue obsolete or
easier to deal with, etc), a date field specifying when results 
from that action are expected (or a reminder should be sent), 
and an actor field specifying who is looking after that action.


and if the actor finishes the action, a click on the done 
button would take the ticket to idle (waiting for the next

action to be determined) or, better, the next action to
specify would be obvious, going directly back to waiting.

this combination of two extra states+three one-line fields
would be more flexible and less complex than trying to
capture all eventualities in pre-designed fields/states, as
trac currently aims to do. you name one part of the 
current problem: too many fields not relevant to every 
ticket; i named another: too few relevant fields. having 
more general fields could address both parts.


i can understand if you want to hold back until the next
trac release, as that seems to switch a few things around.
it is just that if i think of the current state of ghc's trac as
wasting your time:

- if you wanted to go through all tickets to figure out 
   their state and adjust their milestones, i estimate that

   could take anything up to a full day; so long, in fact,
   that you decided not to do it for this release

- if you wanted to figure out which tickets are pending
   full implementation of open type functions, you'd 
   have to go through all type-system tickets


- etc. etc.

if, instead, all the information relevant to organisation
(as opposed to information relevant to fixing) were 
available in ticket fields, one could go through all tickets 
in an hour (without ever having to wade into the ticket 
history/comments), and many things one might want to 
figure out could become a simple trac-query instead 
of a full search. an overview page translating states to 
colour could tell at a glance which tickets are actively 
waiting, and which are idling or overdue (hence need

attention).

in fact, since all information about a ticket state would
be visible to everyone, from the ticket fields, there
would no longer be a need to go through all tickets
at every release just to reassure submitters that their
tickets weren't overlooked.

in other words, i'd classify this meta-ticket as both
urgent and important: urgent because the current
system is becoming unwieldy, important because
a reorganised system should save you a lot of time.

claus


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate

[Jean-Philippe Bernardy]

Hi

On 10/24/07, Ian Lynagh [EMAIL PROTECTED] wrote:

 Hi,

 On Wed, Oct 24, 2007 at 09:28:51AM +0200, Jean-Philippe Bernardy wrote:
 
  I ran into this problem with the GHC API (GHC 6.8.1 Second Release 
  Candidate)
 
  upon doing:
 
session - GHC.newSession (Just path)
 
  I run into:
 
  yi: Can't find package.conf as /home/jp/usr//lib/ghc-6.8.0.20071019
  /driver/package.conf.inplace

 Thanks for the report; however, I can't reproduce this.

Somehow I got a carriage return inserted in the libdir that I passed
to newSession. So the only problem on GHC side is that the error
message is slightly misleading.
(Nothing to worry about I would say)

Thanks
-- JP
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Incompatibility between Yi and GHC 6.8 (rc)

[Jean-Philippe Bernardy]

Hello,

I spent some time to make Yi work with 6.8, and failed up to now.
Before I go into details, let's see what I'm trying to do with Yi.

The idea is to have a fully dynamic application where the user is
allowed to run arbitrary haskell code on the command line. This can be
used to quickly test new code, etc. In particular, one needs to be
able to reload the configuration in that manner.

This is achieved basically by having everything running inside a
specially made GHC Session. The dynamic code is able to reload
itself because it is passed a pointer to the GHC session.

The GHC experts will see here that this cannot work :) Indeed, GHC has
a number of global variables, which, if accessed through code loaded
in a GHC session, will be instanciated again. This means that
accessing a level 1 session with level 2 code is normally not
possible.

However, I found a workaround: encapsulate all calls to the GHC API in
a data structure in level 1 code, which is then passed to level 2.
(A haskell version of C-style callbacks). While this worked
beautifully with GHC 6.6, it fails with 6.8rc. with

  exception :: GhcException
  yi: panic! (the 'impossible' happened)
(GHC version 6.8.0.20071019 for i386-unknown-linux):
  a static opt was looked at too early!

This happens at a seemingly unrelated point in the code. (inside the
bytecode interpreter?)

I can't really report a bug here, because what I'm trying to do is
probably fairly unsupported by GHC. However, I'd appreciate some sort
of advice. Is my workaround the correct approach? How would GHC people
implement a dynamic application? Should I drop the idea completely?
...

Thanks in advance for your help :)
-- JP

Attached: a darcs patch to the Yi repo to (try to) support 6.8.

New patches:

[adapt to GHC 6.8
[EMAIL PROTECTED] {
hunk ./Makefile 13
-	dist/build/yi/yi -B. -f$(frontend)
+	cp --preserve=timestamps -R Yi dist/build
+	dist/build/yi/yi -Bdist/build -f$(frontend)
hunk ./Setup.hs 4
-import Control.Monad(when, filterM, unless)
-import Data.List (intersect)
+import Control.Monad
hunk ./Setup.hs 7
-import Distribution.Setup
+import Distribution.Simple.Setup
hunk ./Setup.hs 9
+import Distribution.Simple.GHC as GHC
hunk ./Setup.hs 11
-import Distribution.Simple.Utils
+import Distribution.Simple.Program
+import Distribution.Verbosity
hunk ./Setup.hs 14
-import System.Exit
hunk ./Setup.hs 15
-import System.Info
-import System.Process
hunk ./Setup.hs 16
+import Control.Applicative
hunk ./Setup.hs 22
-getLibDir ghcPath = do 
-  (_, out, _, pid) - runInteractiveProcess ghcPath [--print-libdir]
-   Nothing Nothing
-  libDir - hGetLine out
-  waitForProcess pid
-  return libDir
-
hunk ./Setup.hs 24
-bHook :: PackageDescription - LocalBuildInfo - Maybe UserHooks - BuildFlags - IO ()
-bHook pd lbi hooks bfs = do
-  let ghc = compilerPath . compiler $ lbi
+-- TODO: add a configuration hook that does not want to build for
+-- certain combination of flags
+
+bHook :: PackageDescription - LocalBuildInfo - UserHooks - BuildFlags - IO ()
+bHook pd lbi hooks flags = do
+  let verbosity = buildVerbose flags
hunk ./Setup.hs 31
+  ghcOut = rawSystemProgramStdoutConf verbosity ghcProgram (withPrograms lbi)
hunk ./Setup.hs 33
-  libdir - getLibDir ghc
+  libdir - head . lines $ ghcOut [--print-libdir]
+  putStrLn $ GHC libdir =  ++ show libdir
hunk ./Setup.hs 39
-  buildHook defaultUserHooks pd' lbi hooks bfs
+  buildHook defaultUserHooks pd' lbi hooks flags
hunk ./Setup.hs 41
-  res - mapM (precompile ghc) precompiles
-  let sucessfuls = [m | (m,code) - res, code == ExitSuccess]
-  nok = null $ intersect sucessfuls [Yi.Vty.UI, Yi.Gtk.UI]
-  putStrLn $ Sucessfully compiled:  ++ show sucessfuls
-  when nok $ do
-   putStrLn No frontend was compiled sucessfully. Giving up.
-   exitWith (ExitFailure 1)
+  mapM_ (precompile pd' lbi verbosity) precompiles
hunk ./Setup.hs 43
-precompile ghc (moduleName, dependencies) = do
+dependencyName (Dependency name _) = name
+
+precompile pd lbi verbosity (moduleName, dependencies) = when ok $ do  
+  -- just pretend that we build a library with the given modules
hunk ./Setup.hs 48
-  exitCode - rawSystemVerbose 0 ghc (precompArgs ++ map (-package ++) dependencies ++ [moduleName])
-  when (exitCode /= ExitSuccess) $
-   putStrLn $ Precompiling failed:  ++ moduleName
-  return (moduleName, exitCode)
+  let [Executable yi _ yiBuildInfo] = executables pd
+  pd' = pd {executables = [], 
+library = Just (Library {exposedModules = [moduleName],
+ libBuildInfo = yiBuildInfo})}
+  GHC.build pd' lbi verbosity
+ where availablePackages = map dependencyName $ buildDepends pd
+   ok = all (`elem` availablePackages) dependencies
+   
hunk ./Setup.hs 61
-   (Yi.Gtk.UI, [gtk, sourceview]),
-   (Yi.Dired, [unix])]
-

Re: [Haskell] Re: Trying to install binary-0.4

[Simon Marlow]

Duncan and I have started a wiki page to collect proposals for ways to 
avoid or alleviate the pain from future package reorganisations.


http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility

It's been helpful for me to write all this down, the issues seem much 
clearer.  However, I don't see an obviously best solution.  For me proposal 
4.2 (see the wiki page) looks the most promising, but it doesn't provide 
complete backwards compatibility, so I imagine there will be people who 
disagree.


Please read the page.  Fix problems, add rationale, add proposals if you 
have any that are substantially different from those already there.  For 
general discussion just reply to this message (replies directed to 
[EMAIL PROTECTED]).


Cheers,
Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Brainstorming package compatibility problem

[Bulat Ziganshin]

i've forwarded this message from libraries list because i think it's very
important topic for Haskell growth. please answer only to [EMAIL PROTECTED]


This is a forwarded message
From: Simon Marlow [EMAIL PROTECTED]
===8==Original message text===
Duncan and I have started a wiki page to collect proposals for ways to 
avoid or alleviate the pain from future package reorganisations.

http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility

It's been helpful for me to write all this down, the issues seem much 
clearer.  However, I don't see an obviously best solution.  For me proposal 
4.2 (see the wiki page) looks the most promising, but it doesn't provide 
complete backwards compatibility, so I imagine there will be people who 
disagree.

Please read the page.  Fix problems, add rationale, add proposals if you 
have any that are substantially different from those already there.  For 
general discussion just reply to this message (replies directed to 
[EMAIL PROTECTED]).

Cheers,
Simon

___
Libraries mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/libraries

===8===End of original message text===



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell Weekly News: October 25, 2007

[Don Stewart]

---
Haskell Weekly News
http://sequence.complete.org/hwn/20071025
Issue 66 - October 25, 2007
---

   Welcome to issue 66 of HWN, a newsletter covering developments in the
   [1]Haskell community.

   A huge month for the Haskell community, with the Haskell Workshop,
   ICFP and CUFP conferences, the second international Haskell Hackathon,
   and 63 libraries and tools uploaded to hackage! A round of applause to
   everyone involved!

   1. http://haskell.org/

Hackage

   This week's new libraries in [2]the Hackage library database.

   2. http://hackage.haskell.org/

 * SDL 0.5.0. Uploaded by Lemmih. [3]SDL, a binding to libSDL.

 * Stream 0.2.1. Uploaded by Wouter Swierstra. [4]Stream, functions,
   analogous to those from Data.List, to create and manipulate
   infinite lists

 * bktrees 0.1.1. Uploaded by Josef Svenningsson. [5]bktrees,
   Burhard-Keller trees provide an implementation of sets which apart
   from the ordinary operations also has an approximate member
   search, allowing you to search for elements that are of a certain
   distance from the element you are searching for.

 * happy 1.17. Uploaded by Simon Marlow. [6]happy, a parser generator
   for Haskell.

 * HaXml 1.19. Uploaded by Malcolm Wallace. [7]HaXml, utilities for
   parsing, filtering, transforming and generating XML documents.

   3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-0.5.0
   4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.2.1
   5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bktrees-0.1.1
   6. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happy-1.17
   7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml-1.19

 * polyparse 1.1. Uploaded by Malcolm Wallace. [8]polyparse, A
   variety of alternative parser combinator libraries, including the
   original HuttonMeijer set. The Poly sets have features like good
   error reporting, arbitrary token type, running state, lazy
   parsing, and so on. Finally, Text.Parse is a proposed replacement
   for the standard Read class, for better deserialisation of Haskell
   values from Strings.

 * bzlib 0.4.0.1 . Uploaded by Duncan Coutts. [9]bzlib, compression
   and decompression in the bzip2 format.

 * zlib 0.4.0.1. Uploaded by Duncan Coutts. [10]zlib, compression and
   decompression in the gzip and zlib formats

 * tar 0.1.1.1. Uploaded by Bjorn Bringert. [11]tar, a library for
   reading and writing TAR archives.

 * unix-compat 0.1.2.0. Uploaded by Bjorn Bringert. [12]unix-compat,
   provides portable implementations of parts of the unix package.
   This package re-exports the unix package when available. When it
   isn't available, portable implementations are used.

   8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/polyparse-1.1
   9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib-0.4.0.1
  10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.4.0.1
  11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tar-0.1.1.1
  12. 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-compat-0.1.2.0

 * oeis 0.1. Uploaded by Brent Yorgey. [13]oeis, Haskell interface to
   the Online Encyclopedia of Integer Sequences.

 * dataenc 0.9. Uploaded by Magnus Therning. [14]dataenc, Data
   encoding library currently providing Uuencode, Base64, Base64Url,
   Base32, Base32Hex, and Base16.

 * cabal-setup 1.2.1. Uploaded by Simon Marlow. [15]cabal-setup,
   cabal-setup is a user interface to Cabal. It provides the basic
   commands for configuring, building, and installing Cabal packages.

 * cabal-install 0.4.0. Uploaded by [EMAIL PROTECTED]
   [16]cabal-install, apt-get like tool for Haskell. The 'cabal'
   command-line program simplifies the process of managing Haskell
   software by automating the fetching, configuration, compilation
   and installation of Haskell libraries and programs.

 * HTTP 3001.0.0. Uploaded by Bjorn Bringert. [17]HTTP, A library for
   client-side HTTP.

  13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/oeis-0.1
  14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.9
  15. 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-setup-1.2.1
  16. 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install-0.4.0
  17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP-3001.0.0

 * iconv 0.4. Uploaded by Duncan Coutts. [18]iconv, provides an
   interface to the POSIX iconv library functions for string encoding
   conversion.

 * binary 0.4.1. Uploaded by the Binary Strike Team. [19]binary,
   efficient

Re: [Haskell-cafe] Binary constants in Haskell

[Ketil Malde]

Don Stewart [EMAIL PROTECTED] writes:

 Are there binary constants in Haskell, as
 we have, for instance, 0o232 for octal and
 0xD29A for hexadecimal?

 No, though it is an interesting idea.

Presumably it is less common since octal and hexadecimal are more
compact and almost as easy to interpret as bit patterns?  Why would
you want them?

Prelude let bin = foldl...
Prelude 0o232
154
Prelude bin [0,1,0, 0,1,1, 0,1,0]
154
Prelude 0xD29A
53914
Prelude bin [1,1,0,1, 0,0,1,0, 1,0,0,1, 1,0,1,0]
53914

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Existential types (Was: Type vs TypeClass duality)

[apfelmus]

Dan Weston wrote:

Thanks for the concise explanation. I do have one minor question though.

  -+- A more useful example is
 
  ∃a. Show a = a   i.e.  ∃a.(a - String, a)
 
  So, given a value (f,x) :: ∃a.(a - String, a), we can do
 
  f x :: String
 
  but that's pretty much all we can do. The type is isomorphic to a simple
  String.

Don't you mean *epimorphic* instead of isomorphic (not that it matters)? 
For any existential type a of cardinality less than that of String, it 
is isomorphic, but if a = String, then by Cantor's theorem String - 
String has a cardinality greater than String and cannot be isomorphic to 
it.


I do mean isomorphic. The point is that because we can't know what  a 
is, the only thing we will ever be able to do with it is plug it into 
the function given. So, there is no difference in using the function 
result in the first place.


To show that formally, one has to use _parametricity_ which is basically 
the fact that the intuition about ∀ (and ∃) is true. For instance, the 
intuition says that every function of type


  ∀a. a - a

has to be the identity function (or _|_ but let's ignore that) because 
it may not look into  a . These quotes can be translated into 
math-speak and are then called parametricity.



Regards,
apfelmus

___
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]

Peter Hercek wrote:

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)


It's probably best to interpret ∀a as you are to choose any type  a 
and I will comply. Then, it doesn't matter whether you first supply a 
String and then choose some  a  or whether you first choose some  a  and 
then supply a String. In both cases, the choice is yours and independent 
of the String. So, the types


  String - ∀a.a  and  ∀a.(String - a)

are isomorphic. (And you're right, the only thing this function can do 
is to return _|_.)


In contrast, ∃a means I choose a concrete type  a  at will and you will 
have to deal with all of my capricious choices.


Regards,
apfelmus

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell Paralellism

[Dominik Luecke]

Hello,

I am trying to use the code 

rels list = 
let 
o1 = (map makeCompEntry) $ head $ splitList list
o2 = (map makeCompEntry) $ head $ tail $ splitList list
o3 = (map makeCompEntry) $ head $ tail $ tail $ splitList list
in
  case (head $ tail $ tail $ tail $ splitList list) of
[] - o1 `par` o2 `par` o3 `seq` o1 : o2 : o3 : []
_  - 
let o4 = rels (head $ tail $ tail $ tail $ splitList list)
in
  o1 `par` o2 `par` o3 `par` o4 `seq` 
  o1 : o2 : o3 : o4

to apply some operation on some lists in parallel. The input list list
is quite long (about 10^17) entries, and I split it into chunks of 1000
entries each. I am compiling with the options  -O2 --make -smp
-threaded and when running the file with +RTS -N2 -sstderr -RTS, I
see that only one worker thread is really doing anything. I am using a
vanilla build of ghc-6.6.1 running on Ubuntu 7.10. I am currently
wondering about what I am doing wrong.

Regards, 
 Dominik

-- 
Dominik Luecke Phone +49-421-218-64265
Dept. of Computer Science  Fax   +49-421-218-9864265
University of Bremen   [EMAIL PROTECTED]   
P.O.Box 330440, D-28334 Bremen
PGP-Key ID 0x2D82571B

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Paralellism

[Alberto Ruiz]

Hello Dominik,

I have used something like this and it worked very well:

import Control.Parallel.Strategies

inParallel = parMap rwhnf id

[a,b] = inParallel [f x, g y]

I hope it helps,

Alberto

On Thursday 25 October 2007 11:36, Dominik Luecke wrote:
 Hello,

 I am trying to use the code

 rels list =
 let
 o1 = (map makeCompEntry) $ head $ splitList list
 o2 = (map makeCompEntry) $ head $ tail $ splitList list
 o3 = (map makeCompEntry) $ head $ tail $ tail $ splitList list
 in
   case (head $ tail $ tail $ tail $ splitList list) of
 [] - o1 `par` o2 `par` o3 `seq` o1 : o2 : o3 : []
 _  -
 let o4 = rels (head $ tail $ tail $ tail $ splitList list)
 in
   o1 `par` o2 `par` o3 `par` o4 `seq`
   o1 : o2 : o3 : o4

 to apply some operation on some lists in parallel. The input list list
 is quite long (about 10^17) entries, and I split it into chunks of 1000
 entries each. I am compiling with the options  -O2 --make -smp
 -threaded and when running the file with +RTS -N2 -sstderr -RTS, I
 see that only one worker thread is really doing anything. I am using a
 vanilla build of ghc-6.6.1 running on Ubuntu 7.10. I am currently
 wondering about what I am doing wrong.

 Regards,
  Dominik
___
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]

Alfonso Acosta wrote:

This bit was specially helpful:

So, how to compute a value  b  from an existential type ∃a.(a - a)? ...

Could you give a specific example of computing existential types?


Well, the word compute was probably not a good choice, I meant the 
following question: given a type  ∃a.(a, a - String) , how can I 
pattern match on it? And how to construct values of that type? (Note 
the different example, since  ∃a.(a - a)  pretty much behaves like the 
singleton type  () ).


That's probably best detailed with a comparison to the finite sum type 
 Either A B . (∃ is like an infinite sum.) (I'll abbreviate concrete 
types like  Int  with  A,B,...  since that's less to write.) For 
constructing a value of type  Either A B , we have two functions


  Left  :: A - Either A B
  Right :: B - Either A B

Likewise for ∃, we have functions

  fromA :: (A, A - String) - ∃a.(a, a - String)
  fromB :: (B, ... etc.
  ...

but this time for all types  A,B,... . We don't need infinitely many 
such functions, one polymorphic functions will do


  from  :: ∀b. (b, b - String) - ∃a.(a, a - String)

In fact, that's exactly what the constructor of

  data Showable = forall b. Showable (b, b - String)

does:

  Showable :: ∀b. (b, b - String) - Showable

That's all there is to it. (To connect to TJ's original post, he 
basically wants a language where you don't have to write down this 
function  from  or  Showable  anymore, the compiler should infer it for 
you.)



Pattern matching is similar. For  Either A B , we have case expressions

  foobar :: Either A B - C
  foobar e = case e of
Left  a - foo a
Right b - bar b

You probably also know the Prelude function

  either :: ∀c. (A - c) - (B - c) - Either A B - c

In fact, the case expression can be seen as a syntactic convenience for 
the  either  function, any such pattern match with branches  foo  and 
bar  can be rewritten as


  foobar e = either foo bar e

(Exercise: Convince yourself that it's the same for the function  maybe 
. Exercise: Same for  foldr  (ok, ok, the situation is a bit different 
there).)


Now, ∃ also has a pattern match function. Naively, we would have to 
supply an infinite amount of branches


  match :: ∀c.
((A, A - String) - c)
 - ((B, B - String) - c)
 - ...
 - ∃a.(a, a - String) - c

but again, this is just one polymorphic branch

  match :: ∀c. (∀a. (a,a - String) - c) - ∃a.(a, a - String) - c

Again, this is what happens when using a case expression for

  data Showable = forall b. Showable (b, b - String)

  foobar :: Showable - C
  foobar s = case s of
  Showable fx - foo fx

 The branch  foo  must have a polymorphic type ∀a. (a,a - String) - 
C. That's all there is to understand pattern matching.



Of course, all this doesn't explain where existential types are useful. 
(TJ's post is one example but that's one of their least useful uses.) 
Actually, they show up rather seldom.



Peter Hercek wrote:

More generally, we have

  ∃a.(f a)= ∀b. (∀a.(f a) - b) - b


Is that by definition? Any pointers to an explanation why
they are valid?


The right hand side is exactly the type of the  match   function 
(without the last function argument). The idea is that this type can in 
fact be used as an implementation for ∃ , just like


  ∀c. (A - c) - (B - c) - c

can be used as an implementation for  Either A B .


Alfonso Acosta wrote:

The Haskell Wikibook is usually be helpful but unfortunately it wasn't
that clear in the case of existentials (for me at least). I think the
existentials article misses the clarity shown by aplemus' explanation
and furthermore does not cover the computing a value from an
existantial type directly. Maybe it would be a good idea to extend
it.


Yes please! At the moment, I don't have the time to polish the article 
or my e-mails myself. In any case, I hereby license my explanations 
about existentials under the terms noted on 
http://en.wikibooks.org/wiki/User:Apfelmus. (This also means that I 
don't allow to put them on the haskellwiki which has a more liberal 
license.)




Thanks for posting this, I finally understand existentials!


λ(^_^)λ


Regards,
apfelmus

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Paralellism

[Dominik Luecke]

Hello,

it looks quite similar, but it is not completely what I need, I rather
need something like

inParallel = parMap rwhnf

outList = inParallel (map f) listOfLists

If I use your construction on the first 2 elements of my list, I see
several threads working, but not in the other case.

Regards, 

 Dominik

On Thu, 2007-10-25 at 11:53 +0200, Alberto Ruiz wrote:
 Hello Dominik,
 
 I have used something like this and it worked very well:
 
 import Control.Parallel.Strategies
 
 inParallel = parMap rwhnf id
 
 [a,b] = inParallel [f x, g y]
 
 I hope it helps,
 
 Alberto
 
 On Thursday 25 October 2007 11:36, Dominik Luecke wrote:
  Hello,
 
  I am trying to use the code
 
  rels list =
  let
  o1 = (map makeCompEntry) $ head $ splitList list
  o2 = (map makeCompEntry) $ head $ tail $ splitList list
  o3 = (map makeCompEntry) $ head $ tail $ tail $ splitList list
  in
case (head $ tail $ tail $ tail $ splitList list) of
  [] - o1 `par` o2 `par` o3 `seq` o1 : o2 : o3 : []
  _  -
  let o4 = rels (head $ tail $ tail $ tail $ splitList list)
  in
o1 `par` o2 `par` o3 `par` o4 `seq`
o1 : o2 : o3 : o4
 
  to apply some operation on some lists in parallel. The input list list
  is quite long (about 10^17) entries, and I split it into chunks of 1000
  entries each. I am compiling with the options  -O2 --make -smp
  -threaded and when running the file with +RTS -N2 -sstderr -RTS, I
  see that only one worker thread is really doing anything. I am using a
  vanilla build of ghc-6.6.1 running on Ubuntu 7.10. I am currently
  wondering about what I am doing wrong.
 
  Regards,
   Dominik
-- 
Dominik Luecke Phone +49-421-218-64265
Dept. of Computer Science  Fax   +49-421-218-9864265
University of Bremen   [EMAIL PROTECTED]   
P.O.Box 330440, D-28334 Bremen
PGP-Key ID 0x2D82571B

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell Paralellism

[Simon Marlow]

Dominik Luecke wrote:

I am trying to use the code 

rels list = 
let 
o1 = (map makeCompEntry) $ head $ splitList list

o2 = (map makeCompEntry) $ head $ tail $ splitList list
o3 = (map makeCompEntry) $ head $ tail $ tail $ splitList list
in
  case (head $ tail $ tail $ tail $ splitList list) of


you've written 'splitList list' 4 times here.  The compiler might be clever 
enough to common them up, but personally I wouldn't rely on it.  Your code 
can be shortened quite a lot, e.g:


  let
  (o1:o2:o3:rest) = map makeCompEntry (splitList list)
  in
case rest of
  ...


[] - o1 `par` o2 `par` o3 `seq` o1 : o2 : o3 : []
_  - 
let o4 = rels (head $ tail $ tail $ tail $ splitList list)

in
  o1 `par` o2 `par` o3 `par` o4 `seq` 
  o1 : o2 : o3 : o4


without knowing what splitList and the rest of the program does, it's hard 
to say why you don't get any parallelism here.  But note that when you say:


o1 `par` o2 `par` o3 `seq` o1 : o2 : o3 : []

what this does is create sparks for o1-o3 before returning the list 
[o1,o2,o3].  Now, something else is consuming this list - if whatever 
consumes it looks at the head of the list first, then you've immediately 
lost the opportunity to overlap o1 with anything else, because the program 
is demanding it eagerly.


All this is quite hard to think about, and there is a serious lack of tools 
at the moment to tell you what's going on.  We do hope to address that in 
the future.


Right now, I suggest keeping things really simple.  Use large-grain 
parallelism, in a very few places in your program.  Use strategies - parMap 
is a good one because it hides the laziness aspect, you don't need to worry 
about what is getting evaluated when.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Josef Svenningsson]

On 10/24/07, Neil Mitchell [EMAIL PROTECTED] wrote:
 Hi

   Are there binary constants in Haskell, as
   we have, for instance, 0o232 for octal and
   0xD29A for hexadecimal?
 
  No, though it is an interesting idea.

 You can get pretty close with existing Haskell though:

 (bin 100010011)

 where bin :: Integer - Integer, and is left as an exercise for the
 reader. Obviously its not as high performance, as proper binary
 literals, but if you write them as top-level constants, they'll only
 be computed once and shouldn't end up being in the performance
 critical bits.

To make it efficient you could use Template Haskell and have the bin
function generate the constant which could then be spliced in. I
suppose it would look something like:
$(bin 100010011)

Not too bad.

/Josef
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] freebsd-7.0BETA1 and ghc

[Maxime Henrion]

brad clawsie wrote:
 On Wed, Oct 24, 2007 at 06:14:49PM -0400, Xiao-Yong Jin wrote:
  Is there any hope for it to be fixed before the freeze of
  ports tree? 
 
 i believe that is the purpose of the extended beta/rc period, to allow
 ports maintainers a chance to get things fixed before the main release
 
 as it stands a fix was submitted by a user but has not been entered
 into the main ports tree (yet):
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=117235 
 
 my impression of freebsd beta releases is that the term beta is not
 being casually applied (like google etc), but is a true cautionary label

I'll try to coordinate with fellow FreeBSD developers who are interested
in Haskell, in order to ensure we'll get GHC for FreeBSD 7 soon enough.
I am not sure however, that it will happen in time for 7.0-RELEASE.  The
ports freeze is currently planned for October 30.

Cheers,
Maxime
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Dusan Kolar]

Hello all,

 // PLS, no flame

 I think the question was not whether there's a way, how to handle the 
problem of encryption of a binary number to anything suitable and, more 
or less, readable by a human and transforming it to a binary form, but 
whether there's such a literal or not and whether it is bad idea to have 
something like 0b10111011.


 From my point of view, the difference between 0b10111011 and 
(bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters. Moreover, 
allowing ADA features for all numeric literals we could have 0b1011_1011 
;-) where the type would be Num a = a, of course.


 So, i would expect only two answers: NO, it is ...,  or YES, in 
version 6.9.0 it is possible. ;-)


 Dusan


Ketil Malde wrote:

Don Stewart [EMAIL PROTECTED] writes:

  

Are there binary constants in Haskell, as
we have, for instance, 0o232 for octal and
0xD29A for hexadecimal?
  


  

No, though it is an interesting idea.



Presumably it is less common since octal and hexadecimal are more
compact and almost as easy to interpret as bit patterns?  Why would
you want them?

Prelude let bin = foldl...
Prelude 0o232
154
Prelude bin [0,1,0, 0,1,1, 0,1,0]
154
Prelude 0xD29A
53914
Prelude bin [1,1,0,1, 0,0,1,0, 1,0,0,1, 1,0,1,0]
53914

-k
  


--

Dusan Kolartel: +420 54 114 1238
UIFS FIT VUT Brno  fax: +420 54 114 1270
Bozetechova 2   e-mail: [EMAIL PROTECTED]
Brno 612 66
Czech Republic

--

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Ketil Malde]

Dusan Kolar [EMAIL PROTECTED] writes:

  // PLS, no flame

I apologize if my post came across as such, that was certainly not the
intent. 

 I think the question was [..] whether there's such a literal or not
 and whether it is bad idea to have something like 0b10111011.

I agree.

  From my point of view, the difference between 0b10111011 and
 (bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.

And from my point of view, 0xEE or 0x273 are equally readable, and
even more succinct.  If you are into bit-twiddling, that is.  For
user-friendly bitfields you should obviously provide a higher level
interface.

  So, i would expect only two answers: NO, it is ...,  or YES, in
 version 6.9.0 it is possible. ;-)

As far as I know, there are no such plans.  Send in a patch and see if
it gets accepted :-)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Iavor Diatchki]

Hi,

We have no binary literals in Haskell and there are situations when it
would have been useful to have this feature (e.g., if the spec of
something that you are working with is already provided using this
notation).

While it may be useful to have overloaded binary literals in the usual
Haskell style, during my PhD work I found that it is also useful
(perhaps even more so) to add non-overloaded binary literals where the
number of digits in the literal determines its type.  The notation
that I used was B00010011 to be a literal of type Word8.  I chose this
notation over one like 0b00010011 because I think that the leading
zero is confusing (the literal usually has plenty of 0s already!).
Also, I like it that my notation suggests that the literals are the
constructors of the corresponding word type.

I think that binary literals are more useful when you work with fairly
short bit sequences, mixing and matching to make longer ones.
Unfortunately, in current Haskell we don't have a family of word types
but instead, a few predefined ones, the shortest of which is Word8, so
perhaps this notation is not so useful.   (I have encoded families of
word types in Haskell, but I think that having language support for
such things as in my work on bitdata, in bluespec, or cryptol is much
nicer).

Hope this helps!
-Iavor

On 10/25/07, Ketil Malde [EMAIL PROTECTED] wrote:
 Dusan Kolar [EMAIL PROTECTED] writes:

   // PLS, no flame

 I apologize if my post came across as such, that was certainly not the
 intent.

  I think the question was [..] whether there's such a literal or not
  and whether it is bad idea to have something like 0b10111011.

 I agree.

   From my point of view, the difference between 0b10111011 and
  (bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.

 And from my point of view, 0xEE or 0x273 are equally readable, and
 even more succinct.  If you are into bit-twiddling, that is.  For
 user-friendly bitfields you should obviously provide a higher level
 interface.

   So, i would expect only two answers: NO, it is ...,  or YES, in
  version 6.9.0 it is possible. ;-)

 As far as I know, there are no such plans.  Send in a patch and see if
 it gets accepted :-)

 -k
 --
 If I haven't seen further, it is by standing in the footprints of giants
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] lazily traversing a foreign data structure

[Graham Fawcett]

Hi folks,

I'm writing a Gnu DBM module as an exercise for learning Haskell and
its FFI. I'm wondering how I might write a function that returns the
database keys as a lazy list. I've wrapped the two relevant foreign
functions:

firstKey :: Ptr Db - IO (Maybe String)
nextKey  :: Ptr Db - String - IO (Maybe String)

NextKey takes a key, and returns the next one. Either function could
return Nothing, since the db may have 0 or 1 keys.

Given these, is it possible to write a (simple) function

allKeys :: Ptr Db - IO [String]

that lazily fetches the keys? (Or, an idiomatic way of achieving the
same end?)

Thanks,

Graham
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Existential types (Was: Type vs TypeClass duality)

[apfelmus]

Ryan Ingram wrote:

On 10/24/07, apfelmus [EMAIL PROTECTED] wrote:
So, instead of storing a list [∃a. Show a = a], you may as well 
store a

list of strings [String].


I've seen this before, and to some extent I agree with it, but it
breaks down for bigger examples due to sharing.

In most cases, x has a more compact representation than the result
of evaluating show x.  So if you keep a list of [show x, show y,
show z] around for a long period of time, you're leaking space.
Consider instead:

data StringFn where
   StringFn :: forall a. a - (a - String) - StringFn

applyStringFn :: StringFn - String
applyStringFn (StringFn a f) = f a

[ StringFn x show, StringFn y show, StringFn z show ]

Now, you use more time every time you compute the result, but StringFn
has a compact representation; you're not leaking the space used for
the string throughout the execution of the program, but only
allocating it while it's used.


Indeed. (Although the effect will be marginal in this particular 
example since the unevaluated thunk (show x) is represented as 
compactly as  x . But the time-space trade-off would matter when 
strings from the list are used several times.)


In a sense, that's also the reason why stream fusion à la Duncan + 
Roman + Don uses an existential type


  data Stream a where
Stream :: ∀s. s - (s - Step a s) - Stream a

  data Step a s = Done
| Yield a s
| Skip s

I mean, every stream can be represented by the list of its results but 
the observation for fusion is that there is a much more compact 
representation for the state (like an integer for [1..] or the source 
list in  map f . map g $ [x,y,...])


Regards,
apfelmus

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Stefan O'Rear]

On Thu, Oct 25, 2007 at 02:40:36PM +0200, Josef Svenningsson wrote:
 On 10/24/07, Neil Mitchell [EMAIL PROTECTED] wrote:
  Hi
 
Are there binary constants in Haskell, as
we have, for instance, 0o232 for octal and
0xD29A for hexadecimal?
  
   No, though it is an interesting idea.
 
  You can get pretty close with existing Haskell though:
 
  (bin 100010011)
 
  where bin :: Integer - Integer, and is left as an exercise for the
  reader. Obviously its not as high performance, as proper binary
  literals, but if you write them as top-level constants, they'll only
  be computed once and shouldn't end up being in the performance
  critical bits.
 
 To make it efficient you could use Template Haskell and have the bin
 function generate the constant which could then be spliced in. I
 suppose it would look something like:
 $(bin 100010011)

Eek.  Template Haskell is massive overkill for this, and requires that
every syntax author muddle with syntax trees.  The Right Way to handle
this is constant folding of user defined functions; although I'm not
sure what form such a mechanism would take.  Perhaps a pragma FOLD 1
saying that this function should always be inlined if the first argument
is ground?

Lack of general constant folding is a serious problem with GHC.  Much
overly-slow numerics code is due to x^2, which loops over the bitwise
structure of 2 each time.  If (^) was marked FOLD 2, then we would get
(after a small amount of the compiler's usual symbolic manipulations) x
* x.

Bitwise operations are not folded even if both arguments are ground.
This would require a few primitive rules for xorInt# and friends, but
you'd also need something like FOLD to bypass the checks in shiftR etc.

Perhaps some kind of termination analysis (well founded recursion on
presburger arithmetic could certainly handle (^) and bin, no clue how
hard something like that is to implement) is in order.

I see an alarming trend towards ad-hoc transformation patterns and
excessive use of syntactic abstraction, when we should just be using
Haskell's rich semantic structure.  Total functions, full laziness, and
compile time evaluation of finite non-bottom CAFs...

Stefan


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Claus Reinke]

  From my point of view, the difference between 0b10111011 and
 (bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.


how about using ghc's new overloaded strings for this?

   10111011::Binary

there used to be a way to link to ghc head's docs, but 
i can't find it right now. the test is 


http://darcs.haskell.org/testsuite/tests/ghc-regress/typecheck/should_compile/tc224.hs

and the xml docs would be

http://darcs.haskell.org/ghc/docs/users_guide/glasgow_exts.xml

claus


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Don Stewart]

claus.reinke:
   From my point of view, the difference between 0b10111011 and
  (bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.
 
 how about using ghc's new overloaded strings for this?
 
10111011::Binary
 
 there used to be a way to link to ghc head's docs, but 
 i can't find it right now. the test is 
 
 http://darcs.haskell.org/testsuite/tests/ghc-regress/typecheck/should_compile/tc224.hs
 
 and the xml docs would be
 
 http://darcs.haskell.org/ghc/docs/users_guide/glasgow_exts.xml

Why not use a Num instance for Binary, with fromInteger :: Integer - a,
Yielding,

10111011 :: Binary

Overloaded numeric literals seem better here than strings :)

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Don Stewart]

dons:
 claus.reinke:
From my point of view, the difference between 0b10111011 and
   (bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.
  
  how about using ghc's new overloaded strings for this?
  
 10111011::Binary
  
  there used to be a way to link to ghc head's docs, but 
  i can't find it right now. the test is 
  
  http://darcs.haskell.org/testsuite/tests/ghc-regress/typecheck/should_compile/tc224.hs
  
  and the xml docs would be
  
  http://darcs.haskell.org/ghc/docs/users_guide/glasgow_exts.xml
 
 Why not use a Num instance for Binary, with fromInteger :: Integer - a,
 Yielding,
 
 10111011 :: Binary
 
 Overloaded numeric literals seem better here than strings :)

Something like this:

import Data.List
import Data.Bits

newtype Binary = Binary Integer deriving (Eq, Show)

instance Num Binary where
fromInteger n = Binary . roll . map (read.return) . show $ n
  where
roll = foldl' unstep 0

unstep a 1 = a `shiftL` 1 .|. fromIntegral 1
unstep a 0 = a `shiftL` 1
unstep a _ = error Invalid character in binary literal

Yielding,

*A 0 :: Binary
Binary 0

*A 101 :: Binary
Binary 5

*A  :: Binary
Binary 15

*A 1010101011010111 :: Binary
Binary 43735

*A 42 :: Binary
Binary *** Exception: Invalid character in binary literal

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Derek Elkins]

On Thu, 2007-10-25 at 11:30 -0400, Graham Fawcett wrote:
 Hi folks,
 
 I'm writing a Gnu DBM module as an exercise for learning Haskell and
 its FFI. I'm wondering how I might write a function that returns the
 database keys as a lazy list. I've wrapped the two relevant foreign
 functions:
 
 firstKey :: Ptr Db - IO (Maybe String)
 nextKey  :: Ptr Db - String - IO (Maybe String)
 
 NextKey takes a key, and returns the next one. Either function could
 return Nothing, since the db may have 0 or 1 keys.
 
 Given these, is it possible to write a (simple) function
 
 allKeys :: Ptr Db - IO [String]
 
 that lazily fetches the keys? (Or, an idiomatic way of achieving the
 same end?)

Just use unsafeInterleaveIO in the obvious definition to read all the
keys.  That said, it's not called unsafeInterleaveIO for no reason.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Graham Fawcett]

On 10/25/07, Derek Elkins [EMAIL PROTECTED] wrote:
 On Thu, 2007-10-25 at 11:30 -0400, Graham Fawcett wrote:
  I'm writing a Gnu DBM module as an exercise for learning Haskell and
  its FFI. I'm wondering how I might write a function that returns the
  database keys as a lazy list. I've wrapped the two relevant foreign
  functions:
 Just use unsafeInterleaveIO in the obvious definition to read all the
 keys.  That said, it's not called unsafeInterleaveIO for no reason.


Ah thanks, that's just the thing. Safety warnings duly noted.

Graham
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: Math.OEIS 0.1

[Carl Witty]

On Mon, 2007-10-22 at 10:54 -0400, Brent Yorgey wrote:
 
 
 The Online Encyclopedia of Integer Sequences should really
 contain more
 Haskell code for describing the sequences. 
 
 Agreed!  I propose an OEIS party where we all sit around one day and
 submit Haskell code. =)
 
 (I'm only half joking...)

See
http://www.sagemath.org/hg/sage-main/file/cf44d55e626b/sage/combinat/sloane_functions.py
 for the very beginnings of an effort to write OEIS code in Python (for the 
SAGE computer algebra system).  (It looks like currently 130 sequences are 
implemented.)  Maybe this would be useful as a starting point.

The above hyperlink is for today's version of the file.  I couldn't
figure out how to link to the latest version, but this is an RSS feed
for updates to that file:
http://www.sagemath.org/hg/sage-main/rss-log/tip/sage/combinat/sloane_functions.py

Carl Witty


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Brandon S. Allbery KF8NH]

On Oct 25, 2007, at 13:04 , Derek Elkins wrote:


Just use unsafeInterleaveIO in the obvious definition to read all the
keys.  That said, it's not called unsafeInterleaveIO for no reason.


I think it might actually be safe in this case:  if the file changes  
out from under your lazy I/O, far worse things happen in the gdbm  
library layer than in the unsafe-IO Haskell layer.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Ryan Ingram]

On 10/25/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
 I think it might actually be safe in this case:  if the file changes
 out from under your lazy I/O, far worse things happen in the gdbm
 library layer than in the unsafe-IO Haskell layer.

Right, but if you do something like

do
  keys - getKeysLazy db
  [.. some computation A here that may or may not evaluate all the keys ..]
  addRow db newRow
  [.. some other computation B that uses the key list ..]

does B see the new row or not?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Brandon S. Allbery KF8NH]

On Oct 25, 2007, at 14:21 , Ryan Ingram wrote:


On 10/25/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:

I think it might actually be safe in this case:  if the file changes
out from under your lazy I/O, far worse things happen in the gdbm
library layer than in the unsafe-IO Haskell layer.


Right, but if you do something like

do
  keys - getKeysLazy db
  [.. some computation A here that may or may not evaluate all the  
keys ..]

  addRow db newRow
  [.. some other computation B that uses the key list ..]

does B see the new row or not?


My point is that there's no promise for that one *even in C*.  (The  
equivalent construct being adding the new row before nextKey has  
failed.)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Existential types (Was: Type vs TypeClass duality)

[Wouter Swierstra]

In a sense, that's also the reason why stream fusion à la Duncan +  
Roman + Don uses an existential type


  data Stream a where
Stream :: ∀s. s - (s - Step a s) - Stream a

  data Step a s = Done
| Yield a s
| Skip s


I thought there was a deeper reason for this, but I might be wrong.

You can represent all inductive types by their Church encoding. This  
basically identifies every inductive type with its fold.


You can do the same for terminal coalgebras and coinductive types,  
but things are a bit different. Suppose we define:


data CoFix f = In (f (CoFix f))

Then the unfold producing a value of type CoFix f has type:

forall a . (a - f a) - a - CoFix f

Now if my logic doesn't fail me, we can also write this as

(exists a . (a - f a, a)) - CoFix f

Using the co-Church encoding of colists yields the above Stream  
data type, where f corresponds to the Step data type. (The Skip  
constructor is a bit of a fix to cope with filter and friends).


Best,

  Wouter___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Henning Thielemann]

On Thu, 25 Oct 2007, Don Stewart wrote:

 claus.reinke:
 
  how about using ghc's new overloaded strings for this?
 
 10111011::Binary
 
  there used to be a way to link to ghc head's docs, but
  i can't find it right now. the test is
 
  http://darcs.haskell.org/testsuite/tests/ghc-regress/typecheck/should_compile/tc224.hs
 
  and the xml docs would be
 
  http://darcs.haskell.org/ghc/docs/users_guide/glasgow_exts.xml

 Why not use a Num instance for Binary, with fromInteger :: Integer - a,
 Yielding,

 10111011 :: Binary

 Overloaded numeric literals seem better here than strings :)

The result would be very unexpected - it reminds me much on C's octal
interpretation of all number literals starting with a 0.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Graham Fawcett]

On 10/25/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
 On Oct 25, 2007, at 14:21 , Ryan Ingram wrote:
  Right, but if you do something like
 
  do
keys - getKeysLazy db
[.. some computation A here that may or may not evaluate all the
  keys ..]
addRow db newRow
[.. some other computation B that uses the key list ..]
 
  does B see the new row or not?

 My point is that there's no promise for that one *even in C*.  (The
 equivalent construct being adding the new row before nextKey has
 failed.)

Just so. Deletions, for example, may change the ordering of the
internal hashtable (according to the gdbm manpage), making some keys
unfindable by a series of nextKey calls.

(If I were writing a serious module, and not just noodling around, I
imagine I'd document this, and let the user decide whether strict
evaluation was required.)

Thanks again to all,
Graham
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Henning Thielemann]

On Thu, 25 Oct 2007, Stefan O'Rear wrote:

 On Thu, Oct 25, 2007 at 02:40:36PM +0200, Josef Svenningsson wrote:
  On 10/24/07, Neil Mitchell [EMAIL PROTECTED] wrote:
  
   You can get pretty close with existing Haskell though:
  
   (bin 100010011)
  
   where bin :: Integer - Integer, and is left as an exercise for the
   reader. Obviously its not as high performance, as proper binary
   literals, but if you write them as top-level constants, they'll only
   be computed once and shouldn't end up being in the performance
   critical bits.
  
  To make it efficient you could use Template Haskell and have the bin
  function generate the constant which could then be spliced in. I
  suppose it would look something like:
  $(bin 100010011)

 Eek.  Template Haskell is massive overkill for this, and requires that
 every syntax author muddle with syntax trees.  The Right Way to handle
 this is constant folding of user defined functions; although I'm not
 sure what form such a mechanism would take.  Perhaps a pragma FOLD 1
 saying that this function should always be inlined if the first argument
 is ground?

Generally I prefer to solve such problems within Haskell instead of
blowing up the language. If at all number literals are supported, then
that should be done in a consistent manner. E.g. in Modula-3 you write
2_1, 8_20, 16_10, for a binary, octal, hexadecimal number.
 http://www.cs.tut.fi/lintula/manual/modula3/m3defn/html/numbers.html
   I can't remember that I ever used this feature, because Modula-3 has
much better support for bit oriented data, namely bit sets. In Haskell we
could achieve the same with an appropriate library.
  (bin 11002000) would not yield a compile time error, but due to its
seldom usage this might be ok. I vote for this approach.

 Lack of general constant folding is a serious problem with GHC.  Much
 overly-slow numerics code is due to x^2, which loops over the bitwise
 structure of 2 each time.  If (^) was marked FOLD 2, then we would get
 (after a small amount of the compiler's usual symbolic manipulations) x
 * x.

I hoped GHC did this all the time. :-(

 I see an alarming trend towards ad-hoc transformation patterns and
 excessive use of syntactic abstraction, when we should just be using
 Haskell's rich semantic structure.

Agreed!

 Total functions, full laziness, and compile time evaluation of finite
 non-bottom CAFs...

If I write a program that approximates a big but fixed number of digits of
Pi - how can we prevent the compiler from computing Pi, and generating a
program which contains just the digits of Pi as constant data?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Stefan O'Rear]

On Thu, Oct 25, 2007 at 09:41:27PM +0200, Henning Thielemann wrote:
  Total functions, full laziness, and compile time evaluation of finite
  non-bottom CAFs...
 
 If I write a program that approximates a big but fixed number of digits of
 Pi - how can we prevent the compiler from computing Pi, and generating a
 program which contains just the digits of Pi as constant data?

-O0

Stefan


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[Henning Thielemann]

On Thu, 25 Oct 2007, Stefan O'Rear wrote:

 On Thu, Oct 25, 2007 at 09:41:27PM +0200, Henning Thielemann wrote:
   Total functions, full laziness, and compile time evaluation of finite
   non-bottom CAFs...
 
  If I write a program that approximates a big but fixed number of digits of
  Pi - how can we prevent the compiler from computing Pi, and generating a
  program which contains just the digits of Pi as constant data?

 -O0

The compiled program should run fast nevertheless ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: Math.OEIS 0.1

[Jacques Carette]

Carl Witty wrote:
On Mon, 2007-10-22 at 10:54 -0400, Brent Yorgey wrote:
The Online Encyclopedia of Integer Sequences should really

contain more
Haskell code for describing the sequences. 


Agreed!  I propose an OEIS party where we all sit around one day and
submit Haskell code. =)

(I'm only half joking...)
  


See
http://www.sagemath.org/hg/sage-main/file/cf44d55e626b/sage/combinat/sloane_functions.py
 for the very beginnings of an effort to write OEIS code in Python (for the 
SAGE computer algebra system).  (It looks like currently 130 sequences are 
implemented.)  Maybe this would be useful as a starting point.
  



This is a bit of a waste of human time, especially since automated 
methods (like gfun [1]) can automatically find closed-forms for about 
1/3 of the sequences on OEIS.  Generating code from the output of gfun 
is an easy task, and leads to rather pretty results [2], in my 
completely biased opinion.  Very very few of the sequences outside of 
that 1/3 has known programs associated with them.


Now, using many of Jerzy Karczmarczuk's ideas [3] and Haskell packages, 
one could rewrite gfun in Haskell, and the end result would likely be 
extremely elegant, although making it efficient might be rather more 
challenging.


Jacques

[1] http://portal.acm.org/citation.cfm?id=178368 and 
http://algo.inria.fr/libraries/

[2] http://www.cas.mcmaster.ca/~carette/publications/CaretteJanicki.pdf
[3] http://users.info.unicaen.fr/~karczma/arpap/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazily traversing a foreign data structure

[Ryan Ingram]

On 10/25/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
 My point is that there's no promise for that one *even in C*.  (The
 equivalent construct being adding the new row before nextKey has
 failed.)

Sure, but in C, it's highly likely that the full evaluation of the key
list happens in one place, that's just how code tends to get written.
That said, in C code, I've often seen bugs where code called during
the iteration of a collection modifies that collection; that's
something that has been really refreshing to get away from when
writing Haskell.

With the unsafeInterleaveIO example, the pure keylist could get
deferred indefinitely, stored in a data structure, partially evaluated
at many different times against many different versions of the
database, etc., and it's not necessarily clear to the person who just
has a [Key] that they are doing deferred calls to nextKey like it
tends to be in C.

It's safe if you use it in a predictable fashion, and in a real API
I'd probably provide getKeys and unsafeLazyGetKeys and let the
programmer decide.

  -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] List comprehension order of evaluation

[Maurí­cio]

Hi,

Today, if I write:

[a:[b] | a-ab , b-12]

I get:

[a1,a2,b1,b2]

Are there any guarantees that I'll never
get [a1,b1,a2,b2] instead, i.e.,
that the first list will always be the
last one to be fully transversed? Even
if I use a different compiler or a
future version of Haskell?

Reading how list comprehensions are
translated in the Haskell report it
seems the answer is yes. Is that
written in stone? Can compilers do
it in their own different way?

Thanks,
Maurício

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List comprehension order of evaluation

[Jonathan Cast]

On Thu, 2007-10-25 at 19:59 -0200, Maurí­cio wrote:
 Hi,
 
 Today, if I write:
 
 [a:[b] | a-ab , b-12]
 
 I get:
 
 [a1,a2,b1,b2]
 
 Are there any guarantees that I'll never
 get [a1,b1,a2,b2] instead, i.e.,
 that the first list will always be the
 last one to be fully transversed? Even
 if I use a different compiler or a
 future version of Haskell?

 Reading how list comprehensions are
 translated in the Haskell report it
 seems the answer is yes.

Correct.

  Is that
 written in stone?

Yes.  It's a consequence of the MonadPlus law (for [] and other
non-determinism monads)

(xn `mplus` ys) = f = (xn = f) `mplus` (ys = f)

which implies

  [ f x y | x - xn ++ xn', y - ys]
= [ f x y | x - xn, y - ys] ++ [ f x y | x - xn', y - ys]

(This rule plus the monad laws plus the natural transformation law for
return

  map f (return x) = return (f x)

provides a complete calculation system for list comprehensions, btw.
And those laws are all very much set in stone.)

  Can compilers do
 it in their own different way?

No.

jcc

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List comprehension order of evaluation

[Thomas Hartman]

If I understand list comprehensions correctly, what you wrote is the same
as

do a - ab;
  b - 12;
  [a:[b]]

which is the same as

ab == \a - do b - 12; [a:[b]]

which is the same as

ab = \a - 12 = \b - [a:[b]]

which is the same as

concat $ map  (  \a - 12 = \b - [a:[b]] ) ab

 enough desugaring for now

Point is, yes it's written in stone.

List comprehensions is just syntactic sugar for monad operations.

Good exercise is to take the above expressions and add parenthesis to make
it easier to understand order of operations. (Still trips me up often
enough).

Thomas.





Maurí­cio [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/25/2007 05:59 PM

To
haskell-cafe@haskell.org
cc

Subject
[Haskell-cafe] List comprehension order of evaluation






Hi,

Today, if I write:

[a:[b] | a-ab , b-12]

I get:

[a1,a2,b1,b2]

Are there any guarantees that I'll never
get [a1,b1,a2,b2] instead, i.e.,
that the first list will always be the
last one to be fully transversed? Even
if I use a different compiler or a
future version of Haskell?

Reading how list comprehensions are
translated in the Haskell report it
seems the answer is yes. Is that
written in stone? Can compilers do
it in their own different way?

Thanks,
Maurício

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



---

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[John Meacham]

On Thu, Oct 25, 2007 at 04:06:56PM +0200, Dusan Kolar wrote:
 Hello all,
 
  // PLS, no flame
 
  I think the question was not whether there's a way, how to handle the 
 problem of encryption of a binary number to anything suitable and, more 
 or less, readable by a human and transforming it to a binary form, but 
 whether there's such a literal or not and whether it is bad idea to have 
 something like 0b10111011.

I have often wanted this feature too. I think the only complaint someone
might have is that 'b' is also a valid hexadecimal character, which
can be confusing if the number is out of context. 

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary constants in Haskell

[John Meacham]

On Thu, Oct 25, 2007 at 09:52:27AM -0700, Don Stewart wrote:
 dons:
  claus.reinke:
 From my point of view, the difference between 0b10111011 and
(bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.
   
   how about using ghc's new overloaded strings for this?
   
  10111011::Binary
   
   there used to be a way to link to ghc head's docs, but 
   i can't find it right now. the test is 
   
   http://darcs.haskell.org/testsuite/tests/ghc-regress/typecheck/should_compile/tc224.hs
   
   and the xml docs would be
   
   http://darcs.haskell.org/ghc/docs/users_guide/glasgow_exts.xml
  
  Why not use a Num instance for Binary, with fromInteger :: Integer - a,
  Yielding,
  
  10111011 :: Binary
  
  Overloaded numeric literals seem better here than strings :)
 
 Something like this:
 
 import Data.List
 import Data.Bits
 
 newtype Binary = Binary Integer deriving (Eq, Show)
 
 instance Num Binary where
 fromInteger n = Binary . roll . map (read.return) . show $ n
   where
 roll = foldl' unstep 0
 
 unstep a 1 = a `shiftL` 1 .|. fromIntegral 1
 unstep a 0 = a `shiftL` 1
 unstep a _ = error Invalid character in binary literal
 
 Yielding,
 
 *A 0 :: Binary
 Binary 0
 
 *A 101 :: Binary
 Binary 5
 
 *A  :: Binary
 Binary 15
 
 *A 1010101011010111 :: Binary
 Binary 43735
 
 *A 42 :: Binary
 Binary *** Exception: Invalid character in binary literal

This would have some decidedly weird consequences

fromIntegral (6::Int) :: Binary
Binary *** Exception: Invalid character in binary literal

and that constant 6 can be somewhere far removed from the actual binary
cast.

also, 
fromInteger (toInteger x + toInteger y ) :: Binary /= x + y

all sorts of oddness will result.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Unfoldr love

[Justin Bailey]

In my best Homer Simposon voice - unfoldr - is there anything it can't do?

I have strange unfoldr love right now. I'm probably too impressed by
this function, but it takes a string and splits it into a list of
words, while keeping quoted phrases together:

import Data.List

phrasesAndWords :: String - [String]
phrasesAndWords =
  let startsWith w c = [c] `isPrefixOf` w
  endsWith w c = [c] `isSuffixOf` w
  buildPhrases [] = Nothing
  buildPhrases (w:ws)
| w `startsWith` '' = -- A word starts with a '', now
look for ending ''
let (p, rest) = break (`endsWith` '') (w:ws)
in
  case () of
() | null p - Just ((init . tail) w, ws) --
single word in quotes
   | null rest - Just ((tail . unwords) p, rest)
-- No ending quote
   -- Some amount of words in the phrase and some not
   | otherwise - Just ((init . tail) (unwords (p
++ [head rest])), tail rest)
| otherwise = Just (w, ws)
  in
-- Use of words makes sure any valid quotes appear at beginning or
-- end of a word.
unfoldr buildPhrases . words

Of course it's not a full parser (no nested quotes or escaping) but
who would think unfoldr could do that?

Justin

p.s. Style comments, improvements welcome.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell Weekly News: October 25, 2007

[Don Stewart]

---
Haskell Weekly News
http://sequence.complete.org/hwn/20071025
Issue 66 - October 25, 2007
---

   Welcome to issue 66 of HWN, a newsletter covering developments in the
   [1]Haskell community.

   A huge month for the Haskell community, with the Haskell Workshop,
   ICFP and CUFP conferences, the second international Haskell Hackathon,
   and 63 libraries and tools uploaded to hackage! A round of applause to
   everyone involved!

   1. http://haskell.org/

Hackage

   This week's new libraries in [2]the Hackage library database.

   2. http://hackage.haskell.org/

 * SDL 0.5.0. Uploaded by Lemmih. [3]SDL, a binding to libSDL.

 * Stream 0.2.1. Uploaded by Wouter Swierstra. [4]Stream, functions,
   analogous to those from Data.List, to create and manipulate
   infinite lists

 * bktrees 0.1.1. Uploaded by Josef Svenningsson. [5]bktrees,
   Burhard-Keller trees provide an implementation of sets which apart
   from the ordinary operations also has an approximate member
   search, allowing you to search for elements that are of a certain
   distance from the element you are searching for.

 * happy 1.17. Uploaded by Simon Marlow. [6]happy, a parser generator
   for Haskell.

 * HaXml 1.19. Uploaded by Malcolm Wallace. [7]HaXml, utilities for
   parsing, filtering, transforming and generating XML documents.

   3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-0.5.0
   4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.2.1
   5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bktrees-0.1.1
   6. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happy-1.17
   7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml-1.19

 * polyparse 1.1. Uploaded by Malcolm Wallace. [8]polyparse, A
   variety of alternative parser combinator libraries, including the
   original HuttonMeijer set. The Poly sets have features like good
   error reporting, arbitrary token type, running state, lazy
   parsing, and so on. Finally, Text.Parse is a proposed replacement
   for the standard Read class, for better deserialisation of Haskell
   values from Strings.

 * bzlib 0.4.0.1 . Uploaded by Duncan Coutts. [9]bzlib, compression
   and decompression in the bzip2 format.

 * zlib 0.4.0.1. Uploaded by Duncan Coutts. [10]zlib, compression and
   decompression in the gzip and zlib formats

 * tar 0.1.1.1. Uploaded by Bjorn Bringert. [11]tar, a library for
   reading and writing TAR archives.

 * unix-compat 0.1.2.0. Uploaded by Bjorn Bringert. [12]unix-compat,
   provides portable implementations of parts of the unix package.
   This package re-exports the unix package when available. When it
   isn't available, portable implementations are used.

   8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/polyparse-1.1
   9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib-0.4.0.1
  10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.4.0.1
  11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tar-0.1.1.1
  12. 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-compat-0.1.2.0

 * oeis 0.1. Uploaded by Brent Yorgey. [13]oeis, Haskell interface to
   the Online Encyclopedia of Integer Sequences.

 * dataenc 0.9. Uploaded by Magnus Therning. [14]dataenc, Data
   encoding library currently providing Uuencode, Base64, Base64Url,
   Base32, Base32Hex, and Base16.

 * cabal-setup 1.2.1. Uploaded by Simon Marlow. [15]cabal-setup,
   cabal-setup is a user interface to Cabal. It provides the basic
   commands for configuring, building, and installing Cabal packages.

 * cabal-install 0.4.0. Uploaded by [EMAIL PROTECTED]
   [16]cabal-install, apt-get like tool for Haskell. The 'cabal'
   command-line program simplifies the process of managing Haskell
   software by automating the fetching, configuration, compilation
   and installation of Haskell libraries and programs.

 * HTTP 3001.0.0. Uploaded by Bjorn Bringert. [17]HTTP, A library for
   client-side HTTP.

  13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/oeis-0.1
  14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.9
  15. 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-setup-1.2.1
  16. 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install-0.4.0
  17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP-3001.0.0

 * iconv 0.4. Uploaded by Duncan Coutts. [18]iconv, provides an
   interface to the POSIX iconv library functions for string encoding
   conversion.

 * binary 0.4.1. Uploaded by the Binary Strike Team. [19]binary,
   efficient

Re: [Haskell-cafe] Re: Hiding side effects in a data structure

[John Meacham]

On Tue, Oct 23, 2007 at 10:01:37AM +0100, Jon Fairbairn wrote:
 That sort of misses my point. Given the length of time I've
 been involved with it, I hardly need encouragement to use
 Haskell, but if even I find getting to the documentation
 off-putting, having to know a trick to do it isn't exactly
 going to draw the reluctant programmer away from its bad
 language habits.

Heh, the plethora of pdf papers on Haskell is part of what originally
brought me to respect it. Something about that metafont painted cmr
just makes me giddy as a grad student. A beautifully rendered type
inference table is a masterful work of art.

Did I mention I was a little odd? I am sure I did.

John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe