- Haskell-Cafe - Haskell.org

Re: Haskell <-> C/C++ comunication (sockets/pipes?)
by Jorge Adriano 28 Sep '01

28 Sep '01

Can you tell me what is the problem here? Haskell app output is redirected to C++ input app (and vice-versa) using pipes. (used Erays shell script sugestion) When I try Hsk: 1. get, 2.send C++: 1. send, 2 get It works fine, but if I try it the other way around it locks. C++ app won't get any input. Seems to me like Hsk is not 'flushing' the output. If this is the case, I can't really explain why it happens... if the output was not redirected I am pretty sure that, before trying to get input the output would be flushed (imagine something like putStrLn "please type an int:") So what is the issue here? Here is the code, And once again, thanks in advance. J.A. ------------------------------- Haskell app: send -> get ------------------------------- main :: IO() main = do --send hsnum putStrLn "6" -- get cnum and save num <- readLn :: IO(Int) writeFile "./reshs.txt" (show num) ---------------------------- C++ app: get -> send ---------------------------- #include <cstdio> #include <iostream> #include <fstream> nt main(){ // *get* hsnum and save int num; ofstream out("rescc.txt"); cin >> num; out << num; // *send* cnum cout << 10 << '\n' << flush; //it works without the flush return 0; }

1 0

RE: GUI Library Task Force
by Simon Marlow 27 Sep '01

27 Sep '01

> Thats great. I don't disagree. Its just a matter of priority. > So how about this agenda? Careful: we're in danger of not getting *anything* done if we try to prioritise the tasks like this. I think it's far more important to just have one complete GUI system that everyone can use, even if it isn't perfect. I'm absolutely in favour of the current GUI effort. So, when the hierarchical libraries come on-line then we'll have to rename the modules of the GUI library to place them in the hierarchy. That's not a big deal, since we're going to rename all our other library modules too. > Addendum 1: Hierarchical Library Namespace The extension is virtually finalized and all the compilers implement it. However, there's the much bigger task of actually moving over to using the hierarchically organised libraries; this effort is ongoing. We intend to move GHC over for the next version, but leave some compatibility libraries in place. > Addendum 2: Concurrency Hasn't changed much in ages, and largely independent of the others (apart from module name differences with the library hierarchy). Consider GHC's implementation as a draft proposal for a report adendum. I plan to write up a proper proposal at some point (although if someone else were to volunteer, I wouldn't complain :-). > Addendum 3: FFI Almost finalized. Again, independent apart from module names. > Addendum 4: Exceptions Consider GHC's implementation a proposal, but omit the asynchronous exception support. Hugs (in CVS) implements nearly the same interface. > Addendum 4.5?: Proc Syntax for Arrows > Addendum 5: Library Interface Compatibility Guidelines The document we've been drafting for the new library organisation has the beginnings of a set of guidelines, and contributions are of course welcome. The point I'm making is that we can parallelise these tasks to a certain extent, and that doing so is essential in order for us avoid bottlenecks and to converge at all. I agree with many of the points you raise about Haskell needing these features in order to be an "industrial strength" language, but saying things like "we must wait for X so we can do Y properly" has historically not resulted in X appearing in a timely fashion, which in turn leads to no Y at all. Manuel has done a good job of specifying the job of the GUI task force so that it doesn't depend on any of these other tasks, and I think that's the right way to go. Cheers, Simon

2 1

Haskell <-> C/C++ comunication (sockets/pipes?)
by Jorge Adriano 26 Sep '01

26 Sep '01

Hi all, I was thinking about making some GUIs in Qt/KDE for some haskell applications (compiled with ghc). My first idea was to simply run haskell applications with some args using the GUI and get the results from some file or something like that. Anyway someone told me that a better idea would be to use pipes to enable the GUI to comunicate with the application. I checked the ghc libs and there was a pipe function, but I would need named pipes here (right?) since the two processes are not related. I didn't found any function for that in the ghc libs... is there one? I was also told that another (better way) to do this would be to use sockets. I've worked a little bit with posix stuff (fork, pipes, etc) but I never worked with sockets. I was thinking about using named pipes if that's possible, anyway, Id like to know what you think. Is possible. Is sockets a good solution? better? worth the trouble of learning how to use them? Any better ideas? J.A. PS: Good luck to the GUI task force ;)

3 4

RE: Joy and Concatenative Programming
by Frank Atanassow 25 Sep '01

25 Sep '01

