Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Ketil Malde

Mike Meyer m...@mired.org writes:

 Niklas Larsson metanik...@gmail.com wrote:
2012/12/15 Mike Meyer m...@mired.org:
 Only if Tanenbaum documented the internal behavior of Linux before
 it was written.

Tannenbaum wrote Minix, the operating system that Linus used (and
hacked on) before he did Linux. Minix contained lots of features that
was reimplemented in Linux.

 Ah, Minix isn't documentation.  And it has a radically different
 architecture

The point is that Linux read the source code to Minix before
implementing similar things - quite likely using the same algorithms,
for instance.  So if containers is a translation of FXT, then surely
Linux is a translation of Minix.

 That makes a successful lawsuit unlikely 

The point of the point is that neither of these are translations of
literary works, there is no precedence for considering them as such, and
that reading somebody's work (whether literary or source code) before
writing one's own does not imply that the 'somebody' will hold any
rights to the subsequent work.

Translations in software is what compilers do, not reimplementing
specific algorithms.

 it'll never go to court, so there isn't an infringement.  

Wot?

-k



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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Ketil Malde

Mike Meyer m...@mired.org writes:

 As it's commonly understood, reverse engineering doesn't involve
 looking at the code. 

I guess I should make it clear that I don't use it in the strict sense -
I would call that clean-room reverse engineering.  (I'm not sure which
is the most commonly understood meaning, I think Wikipedia supports
both interpretations)

 That's why it's called reverse engineering instead of copying. 

I mean the process of reimplementing specific functionality from another
system, with or without knowledge of implementation details.  I would
use copying to mean verbatim cut-and-pasting, which is something else.

In particular when copyright is concerned, I believe that verbatim
copying in many cases will require a license to the original work, but
merly examining the original work to make use of algorithms, tricks, and
structures from it will not.

I suspect there's nothing magical about source code, if I extract a
component (algorithm or data structure, say) from a program and use it
in my own program, I'm not convinced it matters if I extract it from
object code, source code, or documentation - they're all copyrighted
works, and could be interpreted as translations of the same work.  I
could be wrong about that, though.

-k



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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Chris Smith
Ketil Malde ke...@malde.org wrote:
 The point of the point is that neither of these are translations of
 literary works, there is no precedence for considering them as such, and
 that reading somebody's work (whether literary or source code) before
 writing one's own does not imply that the 'somebody' will hold any
 rights to the subsequent work.

So IANAL, but I do have an amateur interest in copyright law.  The debate
over the word translation is completely irrelevant.  The important point
is whether it is a derived work.  That phrase certainly includes more
than mere translation.  For example, it includes writing fiction that's set
in the same fantasy universe or HHS the same characters as another author's
works.  It also includes making videos with someone else's music playing in
the background. If you create a derived work, then the author of the
original definitely has rights to it, regardless of whether it is a mere
translation.  That's also why the word derived in a comment was
particularly Dacey to the legal staff and probably caused them to overreact
in this case.

The defense in the case of software is to say that the part that was copied
was not a work of authorship in the sense that, say, a fiction character
is.  This is generally not a hard case to win, since courts see computer
software as dominated by its practical function.  But if you copied
something that was clearly a matter of expression and not related to the
function of the software, you could very well be creating a derived work
over which the original author could assert control.

That said, I agree that in this particular case it's very unlikely that the
original author could have won an infringement case.  I just balked a
little at the statements about translation, which was really just an
example.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Cabal: Retrieve directory in which binaries get installed

2012-12-17 Thread Björn Peemöller
Hello cafe,

I'd like to retrieve the path in which binaries get installed when I
`cabal install` a package.

Normally, this would be ~/.cabal/bin on my Linux, but since I share my
home folder on two architectures, in ~/.cabal/config I set the
user-install prefix to ~/.cabal/$arch, so binaries get installed to
~/.cabal/$arch/bin.

I have the feeling that it should be rather simple to retrieve the
FilePath from the Cabal API, does anyone know how to do this?

Thanks in advance,
Björn

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


Re: [Haskell-cafe] Cabal: Retrieve directory in which binaries get installed

2012-12-17 Thread Roman Cheplyaka
There's getBinDir in the generated module Paths_pkgname
(dist/build/autogen/Paths_pkgname.hs).

This module is generated by cabal configure and can be imported
in the modules of your package.

Roman

* Björn Peemöller b...@informatik.uni-kiel.de [2012-12-17 11:05:52+0100]
 Hello cafe,
 
 I'd like to retrieve the path in which binaries get installed when I
 `cabal install` a package.
 
 Normally, this would be ~/.cabal/bin on my Linux, but since I share my
 home folder on two architectures, in ~/.cabal/config I set the
 user-install prefix to ~/.cabal/$arch, so binaries get installed to
 ~/.cabal/$arch/bin.
 
 I have the feeling that it should be rather simple to retrieve the
 FilePath from the Cabal API, does anyone know how to do this?
 
 Thanks in advance,
 Björn
 
 ___
 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] Navigating 'Strategic' programming babel

2012-12-17 Thread Ravi Sahni
Clearly Haskell has great possibilities in the field of
language-processing.  And the nuisances associated with little actual
computation buried under much data-structure navigation are well addressed
by 'strategic-programming' systems.

But now comes the rub -- there seem to be a lot of very similar systems.

Any guidance on which/what/how to choose?

My own current sketchy-patchy knowledge is as below. I would appreciate
links/pointers to more substansive literature.

First there was Meertens and his folks working on generic haskell
Did that later become template haskell?

That branched out into strafunski, stratego/xt.

SYB is ___ not sure here: some literature suggests that its identical to
strafunski.  Some suggests that it is strafunski done more within the
haskell language rather than in libraries.

Then there's uniplate. How does it compare to SYB?  Or is that a confused
comparison?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Navigating 'Strategic' programming babel

2012-12-17 Thread José Pedro Magalhães
Hi Ravi,

You might want to browse through Comparing Libraries for Generic
Programming in Haskell:
http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-010.pdf

SYB and Uniplate are two widely used and well-maintained systems for
strategic traversals over arbitrary datatypes. There are other options,
too, but it depends on exactly what you want to do.


Cheers,
Pedro

On Mon, Dec 17, 2012 at 11:30 AM, Ravi Sahni ganeshsahn...@gmail.comwrote:

 Clearly Haskell has great possibilities in the field of
 language-processing.  And the nuisances associated with little actual
 computation buried under much data-structure navigation are well addressed
 by 'strategic-programming' systems.

 But now comes the rub -- there seem to be a lot of very similar systems.

 Any guidance on which/what/how to choose?

 My own current sketchy-patchy knowledge is as below. I would appreciate
 links/pointers to more substansive literature.

 First there was Meertens and his folks working on generic haskell
 Did that later become template haskell?

 That branched out into strafunski, stratego/xt.

 SYB is ___ not sure here: some literature suggests that its identical to
 strafunski.  Some suggests that it is strafunski done more within the
 haskell language rather than in libraries.

 Then there's uniplate. How does it compare to SYB?  Or is that a confused
 comparison?



 ___
 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] Navigating 'Strategic' programming babel

2012-12-17 Thread Ravi Sahni
On Mon, Dec 17, 2012 at 4:06 PM, José Pedro Magalhães j...@cs.uu.nl wrote:

 Hi Ravi,

 You might want to browse through Comparing Libraries for Generic
 Programming in Haskell:
 http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-010.pdf

 SYB and Uniplate are two widely used and well-maintained systems for
 strategic traversals over arbitrary datatypes. There are other options,
 too, but it depends on exactly what you want to do.


My interest is language processing for which stratego, strafunski, UUAG etc
are specially tailor-made.  Yes Ive read the 'comparing libraries' paper in
which it says that strafunski and SYB approaches are so similar that
strafunski is subsumed under SYB for the purposes of that paper.

