Non-exhaustive pattern in Socket.hsc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Non-exhaustive pattern in Socket.hsc

Dominic Steinitz
I'm getting

[root@tility pcap]# ./test
test: Socket.hsc:(1434,17)-(1523,20): Non-exhaustive patterns in case

The problem is caused because pcap_findalldevs is returning an address family
value of 17

#define PF_PACKET       17      /* Packet family.  */

#define AF_PACKET       PF_PACKET

and the ghc Family datatype doesn't support it :-(

data Family
  = AF_UNSPEC
    | AF_UNIX
    | AF_INET
    | AF_INET6
    | AF_SNA
    | AF_DECnet
    | AF_APPLETALK
    | AF_ROUTE
    | AF_X25
    | AF_AX25
    | AF_IPX
        -- Imported from Network.Socket

*Main> map packFamily
[AF_UNSPEC,AF_UNIX,AF_INET,AF_INET6,AF_SNA,AF_DECnet,AF_APPLETALK,AF_ROUTE,AF_X25,AF_AX25,AF_IPX]
[0,1,2,10,22,12,5,16,9,3,4]

I think I have two choices:

1. Amend ghc. I haven't built ghc for a long time. Would I have to build the
whole of ghc? I presume I would have to because of dependencies.

2. Use Network.Alt since
http://www.cs.helsinki.fi/u/ekarttun/network-alt/doc/Network.Alt.Types.html 
defines

type Family = Int

Any advice? What is the long term plan for Network anyway?

Thanks, Dominic.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Non-exhaustive pattern in Socket.hsc

Ashley Yakeley
Dominic Steinitz wrote:

> data Family
>   = AF_UNSPEC
>     | AF_UNIX
>     | AF_INET
>     | AF_INET6
>     | AF_SNA
>     | AF_DECnet
>     | AF_APPLETALK
>     | AF_ROUTE
>     | AF_X25
>     | AF_AX25
>     | AF_IPX
>         -- Imported from Network.Socket

> What is the long term plan for Network anyway?

That's a good question. C/C++ uses this address-family-based approach to
handle different protocols, but I think Haskell would do better with a
static approach that typed sockets by network. For instance:

   newtype IP4Address = IP4Address Word32
   newtype IP6Address = IP6Address Word128

   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
     -- or use classes

etc.

--
Ashley Yakeley, Seattle WA
WWEWDD? http://www.cs.utexas.edu/users/EWD/

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Non-exhaustive pattern in Socket.hsc

Simon Marlow-5
In reply to this post by Dominic Steinitz
Dominic Steinitz wrote:

> I'm getting
>
> [root@tility pcap]# ./test
> test: Socket.hsc:(1434,17)-(1523,20): Non-exhaustive patterns in case
>
> The problem is caused because pcap_findalldevs is returning an address family
> value of 17
>
> #define PF_PACKET       17      /* Packet family.  */
>
> #define AF_PACKET       PF_PACKET
>
> and the ghc Family datatype doesn't support it :-(
>
> data Family
>   = AF_UNSPEC
>     | AF_UNIX
>     | AF_INET
>     | AF_INET6
>     | AF_SNA
>     | AF_DECnet
>     | AF_APPLETALK
>     | AF_ROUTE
>     | AF_X25
>     | AF_AX25
>     | AF_IPX
>         -- Imported from Network.Socket

I've now fixed this, the fix will be in GHC 6.6 and future releases of
the network library.

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Non-exhaustive pattern in Socket.hsc

Einar Karttunen
In reply to this post by Ashley Yakeley
On 02.05 13:05, Ashley Yakeley wrote:
> That's a good question. C/C++ uses this address-family-based approach to
> handle different protocols, but I think Haskell would do better with a
> static approach that typed sockets by network. For instance:
>
>   newtype IP4Address = IP4Address Word32
>   newtype IP6Address = IP6Address Word128
>
>   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
>     -- or use classes

This is going to be painfull for applications that want to support
multiple protocols. Why should most applications care whether
it is an IPv4 or an IPv6 address if everything just works?

Of course one can force the app to just use a specific address family,
but is that required most of the time?

- Einar Karttunen
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re[2]: Non-exhaustive pattern in Socket.hsc

Bulat Ziganshin-2
Hello Einar,

Wednesday, May 3, 2006, 1:34:35 PM, you wrote:

> On 02.05 13:05, Ashley Yakeley wrote:
>> That's a good question. C/C++ uses this address-family-based approach to
>> handle different protocols, but I think Haskell would do better with a
>> static approach that typed sockets by network. For instance:
>>
>>   newtype IP4Address = IP4Address Word32
>>   newtype IP6Address = IP6Address Word128
>>
>>   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
>>     -- or use classes

> This is going to be painfull for applications that want to support
> multiple protocols. Why should most applications care whether
> it is an IPv4 or an IPv6 address if everything just works?

type classes?

(it's universal answer, after all :) )


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Non-exhaustive pattern in Socket.hsc

Tomasz Zielonka
On Wed, May 03, 2006 at 02:01:46PM +0400, Bulat Ziganshin wrote:

> > On 02.05 13:05, Ashley Yakeley wrote:
> >>   openTCP4 :: IP4Address -> Word16 -> IO (TCPConnection IP4Address)
> >>     -- or use classes
>
> > This is going to be painfull for applications that want to support
> > multiple protocols. Why should most applications care whether
> > it is an IPv4 or an IPv6 address if everything just works?
>
> type classes?
>
> (it's universal answer, after all :) )

How many functions would benefit from increased type-safety?
I only see getsockname and getpeername... Not much benefit for
the added burden.

For applications dealing with many simultaneous connections
on different protocols you would probably resort to an existential
wrapper that would hide the type of protocol. It would make
more sense if Haskell's support for existential types was more
standard, lightweight and straightforward.

Best regards
Tomasz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Non-exhaustive pattern in Socket.hsc

Dominic Steinitz
In reply to this post by Simon Marlow-5
On Wednesday 03 May 2006 9:21 am, Simon Marlow wrote:

> Dominic Steinitz wrote:
> > I'm getting
> >
> > [root@tility pcap]# ./test
> > test: Socket.hsc:(1434,17)-(1523,20): Non-exhaustive patterns in case
> >
> > The problem is caused because pcap_findalldevs is returning an address
> > family value of 17
> >
> > #define PF_PACKET       17      /* Packet family.  */
> >
> > #define AF_PACKET       PF_PACKET
> >
> > and the ghc Family datatype doesn't support it :-(
> >
> > data Family
> >   = AF_UNSPEC
> >
> >     | AF_UNIX
> >     | AF_INET
> >     | AF_INET6
> >     | AF_SNA
> >     | AF_DECnet
> >     | AF_APPLETALK
> >     | AF_ROUTE
> >     | AF_X25
> >     | AF_AX25
> >     | AF_IPX
> >
> >         -- Imported from Network.Socket
>
> I've now fixed this, the fix will be in GHC 6.6 and future releases of
> the network library.
>
> Cheers,
> Simon

Simon,

Thanks. I'll give network-alt a go before building ghc.

Dominic.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries