Also, you don't seem to have thought about the question of parametric
instances: do you allow them or not, if you do, what computational
power do they get etc.?
I may or may not have thought about it. Maybe you can give an example
of parametric instances where there could be problems, so that
On Sat, Jan 14, 2012 at 1:29 AM, Bardur Arantsson s...@scientician.net wrote:
So, the API becomes something like:
runSocketServer :: ((Chan a, Chan b) - IO ()) - ... - IO ()
where the first parameter contains the client logic and A is the type of
the messages from the client and B is the
On Fri, Jan 13, 2012 at 12:19:34PM -0800, Donn Cave wrote:
Quoth Serge D. Mechveliani mech...@botik.ru,
...
Initially, I did the example by the Foreign Function Interface for C.
But then, I thought But this is unnatural! Use plainly the standard
Haskell IO, it has everything.
So, your
I've been trying to write networking code in Haskell too. I've also
come to the conclusion that channels are the way to go. However,
what's missing in the standard `Chan` type, which is essential for my
use-case, is the ability to do the equivalent of the unix select call.
My other slight qualm is
Disregard that last comment on `TChan`s; retry blocks. you learn a new
thing every day [=
Daniel
On 14 January 2012 11:27, Daniel Waterworth da.waterwo...@gmail.com wrote:
I've been trying to write networking code in Haskell too. I've also
come to the conclusion that channels are the way to
Hi guys,
I'm not happy with asynchronous I/O in Haskell. It's hard to reason
about, and doesn't compose well.
Async I/O *is* tricky if you're expecting threads to do their own
writes/reads directly to/from sockets. I find that using a
message-passing approach for communication makes
On 01/14/2012 11:42 AM, Joey Adams wrote:
On Sat, Jan 14, 2012 at 1:29 AM, Bardur Arantssons...@scientician.net wrote:
So, the API becomes something like:
runSocketServer :: ((Chan a, Chan b) - IO ()) - ... - IO ()
where the first parameter contains the client logic and A is the type
Hi Daniel,
I've been trying to write networking code in Haskell too. I've also
come to the conclusion that channels are the way to go.
isn't a tuple of input/output channels essentially the same as a stream
processor arrow? I found the example discussed in the arrow paper [1]
very
On 01/10/2012 11:12 PM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Tue Jan 10 09:54:38 -0500 2012:
On 01/10/2012 12:17 AM, Edward Z. Yang wrote:
Hello Mikhail,
Hi.
(Apologies for reviving a two month old thread). Have you put some thought into
whether or not these
Hi Peter,
streamproc is a very interesting package, I'll surely use it somewhere
in the future. However, I'm not convinced that this solves my
immediate problem, but perhaps this is due to my inexperience with
arrows. My problem is:
I have a number of network connections and I have a system that
Bryan O'Sullivan b...@serpentine.com writes:
The question is a simple one. Must all operations on a TVar happen
within *the same* atomically block, or am I am I guaranteed thread
safety if, say, I have a number of atomically blocks in an IO
function.
If you want successive operations to see
Quoth Serge D. Mechveliani mech...@botik.ru,
By openFile you, probably, mean openFd.
Yes, sorry!
Another point is the number of open files, for a long loop.
...
toA_IO = openFd toA WriteOnly Nothing defaultFileFlags
...
When applying axiomIO in a loop of 9000 strings, it breaks:
On Sat, Jan 14, 2012 at 11:57, Donn Cave d...@avvanta.com wrote:
I don't know. When I was younger, I used to track these problems down
and try to explain in detail why buffered I/O is a bad bet with pipes,
sockets etc. I don't think anyone listened. I think I am going to
experiment with I
On 01/14/2012 03:55 PM, Ketil Malde wrote:
Bryan O'Sullivanb...@serpentine.com writes:
The question is a simple one. Must all operations on a TVar happen
within *the same* atomically block, or am I am I guaranteed thread
safety if, say, I have a number of atomically blocks in an IO
function.
On 14 January 2012 18:05, Steffen Schuldenzucker
sschuldenzuc...@uni-bonn.de wrote:
I think consistent state here means that you can be sure no other thread
has modified a, say, TVar, within the current 'atomically' block.
OK, well take a modified example, where I am wanting to call an IO
On 14 January 2012 19:24, Rob Stewart robstewar...@googlemail.com wrote:
On 14 January 2012 18:05, Steffen Schuldenzucker
sschuldenzuc...@uni-bonn.de wrote:
I think consistent state here means that you can be sure no other thread
has modified a, say, TVar, within the current 'atomically'
On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
I may or may not have thought about it. Maybe you can give an example
of parametric instances where there could be problems, so that I can
figure out whether my system works on the example or not.
The
On 1/14/12 6:27 AM, Daniel Waterworth wrote:
p.s I'd avoid the TChan for networking code as reading from a TChan is
a busy operation. [1]
[1]
http://hackage.haskell.org/packages/archive/stm/2.2.0.1/doc/html/src/Control-Concurrent-STM-TChan.html#readTChan
The `retry`-ness will be rectified
On 1/14/12 2:24 PM, Rob Stewart wrote:
Are IO functions permissible in STM atomically blocks?
They are not. The semantics of STM are that each transaction is retried
until it succeeds, and that the number of times it is retried does not
affect the program output. Thus, you can only do things
I'm a research mathematician at a research institute with a bunch of other
mathematicians (a number of whom are also expert programmers). I recently
(starting three months ago) have been learning Haskell. I'm going to give
a talk to the staff about it. Most of the audience are pretty
Hi everybody,
I want to test a higher level language than C/C++ (type inference, garbage
collection), but much faster than Python. So I am naturally led to Haskell or
OCaml.
I have read and tested tutorials for the two languages. For the time being, my
preference goes to Haskell, first
Hey Victor,
Thankfully, there's lots of material and experience reports available,
along with code, for the Haskell+science use case.
In my view Haskell works well as a coordination language, for
organizing computation at a high level, and thanks to its excellent
compiler and runtime, also works
On Sat, Jan 14, 2012 at 18:18, TP paratribulati...@free.fr wrote:
Times expr1 Plus( expr2 expr3 ) -
OCaml pattern syntax is not the same as Haskell pattern syntax. The
correct way to write that pattern is
Times expr1 (Plus expr2 expr3)
This is consistent with Haskell not using
Hi
I'm working on a little experiment at the moment: using monadic
QuickCheck to test the integration of my code and the database. I see
some of my functions having properties like - given a database in this
state, selectAll should return all rows, and so on. My initial attempt
has worked nicely,
I'm using haskell-src-exts together with SYB for a code-rewriting project,
and I'm having difficulty with parenthesization. I naïvely expected that
parentheses would be absent from the abstract syntax, being removed during
parsing and inserted during pretty-printing. It's easy for me to remove
Hi Conal
I don't know if any Haskell src-exts code exists. Norman Ramsey has
published an algorithm for it, plus ML code:
http://www.cs.tufts.edu/~nr/pubs/unparse-abstract.html
I've transcribed the code to Haskell a couple of times for small
expression languages. As far as I remember you need
26 matches
Mail list logo