However it seems that the strafunski-ecosystem being integrated with aterm
etc, likewise stratego, are more suited to full-scale language processing.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] [Haskell] ANN: Haskell bindings for the igraph C library

2012-12-17 Thread Nils Schweinsberg

Am 16.12.2012 20:24, schrieb Jason Dagit:

How does this compare with fgl? http://hackage.haskell.org/package/fgl


FGL is a pure Haskell library while our haskell-igraph package uses the 
foreign function interface to run all graph-related calculations in C 
the C library igraph (I haven't implemented any graph algorithms). The 
runtime performance with our igraph library should be the same as if 
you'd be using the native C library (if you ignore the small 
Haskell-C-Haskell overhead).


It is also seems to be more of a higher level library. As user you don't 
have to worry about node-IDs/labels or whether your graph is static or 
not (in the FGL context). Using features like GADTs and type 
families/associated types it is possible to keep track of informations 
like whether or not your graph is directed/weighted or not, while in FGL 
all graphs are by default directed and unweighted. Consider for example


  edges :: Graph d a - [Edge d a]

  -- directed, unweighted graph
  g :: Graph D a

  -- undirected, weighted graph
  w :: Graph (Weighted U) a

which leads to

  edges g :: [Edge D a]
  edges w :: [Edge (Weighted U) a]

or even functions like

  toUndirected :: (IsDirected d, E (ToUndirected d) a)
   = Graph d a
   - Graph (ToUndirected d) a

  toDirected   :: (IsUndirected u, E (ToDirected u) a)
   = Graph u a
   - Graph (ToDirected u) a

which evaluate to

  toUndirected g :: Graph U a
  toDirected   w :: Graph (Weighted D) a

This is even revertable, and `toDirected . toUndirected == id` while the 
FGL function `undir` simply adds all missing edges and loses track of 
what the original/directed graph looked like.


Maybe George has more details on why he wanted to use igraph instead of FGL.


- Nils

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


[Haskell-cafe] HTF Quickcheck

2012-12-17 Thread graham
Getting test failures, I believe, due to using conditional properties
within quickckeck etc

[TEST] RecFunSpec:map (test/RecFunSpec.hs:48)
Gave up! Passed only 20 tests.
*** Failed! (2ms)

Is there a way for HTF/Quickcheck to specify these are not failed i.e.
only fail if there is an actual error ?

Thanks

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


Re: [Haskell-cafe] HTF Quickcheck

2012-12-17 Thread Roman Cheplyaka
Unfortunately, I don't know the answer to your question.

However, if you don't find a solution, I suggest using SmallCheck
instead of QuickCheck — it works better when you have many unsuitable
cases.
https://github.com/feuerbach/smallcheck/wiki/Comparison-with-QuickCheck

As far as I know, SmallCheck is not supported by HTF, but it is
supported by test-framework.

Roman

* gra...@fatlazycat.com gra...@fatlazycat.com [2012-12-17 15:50:32+]
 Getting test failures, I believe, due to using conditional properties
 within quickckeck etc
 
 [TEST] RecFunSpec:map (test/RecFunSpec.hs:48)
 Gave up! Passed only 20 tests.
 *** Failed! (2ms)
 
 Is there a way for HTF/Quickcheck to specify these are not failed i.e.
 only fail if there is an actual error ?
 
 Thanks

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


Re: [Haskell-cafe] HTF Quickcheck

2012-12-17 Thread Simon Hengel
On Mon, Dec 17, 2012 at 03:50:32PM +, gra...@fatlazycat.com wrote:
 Getting test failures, I believe, due to using conditional properties
 within quickckeck etc
 
 [TEST] RecFunSpec:map (test/RecFunSpec.hs:48)
 Gave up! Passed only 20 tests.
 *** Failed! (2ms)
 
 Is there a way for HTF/Quickcheck to specify these are not failed i.e.
 only fail if there is an actual error ?

