date:20091209

Yes, I was referring to CCG. Thank you.

--
From: "John Lask" 
Sent: 09 Wednesday December 2009 1920
To: "John D. Earle" 
Cc: "Haskell Cafe" 
Subject: Re: [Haskell-cafe] Natural Language Processing

maybe this helps ...
see http://www.cs.chalmers.se/~aarne/GF/

I quote from the web site: GF is

"a categorial grammar formalism, like ACG, CCG, but different and 
equipped with different tools"

it compiles with at least GHC 6.8.2

Is Parsec capable of parsing a mildly context sensitive language? In 
particular does it parse a combinatory categorial grammar? Does Haskell 
have such tools in its shed? What sort of facilities does Haskell have 
for natural language processing?

___
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] Natural Language Processing

2009-12-09 Thread John Lask


maybe this helps ...
see http://www.cs.chalmers.se/~aarne/GF/

I quote from the web site: GF is

"a categorial grammar formalism, like ACG, CCG, but different and 
equipped with different tools"


it compiles with at least GHC 6.8.2

Is Parsec capable of parsing a mildly context sensitive language? In 
particular does it parse a combinatory categorial grammar? Does Haskell 
have such tools in its shed? What sort of facilities does Haskell have 
for natural language processing?
 
 





___
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] Natural Language Processing

2009-12-09 Thread John Meacham

On Wed, Dec 09, 2009 at 06:11:04PM -0700, John D. Earle wrote:
> Is Parsec capable of parsing a mildly context sensitive language? In
> particular does it parse a combinatory categorial grammar? Does
> Haskell have such tools in its shed? What sort of facilities does
> Haskell have for natural language processing?

The happy parser generator now has a GLR mode, which allows parsing of
ambiguous grammers such as occur in natural languages. It uses clever
representation to avoid space issues with storing the large number of
possible parse trees. I believe NLP was one of the main motivations of
the feature but am not sure. I too am interested in lightweight NLP in
haskell but have not had time to put into it. I'd be curious what you
come up with.

http://www.haskell.org/happy/doc/html/sec-glr.html

John

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

[Haskell-cafe] Re: Re: Re: Allowing hyphens in identifiers

2009-12-09 Thread Maciej Piechotka

On Wed, 2009-12-09 at 15:54 -0800, Gregory Crosswhite wrote:
> On Dec 9, 2009, at 3:24 PM, Maciej Piechotka wrote:
> 
> > On Thu, 2009-12-10 at 11:54 +1300, Richard O'Keefe wrote:
> > - Composition: In which first letters are not capitalized
> > 
> > In combination of those I belive there is no disambiguoty since the
> > lower case words functions as terminators. 
> 
> Except for data constructors, which are a special class of functions that 
> start with capital letters;  this where an ambiguity can (and does) crop up 
> that is resolved by the spacing rule.
> 
> Cheers,
> Greg

You're right. However it is still rather rare case comparing to the use
of - I belive. Epsecially that with - we already have sufficiently
complicated paring rules [($), ($a), (a$) where $ is any operator except
- vs. -]

Regards


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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

Interesting point. I'll have to try what you suggested. A proportional font 
would lessen the need to align things up vertically. It is annoying from a 
typographical stand point when things are almost aligned, but a tad off and 
so I must admit that I am guilty as charged. Monospaced fonts encourage this 
condition.


--
From: "Evan Laforge" 
Sent: 09 Wednesday December 2009 1847
To: "John D. Earle" 
Cc: "Haskell Cafe" 
Subject: Re: [Haskell-cafe] Re: Allowing hyphens in identifiers


On Wed, Dec 9, 2009 at 3:26 PM, John D. Earle  wrote:

The problem that I see with elision resulting in juxtaposition is that it
would alter the layout. Each line would not have the same number of
characters before and after the makeover. Visual appearance would also be
altered. Replacing hyphens with underscores as I originally proposed


As long as we're pushing pet peeves: don't line things up vertically
then.  If you use a newline and add a tab level you can still use
layout and not have this problem.  You wind up with less indentation
too, though occasionally more vertical space.  And you can use
proportional fonts if you want.  And you can use editor indent/dedent
commands without the editor having to understand haskell.  Etc.

My pet peeve is having to lean on the space bar while squinting at the
screen because someone wants to line things up vertically. 


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

Re: [Haskell-cafe] Re: Handles with their IOMode in their type

2009-12-09 Thread Brandon S. Allbery KF8NH


On Dec 9, 2009, at 16:51 , Bas van Dijk wrote:

I will change the types to:

stdin :: Handle ReadMode
stdout :: Handle WriteMode
stderr :: Handle WriteMode

Or are there scenarios where people want to write to stdin or read
from stdout or stderr?



These situations *do* come up; the controlling terminal for a program  
is open read/write on all 3 file descriptors initially, ands programs  
like more/less/pg rely on this and do their I/O on stdout.   
Additionally, on *BSD pipes are actually socketpairs and therefore  
bidirectional, and a small number of programs rely on this.


But I would not do that by default, just expose a way for programs to  
make it so if they wish.


(Hm, just discovered that the System.Posix.IO wrapper for fcntl() does  
*not* expose the part of the result of F_GETFL that reports the open  
mode.  Boo hiss.)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsec-like parser combinator that handles left recursion?

2009-12-09 Thread Nils Anders Danielsson


On 2009-12-09 18:50, Dan Doel wrote:

(Your parsers aren't PEGs, are they? If so, I apologize for the
redundancy.)


No, my parsers use Brzozowski derivatives.

See the related work section of the paper I mentioned for some other
parser combinator libraries which can handle (some) left recursive
grammars.

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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

2009-12-09 Thread Evan Laforge

On Wed, Dec 9, 2009 at 3:26 PM, John D. Earle  wrote:
> The problem that I see with elision resulting in juxtaposition is that it
> would alter the layout. Each line would not have the same number of
> characters before and after the makeover. Visual appearance would also be
> altered. Replacing hyphens with underscores as I originally proposed

As long as we're pushing pet peeves: don't line things up vertically
then.  If you use a newline and add a tab level you can still use
layout and not have this problem.  You wind up with less indentation
too, though occasionally more vertical space.  And you can use
proportional fonts if you want.  And you can use editor indent/dedent
commands without the editor having to understand haskell.  Etc.

My pet peeve is having to lean on the space bar while squinting at the
screen because someone wants to line things up vertically.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Re: Allowing hyphens in identifiers



On Dec 10, 2009, at 12:24 PM, Maciej Piechotka wrote:
[it appears that I have been misinformed about "." vs " . "]


Personally I don't have any strong feelings about conventions as  
long as

they are consistent within one language. Camel cases are no more
uncommon then the underscore and they saved space in the past (ok. now
it does not matter) and hyphen is very rarly used (to not have problem
with minus).


baStudlyCase was *never* about saving space.
It was copied from Smalltalk by people who failed to realise that
Smalltalk did it that way because the Smalltalk character set didn't
_have_ an underscore.

Nor is being "uncommon" the issue.



For example:
- Java - camel cases both in classes and methods (convention very
similar to Haskell)


which is why I have something similar to my little hspp tool for
reading and writing Java.

The fact that other people do something ill-considered is no reason
why we have to follow them.  Your own list of languages shows that
baStudlyCase is not universal.

For that matter, the Interlisp and S convention was to separate
words in an identifier with dots.

(once again, every runTogetherWord inThisMessage is flagged as a
spelling mistake...)

Thanks to GHC's -F and -pgmF options, people can now choose
whether to writeInAnUnreadableAndUglyStyle or not.  Brilliant!


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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers



On Dec 10, 2009, at 12:05 PM, Deniz Dogan wrote:


2009/12/9 Richard O'Keefe :


Here is such a preprocessor.  This is meant for people to try out.
I don't claim that it's perfect, it's just a quick hack.



Is there any flag I can pass to e.g. GHC to make it use the
preprocessor automagically or do I write my own little hack to apply
the preprocessor?


It's amazing what you find in the manual:
-F  
runs a custom preprocessor.
Let the source file be $S.
First, literate Haskell processing is done,
producing $L.
Then  "$S" "$L" "$O" is run,
where $O is where GHC wants your program to
write its output.
GHC then reads $O.

-pgmF cmd
tells GHC to use cmd as the custom preprocessor.

My little hspp was written before I realised this could be done,
so I had to whip up
#!/bin/sh
exec hspp <"$2" >"$3"
and use that.
Sample session:

m% cat main.hs
main = print (take-while (<10) [1..])
m% ghc -F -pgmF hspp.sh main.hs
m% a.out
[1,2,3,4,5,6,7,8,9]

If there isn't a GHC option to count the dragons in the moon,
there soon will be.

One option that would be nice would be accepting -help as well
as --help.

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

[Haskell-cafe] Natural Language Processing

Is Parsec capable of parsing a mildly context sensitive language? In particular 
does it parse a combinatory categorial grammar? Does Haskell have such tools in 
its shed? What sort of facilities does Haskell have for natural language 
processing?

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

[Haskell-cafe] Re: OpenAL and Hsndfile

2009-12-09 Thread jean legrand

a while ago, I wrote a minimal and inefficient code to generate and play an 
audible 4-second-sine sound 
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1538
Can you hear something with it ?



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

Re: [Haskell-cafe] Nano-Languages

I delved a little more deeper into 
http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf. I'm uncertain if I am 
able to understand the value of what its authors are proposing. The emphasis 
appears to be on extending the syntax of the language at runtime, but like 
so what. My impression after skimming a portion of the paper is they are 
advocating a bottom up approach whereas I am advocating a top down approach. 
Our orientation appears to be different. 


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

Re: [Haskell-cafe] forkSequence, runPar, parallelize

2009-12-09 Thread Mario Blažević

> 
> >        I can't test it right now, but wouldn't the
> > following do the job in the Identity monad?
> 
> > forkExec :: Identity a -> Identity (Identity a)
> > forkExec k = let result = runIdentity k
> >             in result `par` return (Identity result)
> 
> 
> Since Identity is a newtype, would that be equivalent to "result `par`
> result"? The forkExec in the IO monad let's other computations keep
> going until I need the result from the forked computation.


You're right, it doesn't seem to work the way I hoped. The equivalent function 
on
Maybe monad works, though, so it is possible to write forkExec in monads other
than IO.

> In a pure computation, I can already get the same result with `par`
> and laziness, right?

Yes. The goal is to enable writing monadic parallel computations which work 
under
any parallelizable monad. For example, I'm using it to run two trampolining
producer/consumer coroutines in parallel. A large majority of interesting
coroutines I have are completely agnostic with respect to the underlying monad.


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

