David Menendez wrote:
] data Vec n a where
] Nil :: Vec Zero a
] Cons :: a -> Vec n a -> Vec (Succ n) a
] data Vec_0 a = Nil
] data Vec_s v a = Cons a (v a)
Ashley Yakeley wrote:
] vcons a v Zero = a
] vcons a v (Succ n) = v n
S.M.Kahrs wrote:
] data Cons b a = a :. b
On behalf of the many, many contributors, I am pleased to announce
that the
Haskell Communities and Activities Report
(8th edition, May 2005)
http://www.haskell.org/communities/
is now available from the Haskell Communities home page in severa
hey guys !
I´m pretty nu to haskell, and i got the following things to do:
code a client in python that sends string ->done
code a server in haskell that recieves string -> to do...
i initialized the server, set up a socket on port 9900,
so the socket is allready open...
First i read th
Tony Finch <[EMAIL PROTECTED]> writes:
>> But they don't differ in addressing. In BSD sockets the difference
>> between streams and packets lies in "socket type", while addresses
>> are split into "address families" which bijectively correspond to
>> "protocol families".
>
> I believe there are so
On Thu, 12 May 2005, Marcin 'Qrczak' Kowalczyk wrote:
>
> But they don't differ in addressing. In BSD sockets the difference
> between streams and packets lies in "socket type", while addresses
> are split into "address families" which bijectively correspond to
> "protocol families".
I believe the
Einar Karttunen wrote:
But what URI should represent e.g. unix datagram sockets?
Having an URI connection function would be nice, but having
it as the primary alternative would not be very nice.
Could URI schemes like those in the Java Generic Connection Framework
(see:
http://developers.sun.com/
Peter Simons <[EMAIL PROTECTED]> writes:
> >> [URIs might be the answer]
>
> > But what URI should represent e.g. unix datagram sockets?
>
> I don't think it's worth even trying to hide both stream-
> and packet-oriented services behind the same API. These are
> completely different things, trea
Einar Karttunen writes:
>> Well, I certainly _do_ need [a representation of network
>> addresses in Haskell].
> You can certainly get it:
> getHost mySocketAddress niNumerichost
> getServ mySocketAddress niNumericserv
Um, yes, but 'String' isn't a very good representation for
manipulating n
Peter Simons <[EMAIL PROTECTED]> writes:
> > Lifting [network address information] to Haskell level
> > seems quite pointless, as it is usually just fed back to
> > the C functions.
>
> Well, I certainly _do_ need it.
You can certainly get it:
getHost mySocketAddress niNumerichost
getServ mySoc
At 14:05 12/05/05 +0200, Peter Simons wrote:
The longer I think about this whole thing, the more I am
convinced that using URIs is the answer.
FWIW, the revised URI parsing code [2][3] in the latest libraries includes
support for IPv6 literals, as specified by RFC 3986 [1].
#g
--
[1] ftp://ftp.rf
Doctoral Studentships in Computing Science
Oxford University Computing Laboratory (CancerGrid)
Microsoft Research
Applications are invited for two doctoral studentships at the
University of Oxford, starting in October 2005, in the areas of:
* object models
* web services
The students will
Einar Karttunen writes:
> Lifting [network address information] to Haskell level
> seems quite pointless, as it is usually just fed back to
> the C functions.
Well, I certainly _do_ need it.
> The current way is to ignore adress families as much as
> possible while still supporting multipl
Peter Simons <[EMAIL PROTECTED]> writes:
> Judging from a quick glance, the code seems to marshal the
> POSIX API:
>
> type SockAddrLen = Int
> data SockAddrT
> type SockAddr = ForeignPtr SockAddrT
> data SocketAddress = SA !SockAddr !SockAddrLen
>
> I'm not sure whether that's a use
13 matches
Mail list logo