I have no idea about HTF, but QuickCheck thinks those are failures, too.
If I run into something like this, it  indicates a bug in my arbitrary
instance.  Here I would just adapt it so that it generates valid test
data (possibly with the help of a newtype wrap).

Cheers,
Simon

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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Mike Meyer
On 12/17/12, Ketil Malde ke...@malde.org wrote:
  I would use copying to mean verbatim cut-and-pasting, which is something 
 else.

I feel I should point out that, while that's currently a common
definition of copying, it's not the legal definition. Copyright law
predates the ability to mechanically create copies of a work. The
closest you could come was the printing press, which started with what
was at the time a handmade mirror image of the work you were going to
print copies of.

Back then, the only way to create a copy of a printed page (or
anything else that wasn't created with the express purpose of being
duplicated) was to read the original, and transcribe it into a copy.
There was no cut-n-paste or copy command - just reading and
creating another copy by hand. Changes made along the way that
depended on the original - adding illustrations or illuminations,
setting it to music, re-arranging it into a script for a play, or
translating it to another language - were all considered derived
works, and hence infringing.

IANAL, but I've been studying copyright law since before the US signed
the Berne treaty. Generally, copyright law in the US has been getting
stricter, not more permissive - largely because the only people who
cared were the large copyright holders. In general, new media brought
under the purview of copyright is treated as strictly as the law can
be interpreted.

In the US, most radio stations pay a license fee in order to play
music. Bars and restaurants (and even the Girl Scouts!) are required
to pay a license fee for public performances if they play live or
recorded music. If you buy media capable of recording music or video,
part of the cost is used to compensate the copyright holders of the
presumably infringing copies you're going to make onto them. If I took
a picture of my living room, I'd technically be in violation of a slew
of copyrights (images of the statuary on the mantelpiece, paintings
hanging on the wall, etc.) but chances are that nobody would care
unless I included images from a FOX television show.

Personally, I think this is silly, but it's the law.

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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Mike Meyer
Ketil Malde ke...@malde.org wrote:
Mike Meyer m...@mired.org writes:
 Niklas Larsson metanik...@gmail.com wrote:
2012/12/15 Mike Meyer m...@mired.org:
 Only if Tanenbaum documented the internal behavior of Linux before
 it was written.
Tannenbaum wrote Minix, the operating system that Linus used (and
hacked on) before he did Linux. Minix contained lots of features that
was reimplemented in Linux.
 Ah, Minix isn't documentation.  And it has a radically different
 architecture
The point is that Linux read the source code to Minix before
implementing similar things - quite likely using the same algorithms,
for instance.  So if containers is a translation of FXT, then surely
Linux is a translation of Minix.

Since they are both C, the concept of translation  doesn't enter into that 
case at all.

I never said that containers was a translation of FXT. I said that translations 
are considered to be derived work requiring permission to copy. This is deeply 
embedded in copyright law, and the GPL *depends* on it working for software. 
Otherwise, a distribution of GPL' d software translated to another language 
(say as asm from the compiler, or a linkable object, or even an executable) 
wouldn't be a derivative work and could be distributed without having to obey 
the license.

The point is that containers being in haskell isn't a defense against copyright 
violation. It doesn't mean that it *is* a translation, merely that it might be. 
That the author of containers said it was derived from FXT opens the 
possibility that his version is actually GPL'ed, so using it opens up the 
possibility of a lawsuit. It may not stand up in court, but the lawyer 
objecting is trying to avoid just that possibility.

 That makes a successful lawsuit unlikely 
The point of the point is that neither of these are translations of
literary works, there is no precedence for considering them as such,

Actually, there *is* a precedent for considering them such. The clean-room 
implementations of the IBM PC bios were done because a judge ruled that 
translating from asm to binary was an infringing copy.

