Re: Sending wide characters over the network socket
G'day all. On Sat, Jul 05, 2003 at 11:44:54PM -0400, Dimitry Golubovsky wrote: > What would be really nice to have is some sort of object input/output > over network. Then, by sending a String, I would expect it to be > recreated at the other end. And if the other end expects, say [Int] then > an error would be detected. Well there is already a binding for COM (which isn't portable, of course), a beta binding for CORBA, several XML libaries and a half-finished binding for ASN.1. Any of these would get you at least part of the way there. I think what you are asking for, though, is some equivalent of Java's serializable objects. I'm not convinced that producing yet another RPC protocol would be a useful thing, even if it was optimised for Haskell. It seems to me that adequately supporting the large number of existing standards (off the top of my head: DCOM, CORBA, XML-RPC, SOAP, .NET, ASN.1 and Sun RPC; no doubt I've missed a few) would be a far better use of effort. One thing which would be good was a more extensible "derives" keyword which lets you automatically derive code to marshall and demarshall for whatever RPC protocol you want. I'd love to be able to write: data SomeComplexType = Stuff MoreStuff EvenMoreStuff | AndSomeMore AdNauseam deriving( Asn1.Ber, Asn1.Xer, XmlRpc, DCom ) and have it automatically generate any interface definitions (IDL, ASN.1 specifications, whatever) suitable to hold the data type. > I haven't looked through the whole GHC > runtime, and maybe something like this is already there, any clue is > welcome. The only built-in thing is Read/Show, which is functional, but slow, as its representation is textual. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Record of STRefs better than STRef to a Record?
G'day all.
On Wed, Nov 13, 2002 at 04:05:42AM +, Jorge Adriano wrote:
> If I use an STRef to a record, will a new record be created each time I want
> to update a single field?
Basically, yes.
> Right now I'm using a record of STRefs, like:
> data E s = E{
> refi :: STRef s Int,
> refc :: STRef s Char
> }
>
> but it can get a little messy, since thread s propagates to every datatype
> that uses the record type in it's definition.
You could always use IORefs, if you don't mind having the IO monad
threaded through.
Cheers,
Andrew Bromage
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: External library infrastructure
G'day all. On Tue, Nov 12, 2002 at 05:25:42PM +, Alastair Reid wrote: > So as people try to come up with a distribution and build mechanism > that will work for GHC, it would be good to think about how that > same mechanism would work for Hugs too. If you will allow me to AOL... Me too! Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: foralls in newtypes
G'day all.
On Wed, Oct 16, 2002 at 07:54:17AM -0700, Hal Daume III wrote:
> I was reading the HFL libs, namely Control.Monad.Logic, and there's a
> definition in there:
>
> newtype Logic a = Logic { mkLogic :: (forall b. (a -> b -> b) -> b -> b) }
>
> I'm curious why this is legal, but
>
> newtype Logic2 a = forall b . Logic2 ((a -> b -> b) -> b -> b)
>
> is not...
Firstly, it's not the same type, but you probably worked that much
out by yourself. You don't want an existentially quantified
constructor at all, what you want is a constructor with a single
argument which has an existentially quantified function type.
Secondly, I've changed the definition of Logic since you looked at
it, so this is no longer valid. We'll look at a simpler example
anyway, using data instead of newtype:
data CPS a = forall b. CPS ((a -> b) -> b)
What should the type of this function be?
mkCPS (CPS x) = x
Cheers,
Andrew Bromage
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mergesort. Reply
G'day all. On Mon, Jul 01, 2002 at 09:04:37AM +0200, Ketil Z. Malde wrote: > I was going to run through the statistics to work out the expected > running time for a quick sort (i.e. sorting random data); Few programs routinely run on random data. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mergesort. Reply
G'day all. On Fri, Jun 28, 2002 at 09:44:11AM +0200, Ketil Z. Malde wrote: > I, for one, am sorting expected, not worst-case, data :-) > > > What's this obsession with worst-case behaviour anyway? The best algorithm to use is the one which exploits known facts about the data. The converse is: The worst algorithm to use is the one whose worst case behaviour happens on the sort of data you want to feed it. So if, for example, you know that your data will cause expected-case behaviour on average, more power to you. If don't know that your data will cause worst-case behaviour on average, shame on you for not being obsessed enough. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mergesort
G'day all. On Wed, Jun 26, 2002 at 04:06:50PM +0200, Koen Claessen wrote: > What implementation of mergesort are you using? (Could you > send me code?) I don't know for sure, but I'd be willing to bet it's Carsten Holst's merge sort with Andy Gill's partition function. If you have the GHC sources handy, you'll find it in ghc/compiler/utils/Util.lhs and the function is called mergeSort (note the capitalisation). There are a number of variations for various alternate orderings in there too. If you don't have the GHC source and don't want to download it for some reason, I've temporarily put a copy of the relevant file at: http://alicorna.net/Util.lhs This will be removed in a few days. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [HOpenGL] HOpenGL and --enable-threaded-rts
G'day all. On Tue, Jun 18, 2002 at 05:58:15PM +0100, Alastair Reid wrote: > A further piece of what one might call thread local state is > 'recursive locks' like those found in Java. Recursive locks arguably should be part of the lock abstraction, not "thread local state ". Since all it costs is another counter, it's almost trivial for the lock implementation (usually the OS) to implement it, of only as an option. For comparison: all Win32 built-in locks (Win32 confusingly differentiates "mutexes" and "critical sections" even though they are essentially the same thing) are recursive. Under all pthreads implementations that I'm aware of, THREAD_MUTEX_RECURSIVE is supported. I don't know enough about any other platforms to comment, but my bet is you'll find it pretty much everywhere. I think you need to look no further than the thread id itself for "thread local state". As soon as you want to do anything with the thread id other than compare equality (even Ord-type comparison is not supported under pthreads), you have thread local state. I don't mean to detract from the fine work which the HOpenGL people have achieved, but I think that binding to the C implementation of GLUT was, in retrospect, a mistake. Binding to foreign language-specific frameworks in general is a mistake, IMO. Today it's only threads which you may be able to hack around, but tomorrow, your called-back function will want to throw an exception, or something even hairier will turn up and you'll be back where you started. Sorry for the pessimism, but this is bitter experience talking. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What's the '0' for in the version number?
G'day all. > > Why is it GHC "5.02.2", "5.03" etc.? Wouldn't it be easier > > with "5.2.2", "5.3"? On Mon, May 06, 2002 at 11:44:03AM +0100, Simon Marlow wrote: > I don't know, probably historical reasons: as far as I can remember, > GHC's version numbers always had two digits after the decimal point. At least until you get into two-digit major version numbers, this way of doing things makes the filenames appear in version order when you type 'ls'. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Student Programming Projects
G'day all. On Fri, Nov 02, 2001 at 11:52:04AM -0500, Barbara Nostrand wrote: > I posted this message a while ago and got a few suggestions that > sounded like they would maintain student interest. Alas, my disk > drive crashed soon thereafter. So if you have given me suggestions > before, please do so again. I was particularly intrigued by the > suggestions put forth by someone who complained that someone > else's suggested projects were too theoretical. That may have been me. IME, there's only so much theorem proving to which you can subject an undergraduate before they switch off. My suggestion is to look to the other subjects that they've done and raid them for ideas. For example: - If they know about DFAs and regular expressions, get them to implement a cut-down version of Lex. (I have a really neat DFA construction method tucked away which is much more "algebraic data type" than the one you get taught in the Dragon Book. It's also much faster. Available on request.) - If they know about graphics, get them to implement a simple ray tracer. Limit yourself to one kind of geometry (say, spheres) but allow different kinds of light source and surface material. - If they know about game playing, alpha-beta search, heuristic search, get them to implement a program which plays some one- or two-player game and let them compete against each other (in one-player games, lowest average and/or worst-case number of moves wins some small prize, use runtime to break ties). Some suggestions for games of about the right complexity: "Mastermind", 15-puzzle. - If they know about Unix, get them to implement a program from the standard environment, like diff(1). (Provide or point them to an algorithm for longest common substring first, of course.) - If they know something about numerical analysis (or even if they don't), how about a program to perform numeric integration of a function? Gauss-Konrod quadrature with binary subdivision tends to be quite easy to understand. - If they've been introduced to the class NP, get them to try to solve an NP-hard optimisation problem. Impose a time/resource limit. Whatever happens, give them a project that they can see the practical use of, or if not, that they can play with. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strict functions
G'day all. On Fri, Oct 19, 2001 at 02:30:59PM +0100, Ian Lynagh wrote: > Also, the prelude definition of zipWith has LVL whereas the following > definition has LVV. Why is something like the following not used? > > > zipWith :: (a->b->c) -> [a] -> [b] -> [c] > > zipWith f (a:as) (b:bs) = f a b : zipWith f as bs > > zipWith _ _ [] = [] > > zipWith _ _ _ = [] Generally speaking, Haskell programmers don't like inserting more code with the only effect being to make the function less lazy. This goes double for standard library code. I say "generally" because occasionally there's a good reason (e.g. forcing evaluation can make a program more space-efficient). Is there a good reason behind your version of zipWith other than the strictness signature being more symmetrical? :-) If you really need a reason which doesn't involve bottom, consider a (fairly common) call such as: zipWith f xs [1..] If xs is finite, your version of zipWith would evaluate the infinite list [1..] one place beyond that which was really needed. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UniCode
G'day all. On Fri, Oct 05, 2001 at 06:17:26PM +, Marcin 'Qrczak' Kowalczyk wrote: > This information is out of date. AFAIR about 4 of them is assigned. > Most for Chinese (current, not historic). I wasn't aware of this. Last time I looked was Unicode 3.0. Thanks for the update. > In Haskell String = [Char]. I'll concede that String and [Char] are identical as far as the programmer is concerned. :-) There was some research 10+ years ago about alternative representations for lists which were semantically identical but a little more efficient in memory use. Even if you don't go that far (it is fiddly), constant strings, for example, could be representable as UTF-16/UTF-8/whatever along with some machinery to generate the list on demand. Char objects could be implemented as flyweights. Lots of possibilities. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UniCode
G'day all. On Fri, Oct 05, 2001 at 02:29:51AM -0700, Krasimir Angelov wrote: > Why Char is 32 bit. UniCode characters is 16 bit. It's not quite as simple as that. There is a set of one million (more correctly, 1M) Unicode characters which are only accessible using surrogate pairs (i.e. two UTF-16 codes). There are currently none of these codes assigned, and when they are, they'll be extremely rare. So rare, in fact, that the cost of strings taking up twice the space that the currently do simply isn't worth the cost. However, you still need to be able to handle them. I don't know what the "official" Haskell reasoning is (it may have more to do with word size than Unicode semantics), but it makes sense to me to store single characters in UTF-32 but strings in a more compressed format (UTF-8 or UTF-16). See also: http://www.unicode.org/unicode/faq/utf_bom.html It just goes to show that strings are not merely arrays of characters like some languages would have you believe. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Student Programming Projects
G'day all. On Thu, Sep 20, 2001 at 09:01:42AM -0400, Barbara Nostrand wrote: > Next Semester, I am supposed to teach a short course in Haskell. > Can anyone recommend interesting programming projects which can > be completed in about a month? Thank you very much. How much programming experience will the students have? Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: linking with c++ libraries
G'day all. On Mon, Jul 30, 2001 at 06:06:07AM -0700, Julian Seward (Intl Vendor) wrote: > After some discussion in the GHC office, we're unsure about why > you need to compile Main.c with a C++ compiler for this to work. Under g++ you may not strictly need it. I'm not sure about that. However, some C++ systems do. Such systems handle static constructors and destructors by rewriting the main() function to perform the initialisation and destruction. See also Eric Myers, "More Effective C++" item 34. It's also touched on briefly in the C++ FAQ: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: linking with c++ libraries
G'day all. On Sat, Jul 21, 2001 at 01:32:43AM +0800, Corneliu Popeea wrote: > I'm trying to use from Haskell a C++ library (Omega Calculator). > I'm using the following command: > > ghc -c -fglasgow-exts -package lang main.hs > ghc main.o mylib.o -lomega -lstdc++ -fglasgow-exts -package lang > > Do I need to add more options? To reliably link with C++, you need to compile both the code which invokes C++ (i.e. whatever uses the C++ library) and "main" (that is, ghc/rts/Main.c, not main.hs) with a C++ compiler. So, in summary: - Compile any code which may call the C++ library (and keep inter-module inlining in mind; probably safest to compile all of your code this way) via C, and compile the C with g++. - Re-compile the run-time system (at least Main.c) with g++, too. That may not fix your specific core dump, but you'll need to do this anyway. Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonadError and fundeps
G'day all. On Thu, May 10, 2001 at 09:24:36PM +, Marcin 'Qrczak' Kowalczyk wrote: > BTW, another question: should MonadPlus instead of just Monad be > a superclass of MonadError? It has a natural definition in terms > of catchError. I can see how mplus has a "natural" definition (I can think of one or two circumstances where it's not semantically "natural", even if it is operationally "natural", but that's beside the point). What about mzero, though? What "natural definition" did you have in mind? Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to convert the type signature of a variable to a String?
G'day all. Mon, 9 Apr 2001 11:52:47 +0200, Pasch, Thomas (ACTGRO) <[EMAIL PROTECTED]> pisze: > > For example: > > > > 'function f' gives the String "a->a" On Sat, Apr 14, 2001 at 08:28:16PM +, Marcin 'Qrczak' Kowalczyk wrote: [...] > In this form it's not even theoretically consistent: any function > can be treated as a function of a more specific type, so the result > would be ambiguous (for example f has type Int->Int too, so asking > for a type should give "Int->Int" too). I think I understand what you're saying, but I'd just like to understand this practically. We know that the most general type of `id' is "a->a". We assume there's a theoretical function: get_the_function_type_of :: a -> String where a can be a function type. Now consider: f :: (String -> String) -> String f g = g (get_the_function_type_of g) The question is: Should `f id' return "a->a" or "String->String"? Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