Re: [Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1

2009-12-09 Thread James Hall

2009/12/9 Richard O'Keefe 

>
> On Dec 10, 2009, at 2:58 AM, Roel van Dijk wrote:
>
>> I tried to be conservative with the choice of unicode symbols. I have
>> defined the division sign (÷) to be (/). But it could just as well be
>> defined as 'div'.
>>
>
> No it couldn't.  One expects 3÷2 to be 1½, not 1.
> You will, for example, find this text on the web:
> "Mathematically, the division sign is equivalent to the forward slash.
> Thus, for example, 4 ÷ 5 = 4/5 = 0.8"
> This is actually historically backwards.  When I was a nipper,
> 1/6 meant "one and six" or "eighteen pence" or at least three
> loaves of good bread.  As far as I'm aware, the use of "/"
> instead of "÷" is a computerism introduced in the days of 6 bit
> character sets.
>
>
>  Another choice that could lead to some discussion is the definition of
>> (⊂) to be 'Data.Set.isProperSubsetOf' and (⊆) to be
>> 'Data.Set.isSubsetOf'. An alternative choice would be to have (⊊) for
>> 'isProperSubsetOf' and (⊂) for 'isSubsetOf'.
>>
>
> Mathematicians may use the plain horseshoe for either subset or
> proper subset, depending on the author.  But I've never ever seen
> anyone use the horseshoe with an equals bar for proper subset;
> that would really make no sense.
>

The second notation uses a horseshoe with an equals bar and a _slash_
through it to indicate proper subset, and I have seen that several times
before; however, I prefer the first notation style.


>
> I suggest that you take the Z formal specification language as your
> guide (plain horseshoe is proper subset, horseshoe with equal bar is
> subset-or-equal).  If you don't like Z, try B:  same thing.
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] forkSequence, runPar, parallelize

2009-12-09 Thread Dan Weston

It's a good thing then that forkExec and return are denotationally equal 
(though not operationally). Otherwise, I'd be worried.


Matthew Brecknell wrote:

Antoine Latter wrote:

A similar function that I'm fond of:

forkExec :: IO a -> IO (IO a)


It's cute that forkExec already has a dual operation with just the right
name (specialised to IO):

join :: IO (IO a) -> IO a



___
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: Re: Allowing hyphens in identifiers

2009-12-09 Thread Gregory Crosswhite

On Dec 9, 2009, at 3:24 PM, Maciej Piechotka wrote:

> On Thu, 2009-12-10 at 11:54 +1300, Richard O'Keefe wrote:
> - Composition: In which first letters are not capitalized
> 
> In combination of those I belive there is no disambiguoty since the
> lower case words functions as terminators. 

Except for data constructors, which are a special class of functions that start 
with capital letters;  this where an ambiguity can (and does) crop up that is 
resolved by the spacing rule.

Cheers,
Greg

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

Re: [Haskell-cafe] Nano-Languages

Stefan, I managed to look at the paper and yeah you may be onto something. I 
am certainly open to ideas. Looks promising. There needs to be a standard 
way to extend the language without having to concern oneself with everything 
that goes under the hood. There is certainly an interest in this. It is like 
what everyone wants for Christmas.


--
From: "Stefan Holdermans" 
Sent: 09 Wednesday December 2009 1536
To: "John D. Earle" 
Cc: "Haskell Cafe" 
Subject: Re: [Haskell-cafe] Nano-Languages


John,

It might be better to go about it in a fashion similar to how one  would 
use Haskell to create a new language using Happy, but instead  of making 
a full fledged language create a language that makes only  minor 
adjustments to the official language where most of the  original source 
code and command line options are copied verbatim  with a handful of 
things caught such as the Richard O'Keefe newtype,  a nano-language if 
you will. Actually I have known about this  possibility for years. There 
is always something you would like to  change about whatever language you 
are working with and so I have  put thought into it.


What about¯syntax macros? 
http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf


Cheers,

  Stefan 


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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

The problem that I see with elision resulting in juxtaposition is that it 
would alter the layout. Each line would not have the same number of 
characters before and after the makeover. Visual appearance would also be 
altered. Replacing hyphens with underscores as I originally proposed would 
alleviate both of these problems.


There is also the matter of canonicalization for the purposes of comparing 
identifiers. Would it be wise for the a version that lacks hyphens be 
regarded as equivalent to one that does?


--
From: "Richard O'Keefe" 
Sent: 09 Wednesday December 2009 1554
To: "Maciej Piechotka" 
Cc: 
Subject: Re: [Haskell-cafe] Re: Allowing hyphens in identifiers



On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote:

You mean to parse a - b differently then a-b? You don't have the
problem
in LISP as AFAIR you use (- a b) but in Haskell it would be a problem.


It's a problem that COBOL solved a long time ago:
COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME.
Haskell already has this problem with ".", where we generally need
to put spaces around "." with the meaning "composition" and not
put spaces around other uses.

This is something someone could easily try out by writing a trivial
preprocessor to convert hyphens with letters on each side to
underscores.  See how it works.

Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might
be nice to have a wee preprocessor that turned
 _ 
into  

so that I could write take_while and Haskell could see takeWhile.
[I'm writing this in MacOS X Mail.  "takeWhile" is underlined in
red as a spelling mistake, "take_while" is not.  Maybe they know
something...]

Here is such a preprocessor.  This is meant for people to try out.
I don't claim that it's perfect, it's just a quick hack.














___
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: Re: Allowing hyphens in identifiers

2009-12-09 Thread Maciej Piechotka

On Thu, 2009-12-10 at 11:54 +1300, Richard O'Keefe wrote:
> On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote:
> > You mean to parse a - b differently then a-b? You don't have the  
> > problem
> > in LISP as AFAIR you use (- a b) but in Haskell it would be a problem.
> 
> It's a problem that COBOL solved a long time ago:
>   COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME.
> Haskell already has this problem with ".", where we generally need
> to put spaces around "." with the meaning "composition" and not
> put spaces around other uses.
> 

Well. http://en.wikipedia.org/wiki/Backward_compatibility

About '.' - there are two contexts in which it is used:
- Hierarchical modules: In which first letters (except maybe last one)
are capitalized
- Composition: In which first letters are not capitalized

In combination of those I belive there is no disambiguoty since the
lower case words functions as terminators. While it can be discussed as
an error of the past it is not the problem that spaces creates problems:
ghci> :t head . tail
head . tail :: [a] -> a
ghci> :t head .tail
head .tail :: [a] -> a
ghci> :t head.tail
head.tail :: [a] -> a

Or even:
ghci> :t
Data.IORef.readIORef.System.IO.Unsafe.unsafePerformIO.Data.IORef.newIORef
Data.IORef.readIORef.System.IO.Unsafe.unsafePerformIO.Data.IORef.newIORef
  :: a -> IO a

Even in hugs:
Hugs> :t head.tail
head . tail :: [a] -> a
Hugs> :t head . tail
head . tail :: [a] -> a
Hugs> :t head .tail
head . tail :: [a] -> a
Hugs> :t head.tail
head . tail :: [a] -> a
Main> :t
Data.IORef.readIORef.System.IO.Unsafe.unsafePerformIO.Data.IORef.newIORef
readIORef . unsafePerformIO . newIORef :: a -> IO a

I would question sanity of using . here but it is not the case that we
get flood of posts why adding/removing space next to ./- causes any
problems. People with practically any programmin backround would expect
a-b be equivalent to a - b. Sometimes this 2 spaces are needed to fit in
72/80 columns.

> This is something someone could easily try out by writing a trivial
> preprocessor to convert hyphens with letters on each side to
> underscores.  See how it works.
> 
> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might
> be nice to have a wee preprocessor that turned
>_ 
> into   
> 
> so that I could write take_while and Haskell could see takeWhile.
> [I'm writing this in MacOS X Mail.  "takeWhile" is underlined in
> red as a spelling mistake, "take_while" is not.  Maybe they know
> something...]
> 
> Here is such a preprocessor.  This is meant for people to try out.
> I don't claim that it's perfect, it's just a quick hack.

Personally I don't have any strong feelings about conventions as long as
they are consistent within one language. Camel cases are no more
uncommon then the underscore and they saved space in the past (ok. now
it does not matter) and hyphen is very rarly used (to not have problem
with minus). 

For example:
- Java - camel cases both in classes and methods (convention very
similar to Haskell)
- .Net - the same (but first letter of method is capitalized)
- Python - underscore
- C/C++ - Veries

Regards


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