If you have a precedent that translating from one programming language to 
another is *not* the creation of a derived work, I'd be interested in hearing 
about it. Without such a precedent, then a case can be made that such a 
translation is a derived work (and you're the only person I've ever heard claim 
otherwise) which opens up the possibility of a lawsuit, which is what the 
problem is.

and
that reading somebody's work (whether literary or source code) before
writing one's own does not imply that the 'somebody' will hold any
rights to the subsequent work.

This is correct. Reading a copyrighted work does not prove that some subsequent 
creation is a copy of that work.  It does, however, make it *possible* that 
such a work is a copy and needs the appropriate permissions.

Translations in software is what compilers do, not reimplementing
specific algorithms.

Translation in a copyright case is a term of law, and has *nothing* to do 
with the behavior of compilers (other than the precedent that what a compiler 
does is considered a translation for copyright purposes).

Reimplementing an algorithm may or may not be a copyright violation. Depends on 
whether or not the reimplementation involved creation of a work derived (in the 
legal sense) from the original. Access to the original is required for that to 
happen. The two being in the same language is *not* required for that to 
happen. Access to the original and working in the same language is *not* 
sufficient for that to happen.

 it'll never go to court, so there isn't an infringement.  

Tannenbaum isn't going to sue Linus. So either he doesn't believe there is an 
infringement (I suspect this is likely, as he has had access the source and 
would probably have at least said something if he thought there was an 
infringement) or doesn't care enough to go to court. Until a judge tells Linus 
he's infringing, he isn't.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Mike Meyer
Ketil Malde ke...@malde.org wrote:
In particular when copyright is concerned, I believe that verbatim
copying in many cases will require a license to the original work, but
merly examining the original work to make use of algorithms, tricks,
and
structures from it will not.

If you don't actually copy any of the text in the latter case, that would be 
correct. But there's an incredible amount of grey between those two extremes of 
black and white, and it's possible that you've unintentionally recreated 
significant bits of the original.

The Oracle/Google lawsuit was all about those shades of grey - some of the 
API's in Dalvik were implemented by people who had read the Java sources. 
Oracle claimed as much as possible was derivative, Google that none of it was. 
The judge ruled that some uses were infringing and some uses were not. This was 
a technically literate judge - he ruled that one of the cases was 
non-infringing because he could trivially implement the function in Java 
himself.

The lawyer who pointed out the possible infringement here isn't really worried 
about losing such a lawsuit - there are lots of ways to deal with that short of 
actually releasing any sources they consider proprietary. They want to avoid 
the lawsuit *at all*, as that will almost certainly be more expensive than 
losing it. At least, that's what I hear from clients who ask me not to include 
GPL'ed software.

   mike
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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


Re: [Haskell-cafe] Navigating 'Strategic' programming babel

2012-12-17 Thread Stephen Tetley
Strafunski is now rather out of date - it was developed before Cabal
and used a custom install depending whether or not you wanted to use
the DriFt preprocessor.

Andy Gill has a modern re-implementation of Strafuski on Hackage called KURE.

Aside from SYB, Neil Mitchell's Uniplate is popular and generally well
documented.

On 17 December 2012 11:12, Ravi Sahni ganeshsahn...@gmail.com wrote:

 However it seems that the strafunski-ecosystem being integrated with aterm
 etc, likewise stratego, are more suited to full-scale language processing.


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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Clark Gaebel
So I heard back from softwarefreedom.org, and they're looking for a
representative from haskell.org to talk to them, as they want to avoid
conflict-of-interests with other clients.

Does anyone with any official status want to talk to real lawyers about
this issue, then let the list know of anything interesting that was said?
Let me know.

  - Clark


