is will finish successfully?
> # tmp/bin/ghc --version # GHC should be usable
>
>
> success on both my machines using a slightly modified version of your
> suggestion above for 21506:
>
> ./configure --prefix=`pwd`/tmp# specifying ./tmp seems to be critical
>
>
-rc .
$ make install# perhaps this will finish successfully?
# tmp/bin/ghc --version # GHC should be usable
success on both my machines using a slightly modified version of your
suggestion above for 21506:
./configure --prefix=`pwd`/tmp# specifying ./tmp seems
| This seems to works marvellously, but in writing it I ran into 2
| annoyances.
|
| 1) The type errors produced by trying to use a function on a disallowed
| phantom type are rather unclear.
|
| Could not deduce (Restrict Int ('[] *)) arising from a use of ‛foo
|
| Which got me thinking,
* Merijn Verstraaten mer...@inconsistent.nl [2013-06-15 22:05:52+0100]
2) for some reason the type families syntax always requires a full
argument list, which I find rather ugly. I would much prefer to use
KindSignatures and write type family Restrict :: * - [*] -
Constraint, but GHC
Hello fellow haskellers!
I was experimenting with restricting functions operating on GADTs with phantom
types to only work on a subset of the possible phantom types. I ended up with
the following code:
{-# LANGUAGE ConstraintKinds, DataKinds, GADTs, TypeFamilies, TypeOperators #-}
import
#2588: Missed suggestion with context on foralls
---+
Reporter: NeilMitchell | Owner:
Type: bug | Status: closed
Priority: lowest
On Sat, Dec 15, 2012 at 08:13:44AM +0100, Petr P wrote:
This is strange, I thought that cpphs should be specified in
build-tools:, not in build-depends:.
http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information
Best regards,
Petr
Presumably the reason to list
2012/12/15 Brent Yorgey byor...@seas.upenn.edu
On Sat, Dec 15, 2012 at 08:13:44AM +0100, Petr P wrote:
This is strange, I thought that cpphs should be specified in
build-tools:, not in build-depends:.
http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information
On 13 Dec 2012, at 18:40, Michael Snoyman wrote:
I'm not quite certain what to make of:
If you have a commercial use for cpphs, and feel the terms of the (L)GPL
are too onerous, you have the option of distributing unmodified binaries
(only, not sources) under the terms of a different
On 13 Dec 2012, at 10:41, Petr P wrote:
In particular, we can have a BSD package that depends on a LGPL package, and
this is fine for FOSS developers. But for a commercial developer, this can be
a serious issue that is not apparent until one examines *every* transitive
dependency.
This
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote:
So if I put cpphs into build-tools and I don't have it installed, the
build will fail? Is this a desired behavior, or a bug?
Shortcoming of cabal; it only knows about libraries because it is really
just a front-end for ghc-pkg,
On Sat, Dec 15, 2012 at 4:25 PM, Malcolm Wallace malcolm.wall...@me.comwrote:
On 13 Dec 2012, at 10:41, Petr P wrote:
In particular, we can have a BSD package that depends on a LGPL package,
and this is fine for FOSS developers. But for a commercial developer, this
can be a serious issue
On Sat, Dec 15, 2012 at 9:25 AM, Malcolm Wallace malcolm.wall...@me.comwrote:
This might a good time to remind everyone that every single program
compiled by a standard GHC is linked against an LGPL library (the Gnu
multi-precision integer library) - unless you take care first to build your
On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery allber...@gmail.com
wrote:
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote:
So if I put cpphs into build-tools and I don't have it installed, the
build will fail? Is this a desired behavior, or a bug?
Shortcoming of
On Sat, Dec 15, 2012 at 4:38 PM, Henk-Jan van Tuyl hjgt...@chello.nlwrote:
On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery allber...@gmail.com
wrote:
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote:
So if I put cpphs into build-tools and I don't have it installed, the
On 15 Dec 2012, at 16:54, Michael Snoyman wrote:
I would strongly recommend reconsidering the licensing decision of cpphs.
Even if the LICENSE-commercial is sufficient for non-source releases of
software to be protected[1], it introduces a very high overhead for companies
to need to
This is strange, I thought that cpphs should be specified in
build-tools:, not in build-depends:.
http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information
Best regards,
Petr
2012/12/13 Michael Snoyman mich...@snoyman.com
On Thu, Dec 13, 2012 at 9:51 PM, Daniel
Dear Haskellers,
following up the recent discussion about copyleft licenses, I'd suggest a
(hopefully minor) improvement of Hackage: For each package, gather the list
of the licenses of everything it depends on. I think this would help
considerably people who don't want or can't use software
On Thu, 13 Dec 2012 11:41:14 +0100, Petr P petr@gmail.com wrote:
For each package, gather the list
of the licenses of everything it depends on. I think this would help
considerably people who don't want or can't use software licensed under a
particular license (most often (L)GPL). In
I think that's a great idea. I just implemented this on PackDeps:
http://packdeps.haskellers.com/licenses
As with all features on that site, I'll be happy to deprecate it as soon as
Hackage incorporates the feature in the future.
Michael
On Thu, Dec 13, 2012 at 12:41 PM, Petr P
On 12/13/2012 12:51 PM, Michael Snoyman wrote:
I think that's a great idea. I just implemented this on PackDeps:
http://packdeps.haskellers.com/licenses
As with all features on that site, I'll be happy to deprecate it as
soon as Hackage incorporates the feature in the future.
awesome
On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez t...@snarc.org wrote:
On 12/13/2012 12:51 PM, Michael Snoyman wrote:
I think that's a great idea. I just implemented this on PackDeps:
http://packdeps.haskellers.**com/licenseshttp://packdeps.haskellers.com/licenses
As with all features on
While you're at it, maybe whitelisting cpphs would be nice as well =).
On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman mich...@snoyman.com wrote:
On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez t...@snarc.org wrote:
On 12/13/2012 12:51 PM, Michael Snoyman wrote:
I think that's a great
Are you referring to:
http://code.haskell.org/cpphs/LICENCE-commercial
If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
the cabal file to mention the BSD3 so that its package description is less
intimidating?
On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa
From [1] I gather that its license really is LGPL/GPL. However, when
used as a preprocessor its license doesn't really matter. Many
packages on that list have a LGPL taint because one of its deps use
cpphs. So the whitelist of cpphs would be stating that nobody is
using cpphs as a library
I'm not quite certain what to make of:
If you have a commercial use for cpphs, and feel the terms of the (L)GPL
are too onerous, you have the option of distributing unmodified binaries
(only, not sources) under the terms of a different licence (see
LICENCE-commercial).
It seems like that's
On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
If you have a commercial use for cpphs, and feel the terms of the (L)GPL
are too onerous, you have the option of distributing unmodified binaries
(only, not sources) under the terms of a different licence (see
On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
If you have a commercial use for cpphs, and feel the terms of the (L)GPL
are too onerous, you have the option of distributing unmodified
#2588: Missed suggestion with context on foralls
-+--
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: lowest
#7255: Wrong suggestion when deriving Generic on an instantiated type
--+-
Reporter: dreixel | Owner: dreixel
Type: bug | Status: new
Priority: normal
#7255: Wrong suggestion when deriving Generic on an instantiated type
-+--
Reporter: dreixel |Owner: dreixel
Type: bug | Status: closed
Priority
#7255: Wrong suggestion when deriving Generic on an instantiated type
--+-
Reporter: dreixel | Owner: dreixel
Type: bug | Status: new
Priority: normal
#7255: Wrong suggestion when deriving Generic on an instantiated type
--+-
Reporter: dreixel | Owner: dreixel
Type: bug | Status: new
Priority: normal
#5657: section suggestion adds backticks to operators
---+
Reporter: tinctorius| Owner: simonmar
Type: bug | Status: closed
Priority: high
#5657: section suggestion adds backticks to operators
-+--
Reporter: tinctorius| Owner: simonmar
Type: bug | Status: merge
Priority: high
#5657: section suggestion adds backticks to operators
-+--
Reporter: tinctorius| Owner: simonmar
Type: bug | Status: new
Priority: high
#5657: section suggestion adds backticks to operators
-+--
Reporter: tinctorius| Owner: simonmar
Type: bug | Status: new
Priority: high
#5657: section suggestion adds backticks to operators
-+--
Reporter: tinctorius| Owner: simonmar
Type: bug | Status: new
Priority: high
#5657: section suggestion adds backticks to operators
-+--
Reporter: tinctorius| Owner:
Type: bug | Status: new
Priority: normal| Component
The problem isn't social pressure to be stable, it's the ambiguity of what
stable means. If Hackage 2 institutes a policy whereby things claiming to
be stable are treated better, then stable is likely to become the new
experimental.
I'd say, rather than rely on social agreement on what
On 10/25/11 3:54 AM, Gregory Collins wrote:
On Tue, Oct 25, 2011 at 4:34 AM, wren ng thorntonw...@freegeek.org wrote:
I'm not so sure about that exemption. The experimental stability level
seems to be the norm on Hackage and often means I use this for real
projects, but because I use it for
#5564: Panic in ghci name suggestion
---+
Reporter: judahj| Owner: simonmar
Type: bug | Status: closed
Priority: high | Milestone: 7.4.1
On Tue, Oct 25, 2011 at 4:34 AM, wren ng thornton w...@freegeek.org wrote:
I'm not so sure about that exemption. The experimental stability level
seems to be the norm on Hackage and often means I use this for real
projects, but because I use it for real projects I'm not quite willing to
hammer
On 25 October 2011 18:54, Gregory Collins g...@gregorycollins.net wrote:
On Tue, Oct 25, 2011 at 4:34 AM, wren ng thornton w...@freegeek.org wrote:
I'm not so sure about that exemption. The experimental stability level
seems to be the norm on Hackage and often means I use this for real
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:
Right, but first we need to define what all those terms _mean_... and
it's no good saying your package is stable if you change the API in
a large-scale fashion every release.
I think there are better criteria to use, like:
- do exported
On Tue, Oct 25, 2011 at 11:17, Ketil Malde ke...@malde.org wrote:
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:
Right, but first we need to define what all those terms _mean_... and
it's no good saying your package is stable if you change the API in
a large-scale fashion every
On 25 October 2011 20:17, Ketil Malde ke...@malde.org wrote:
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:
Right, but first we need to define what all those terms _mean_... and
it's no good saying your package is stable if you change the API in
a large-scale fashion every release.
On Tue, Oct 25, 2011 at 2:17 AM, Ketil Malde ke...@malde.org wrote:
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:
Right, but first we need to define what all those terms _mean_... and
it's no good saying your package is stable if you change the API in
a large-scale fashion every
Max Rabkin max.rab...@gmail.com writes:
This is useful information, but to call it stability is not only
misleading, but it also prevents the package from using that field to
indicate whether or not it is stable!
Oh, right - I'm not much interested in the stability of a package. What
I want
#5564: Panic in ghci name suggestion
-+--
Reporter: judahj|Owner: simonmar
Type: bug | Status: new
Priority: high |Milestone: 7.4.1
#5564: Panic in ghci name suggestion
-+--
Reporter: judahj|Owner: simonmar
Type: bug | Status: new
Priority: high |Milestone: 7.4.1
On Mon, Oct 10, 2011 at 09:06:01AM +0100, Paterson, Ross wrote:
The distinction between synopsis and description is borrowed from the
Debian package format:
http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions
The two fields are aimed at different audiences.
Not in
Good point. On the other hand, nobody points package authors to the
Debian documentation (and Debian also has review for newly uploaded
packages, as far as I know).
Re: review process -- Perhaps there would be a use for a review process
somewhere between haskell-platform and the unwashed
On Mon, Oct 24, 2011 at 12:55 PM, Ryan Newton rrnew...@gmail.com wrote:
Good point. On the other hand, nobody points package authors to the
Debian documentation (and Debian also has review for newly uploaded
packages, as far as I know).
Re: review process -- Perhaps there would be a use for a
On 10/24/11 12:34 PM, Gregory Collins wrote:
Examples could include: Your package lacks a description, more than
X% of your modules lack toplevel module comments, fewer than Y% of
your toplevel exports have haddock comments, etc... Packages with
stability=experimental would probably be exempt
On 25 October 2011 13:34, wren ng thornton w...@freegeek.org wrote:
Before dealing with automatic documentation requirements, perhaps it'd be
better to develop a standard consensus on the terms used in the stability
field and actively advocating for people to adopt it, as was done with the
#5564: Panic in ghci name suggestion
-+--
Reporter: judahj|Owner: simonmar
Type: bug | Status: new
Priority: high |Milestone: 7.4.1
#5564: Panic in ghci name suggestion
-+--
Reporter: judahj| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
On Mon, Oct 10, 2011 at 03:17, John Millikin jmilli...@gmail.com wrote:
The package summary is Type-safe ADT-database mapping library., which
gives some idea about what it does.
Whence my suggestion to show this on the package's page. Perhaps I
shouldn't have hidden that at the bottom -- I
Max Rabkin writes:
But I also have a concrete suggestion for Hackage: include the package
synopsis on the package's page. The distinction between synopsis and
description can be confusing, and sometimes it seems to violate DRY to
have the same info in both.
You may have missed the header
On Mon, Oct 10, 2011 at 10:06, Paterson, Ross r.pater...@city.ac.uk wrote:
Max Rabkin writes:
But I also have a concrete suggestion for Hackage: include the package
synopsis on the package's page. The distinction between synopsis and
description can be confusing, and sometimes it seems
, but for tutorials etc. a website might be
more appropriate) but if so link to it from both the Haddocks and the
package description.
But I also have a concrete suggestion for Hackage: include the package
synopsis on the package's page. The distinction between synopsis and
description can be confusing
The package summary is Type-safe ADT-database mapping library., which
gives some idea about what it does.
In my experience, any package that starts its source files with
{-# LANGUAGE GADTs, TypeFamilies, ExistentialQuantification,
StandaloneDeriving, TypeSynonymInstances,
Hi Jeremy
Is this really a problem practically rather than hypothetically?
Data.Text and Syb-with-class - both are general, neither uses the
other for their implementation, adding a dependency to one sounds like
a bad idea - so making a separate 'instance' package seems most
sensible.
Unless
Hello,
There are a number of libraries like syb-with-class, happstack-data, etc,
which provide a new class that potentially has a lot of new instances.
For example, let's say I want a 'Data ctx Text' instance. Where should that
go?
To avoid orphan instances it would need to go in the 'text'
Hi Jeremy
A fourth option is to create a new package which contains just the instance.
For example:
syb-with-class-text
I may be mistaken - but can't you just put the instance in a module
(within syb-with-class) and make syb-with-class not import it by
default?
Why do you have to create a
Excerpts from Ivan Miljenovic's message of Tue Mar 16 01:53:13 +0100 2010:
On 16 March 2010 11:50, Marc Weber marco-owe...@gmx.de wrote:
I may be mistaken - but can't you just put the instance in a module
(within syb-with-class) and make syb-with-class not import it by
default?
That
#3633: Heap size suggestion of 2145 MB gets ignored
-+--
Reporter: tim | Owner: igloo
Type: merge | Status: closed
Priority: high| Milestone: 6.12.2
Could I suggest that the following short text be included in the GHC
6.12.1 final release notes, in some form?
-- cut here --
Updating third-party packages
-
A number of packages will need modifying to build on GHC 6.12.1 (in
some cases, just modifying the
#3633: Heap size suggestion of 2145 MB gets ignored
-+--
Reporter: tim | Owner: igloo
Type: merge | Status: new
Priority: high| Milestone: 6.12.2
#3633: Heap size suggestion of 2145 MB gets ignored
-+--
Reporter: tim | Owner:
Type: bug | Status: new
Priority: normal | Milestone
On Tue, 2009-09-29 at 14:31 -0400, Sean McLaughlin wrote:
Hello,
I have a program that does a lot of unicode manipulation. I'd like
to use hslogger to log various operations.
However, since hslogger uses System.IO.putX, the unicode comes out
mangled. I hacked the source to
use
, Sep 29, 2009 at 1:31 PM
Subject: [Haskell-cafe] suggestion for hslogger
To: haskell-cafe@haskell.org
Hello,
I have a program that does a lot of unicode manipulation. I'd like
to use hslogger to log various operations.
However, since hslogger uses System.IO.putX, the unicode comes out
On Wed, 2009-09-30 at 08:36 -0500, John Goerzen wrote:
If you want to send me a patch that makes it an option (not mandatory),
I would be happy to apply it.
When reviewing it do consider the new Unicode IO library.
Duncan Coutts wrote:
On Wed, 2009-09-30 at 08:36 -0500, John Goerzen wrote:
If you want to send me a patch that makes it an option (not mandatory),
I would be happy to apply it.
When reviewing it do consider the new Unicode IO library.
Hello,
I have a program that does a lot of unicode manipulation. I'd like to use
hslogger to log various operations.
However, since hslogger uses System.IO.putX, the unicode comes out mangled.
I hacked the source to
use System.IO.UTF8 instead, but it would be nice if that was an option so I
Forwarding on to the maintainer, in case he's not on the list.
-- Forwarded message --
From: Sean McLaughlin sean...@gmail.com
Date: Tue, Sep 29, 2009 at 1:31 PM
Subject: [Haskell-cafe] suggestion for hslogger
To: haskell-cafe@haskell.org
Hello,
I have a program that does
Several libraries define their own codes for they keyboard (GLFW, GTK, GLUT,
etc)
Maybe it would be nice to agree on a standard datatype for keys? This might
also include digital buttons on a joystick, etc...
The Windows API has virtual key codes for this.
Peter Verswyvelen wrote:
Several libraries define their own codes for they keyboard (GLFW, GTK, GLUT,
etc)
Maybe it would be nice to agree on a standard datatype for keys? This might
also include digital buttons on a joystick, etc...
The Windows API has virtual key codes for this.
X windows
But should we use X11 as the standard library then, even on Windows or Mac?
It surely is better than nothing, but it feels a bit weird to install X11
just for using the key codes.
Maybe splitting these keys into a separate package would be a good idea?
On Wed, Aug 26, 2009 at 12:42 PM, Yitzchak
Peter Verswyvelen wrote:
Several libraries define their own codes for they keyboard
(GLFW, GTK, GLUT, etc)
Maybe it would be nice to agree on a standard datatype
for keys?
...The Windows API has virtual key codes for this.
I wrote:
X windows key symbols...
are found in the X11 package
Excerpts from Peter Verswyvelen's message of Wed Aug 26 12:15:14 +0200 2009:
Maybe it would be nice to agree on a standard datatype for keys? This might
also include digital buttons on a joystick, etc...
The synergy project (sourceforge) already does some mapping from Windows
- Linux - Mac
I would already be happy with a low level library that holds the union of
all keys, assigning them unique codes. So you would have keys like Apple,
Amiga, Windows, Start, Popup, LeftControl, RightControl, etc... No mapping
is done at the low level.
Then one would need an OS dependent interface to
On Mon, Jun 22, 2009 at 7:27 PM, Tim Sheard she...@cs.pdx.edu wrote:
My idea is to use types to ensure that any
sequence of operations adheres to a path on
a finite state automata. For example
if we wanted to implement the following
automata (This needs to read in a fixed width font)
On Jun 24, 2009, at 05:11 , Johan Tibell wrote:
Oleg writes:
In this design, the operation of creating a socket and connecting it
are bundled together -- which is very common and is the case for
System V, I think (where it is called openActive, I think). If you
for
I don't believe that is
On Wed, Jun 24, 2009 at 8:16 PM, Brandon S. Allbery KF8NH
allb...@ece.cmu.edu wrote:
The BSD socket protocol is explicitly driven by a state machine, btw, but
it's a fairly complex one. Also, it's generally described in terms of the
kernel's view, which includes states you normally can't
existing, I additionally really like the
suggestion of moving from the ML to a wiki in the same style as
Haskell'.
I'll port these comments to the wiki if that is whats agreed on and
hold off on other thoughts for now.
Yes, please start a new wiki page. We can still discuss issues here
On Wed, Jun 24, 2009 at 9:15 PM, John Van Enk vane...@gmail.com wrote:
One thing I'd really like to see, now that I'm thinking about it, is
to drop the dependency on the ./configure step when building network.
If I can figure this out without changing how Network.Socket works
now, would that
I'll take a swing at it. :) If it's as easy as it was to get HsOpenSSL
to build without the ./configure (on windows even!), it shouldn't be
too bad.
PS: If any one has contact with the maintainers of HsOpenSSL, poke
them for me. I'd like my patch included. :)
On Wed, Jun 24, 2009 at 3:25 PM,
A search in google images for sockets state diagram comes up with some
relatively good ones
http://images.google.com/images?hl=enum=1sa=3q=sockets+state+diagrambtnG=Search+images
Most of them are just the TCP connection state logic, but I'm sure I'd find
others there if I looked closer.
- Job
On
On Wed, Jun 24, 2009 at 9:43 PM, Job Vranish jvran...@gmail.com wrote:
A search in google images for sockets state diagram comes up with some
relatively good ones
http://images.google.com/images?hl=enum=1sa=3q=sockets+state+diagrambtnG=Search+images
Most of them are just the TCP connection
On Jun 24, 2009, at 16:04 , Johan Tibell wrote:
On Wed, Jun 24, 2009 at 9:43 PM, Job Vranish jvran...@gmail.com
wrote:
A search in google images for sockets state diagram comes up with
some relatively good ones
On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
I'm in favor of the entire Network library being reworked with an
improved API that is higher level and type-safe instead of a direct
translation/FFI of Berkeley sockets. I also would like the Network
Johan - glad you chimed in!
I'm all in favor of keeping a low level interface and don't have an
issue with Network.Socket existing, I additionally really like the
suggestion of moving from the ML to a wiki in the same style as
Haskell'.
I'll port these comments to the wiki if that is whats
the
suggestion of moving from the ML to a wiki in the same style as
Haskell'.
I'll port these comments to the wiki if that is whats agreed on and
hold off on other thoughts for now.
* ByteStrings! Absolutely. The one issue is I feel network packets
should be represented as strict bytestrings and any
On Mon, Jun 22, 2009 at 1:52 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
Johan - glad you chimed in!
I'm all in favor of keeping a low level interface and don't have an
issue with Network.Socket existing, I additionally really like the
suggestion of moving from the ML to a wiki
Tibelljohan.tib...@gmail.com wrote:
On Mon, Jun 22, 2009 at 1:52 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
Johan - glad you chimed in!
I'm all in favor of keeping a low level interface and don't have an
issue with Network.Socket existing, I additionally really like the
suggestion of moving
On Mon, Jun 22, 2009 at 2:46 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
All,
I've started to add to the network trac [1] - its just framework for
now. Please do add proposals, organized comments, and feel free to
alter the framework. I'm not sure how formal we'd like to make
Hello List,
Is there any one else in favor of hiding the PortNum constructor in
Network.Socket in the next release? Here's why:
Prelude :m + Network.Socket Data.Word
Prelude Network.Socket Data.Word let p = 5000 :: Word16
Prelude Network.Socket Data.Word let p' = PortNum p
Prelude Network.Socket
Quoth John Van Enk vane...@gmail.com,
[... example showing that PortNum is stored in network byte order ]
Notice that using the PortNum constructor does not at all do what the
user expects. This really should be a hidden constructor.
Could you elaborate, what does the user expect?
1 - 100 of 395 matches
Mail list logo