Re: [Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1



On Dec 10, 2009, at 2:58 AM, Roel van Dijk wrote:

I tried to be conservative with the choice of unicode symbols. I have
defined the division sign (÷) to be (/). But it could just as well be
defined as 'div'.


No it couldn't.  One expects 3÷2 to be 1½, not 1.
You will, for example, find this text on the web:
"Mathematically, the division sign is equivalent to the forward slash.
Thus, for example, 4 ÷ 5 = 4/5 = 0.8"
This is actually historically backwards.  When I was a nipper,
1/6 meant "one and six" or "eighteen pence" or at least three
loaves of good bread.  As far as I'm aware, the use of "/"
instead of "÷" is a computerism introduced in the days of 6 bit
character sets.


Another choice that could lead to some discussion is the definition of
(⊂) to be 'Data.Set.isProperSubsetOf' and (⊆) to be
'Data.Set.isSubsetOf'. An alternative choice would be to have (⊊)  
for

'isProperSubsetOf' and (⊂) for 'isSubsetOf'.


Mathematicians may use the plain horseshoe for either subset or
proper subset, depending on the author.  But I've never ever seen
anyone use the horseshoe with an equals bar for proper subset;
that would really make no sense.

I suggest that you take the Z formal specification language as your
guide (plain horseshoe is proper subset, horseshoe with equal bar is
subset-or-equal).  If you don't like Z, try B:  same thing.

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

Re: [Haskell-cafe] Re: can there be (hash-table using) O(n) version of this (I think currently) n log n algo?

2009-12-09 Thread Matt Morrow

Never underestimate teh power of the Int{Set,Map}:

{-# LANGUAGE BangPatterns #-}
import Data.Set(Set)
import Data.IntSet(IntSet)
import qualified Data.Set as S
import qualified Data.IntSet as IS
import Control.Parallel.Strategies(rnf)
import Data.Monoid(Monoid(..))
import Data.List

findsumsIS :: [Int] -> Int -> IntSet
findsumsIS xs wanted = snd . foldl' f mempty $ xs
  where f (!candidates,!successes) next =
  let x = wanted - next
  in case x `IS.member` candidates of
  True -> (candidates, IS.insert next successes)
  False -> (IS.insert next candidates,successes)

-- (i had to add bangs in f since it was blowing the stack)
findsums :: [Int] -> Int -> Set (Int,Int)
findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs
  where f (!candidates,!successes) next =
  if  S.member (wanted-next) candidates
then (candidates, S.insert (next,wanted-next) successes)
else (S.insert next candidates,successes)

{-
  Note that the list has 10 million elements,
  (time is roughly 0.4s with 1 million with IntSet).
-}

{-
main = do
  let s = findsums (take 1000 (cycle [1..999])) 500
  print (rnf s `seq` ())

[...@monire ~]$ time ./FindSums
()

real0m8.793s
user0m8.762s
sys 0m0.022s
-}

{-
main = do
  let s = findsumsIS (take 1000 (cycle [1..999])) 500
  print (rnf s `seq` ())

[...@monire ~]$ time ./FindSumsIS
()

real0m4.488s
user0m4.459s
sys 0m0.023s
-}

Matt

> On Sunday 19 July 2009 09:26:14 Heinrich Apfelmus wrote:
>> Thomas Hartman wrote:
>> > The code below is, I think, n log n, a few seconds on a million +
>> > element
>> > list.
>> >
>> > I wonder if it's possible to get this down to O(N) by using a
>> > hashtable implemementation, or other better data structure.
>> >
>> > -- findsums locates pairs of integers in a list
>> > that add up to a wanted sum.
>> >
>> > findsums :: [Int] -> Int -> S.Set (Int,Int)
>> > findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs
>> >   where f (candidates,successes) next =
>> >  if  S.member (wanted-next) candidates
>> >then (candidates, S.insert (next,wanted-next) successes)
>> >else (S.insert next candidates,successes)
>>
>> Remember that hash tables are actually O(key length) instead of O(1), so
>> I don't think you can break the  log n  for really large lists this
>> way since the key length increases as well (unless most elements are
>> equal anyway).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

2009-12-09 Thread Deniz Dogan

2009/12/9 Richard O'Keefe :
>
> On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote:
>>
>> You mean to parse a - b differently then a-b? You don't have the problem
>> in LISP as AFAIR you use (- a b) but in Haskell it would be a problem.
>
> It's a problem that COBOL solved a long time ago:
>        COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME.
> Haskell already has this problem with ".", where we generally need
> to put spaces around "." with the meaning "composition" and not
> put spaces around other uses.
>
> This is something someone could easily try out by writing a trivial
> preprocessor to convert hyphens with letters on each side to
> underscores.  See how it works.
>
> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
> went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might
> be nice to have a wee preprocessor that turned
>         _ 
> into     
>
> so that I could write take_while and Haskell could see takeWhile.
> [I'm writing this in MacOS X Mail.  "takeWhile" is underlined in
> red as a spelling mistake, "take_while" is not.  Maybe they know
> something...]
>
> Here is such a preprocessor.  This is meant for people to try out.
> I don't claim that it's perfect, it's just a quick hack.
>

Is there any flag I can pass to e.g. GHC to make it use the
preprocessor automagically or do I write my own little hack to apply
the preprocessor?

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

[Haskell-cafe] Re: ANNOUNCE: usb-safe-0.1

On Wed, Dec 9, 2009 at 3:50 PM, Bas van Dijk  wrote:
> On Wed, Dec 9, 2009 at 2:35 PM, Bas van Dijk  wrote:
>> Hello,
>>
>> My usb library provides a standard Haskell abstracting layer over
>> bindings-libusb providing: abstract types instead of Ptrs, automatic
>> marshalling and unmarshalling, automatic garbage collection,
>> exceptions instead of integer return codes, etc..
>>
>> While all that is very nice there are still some things that you can
>> do wrong. For example doing I/O with a closed device or reading from
>> or writing to an endpoint which doesn't belong to the claimed
>> interface. Or reading from an Out endpoint or writing to an In
>> endpoint.
>>
>> I released the usb-safe package to prevent you making these errors. See:
>>
>> http://hackage.haskell.org/package/usb-safe-0.1
>>
>> usb-safe provides the following guarantees:
>>
>> -  You can't reference handles to devices that are closed. In other
>> words: no I/O with closed handles is possible.
>>
>> - The programmer specifies the region in which devices should remain
>> open. On exit from the region the opened devices are automatically
>> closed.
>>
>> - You can't reference handles to configurations that have not been set.
>>
>> - You can't reference handles to interfaces that have not been claimed.
>>
>> - You can't reference handles to alternates that have not been set.
>>
>> - You can't reference endpoints that don't belong to a setted alternate.
>>
>> - You can't read from an endpoint with an Out transfer direction.
>>
>> - You can't write to an endpoint with an In transfer direction.
>>
>> - You can't read from or write to endpoints with the unsupported
>> transfer types Control and Isochronous. Only I/O with endpoints with
>> the Bulk and Interrupt transfer types is allowed.
>>
>> The primary technique used in usb-safe is called "Lightweight monadic
>> regions" which was invented by Oleg Kiselyov and Chung-chieh Shan.
>> See:
>>
>> http://okmij.org/ftp/Haskell/regions.html#light-weight
>>
>> Note that I consider this a preview release. In fact, I haven't tested
>> the package at all. I can only guarantee you that it will pass the
>> type-checker.
>>
>> As always: questions, comments and patches are more than welcome.
>>
>> Please don't look at the hscolour generated source code from the
>> haddock documentation because it screws up the nice unicode symbols I
>> used. If you want to read the source download the package or go
>> straight to the darcs repos:
>>
>> darcs get http://code.haskell.org/~basvandijk/code/usb-safe
>>
>> regards,
>>
>> Bas
>>
>
> I just released a new 0.2 version of usb-safe which adds the type synonym:
>
> type TopDeviceRegion s = DeviceRegionT s IO
>
> and the function:
>
> runTopDeviceRegion ∷ (∀ s. TopDeviceRegion s α) → IO α
>
> I changed the name of 'forkDeviceRegionT' to 'forkTopDeviceRegion' and
> changed its type accordingly.
>
> Because these are API changes and additions I bumped the version from
> 0.1 to 0.2 following the PVP[1].
>
> See:
>
> http://hackage.haskell.org/package/usb-safe-0.2
>
> darcs get http://code.haskell.org/~basvandijk/code/usb-safe
>
> regards,
>
> Bas
>
> [1] http://haskell.org/haskellwiki/Package_versioning_policy
>

And yet another major release for usb-safe-0.3

* This time I renamed the type 'EndpointHandle' to 'FilteredEndpoint'
because it's not really a handle to an endpoint but more of an
endpoint which got filtered and therefor got some more type
information.

* I also renamed lots of type variables to better reflect their
intended meaning.

* Finally I added some documentation.

See: http://hackage.haskell.org/package/usb-safe-0.3 or the darcs
repos for details.

Maybe one major 0.4 release will follow shortly where I remove the
region variables from: ConfigHandle, Interface, InterfaceHandle,
Alternate, AlternateHandle, Endpoint and FilteredEndpoint. I think
these region variables are not strictly necessary in these types
because they are already imprisoned (for lack of a better term) by all
the respected 'with*' functions using their 's' type variables.
However I have to think about if this is a wise change.

regards,

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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers



On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote:
You mean to parse a - b differently then a-b? You don't have the  
problem

in LISP as AFAIR you use (- a b) but in Haskell it would be a problem.


It's a problem that COBOL solved a long time ago:
COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME.
Haskell already has this problem with ".", where we generally need
to put spaces around "." with the meaning "composition" and not
put spaces around other uses.

This is something someone could easily try out by writing a trivial
preprocessor to convert hyphens with letters on each side to
underscores.  See how it works.

Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might
be nice to have a wee preprocessor that turned
 _ 
into 

so that I could write take_while and Haskell could see takeWhile.
[I'm writing this in MacOS X Mail.  "takeWhile" is underlined in
red as a spelling mistake, "take_while" is not.  Maybe they know
something...]

Here is such a preprocessor.  This is meant for people to try out.
I don't claim that it's perfect, it's just a quick hack.



hspp.hs
Description: Binary data


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

Re: [Haskell-cafe] Nano-Languages

2009-12-09 Thread Stefan Holdermans


John,

It might be better to go about it in a fashion similar to how one  
would use Haskell to create a new language using Happy, but instead  
of making a full fledged language create a language that makes only  
minor adjustments to the official language where most of the  
original source code and command line options are copied verbatim  
with a handful of things caught such as the Richard O'Keefe newtype,  
a nano-language if you will. Actually I have known about this  
possibility for years. There is always something you would like to  
change about whatever language you are working with and so I have  
put thought into it.


What about¯syntax macros? http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf

Cheers,

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

Re: [Haskell-cafe] forkSequence, runPar, parallelize

2009-12-09 Thread Antoine Latter

On Wed, Dec 9, 2009 at 3:44 PM, Mario Blazevic  wrote:
>
>        I can't test it right now, but wouldn't the following do the job in
> the Identity monad?
>
> forkExec :: Identity a -> Identity (Identity a)
> forkExec k = let result = runIdentity k
>             in result `par` return (Identity result)
>

Since Identity is a newtype, would that be equivalent to "result `par`
result"? The forkExec in the IO monad let's other computations keep
going until I need the result from the forked computation.

In a pure computation, I can already get the same result with `par`
and laziness, right?

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

Re: [Haskell-cafe] Re: Handles with their IOMode in their type

On Tue, Dec 8, 2009 at 7:22 PM, Lee Houghton  wrote:
> I like this idea.

Thanks

> A small observation, though:
>
>> stdin :: ReadModes ioMode => Handle ioMode
>> stdin = Handle SIO.stdin
>
> This allows writing to stdin by choosing ReadWriteMode as the ioMode. I
> think it would be better to have just
>>
>> stdin :: Handle ReadMode
>
> *HandleExplicitIOMode> hPutStrLn (stdin :: Handle ReadWriteMode) "This
> shouldn't typecheck!"
> *** Exception: : hPutStr: illegal operation (handle is not open for
> writing)
>
> This also shows another reason for stdin, stdout and stderr to be
> monomorphic:
>
>> hGetLine stdin
>
> :1:0:
>    Ambiguous type variable `ioMode' in the constraint:
>      `ReadModes ioMode'
>        arising from a use of `hGetLine' at :1:0-13
>    Probable fix: add a type signature that fixes these type variable(s)

Rightly spotted, thanks!

I will change the types to:

stdin :: Handle ReadMode
stdout :: Handle WriteMode
stderr :: Handle WriteMode

Or are there scenarios where people want to write to stdin or read
from stdout or stderr?

I think I will also rename the IOMode constructors to their
System.IO.IOMode equivalents. Then I will also have to rename the
ioMode types like so:

data IOMode ioMode where
ReadMode  :: IOMode R
WriteMode  :: IOMode W
AppendMode  :: IOMode A
ReadWriteMode :: IOMode RW

Then there are two decisions I still have to make:

1) How to name the module? What about: System.IO.ExplicitIOModes?

2) What to export? Do I only need to export the changed functions and
types like I have now:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 or do I need to
export all the other things that System.IO exports. In the latter case
users have the advantage that they can just swap their import of
System.IO with System.IO.ExplicitIOModes

When I have time I will put this in a package and upload it to hackage.

Oh yes, final question: how to name this package?

What about explicit-iomodes?

regards,

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

Re: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?

2009-12-09 Thread John Lask



I think it would be a usefull addition to the haskell windows tool 
chain, and help facilitate the creation of bindings to  libraries on 
windows where no appropriate import library exists.


I am sure if you put it "out there" in whatever form, someone will find 
a use for it and perhaps build upon it.


jvl

Stephen Tetley wrote:

Hi All,

Would a pure Haskell version of pexports be useful to the Haskell community?

For a Sunday afternoon hack that turned out to take a bit more effort
(its now Wednesday), I thought I'd code up a tool that extracts
function symbols from .dll's (also when I first looked at the C
pexports it seemed somewhat unadopted, though checking today it
appears to in MinGW, so my local MinGW must be out-of-date).

If there are compelling uses that aren't covered by pexports and would
ease Haskell C binding problems on Windows, I don't mind polishing up
my tool, but otherwise I've exhausted my natural interest.

Best wishes

Stephen
___
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] forkSequence, runPar, parallelize

2009-12-09 Thread Mario Blazevic




A similar function that I'm fond of:

forkExec :: IO a -> IO (IO a)
forkExec k
= do
  result <- newEmptyMVar
  _ <- forkIO $ k >>= putMVar result
  return (takeMVar result)

Although I don't think it can be generalized to non-IO monads.

Antoine



	I can't test it right now, but wouldn't the following do the job in the 
Identity monad?


forkExec :: Identity a -> Identity (Identity a)
forkExec k = let result = runIdentity k
 in result `par` return (Identity result)

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

Re: [Haskell-cafe] forkSequence, runPar, parallelize (was: Re: You are in a twisty maze of concurrency libraries, all different ...)

2009-12-09 Thread Matthew Brecknell

Antoine Latter wrote:
> A similar function that I'm fond of:
> 
> forkExec :: IO a -> IO (IO a)

It's cute that forkExec already has a dual operation with just the right
name (specialised to IO):

join :: IO (IO a) -> IO a



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

Re: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?

2009-12-09 Thread Stephen Tetley

Hi Erik

I'm neither expecting nor obliging Unix users to do anything...

pexports (the C tool) extracts function names from dlls. In one of the
messages on the PortAudio thread [1], John Lask explained how to get
from a standard Windows .dll to an .a file suitable for GHC (which is
bundled with a MinGW gcc). Before John's explanation I thought you had
to build the .a file yourself - or do some magic with GreenCard which
is now quite antiquated, but with pexports you can do the missing step
(I almost feel a commuting diagram coming on at this point...).

When I looked for pexports on Sunday it seem rather abandoned (it
didn't seem to be included in MinGW, M Xyz's tutorial points to a very
old version...) so I thought I'd see if I could do the job myself in
Haskell. Anyway it was a bit more work that I imagined and when I was
web-searching for pexports today I found that it was included in
MinGW. So my Haskell version is redundant - but pexports isn't quite
the full story, seemingly people often have to hand-edit the .def file
it produces. If someone else has a use compelling enough that it would
benefit the Haskell community on Windows, I don't mind extending and
polishing my version so it can do a bit more than pexports; but I get
by with cygwin and MinGW myself, so I've no personal inclination to
spend any more time on it (and of course it is no help whatsoever for
includes files and related problems...).

Best wishes

Stephen

[1] http://www.haskell.org/pipermail/haskell-cafe/2009-December/070293.html

2009/12/9 Erik de Castro Lopo :
> Stephen Tetley wrote:
>
>> If there are compelling uses that aren't covered by pexports and would
>> ease Haskell C binding problems on Windows, I don't mind polishing up
>> my tool, but otherwise I've exhausted my natural interest.
>
> I think the main problem you'll face is that pexports is a windows
> only tool. If cabal can be made to use pexports on windows and something
> else on Unix then that should be ok.
>
> If you expect people writing Haskell bindings in Unix to jump though
> hoops to hook pexports into a windows specific build, you are heading
> for disappointment :-).
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> 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] forkSequence, runPar, parallelize (was: Re: You are in a twisty maze of concurrency libraries, all different ...)

2009-12-09 Thread Antoine Latter

On Wed, Dec 9, 2009 at 2:17 PM, Mario Blazevic  wrote:
>        It appears there are several implementations existing on Hackage of
> the following function, in various disguises:
>
>   runPar :: [IO a] -> IO [a]
>
>
> the idea being that the IO computations are run in parallel, rather than
> sequentially. My own Streaming Component Combinators package contains a
> similar function, but somewhat generalized:
>
>
>   class Monad m => ParallelizableMonad m where
>      parallelize :: m a -> m b -> m (a, b)
>
>   instance ParallelizableMonad IO  -- implemented using forkIO
>   instance ParallelizableMonad Identity  -- implemented using par
>   instance ParallelizableMonad Maybe  -- implemented using par
>
>
>        Would there be any interest in having this class packaged in a
> separate library? If so, can you sugest a better name or some additional
> functionality?

A similar function that I'm fond of:

forkExec :: IO a -> IO (IO a)
forkExec k
= do
  result <- newEmptyMVar
  _ <- forkIO $ k >>= putMVar result
  return (takeMVar result)

Although I don't think it can be generalized to non-IO monads.

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

Re: [Haskell-cafe] Haskell job opportunity

2009-12-09 Thread Tom Davie

I have to admit, it's just one criterion too much for me.  I can manage to
satisfy all of them except for willing to work in Manhattan.

Bob

On Tue, Dec 8, 2009 at 5:54 PM, Tom Tobin  wrote:

> On Tue, Dec 8, 2009 at 11:09 AM, siki  wrote:
> > I've posted this before but did not get a whole lot of responses, so here
> it
> > is again:
> [...]
> > You should have at least a bachelor’s degree in computer science from a
> top
> > university
>
> Might I humbly suggest that this is going to severely limit your
> hiring options?  You're looking for the intersection of sets of people
> who:
>
> - Have a BS in computer science (cuts out a fair number of people)
> - Graduated from a "top university" (cuts out a *lot* of people)
> - Is familiar with Java (cuts out some people)
> - Is skilled with Haskell (a fair bet for many on this mailing list, at
> least)
> - Can work in the Manhattan area (cuts out a *lot* of people)
>
> I'm not sure how many people *exist* who meet all these criteria.  ;-)
>  I'd probably start by dropping your "top university" requirement,
> since I don't think it's all that relevant if you find your candidate
> has the skills you're looking for.  You might even find someone who
> fits yet doesn't have a CompSci BS degree; you can phrase it as "a BS
> in computer science or an equivalent strong background in theoretical
> computer science" or somesuch, as appropriate.
> ___
> 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] Type system speculation

People in the Haskell community get awfully excited about Haskell's type 
system.


When I was first learning Haskell, I found this rather odd. After all, a 
"type" is just a flat name that tells the compiler how many bits to 
allocate and which operations to allow, right?


As I read further, I quickly discovered that in Haskell, the type system 
is something much more powerful. In a normal language, the type system 
prevents you from accidentally trying to multiply a string by a binary 
tree of integers, or pass a function an signed integer when it's 
expecting an unsigned integer. But in Haskell, the combination of 
parametric polymorphism, typeclasses and automatic type inference 
combine to form a potent mixture. Even without any exotic language 
extensions, in Haskell you can use the type system to *prove stuff about 
your programs*! And not necessary stuff that's anything to do with the 
usual notion of a "data type". You can prove that lists are non-empty or 
even of a specific size. You can prove that optional values get checked 
before they are used. And you can prove that user input is sanitised 
before being passed to sensitive functions. (Or rather, you can make 
your program simply not compile if the required properties are not 
guaranteed.)




Let's take an example. Suppose you have some functions that obtain input 
from a user, and you have some other functions that do something with 
this data. What you can do is something like this:


 newtype Data x y = Data x

 data Checked
 data Unchecked

 check_string :: Data String Unchecked -> Data String Checked

Now make it so that everything that obtains data from the user returns 
Data String Unchecked, and everything that uses a string to do something 
potentially hazardous demands Data String Checked. (And any functions 
that don't care whether the string is checked or not can just use Data 
String x.)


Only one problem: Any functions that expect a plain String now won't 
work. Particularly, the entirity of Data.List will refuse to accept this 
stuff. Which is kind of galling, considering that a Data String Checked 
*is* a String!


What we're really trying to do here is attach additional information to 
a value - information which exists only in the type checker's head, but 
has no effect on runtime behaviour (other than determining whether we 
*get* to runtime). As far as I can tell, Haskell does not provide any 
way to take an existing type and attach additional information to it in 
such a way that code which cares about the new information can make use 
of it, but existing code which doesn't care continues to work. Any 
comments on this one?




On a rather unrelated note, I found myself thinking about the Type 
Families extension (or whatever the hell it's called). I found that I 
can do this:


 class Collection c where
   type Element c :: *
   empty :: c
   first :: c -> Maybe (Element c)
   ...

This works for collections that can contain *anything*:

 instance Collection [x] where
   type Element [x] = x
   ...

It works for collections that can only contain *one* type:

 instance Collection ByteString where
   type Element ByteString = Word8
   ...

And it works for collections that can handle more than one type, but 
less than *every* type:


 instance Ord x => Collection (Set x) where
   type Element (Set x) = x
   ...

Something quite interesting is happening here: this "Element" thing is 
almost like a *function* which takes one type and returns another. A 
function that operates on types themselves.


Now suppose I want to write a function that converts one kind of 
collection into another:


 convert :: (Collection c1, Collection c2) => c1 -> c2

Erm, no. That doesn't work AT ALL. What we want to say is that the 
element types are constrained (specifically, they're identical).


I searched for quite some time looking for a way to say this. In the 
end, I gave up and let the compiler deduce the type signature 
automatically. Apparently the correct signature is


 convert :: (Collection c1, Collection c2, Element c1 ~ Element c2) => 
c1 -> c2


Apparently the bizare syntax "Element c1 ~ Element c2" means that these 
two types are supposed to be equal. (Why not just an equals sign?)




This got me thinking... Maybe what we'd really like to say is something like

 convert :: (Collection c1 {Element = x}, Collection c2 {Element = x}) 
=> c1 -> c2


In other words, make the assosiated type like a named field of the 
class, using syntax similar to the named fields that values can have.


And then, if we can do it to classes, why not types?

 data Map {keys :: *, values :: *} = ...

 insert :: (Ord k) => k -> v -> Map {keys = k, values = v} -> Map {keys 
= k, values = v}


Now, it seems reasonable that if one of the type fields is 
unconstrained, you do not need to mention it:


 keys :: (Ord k) => Map {keys = k} -> [k]

 values :: Map {values = v} -> [v]

If we can have some mechanism for adding new type fields to an existing 
t

[Haskell-cafe] forkSequence, runPar, parallelize (was: Re: You are in a twisty maze of concurrency libraries, all different ...)

2009-12-09 Thread Mario Blazevic

	It appears there are several implementations existing on Hackage of the 
following function, in various disguises:


   runPar :: [IO a] -> IO [a]


the idea being that the IO computations are run in parallel, rather than 
sequentially. My own Streaming Component Combinators package contains a 
similar function, but somewhat generalized:



   class Monad m => ParallelizableMonad m where
  parallelize :: m a -> m b -> m (a, b)

   instance ParallelizableMonad IO  -- implemented using forkIO
   instance ParallelizableMonad Identity  -- implemented using par
   instance ParallelizableMonad Maybe  -- implemented using par


	Would there be any interest in having this class packaged in a separate 
library? If so, can you sugest a better name or some additional 
functionality?

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

Re: pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?

2009-12-09 Thread Erik de Castro Lopo

Stephen Tetley wrote:

> If there are compelling uses that aren't covered by pexports and would
> ease Haskell C binding problems on Windows, I don't mind polishing up
> my tool, but otherwise I've exhausted my natural interest.

I think the main problem you'll face is that pexports is a windows
only tool. If cabal can be made to use pexports on windows and something
else on Unix then that should be ok.

If you expect people writing Haskell bindings in Unix to jump though
hoops to hook pexports into a windows specific build, you are heading
for disappointment :-).

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: binding to C libraries on Windows

2009-12-09 Thread Erik de Castro Lopo

Andrew Coppin wrote:

> Erik de Castro Lopo wrote:
> > There are bigger problems than that. The Microsoft compiler still doesn't
> > support large chunks of the 1999 ISO C Standard.
> >   
> 
> Seriously? OK, well that's news to me.

Yes, seriously:

http://www.mega-nerd.com/erikd/Blog/Windiots/ms_c99.html

That list  is not complete, just what I felt was stuff that was hard
to do without. The lack  of a standards conforming snpirntf is
particlularly painful.

> I was under the impression that 
> practically all C compilers in existence support the same set of 
> features. (Although I'm sure each one probably has a few non-standard 
> additions too.)

With the GNU compilers (and I suspect most other) the non-standard
features can be switched off. For the GNU compilers -std=c99 or -std=c89
allows the user to pick which standard they are compiling to.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: fgetc and fputc equivalents

2009-12-09 Thread Ben Franksen

John D. Earle wrote:
> Although much work has apparently gone into providing support for
> manipulation binary data I was unable to uncover a Haskell equivalent of
> the C fgetc and fputc functions. The Haskell equivalents work with Unicode
> character streams, not bytes words etcetera. I did find a library for
> handling arrays of bytes and such, but I did not find it to be convenient
> for the application I have in mind. I resolved myself to emitted Unicode
> 0s and 1s that are later converted to binary 0s and 1s by means of a C
> program. Is this functionality missing in Haskell? or did I miss
> something?

It is not in the Standard, but (at least) GHC has hPutBuf and hGetBuf (see
http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html).

Cheers
Ben

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

Re: [Haskell-cafe] diff implementation in haskell

2009-12-09 Thread Erik de Castro Lopo

Chris Eidhof wrote:

> Also, there is a paper about doing a type-safe diff in Agda, 
> http://portal.acm.org/citation.cfm?id=1596614.1596624

That is locke dbehind some ridiculous paywall.

It seems the same paper is available here:

http://people.cs.uu.nl/andres/GDiff.html

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: fgetc and fputc equivalents

2009-12-09 Thread Antoine Latter

On Wed, Dec 9, 2009 at 11:33 AM, John D. Earle  wrote:
> My interest isn't actually to push around characters. I do enough of that.
> What I really want to do is push bits and not bytes.

I thought that fgetc and fputc worked on bytes, not bits?

I've had great luck using the binary package to produce structured
binary data. If it's overkill for what you're trying to do then I
recommend the bytestring package.

See:

http://hackage.haskell.org/package/binary
http://hackage.haskell.org/package/bytestring

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

Re: [Haskell-cafe] Re: binding to C libraries on Windows

There are several C standards by year of publication. There are also drafts 
of those standards. A C compiler may comply with a draft of the official 
standard before it became official, but not the official standard itself. 
Rarely does anyone seek full compliance with respect to any standard it 
seems and it can take years before everyone has bother themselves enough to 
bring themselves up to speed with whatever the current standard is supposed 
to be.


I use the Microsoft CL compiler (aka Visual C++). It has some undocumented 
quirks/optimizations, but for the most part if you are doing native 
development it seems fine. It is the official compiler so you just have to 
learn to love it.


The problem seems to be if you are coming from a POSIX environment and 
assuming that Windows is going to honor its conventions. I personally don't 
bother with the C library very much. I deliberately avoid it. Its Win32/64 
programming all the way with me. That too has its undocumented quirks, but 
is better documented that the brief Java documentation for example. Windows 
programming can be quite difficult. It is just that I've been around it for 
so long.


Windows and Mac are not designed for people who are not dedicated to working 
with these environments. I have experience in both of them. You may want to 
use Microsoft Visual C++ to access the Microsoft .NET Framework rather than 
bother with the C library. There is a Haskell library designed to help you 
access the Microsoft .NET Framework directly from Haskell on Windows. Even 
so, you may want to work with C++ to do this because the Microsoft 
documentation will not explain to you how to do this in Haskell.


--
From: "Andrew Coppin" 
Sent: 09 Wednesday December 2009 1159
To: 
Subject: Re: [Haskell-cafe] Re: binding to C libraries on Windows


Erik de Castro Lopo wrote:

There are bigger problems than that. The Microsoft compiler still doesn't
support large chunks of the 1999 ISO C Standard.



Seriously? OK, well that's news to me. I was under the impression that 
practically all C compilers in existence support the same set of features. 
(Although I'm sure each one probably has a few non-standard additions 
too.)


___
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: binding to C libraries on Windoww

2009-12-09 Thread Stephen Tetley

2009/12/9 Andrew Coppin :

>
> I see. So you're saying that while Cygwin is a Unix emulator, MinGW is just
> a set of Unix-style tools which run natively on Windows?
>

Yes, in a nutshell MinGW executables are native. Executables in Cygwin
may or may not have dependencies on cygwin.dll the Unix emulation
library (depending whether or not they actually use Unix calls of
course).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Nano-Languages

To help clarify my meaning Haskell would be used as an assembler language or 
put in another way an intermediate language for those constructs that are 
caught by the preprocessor for special processing. Since Haskell is a 
functional language I would imagine that this would be unproblematic.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Nano-Languages

What I wrote under "Allowing hyphens in identifiers" and what Richard O'Keefe 
wrote earlier under "A new form of newtype" caused me to think. It was pointed 
out that hyphens are not permitted in Haskell identifiers much as they are in 
Lisp for good cause even though such a feature is regarded by some as 
especially desirable. It is technically feasible (or at least appears to be). 
It is a matter of what constitutes good language design. My suggestion was to 
whip up a makeshift preprocessor to make the necessary substitutions.

It might be better to go about it in a fashion similar to how one would use 
Haskell to create a new language using Happy, but instead of making a full 
fledged language create a language that makes only minor adjustments to the 
official language where most of the original source code and command line 
options are copied verbatim with a handful of things caught such as the Richard 
O'Keefe newtype, a nano-language if you will. Actually I have known about this 
possibility for years. There is always something you would like to change about 
whatever language you are working with and so I have put thought into it.

It would make prototyping of new ideas easier. It would furthermore make it 
possible to make changes that would be unacceptable for an official version of 
the language such as hyphens in place of underscores for those who feel the 
benefit of being able to use hyphens this way outweigh the problems it may 
cause. The official language remains intact.

Broadly speaking I am talking about a preprocessor, but one tailored for the 
needs of Haskell. For related art see Ciao Prolog (see http://ciaohome.org). 
They are using their preprocessor to do some rather sophisticated things which 
include program analysis and optimization. Something so elaborate may not be 
necessary, however. Just some Happy code that has been cobbled together that 
address some of the issues involved that is reworked to satisfy a special need.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: fgetc and fputc equivalents

My interest isn't actually to push around characters. I do enough of that. What 
I really want to do is push bits and not bytes.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] fgetc and fputc equivalents

Although much work has apparently gone into providing support for manipulation 
binary data I was unable to uncover a Haskell equivalent of the C fgetc and 
fputc functions. The Haskell equivalents work with Unicode character streams, 
not bytes words etcetera. I did find a library for handling arrays of bytes and 
such, but I did not find it to be convenient for the application I have in 
mind. I resolved myself to emitted Unicode 0s and 1s that are later converted 
to binary 0s and 1s by means of a C program. Is this functionality missing in 
Haskell? or did I miss something?___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell job opportunity


siki wrote:

I've posted this before but did not get a whole lot of responses, so here it
is again:

Principal investment firm based in Manhattan is looking for an outstanding
software developer to develop and maintain the firm's proprietary valuation
models as well as accounting and portfolio management systems.  
  


Hey, if it was in the UK, I'd probably apply. (Even though I utterly 
fail to meet most of the criteria...)


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

Re: [Haskell-cafe] Re: binding to C libraries on Windoww


Robert Greayer wrote:
It helps, I believe, if you stop thinking of MinGW with MSYS as 'a 
pseudo-Unix system'.  They're billed as the minimal toolset required 
on windows to use the GNU compilers and build system (and, as 
everybody knows, Gnu's not Unix).  The great thing about these 
compilers is that they're cross-platform and freely available, unlike 
MS Visual Studio.  I think that it makes sense that open source 
software developers targeting multiple platforms would want to pick a 
tool suite that works across all those platforms, and the GNU tools 
fit that description.  Cygwin truly is a Unix emulation, but 
MinGW/MSYS is just a packaging of useful open source (GNU) tools for 
Windows (including a shell).  Many programs that work well as native 
Windows apps, such as the GIMP, are built with them.


I see. So you're saying that while Cygwin is a Unix emulator, MinGW is 
just a set of Unix-style tools which run natively on Windows?


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

Re: [Haskell-cafe] Re: binding to C libraries on Windows


Erik de Castro Lopo wrote:

There are bigger problems than that. The Microsoft compiler still doesn't
support large chunks of the 1999 ISO C Standard.
  


Seriously? OK, well that's news to me. I was under the impression that 
practically all C compilers in existence support the same set of 
features. (Although I'm sure each one probably has a few non-standard 
additions too.)


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

Re: [Haskell-cafe] Parsec-like parser combinator that handles left recursion?

2009-12-09 Thread Dan Doel

On Wednesday 09 December 2009 10:51:02 am Nils Anders Danielsson wrote:
> On 2009-12-08 16:11, S. Doaitse Swierstra wrote:
> > In principle it is not possible to parse left-recursive grammars [...]
> 
> I suspect that this statement is based on some hidden assumption. It
> /is/ possible to parse many left recursive grammars using parser
> combinators, without rewriting the grammars or representing the cycles
> in the grammars explicitly. See the following paper draft:
> 
>   Total Parser Combinators
>  
>  http://www.cs.nott.ac.uk/~nad/publications/danielsson-parser-combinators.h
> tml

There's also parsing expression grammars, and the relevant paper "Packrat 
Parsers can Support Left Recursion." (Your parsers aren't PEGs, are they? If 
so, I apologize for the redundancy.)

There's a PEG parser combinator library written by John Meacham (of jhc fame), 
named Frisby (there's also pappy, but it's a parser generator, not a 
combinator library). The parsers themselves aren't monadic, but there are some 
monadic combinators which are used together with recursive do to construct 
(mutually) recursively defined parsers such that the library can observe 
sharing (and thus perform optimizations with that information).

On a side note, someone asked in a thread a while back about how 
(paraphrasing) 'performance problems always seem to be rectified by adding 
more strictness, and laziness always seems to be at best not-a-loss, and never 
a win.' But the Frisby docs state:

  (It is interesting to note that the memory efficiency of frisby depends
  vitally on being as lazy as possible, in contrast to traditional thoughts
  when it comes to memory consumption)

So there. :)

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

[Haskell-cafe] Re: A new form of newtype

2009-12-09 Thread John Lato

> From: "Richard O'Keefe" 
> Subject: Re: [Haskell-cafe] A new form of newtype
>
> People are now writing EDSLs using Haskell to generate code for
> all sorts of interesting things.  What if you want to use Haskell
> as a host for an EDSL targeted at a 24-bit DSP?

*plug* for this specific case, I would use the word24 package,
http://hackage.haskell.org/package/word24

which I wrote for a very similar problem.  It was surprisingly
difficult to get right (N.B. I have only tested the code, not proven
it correct).  I would have much preferred to let the compiler handle
the details.

>
> There may not be MACHINES with 42-bit integers,
> but that doesn't mean there aren't PROBLEMS that need them.
> This whole idea of "let the machine dictate the sizes" is
> precisely what I'm complaining of.
>

>
> Sorry, but creating instances of Bounded is what a compiler is for.
> If I don't write it, I won't wrong it.

I'm pretty sure I don't understand the syntax of your proposal (which
is my fault), but I definitely see the usefulness.  I'll leave the
syntax wrangling for the language lawyers, however.

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

[Haskell-cafe] Re: Checking dependencies from C packages in cabal

2009-12-09 Thread Maurício CA


> Until you get the perfect answer you may want to have a look at
> the cabal definitions of
>
> zlib digest OpenGLRaw GLUT readline GLFW wxcore terminfo
> berkeleydb BerkeleyDB hubris pcre-light HDBC-mysql HDBC-sqlite3
> HDBC-odbc HDBC-postgresql

I do know them. But they just include needed .h and .c files with
Haskell package, mark required libraries but do no version check,
or delegate the task to configure scripts or external programs.
HDBC-mysql Setup program gave me a start, thought. Thanks.

> Also make sure to search the Cabal mailinglist and maybe even
> move this thread to the Cabal mailinglist.

Cabal page sugests Haskell libraries mailing list for questions. I
should have used that.

Thanks. Best,
Maurício

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

Re: [Haskell-cafe] Zumkeller numbers

2009-12-09 Thread Dan Weston

Ouch. That's what happens when you let a machine do the translation. How 
about:


"Once your good name is trashed, you can live unabashed."


David Virebayre wrote:

On Wed, Dec 9, 2009 at 11:47 AM, Henning Thielemann
 wrote:


Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert. 8-]



Is there an English translation of it?


Google translate says : "If the reputation is ruined, one can live
quite openly."

David.
___
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] ANNOUNCE: usb-0.3

2009-12-09 Thread stefan kersten

hi roel,

On 09.12.09 16:50, Roel van Dijk wrote:
> On Wed, Dec 9, 2009 at 4:20 PM, stefan kersten  wrote:
>> looks great, thanks! do you happen to have some example code for working with
>> HID devices (mice, keyboards, etc.)?
> 
> The usb package does not support the various device classes directly.
> You won't find a function like "isKeyPressed ∷ Device → KeyCode → IO
> Bool". But you could write it based solely on functions from the usb
> package. Enumerate the devices connected to your system, find your HID
> device, open a handle (or enter a safe region), choose an interface
> and an alternative and finally send some sort of control request
> encoded in a ByteString. The actual bytes you need to send in order to
> discover if some key on your USB keyboard is pressed is defined
> somewhere in the USB HID device class specification.

ok, thanks. i just thought you might have something ready to use ;)

> If you really need that kind of functionality then you could create a
> package "usb-hid" that offers an abstraction over the HID device
> class. But if you just want to know if some key is pressed then a much
> simpler solution would be to use a library like SDL or GLUT.

i'm interested in "headless" appliances, where no window system is actually
running. on linux i could use the input device layer, but it would be nice to
have something more portable ...


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

[Haskell-cafe] Announcing a summer internship for a NASA-sponsored project

2009-12-09 Thread Lee Pike

* ANNOUNCING:*
* SUMMER INTERNSHIP FOR NASA-SPONSORED PROJECT *

The National Institute of Aerospace (NIA) and Galois, Inc. would like
to announce a Summer Visitor position for a joint in the summer of
2010 (and the summer of 2011). The position will be located at the
NIA, located in the historic Hampton Roads area of Virginia, U.S. The
visitor will work with researchers at both the NIA and Galois.

PROJECT OVERVIEW:
We are looking for a summer visitor to work on a NASA-sponsored
project investigating runtime monitoring applied to hard real-time
distributed systems such as avionics. Runtime monitoring is an
approach to check a system's conformance to safety specifications at
runtime. The work is being directed by Dr. Alwyn Goodloe (NIA) and
Dr. Lee Pike (Galois, Inc.)---contact below.

The visitor's work will depend on the skills and interests of the
student, but it will likely focus on the development and application
of of a monitor synthesis tool, CoPilot. Copilot takes property
specification and synthesizes monitors for the properties to embedded
C. Copilot is a Haskell library built on top of the Haskell eDSL Atom
. The work is expected to
lead to one or more conference publications.

QUALIFICATIONS:
* MUST-HAVES:
* The candidate should have significant experience in programming
in modern typed functional programming languages such as Haskell,
OCAML, or Clean (programming will be done mainly in Haskell).

* Some experience and exposure to writing and debugging C programs.
* Some experience with using and configuring *nix systems.

* NICE-TO-HAVES:
* Experience with real-time systems, RTOSes, scheduling,
distributed systems, control theory, or avionics.
* Experience or interest in in configuring a small distributed
hardware-based system (e.g., using Arduinos).
* Experience or interest in formal methods (e.g., model-checking,
temporal logics, runtime monitoring).

* Good writing skills/experience in writing technical papers.
* Interest in continuing collaboration at his or her home
institution during the remainder of the year.

* Interest in an internship for the summers of 2010 *and* 2011.
* Interest in NASA.

* DO *NOT* NEED:
* A degree (we're interested in hearing from post-docs, graduate
students, and undergrads).
* U.S. citizenship or work visa (all expenses are paid, but we
anticipate this being an unpaid internship).

ABOUT THE NIA:
The National Institute of Aerospace is a nonprofit institution with
both research and educational components. We have both full-time
research staff members as well as faculty and graduate students from
our six member universities. Research carried out at NIA includes
fluid mechanics, space vehicle design, atmospheric science, material
science, and computer science. Within computer science, the primary
focus is in formal methods, and we work closely with the formal
methods group at NASA's Langley Research Center, located less than one
mile away. The visitor will have an opportunity for frequent
interaction with the NASA Langley Formal Methods Group.

The NIA is located in Hampton, Virginia. The cities of Norfolk and
Virginia Beach are nearby as is historic Colonial Willamsburg.
Numerous attractions and activities are available within an hour's
drive. Within a couple of hours are the Outer Banks of North Carolina
and Washington DC, which are popular weekend getaways for our summer
visitors. NASA and NIA both host a large number of summer visitors
(undergraduate and graduate students) from around the world.

ABOUT GALOIS:
Galois, Inc. is located in Portland, Oregon with a mission to create
trustworthiness in critical systems. We’re in the business of taking
blue-sky ideas and turning them into real-world technology solutions.
We've been developing real-world systems for the past 10 years using
Haskell.

BENEFITS:
This is anticipated to be an unpaid but internship in which all living
expenses are covered. These include

* travel expenses to and from the NIA and your home
* housing allowance
* food allowance
* rental car and gas

TO APPLY:
Please email a C.V. (PDF or plain text) and a brief plain text note
statting your interest and experience to Dr. Alwyn Goodloe at >. There is flexibility regarding the dates of the visit.

***
* Application due date: Jan. 15, 2010 *
***

LEARN MORE:
* NIA website: http://www.nianet.org/
* Galois website: http://www.galois.com/
* Hampton Roads: http://en.wikipedia.org/wiki/Hampton_Roads
* NASA Langley Formal Methods Group: http://shemesh.larc.nasa.gov/fm/

Please email either Dr. Alwyn Goodloe and/
or Dr. Lee Pike with any questions.___

Re: [Haskell-cafe] Parsec-like parser combinator that handles left recursion?

2009-12-09 Thread Nils Anders Danielsson


On 2009-12-08 16:11, S. Doaitse Swierstra wrote:

In principle it is not possible to parse left-recursive grammars [...]


I suspect that this statement is based on some hidden assumption. It
/is/ possible to parse many left recursive grammars using parser
combinators, without rewriting the grammars or representing the cycles
in the grammars explicitly. See the following paper draft:

 Total Parser Combinators
 http://www.cs.nott.ac.uk/~nad/publications/danielsson-parser-combinators.html

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

Re: [Haskell-cafe] ANNOUNCE: usb-0.3

2009-12-09 Thread Roel van Dijk

On Wed, Dec 9, 2009 at 4:20 PM, stefan kersten  wrote:
> looks great, thanks! do you happen to have some example code for working with
> HID devices (mice, keyboards, etc.)?

The usb package does not support the various device classes directly.
You won't find a function like "isKeyPressed ∷ Device → KeyCode → IO
Bool". But you could write it based solely on functions from the usb
package. Enumerate the devices connected to your system, find your HID
device, open a handle (or enter a safe region), choose an interface
and an alternative and finally send some sort of control request
encoded in a ByteString. The actual bytes you need to send in order to
discover if some key on your USB keyboard is pressed is defined
somewhere in the USB HID device class specification.

If you really need that kind of functionality then you could create a
package "usb-hid" that offers an abstraction over the HID device
class. But if you just want to know if some key is pressed then a much
simpler solution would be to use a library like SDL or GLUT.

Keep in mind that all functions in the usb package run in *client
side*. To actually use a device (communication) you need the proper
permissions, which in practice implies super-user privileges.
Libraries like SDL interface with the kernel drivers and do not need
such permissions (correct me if I'm wrong).

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

Re: [Haskell-cafe] ANNOUNCE: usb-0.3

2009-12-09 Thread stefan kersten

On 09.12.09 14:35, Bas van Dijk wrote:
> I made a new release of my usb library for high-level communication
> with usb devices from Haskell.

looks great, thanks! do you happen to have some example code for working with
HID devices (mice, keyboards, etc.)?

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

Re: [Haskell-cafe] OpenAL and Hsndfile

2009-12-09 Thread stefan kersten

hi matthew,

On 09.12.09 14:37, Matthew wrote:
> Yesterday, I set out to accomplish the challenge of loading and playing
> a sound from a file.
> So far, my attempts have resulted only in silence... rather
> disheartening after all the effort
> it took to get everything to build and run cleanly.
> 
> I currently take the following steps:
> - Load samples from file into an IOCArray using hsndfile
> - Create an OpenAL buffer which points to the IOCArray
> - Play sound using OpenAL
> code is at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13836

could you isolate the problem by checking if the array returned by hsndfile
actually contains non-zero sample frames? e.g. by computing the maximum 
amplitude:

(Data.List.foldl' (max) 0 . fmap abs) `fmap` Data.Array.MArray.getElems buffer

you could also try to test OpenAL  with a synthesized sound, e.g.
sin(2*pi*f/fs*k); i'm not familiar with OpenAL, though.

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

Re: [Haskell-cafe] Re: ANN: hakyll-0.1

2009-12-09 Thread Robert Greayer

sigh -- to the list this time.

On Wed, Dec 9, 2009 at 9:16 AM, Tom Tobin  wrote:

> On Wed, Dec 9, 2009 at 4:59 AM, Ketil Malde  wrote:
> > Tom Tobin  writes:
> >> If it turns out that Hakyll *is* okay to be BSD3 licensed so
> >> long as neither any binary nor the GPL'd work's source is distributed
> >> under non-GPL terms, well ... I'll say that the meaning of "BSD
> >> licensed" will have become much less reliable, since it means you
> >> actually have to trace the genealogy of the libraries you use *all*
> >> the way back in order to understand the situation for certain.
> >
> > How so?  To me it's the exact converse: if the author of Hakyll may
> > *not* distribute his work under the BSD license, just because it is
> > intended to be linked with some GPL code, this complicates issues
> > tremendously.
>
> For instance, it would mean that businesses which may be writing
> proprietary software can't assume they can freely use a liberally
> licensed (e.g., BSD3) library — which would *completely* go against
> the prevailing understanding of liberally licensed software.  Tainting
> your software with a GPL dependency without realizing it is a
> terrifying prospect (and certainly one of the questions I'd now like
> to pose to the SFLC).
>

I don't think I follow your reasoning here:  certainly, a business can use,
freely, the Hakyll library (meaning that they can redistribute, in binary
form, their executable built with it, without distributing the Hakyll source
or their own source).  They cannot freely use the Pandoc library in the same
way, because it is GPL.  Since the Hakyll library depends on the Pandoc
library, they will of course have some trouble with *building* an executable
that contains Hakyll but not Pandoc.  Both there's no hidden dependency, no
'tainting' of Hakyll involved.  There is a danger, of course, that when
installing Hakyll (via cabal) the user won't realize they've also installed
Pandoc, even though the dependency is clearly specified.  The lesson here is
that someone packaging an executable for distribution has to be aware of
everything they are building into it.  It's possible to make a mistake here,
if one is not careful.  But it doesn't require much diligence to get it
right (if you use cabal to build your executable, you have to specify your
dependencies.  Check the licensing terms of each, and comply).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: usb-safe-0.1

On Wed, Dec 9, 2009 at 2:35 PM, Bas van Dijk  wrote:
> Hello,
>
> My usb library provides a standard Haskell abstracting layer over
> bindings-libusb providing: abstract types instead of Ptrs, automatic
> marshalling and unmarshalling, automatic garbage collection,
> exceptions instead of integer return codes, etc..
>
> While all that is very nice there are still some things that you can
> do wrong. For example doing I/O with a closed device or reading from
> or writing to an endpoint which doesn't belong to the claimed
> interface. Or reading from an Out endpoint or writing to an In
> endpoint.
>
> I released the usb-safe package to prevent you making these errors. See:
>
> http://hackage.haskell.org/package/usb-safe-0.1
>
> usb-safe provides the following guarantees:
>
> -  You can't reference handles to devices that are closed. In other
> words: no I/O with closed handles is possible.
>
> - The programmer specifies the region in which devices should remain
> open. On exit from the region the opened devices are automatically
> closed.
>
> - You can't reference handles to configurations that have not been set.
>
> - You can't reference handles to interfaces that have not been claimed.
>
> - You can't reference handles to alternates that have not been set.
>
> - You can't reference endpoints that don't belong to a setted alternate.
>
> - You can't read from an endpoint with an Out transfer direction.
>
> - You can't write to an endpoint with an In transfer direction.
>
> - You can't read from or write to endpoints with the unsupported
> transfer types Control and Isochronous. Only I/O with endpoints with
> the Bulk and Interrupt transfer types is allowed.
>
> The primary technique used in usb-safe is called "Lightweight monadic
> regions" which was invented by Oleg Kiselyov and Chung-chieh Shan.
> See:
>
> http://okmij.org/ftp/Haskell/regions.html#light-weight
>
> Note that I consider this a preview release. In fact, I haven't tested
> the package at all. I can only guarantee you that it will pass the
> type-checker.
>
> As always: questions, comments and patches are more than welcome.
>
> Please don't look at the hscolour generated source code from the
> haddock documentation because it screws up the nice unicode symbols I
> used. If you want to read the source download the package or go
> straight to the darcs repos:
>
> darcs get http://code.haskell.org/~basvandijk/code/usb-safe
>
> regards,
>
> Bas
>

I just released a new 0.2 version of usb-safe which adds the type synonym:

type TopDeviceRegion s = DeviceRegionT s IO

and the function:

runTopDeviceRegion ∷ (∀ s. TopDeviceRegion s α) → IO α

I changed the name of 'forkDeviceRegionT' to 'forkTopDeviceRegion' and
changed its type accordingly.

Because these are API changes and additions I bumped the version from
0.1 to 0.2 following the PVP[1].

See:

http://hackage.haskell.org/package/usb-safe-0.2

darcs get http://code.haskell.org/~basvandijk/code/usb-safe

regards,

Bas

[1] http://haskell.org/haskellwiki/Package_versioning_policy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

pexports Was: Re: [Haskell-cafe] binding to C libraries on Windows was Low Level Audio - Writing bytes to the sound card?

2009-12-09 Thread Stephen Tetley

Hi All,

Would a pure Haskell version of pexports be useful to the Haskell community?

For a Sunday afternoon hack that turned out to take a bit more effort
(its now Wednesday), I thought I'd code up a tool that extracts
function symbols from .dll's (also when I first looked at the C
pexports it seemed somewhat unadopted, though checking today it
appears to in MinGW, so my local MinGW must be out-of-date).

If there are compelling uses that aren't covered by pexports and would
ease Haskell C binding problems on Windows, I don't mind polishing up
my tool, but otherwise I've exhausted my natural interest.

Best wishes

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

Re: [Haskell-cafe] Re: ANN: hakyll-0.1

2009-12-09 Thread Tom Tobin

On Wed, Dec 9, 2009 at 4:59 AM, Ketil Malde  wrote:
> Tom Tobin  writes:
>> If it turns out that Hakyll *is* okay to be BSD3 licensed so
>> long as neither any binary nor the GPL'd work's source is distributed
>> under non-GPL terms, well ... I'll say that the meaning of "BSD
>> licensed" will have become much less reliable, since it means you
>> actually have to trace the genealogy of the libraries you use *all*
>> the way back in order to understand the situation for certain.
>
> How so?  To me it's the exact converse: if the author of Hakyll may
> *not* distribute his work under the BSD license, just because it is
> intended to be linked with some GPL code, this complicates issues
> tremendously.

For instance, it would mean that businesses which may be writing
proprietary software can't assume they can freely use a liberally
licensed (e.g., BSD3) library — which would *completely* go against
the prevailing understanding of liberally licensed software.  Tainting
your software with a GPL dependency without realizing it is a
terrifying prospect (and certainly one of the questions I'd now like
to pose to the SFLC).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: unicode-symbols-0.1.1

2009-12-09 Thread Roel van Dijk

Hello,

I would like the announce the release of my package unicode-symbols:
http://hackage.haskell.org/package/unicode-symbols

It offers alternative symbols for a number of common functions and
operators from the base and containers packages. When used in
combination with the language extension UnicodeSyntax you can write
really nice code. The only thing missing is a nice λ symbol.

The documentation on hackage should be pretty self explanatory. For
each symbol the documentation gives its exact definition. The source
code however, probably due to a bug in hscolour, is totally
unreadable. To view the sources simply download the package and use a
text editor.

I tried to be conservative with the choice of unicode symbols. I have
defined the division sign (÷) to be (/). But it could just as well be
defined as 'div'. I do not know what would be the logical choice.

Another choice that could lead to some discussion is the definition of
(⊂) to be 'Data.Set.isProperSubsetOf' and (⊆) to be
'Data.Set.isSubsetOf'. An alternative choice would be to have (⊊) for
'isProperSubsetOf' and (⊂) for 'isSubsetOf'. I choose the former
because it is more symmetrical with (<) and (≤).

This package was inspired by unicode-prelude from Péter Diviánszky:
http://hackage.haskell.org/package/unicode-prelude

Regards,
Roel van Dijk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?

2009-12-09 Thread Duncan Coutts

On Mon, 2009-12-07 at 20:31 +0100, Henning Thielemann wrote:
> Somehow I missed this thread. I want to say that I have implemented a general 
> way to add the information of an exception to the "end" of an arbitrary data 
> structure.
> 
> http://hackage.haskell.org/packages/archive/explicit-exception/0.1.4/doc/html/Control-Monad-Exception-Asynchronous.html
> 
> 
> Duncan already mentioned it:
> 
> > data Exceptional e a = Exceptional {
> >   exception :: Maybe e
> >   result:: a
> > }
> 
> > However it's pretty clear from the structure of this type that it cannot
> > cope with lazy error handling in sequences. If you try it you'll find
> > you cannot do it without space leaks.
> 
> Actually you spotted the space leak - but how is it pretty clear, that it 
> has the space leak?

Yes you're right, it's not that clear. First time I saw the type my
intuition was that would have a space leak but I had to do some work to
demonstrate it. I was misremembering, it's only clear in retrospect :-)

> I also agree with you, that the possibility to access the result directly, 
> and thus easily ignore the exception is bad. I thought it could be 
> improved by removing the field accessors and instead provide the function:
> 
> switch :: (Maybe e -> c) -> (a -> c) -> Exceptional e a -> c

True.

As a general approach though, I think I rather like just making up extra
algebraic types and handling them with their natural folds and unfolds.
It's very much in the pure lazy FP tradition.

Duncan

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

Re: [Haskell-cafe] Checking dependencies from C packages in cabal

2009-12-09 Thread Marc Weber

Hi Maurício,

> When pkg-config info is not available for a library (when I could
Until you get the perfect answer you may want to have a look at the
cabal definitions of

zlib digest OpenGLRaw GLUT readline GLFW wxcore terminfo berkeleydb
BerkeleyDB hubris pcre-light HDBC-mysql HDBC-sqlite3 HDBC-odbc
HDBC-postgresql

They all require additional C libraries to built.
Also make sure to search the Cabal mailinglist and maybe even move this
thread to the Cabal mailinglist.
Eg just typing pkg-config and cabal into google revealed:
http://markmail.org/message/aumw5ustnyrishvw
There is a also a bug tracker for Cabal.

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

[Haskell-cafe] OpenAL and Hsndfile

2009-12-09 Thread Matthew

Yesterday, I set out to accomplish the challenge of loading and  
playing a sound from a file.
So far, my attempts have resulted only in silence... rather  
disheartening after all the effort

it took to get everything to build and run cleanly.

I currently take the following steps:
- Load samples from file into an IOCArray using hsndfile
- Create an OpenAL buffer which points to the IOCArray
- Play sound using OpenAL
code is at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13836


I'm wondering if anyone who is familiar with these libraries can tell  
me if I'm using them
sanely or not.  Alternatively, if anyone has a favorite sound library  
and can help me get

started with that, I'd be very grateful.

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

[Haskell-cafe] ANNOUNCE: ls-usb-0.1.0.2

2009-12-09 Thread Roel van Dijk

Hello everyone,

I have released a minor update of my ls-usb program:

http://hackage.haskell.org/package/ls-usb

This small utility lists USB devices connected to your system. It can
also show you the device descriptors, interface descriptors, vendor
and product identifiers and various other things. All in wonderful
colours of course.

The only major change is that it now depends on usb-0.3.*

Regards,
Roel van Dijk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: usb-safe-0.1

Hello,

My usb library provides a standard Haskell abstracting layer over
bindings-libusb providing: abstract types instead of Ptrs, automatic
marshalling and unmarshalling, automatic garbage collection,
exceptions instead of integer return codes, etc..

While all that is very nice there are still some things that you can
do wrong. For example doing I/O with a closed device or reading from
or writing to an endpoint which doesn't belong to the claimed
interface. Or reading from an Out endpoint or writing to an In
endpoint.

I released the usb-safe package to prevent you making these errors. See:

http://hackage.haskell.org/package/usb-safe-0.1

usb-safe provides the following guarantees:

-  You can't reference handles to devices that are closed. In other
words: no I/O with closed handles is possible.

- The programmer specifies the region in which devices should remain
open. On exit from the region the opened devices are automatically
closed.

- You can't reference handles to configurations that have not been set.

- You can't reference handles to interfaces that have not been claimed.

- You can't reference handles to alternates that have not been set.

- You can't reference endpoints that don't belong to a setted alternate.

- You can't read from an endpoint with an Out transfer direction.

- You can't write to an endpoint with an In transfer direction.

- You can't read from or write to endpoints with the unsupported
transfer types Control and Isochronous. Only I/O with endpoints with
the Bulk and Interrupt transfer types is allowed.

The primary technique used in usb-safe is called "Lightweight monadic
regions" which was invented by Oleg Kiselyov and Chung-chieh Shan.
See:

http://okmij.org/ftp/Haskell/regions.html#light-weight

Note that I consider this a preview release. In fact, I haven't tested
the package at all. I can only guarantee you that it will pass the
type-checker.

As always: questions, comments and patches are more than welcome.

Please don't look at the hscolour generated source code from the
haddock documentation because it screws up the nice unicode symbols I
used. If you want to read the source download the package or go
straight to the darcs repos:

darcs get http://code.haskell.org/~basvandijk/code/usb-safe

regards,

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

[Haskell-cafe] ANNOUNCE: usb-0.3

Hello

I made a new release of my usb library for high-level communication
with usb devices from Haskell. See:

http://hackage.haskell.org/package/usb-0.3

I made the following changes compared to the previous 0.2.0.1:

- Moved the enumeration of usb devices in its own module: System.USB.Enumeration

- Moved the device descriptor inside the device type so that you can
retrieve it without doing IO, e.g: deviceDesc :: Device -> DeviceDesc

- Moved the configuration descriptors inside the device descriptor so
you can retrieve them without doing IO, e.g: deviceConfigs ::
DeviceDesc -> [ConfigDesc]

- Implemented standard device requests that are missing from libusb.

- Made the timeout of I/O operations explicit. Now all I/O operations
return an additional Bool that indicates if the operation has timed
out. If an operation timed out does not mean there is no result, it
just means that the result may be incomplete.

- Added experimental (and still untested) support for iteratees for
doing predictable, high-performance, safe, and elegant input
processing using the iteratee package. See module:
System.USB.IO.Synchronous.Enumerator

- Fixed some asynchronous exception related bugs (put a needed
bracket, block and unblock here and there).

- Finally some functions, constructors and types got renamed,
documentation got updated and extended and some refactoring has taken
place.

As always: questions, comments and patches are more than welcome.

darcs get http://code.haskell.org/~basvandijk/code/usb

regards,

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

[Haskell-cafe] ANNOUNCE: bindings-libusb-1.4.2

Hello,

I just uploaded a new release of Maurício C. Antunes' bindings-libusb
to hackage. See:

http://hackage.haskell.org/package/bindings-libusb-1.4.2

bindings-libusb is a bindings-DSL based, low-level binding to libusb.
This release adds support for the recent libusb-1.0.5.

BTW, there is work being done to create a Windows port for libusb.
This means that in the near future libusb and therefor bindings-libusb
and my usb packages will work on all major platforms, hooray!

regards,

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

Re: [Haskell-cafe] diff implementation in haskell

2009-12-09 Thread Sean Leather

On Wed, Dec 9, 2009 at 13:41, Chris Eidhof wrote:

> Also, there is a paper about doing a type-safe diff in Agda,
> http://portal.acm.org/citation.cfm?id=1596614.1596624
>

Surprisingly, the paper also discusses a comparable implementation in
Haskell.

I heard rumors that the library will be ported to Haskell.
>

Yes, I heard that this library will be released at some point. Wonder how
that's going...

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

[Haskell-cafe] Checking dependencies from C packages in cabal

2009-12-09 Thread Maurício CA


Hi, all,

When pkg-config info is not available for a library (when I could
use pkgconfig-depends), what should I use to check if needed
libraries are installed and to give the compiler all needed info
about include files and library location?

Also, is it possible to do that without configure and make
files? I have no experience with them. I also tried reading the
Distribution module, but wasn't able to recognize what could be a
natural way to handle this problem.

Thanks,
Maurício

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

Re: [Haskell-cafe] diff implementation in haskell

2009-12-09 Thread Chris Eidhof


Also, there is a paper about doing a type-safe diff in Agda, 
http://portal.acm.org/citation.cfm?id=1596614.1596624

I heard rumors that the library will be ported to Haskell.

-chris

On 8 dec 2009, at 15:20, Bayley, Alistair wrote:


From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Ketil Malde

Don Stewart  writes:



   http://hackage.haskell.org/package/Diff


Wherein we can read:

| This is an implementation of the O(ND) diff algorithm
[...]. It is O(mn)
| in space.

At first I thought 'N' and 'M' would be the lengths of the lists, and
'D' is the number of differences, but then the space bound
doesn't make
sense.  I tried to find the reference, but Citeseer is down
(again. sigh).

Anybody know what the bounds really are?



I think the space bounds are O(M+N). Section "4b. A Linear Space
Refinement" concludes with "Unfortunately, the input sequences A and B
must be kept in memory, implying that a total of O(M+N) space is
needed."

BTW, there is a minor improvement to this algorithm (claims to be
faster, same space usage):
 http://research.janelia.org/myers/Papers/np_diff.pdf

found via:

http://scholar.google.com/scholar?q=%22An+O(NP)+Sequence+Comparison+Algo
rithm.%22

I thought this paper was easier to understand.

Alistair
*
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*

___
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: Allowing hyphens in identifiers

Oh yes I forgot. You will also need to map not merely those places where 
hyphens are used by the language, but also those circumstances where, wondering 
how to state it abstractly, anyway in string literals and such where 
substitutions should not occur.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Allowing hyphens in identifiers