On Mon, Dec 17, 2012 at 10:45 AM, Mike Meyer m...@mired.org wrote:

 Ketil Malde ke...@malde.org wrote:
 In particular when copyright is concerned, I believe that verbatim
 copying in many cases will require a license to the original work, but
 merly examining the original work to make use of algorithms, tricks,
 and
 structures from it will not.

 If you don't actually copy any of the text in the latter case, that would
 be correct. But there's an incredible amount of grey between those two
 extremes of black and white, and it's possible that you've unintentionally
 recreated significant bits of the original.

 The Oracle/Google lawsuit was all about those shades of grey - some of the
 API's in Dalvik were implemented by people who had read the Java sources.
 Oracle claimed as much as possible was derivative, Google that none of it
 was. The judge ruled that some uses were infringing and some uses were not.
 This was a technically literate judge - he ruled that one of the cases was
 non-infringing because he could trivially implement the function in Java
 himself.

 The lawyer who pointed out the possible infringement here isn't really
 worried about losing such a lawsuit - there are lots of ways to deal with
 that short of actually releasing any sources they consider proprietary.
 They want to avoid the lawsuit *at all*, as that will almost certainly be
 more expensive than losing it. At least, that's what I hear from clients
 who ask me not to include GPL'ed software.

mike
 --
 Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

 ___
 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] haskell-like scripting language

2012-12-17 Thread Christopher Howard
I gave Shelly a try. Pretty cool - using it for some of the scripts on
my system. Has me wondering though: is anyone working on creating a
actual Haskell-like scripting language and engine?

Shelly is cool, as I said, but I imagine it would be more valuable to
have another language that is actually separate from Haskell, with an
interpreter that is more lightweight and changes much less frequently
(than GHC). Something that could be nearly as portable as Bash or Perl.

-- 
frigidcode.com



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


Re: [Haskell-cafe] Navigating 'Strategic' programming babel

2012-12-17 Thread Jake McArthur
I won't compare and contrast all these, but I want to point out that there
is a nicer version of uniplate in the lens package.
On Dec 17, 2012 5:31 AM, Ravi Sahni ganeshsahn...@gmail.com wrote:

 Clearly Haskell has great possibilities in the field of
 language-processing.  And the nuisances associated with little actual
 computation buried under much data-structure navigation are well addressed
 by 'strategic-programming' systems.

 But now comes the rub -- there seem to be a lot of very similar systems.

 Any guidance on which/what/how to choose?

 My own current sketchy-patchy knowledge is as below. I would appreciate
 links/pointers to more substansive literature.

 First there was Meertens and his folks working on generic haskell
 Did that later become template haskell?

 That branched out into strafunski, stratego/xt.

 SYB is ___ not sure here: some literature suggests that its identical to
 strafunski.  Some suggests that it is strafunski done more within the
 haskell language rather than in libraries.

 Then there's uniplate. How does it compare to SYB?  Or is that a confused
 comparison?



 ___
 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] haskell-like scripting language

2012-12-17 Thread Evan Laforge
 Shelly is cool, as I said, but I imagine it would be more valuable to
 have another language that is actually separate from Haskell, with an
 interpreter that is more lightweight and changes much less frequently
 (than GHC). Something that could be nearly as portable as Bash or Perl.

Hugs?  It has doesn't change frequently pretty much nailed.

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


Re: [Haskell-cafe] HTF Quickcheck

2012-12-17 Thread Simon Hengel
On Mon, Dec 17, 2012 at 06:04:15PM +0200, Roman Cheplyaka wrote:
 Unfortunately, I don't know the answer to your question.
 
 However, if you don't find a solution, I suggest using SmallCheck
 instead of QuickCheck — it works better when you have many unsuitable
 cases.
 https://github.com/feuerbach/smallcheck/wiki/Comparison-with-QuickCheck
 
 As far as I know, SmallCheck is not supported by HTF, but it is
 supported by test-framework.

test-framework also sometimes thinks a Gave up! is not a fail, which I
think is a bug.  But I gave up on trying to get that fixed [1], e.g.
this (admittedly contrived) property is still a pass with
test-framework:

defaultMain [testProperty foo $ \x - x == 23 == True]

Cheers,
Simon

[1] https://github.com/batterseapower/test-framework/issues/16

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