[redirected to haskell-cafe] > I just found out about a functional programming language called Joy (see > http://www.latrobe.edu.au/philosophy/phimvt/joy.html) > > Joy differs from Haskell in that it has no variables. Instead, all > functions are postfix, taking a stack as their argument and returning a > stack as a result. Also, IIRC, Joy is untyped. Programming in Joy is like programming with categorical combinators, but ignoring the types. Indeed, a category with one object is just a monoid, and this is supposedly the theory Joy is founded on. But if you really think variables are a nuisance to programming, you can do it in Haskell too, by using list combinators and defining a reverse composition operator. Or just go program in CAML bytecode. It's pretty much the same thing. > Joy advocates contend that the elimination of variables and environments > improves on functional languages in much the same way the elimination of > state improved on imperative languages. I think the situations are qualitatively different. Saying that Joy programs "lack variables" is pretty close to saying that its free variable environments are linearly ordered. Yet a Joy programmer can reorder the arguments on the stack if he rewrites his program to take account of that fact. So, though the ordering is really irrelevant, every Joy program must pick one, and that can be understood as non-declarative, since it has nothing to do with the result of the program. FP languages factor out that arbitrary choice by treating free variable environments as (multi-)sets. (Of course, you lose that advantage when you package up your environment in a closure, because Haskell distinguishes between a -> b -> c and b -> a -> c, even though they are isomorphic.) --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791

1 0

RE: gconsym
by Simon Peyton-Jones 24 Sep '01

24 Sep '01

I don't really understand the "regardless of.." part. But, yes, ":" is a qconop, with precedence and associativity infixr 5. Simon | -----Original Message----- | From: Ian Lynagh [mailto:igloo@earth.li] | Sent: 24 September 2001 13:34 | To: haskell-cafe(a)haskell.org | Subject: gconsym | | | | Just to make sure I am interpreting the report correctly, is | ":" meant to be a valid qconop regardless of the | precedence-level and associativity of the qconop? | | | Thanks | Ian | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

2 1

gconsym
by Ian Lynagh 24 Sep '01

24 Sep '01

Just to make sure I am interpreting the report correctly, is ":" meant to be a valid qconop regardless of the precedence-level and associativity of the qconop? Thanks Ian

1 0

RE: Socket library from hslibs
by Simon Marlow 21 Sep '01

21 Sep '01

Chris Webb writes: > For simple networking, I usually find that the simple Socket interface > from hslibs does everything I need, except that I always need > to import > sClose from SocketPrim as well, so I can close the sockets I open. > Tidying up some old code this morning, I was wondering: is the absence > of sClose in the Socket interface accidental, or should I be disposing > of listening sockets some other way? No, I think you're right. Socket should really export sClose too. Perhaps it should be called Socket.close, or closeSocket? Cheers, Simon

1 0

Socket library from hslibs
by Chris Webb 21 Sep '01

21 Sep '01

For simple networking, I usually find that the simple Socket interface from hslibs does everything I need, except that I always need to import sClose from SocketPrim as well, so I can close the sockets I open. Tidying up some old code this morning, I was wondering: is the absence of sClose in the Socket interface accidental, or should I be disposing of listening sockets some other way? Cheers, Chris.

1 0

Re: let/where
by John Hughes 20 Sep '01

20 Sep '01

The point of where is that it scopes over guards and multiple equations as well as right hand sides. f x | xsquared < 1000 = xsquared | otherwise = 0 where xsquared = x*x For the same reason, it has to be restricted to appear at the "top level" of a right hand side. Of course, we also need a construct to bind local variables inside an expression -- hence let, which therefore cannot scope over guards. Two kinds of scope, two binding constructions. We could have got away with one, if we had thrown out guards and relied just on if-then-else to test conditions instead. But guards are very expressive: some programs would have been a lot harder to write without them. Typical examples are when we just want to pick out one case in the first equation of a function, before lots of pattern matching: f x y | simplecase x y = simpleanswer f p1 p2 = ... f p3 p4 = ... ... There's no neat way to write this with if-then-else: you need to split f into two functions f x y = if simplecase x y then simpleanswer else f' x y f' p1 p2 = ... ... That's the reason Haskell has two binding constructions. John Hughes

3 2

Re: let/where
by Norman Ramsey 20 Sep '01

20 Sep '01

> There was some debate about which to have - it's a matter of personal > preference and style. The problem is that if you have both let and where > in the expression syntax, then > > let a in b where c > > is ambiguous unless you make an arbitrary decision about the precedence, Was it not considered to forbid such ambiguous expressions, requiring explicit parentheses to resolve the ambiguity? Norman, who sometimes wishes `where' were a postfix `let', and not part of the declaration syntax (though he does not wish to give up scoping over multiple guards).

2 1