Re: [Haskell-cafe] containers license issue

2012-12-17 Thread Michael Orlitzky
On 12/17/2012 01:47 PM, Clark Gaebel wrote:
 
 Does anyone ... want to talk to real lawyers ...

No.

This is absurd. If anyone cares, email the original author and explain
the situation. Ask if he's cool with the reimplemented version. Chances
are he'll say yeah, and we've just solved the problem like adults.

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


[Haskell-cafe] category design approach for inconvenient concepts

2012-12-17 Thread Christopher Howard
Recently I read this article I happened across, about the categorical
design pattern:

http://www.haskellforall.com/2012/08/the-category-design-pattern.html

Barely understood it, of course, but it was a rather intriguing concept.
So now I'm looking at all my programming problems trying to make types
that can be composed and that seem to fit the idea of a category.

However, what I'm wondering about is ideas that can be composed but
that don't seem to fit the idea of category, because they don't obey
the associativity law. To give a specific example (pseudo code like,
without any idea here of implementation or proper syntax):

Say you created a type called Component (C for short), the idea being
to compose Components out of other Components. Every C has zero or more
connectors on it. Two Cs can be connected to form a new C using some
kind of composition operator (say, .), provided there are enough
connectors (one on each). Presumably you would need a Fail constructor
of some kind to represent the situation when there is not enough connectors.

Say you had a C (coupler) with two connectors, a C (thing) with one
connector, and a C (gadget) with one connector.

So you could have...

(coupler . thing) . gadget

Because the coupler and the thing would combine to create a component
with one spare connector. This would then combine with the gadget to
make the final component. However, if you did...

coupler . (thing . gadget)

Then thing and gadget combine to make a component with no spare
connectors. And so the new component and the coupler then fail to
combine. Associativity law broken.

So, can I adjust my idea to fit the category concept? Or is it just
not applicable here? Or am I just misunderstanding the whole concept?

-- 
frigidcode.com



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


Re: [Haskell-cafe] category design approach for inconvenient concepts

2012-12-17 Thread Richard O'Keefe

On 18/12/2012, at 3:45 PM, Christopher Howard wrote:
 Recently I read this article I happened across, about the categorical
 design pattern:
 
 http://www.haskellforall.com/2012/08/the-category-design-pattern.html

It's basically the very old idea that an Abstract Data Type
should be a nice algebra: things that look as though they
ought to fit together should just work, and rearrangements
of things ought not to change the semantics in surprising
ways (i.e., Don't Be SQL).

 However, what I'm wondering about is ideas that can be composed but
 that don't seem to fit the idea of category, because they don't obey
 the associativity law.

 Say you created a type called Component (C for short), the idea being
 to compose Components out of other Components. Every C has zero or more
 connectors on it. Two Cs can be connected to form a new C using some
 kind of composition operator (say, .), provided there are enough
 connectors (one on each).

Categories contain two things:
objects
and arrows that connect objects.  Some important things about arrows:
 - for any object x there must be an identity idx : x - x
 - any two compatible arrows must compose in one and only one way:
   f : x - y  g : y - z  =  g . f : x - z
 - composition must be associative (f . g) . h = f . (g . h)
   when the arrows fit together.

Of course for any category there is a dual category,
so what I'm about to say doesn't really make sense,
but there's sense in it somewhere:  the things you are
trying to hook together with your . operator seem to me more
like objects than arrows, and it does not seem as if
they hook together in one and only one way, so it's not so
much _associativity_ being broken, as the idea of . being
a composition in the first place.



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


Re: [Haskell-cafe] category design approach for inconvenient concepts

2012-12-17 Thread Ertugrul Söylemez
Christopher Howard christopher.how...@frigidcode.com wrote:

 Say you created a type called Component (C for short), the idea
 being to compose Components out of other Components. Every C has zero
 or more connectors on it. Two Cs can be connected to form a new C
 using some kind of composition operator (say, .), provided there are
 enough connectors (one on each). Presumably you would need a Fail
 constructor of some kind to represent the situation when there is not
 enough connectors.

 Say you had a C (coupler) with two connectors, a C (thing) with one
 connector, and a C (gadget) with one connector.

 So you could have...

 (coupler . thing) . gadget

 Because the coupler and the thing would combine to create a component
 with one spare connector. This would then combine with the gadget to
 make the final component. However, if you did...

 coupler . (thing . gadget)

 Then thing and gadget combine to make a component with no spare
 connectors. And so the new component and the coupler then fail to
 combine. Associativity law broken.

 So, can I adjust my idea to fit the category concept? Or is it just
 not applicable here? Or am I just misunderstanding the whole concept?

You are not misunderstanding the concept.  You just need to learn how to
apply it in this situation.  Pluggable components with multiple slots
are still modelled by regular categories.  Let's say that Comp is such a
component category (I'm using Haskell syntax):

Comp :: * - * - *

To model a component that takes two inputs you just write a component
that takes one (!) tuple of inputs:

myComp :: Comp (X, Y) Z

For partial application of your component you need a bit more than the
basic category pattern.  Most categories form a family of applicative
functors:

instance Applicative (Comp a)

Then partial application is really just this:

partialMyComp :: X - Comp Y Z
partialMyComp x = myComp . fmap (\y - (x, y)) id

Every category that forms such a family of applicative functors is a
profunctor (see the 'profunctors' package by Edward Kmett):

instance Profunctor Comp

That makes expressing partialMyComp slightly more pleasing:

partialMyComp x = lmap (\y - (x, y)) myComp

Finally to save even more keystrokes enable the TupleSections extension:

partialMyComp x = lmap (x,) myComp

You can get similar description through the Arrow interface:

instance Arrow Comp

partialMyComp x = myComp . arr (x,)

However, often the applicative interface is much more pleasing.

Now to the theory:  What does an applicative functor give you?  It
basically extends a categorical concept by the ability to combine
multiple morphisms to a single one.  Given two morphisms,

c1 :: Comp A B
c2 :: Comp A C

and a function

f :: B - C - D

an applicative functor gives you a well-defined way to combine c1 and c2
into another morphism of type

c3 :: Comp A D

An applicative functor provides about the same theoretical soundness as
a category in that such a combination of multiple Comp morphisms is
itself always a Comp morphism, and that the combination operator itself
cannot introduce unwanted effects because of the Applicative laws:

pure f * x = fmap f x
f * pure x = fmap ($ x) f

pure f * pure x = pure (f x)

In other words, all effects are introduced by primitive components.  I
call them atoms.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


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


Re: [Haskell-cafe] HTF Quickcheck

2012-12-17 Thread graham
So what use are conditional properties meant to be used for ??

If you just want 2 integers that are not equal, it would seem a lot
simpler to do this as a conditional rather than constructing some pair
in an arbitrary instance ?!?

Thanks

On Mon, Dec 17, 2012, at 11:20 PM, Simon Hengel wrote:
 On Mon, Dec 17, 2012 at 06:04:15PM +0200, Roman Cheplyaka wrote:
  Unfortunately, I don't know the answer to your question.
  
  However, if you don't find a solution, I suggest using SmallCheck
  instead of QuickCheck — it works better when you have many unsuitable
  cases.
  https://github.com/feuerbach/smallcheck/wiki/Comparison-with-QuickCheck
  
  As far as I know, SmallCheck is not supported by HTF, but it is
  supported by test-framework.
 
 test-framework also sometimes thinks a Gave up! is not a fail, which I
 think is a bug.  But I gave up on trying to get that fixed [1], e.g.
 this (admittedly contrived) property is still a pass with
 test-framework:
 
 defaultMain [testProperty foo $ \x - x == 23 == True]
 
 Cheers,
 Simon
 
 [1] https://github.com/batterseapower/test-framework/issues/16

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