- Haskell-Cafe - Haskell.org

RE: Exception handling in GHC - ThrowCatch.hs (1/1)
by Simon Marlow 27 Jan '03

27 Jan '03

> You might be interested in this program to investigate what catches > what. Pinched for GHC's testsuite - thanks very much :) Cheers, Simon

1 0

Creating COM objects and passing out pointers to them via a COM interface
by Sarah Thompson 25 Jan '03

25 Jan '03

Hi again, A slightly harder problem this time. I want to implement something that looks something like the Microsoft XML parser. This is a very COM heavy contraption that provides an interface that looks to client applications like a tree of COM objects that reflects the internal structure of an XML document. The idea is, you start with the document object, make a method call requesting the root node, and have a COM object that wraps that node returned to you. You can then request the children of that node, and their children and siblings, all which involves being passed back interface pointers to COM objects. Effectively, there is one COM object per syntactic item in the XML document. I already have my document object working nicely. This is where the actual database resides. I want to be able to spawn views of this database as COM objects. When I've done this in the past (using ATL mostly, euuuugh), I've used an IDL definition something like HRESULT CreateView([in,string] BSTR query, [out,retval] IDbView **); What's the correct way to implement the necessary Haskell code to create the coclass and return a pointer to it? I fiddled around for ages, but either couldn't get GHC to like the types I was using, or when I finally got it to compile, I found that my test harness was being passed an invalid COM object. This should be simple stuff, so I'm sure someone will have done it! Secondly, it is a nasty, though fairly common trick, if you know your objects are going to be created in the same process space, to allow them some 'behind the scenes' communication. In my case, I'd like to avoid needing to serialise and deserialse the data in a view during creation of these child objects (of which there may be a great many, and which may be created on the fy rather often). Ideally, I'd like to be able to do something like: newView :: String -> State -> IO State newView db (State st) = do db <- readIORef st r <- newIORef db -- Insert some kind of COM magic here return (State r) so the database content gets copied within the Haskell environment (lazily, I'd hope), without needing to be serialised and deserialised. Is this feasible? One (messy) approach might be to create a bunch of extra interfaces on the main database object, then create 'thin wrapper' child objects that simply make calls back into the parent object. I'm not so keen on that for various reasons, however. Sarah

1 0

Exeption handling in GHC
by Sarah Thompson 25 Jan '03

25 Jan '03

Hi all, I'm trying to get exception handling working in GHC, but don't seem to be able to make it work. Am I likely to be missing a compiler switch, or something? Cutting things down to basics, I'd have thought that the following expression (typed at the ghci command prompt) should work: try (error "x") but the result is *** Exception: x I seem to get the same problem with compiled code. Any ideas anyone? TIA, Sarah

4 6

Re: Lazy evaluation alternative
by Kevin S. Millikin 24 Jan '03

24 Jan '03

>>>>> "Chris" == Chris Clearwater <chris(a)sharkzone.com> writes: Chris> Sarcasm, Kevin, sarcasm. :) Why is it that those who most need to point out that they were joking are least able to see it in others? Chris> The difference is with the CPS way it is implicit. For Chris> example take the Y combinator written using both methods Chris> (again this is pseduo code, not intended to be real haskell Chris> code or run in hugs) That's a funny definition of "implicit". All you need to delay evaluation is lambda. You're performing a CPS transformation as a way to insert a lambda in the proper place. BUT THAT'S NOT NECESSARY. Just write the lambda where you want it. You don't need to abstract over a continuation to delay evaluation, you can abstract over anything at all (it doesn't matter what). And you only ever apply the most recent continuation (notice how you could use the identifier "c" for every one of your continuations?). You don't have to apply c to pass a value to the current continuation, there's alread a way to do that: just return the value. Chris> Using the lambda way: Y f = f (lazy Y f) Then writing ones Chris> would be something like: ones_fix f = 1:(force f) Chris> Now the CPS way: Y f c = c (f (Y f)) Now writing ones: Chris> ones_fix f c = c 1:f Your translation is wrong. Here's the correct "lambda way" (in the same pseudo functional language): Y f = \ () -> f (Y f) where I didn't presume any "delay" or "lazy" macro. Here's ones_fix: ones_fix f = \ () -> 1 : f Compare to: Y f = \ c -> c (f (Y f)) ones_fix f = \ c -> c (1 : f) Which one seems to be more "implicit"? Where you abstract over a continuation to delay evaluation, I abstract over anything I feel like. Where you apply a continuation to a value, I just return a value. Where you would pass in a continuation to a CPSed function, I would just apply the result to some suitable token (unless I had zero argument functions) (that is, I would "force" an expression wherever you would pass a continuation to a CPSed function). You've performed a CPS transformation, but you never do anything *interesting* with the continuation. That might suggest that, whatever you seem to have achieved, it didn't come from the CPS transformation. Chris> Notice how the CPS way behaves as if it were actually Chris> passed itself, while the lambda way behaves as if it were Chris> passed itself quoted with lambda. The lambda way seems Chris> like a hack while the CPS way feels consistant. I guess I don't understand. Change "\ c ->" to "\ () ->". Remove the application of every "c". Change occurrences of "c" in argument position to "()". -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com

1 0

Handling error in production code
by Sarah Thompson 24 Jan '03

24 Jan '03

What is the best way to handle error in production code? I have successfully built a COM object (many thanks Sigbjorn!!!), which works fine. The only hassle is that an error being thrown causes the program using the COM object to hard terminate. This is clearly not desirable, especially since parse errors can cause this. What I'd *ideally* like would be for a call to return an error code as an HRESULT, but leave the internal state of the object unchanged. Is this feasible? Do I need to think carefully about using something other than 'error'? If so, how do I handle library code's use of error here and there? TIA, Sarah

1 0

Re: A question about dynamic typing
by Jon Cast 23 Jan '03

23 Jan '03

Nick Name <nick.name(a)inwind.it> wrote: > On Thu, 23 Jan 2003 15:38:31 -0600 > Jon Cast <jcast(a)ou.edu> wrote: > > > Another idea: if I allow the list of objects in the panel to be > > > infinite, > > Sorry, but I'm having difficulty figuring out where you'd get an > > infinite list of objects to put in the panel. I suspect any > > solution is going to depend on how the list of objects is put > > together. > It could be any lazy list, potentially infinite (and I would not like > to evaluate it). So we're not talking about an actually infinite list, just an I'd-rather-not-evaluate-it list. That makes things clearer (in particular, it is /possible/ to evaluate the whole thing, if necessary). The reason I think this a good thing is it occurs to me that if you want to map an IO action run for its side-effects (e.g. ``play every file'') to every element in the list, you're going to have to compute out the whole thing anyway, so there's no great harm done in pre-computing every element so you can get the list of elements. OTOH, if you want to say ``give me a new panel with every element derived from the elements in this panel by this transformation'' (either pure or IO), you want the result to still be lazy. So, you have to compute the list of allowed transformations /without/ touching every element. As you've predicted, this requires that you be conservative about what operations are offered. I would store a list of types, or a filter for such a list, with every panel. Panels generated lazily would have to be conservative (see below), but perhaps once the last panel element was computed you could re-create the type list from the actual values. Of course, this leads to the FAQ entry: Q. Why does the list of operations on a panel sometimes grow 3 times as long once I've looked at the last item? But that may be an acceptable price to pay (assuming somebody figures out an answer that'll be understandable by the average user). In any case, once you've got the list of possible types, you can take the transformers/actions for each type and compute the intersection. > An example is a "find" function, wich returns a lazy list with the use > of unsafeInterleaveIO. > It would be useful to see the actual first N files as objects into the > "panel" or desktop area, or list, anything visual, and then be able to > obtain, for example, the filtered list of all the "sound files", which > would still be a lazy list. In this case, I would attach a (possibly empty) list of new constraints to each filter. For example, if you had a class SoundObject, and a function isSoundObject, I would represent the filter as (isSoundObject, [HasClass "SoundObject"]. Then, when the filter was run, I would add the filter's constraints to the argument's constraints. That way, the system would know that any action available across all sound objects was now available. Maps seem harder, but I'm sure the transformations on constraints could be encoded and used to find the new constraints. > Should the user scroll the panel down with some arrow-like control, > the list would get evaluated and the find function would run under > control of the user interface. > I am just thinking about what a "lazy functional desktop environment" > could mean, trying to figure out some use case. That sounds like an excellent idea; please don't take anything I say as a discouragement to that project. > Vincenzo Jon Cast

1 0

Re: A question about dynamic typing
by Jon Cast 23 Jan '03

23 Jan '03

Nick Name <nick.name(a)inwind.it> wrote: > On Sun, 19 Jan 2003 16:02:41 -0600 > Jon Cast <jcast(a)ou.edu> wrote: > > > But, to fully exploit the power of a "functionally-programmed" > > > desktop, the interface should allow the user to map an operation > > > onto all the objects of the panel; in this case the allowed > > > operations should be those that all the object share. > > This is fairly easy if you name the operations; then you can use > > that to compute the intersection of the operations for all the > > types. If you don't name the operations, then of course the > > problem becomes undecidable. > Another idea: if I allow the list of objects in the panel to be > infinite, Sorry, but I'm having difficulty figuring out where you'd get an infinite list of objects to put in the panel. I suspect any solution is going to depend on how the list of objects is put together. > obviously the set of allowed operations in a map is the set of > operations on "objects". But if I filter an infinite list of objects > to all the objects of a certain type, I wish to see all the operations > on that type in the possibilities for a map. If you have a finite list of the types of your objects, then you can list the operations available at each type and use that to get the intersection, I suppose. > How would you deal with such a case? > Vincenzo

2 1

Re: A question about dynamic typing
by Jon Cast 23 Jan '03

23 Jan '03

Nick Name <nick.name(a)inwind.it> wrote: <snip> > Ok, this is clear. I am still not sure of how to decide the type to > give to the "extracted" object. This is fairly easy if you have a finite number of possible types; you can use typeOf to determine which type you have, and then do a case analysis to use the particular type typeOf says you have. Another alternative is to write your operations to take Dynamic. If all of the functions you want to apply have some ``no action'' return value nop (say, they all return IO () with nop = return ()), and they all take monomorphic arguments, (maybe nop f . fromDynamic) will perform f on Dynamics of appropriate type. > In the graphical interface, any object should have a menu saying on > its top row: "Text file" or "Applet" (depending from the type of the > object) and then a list of operations. > This should happen even when the object is inside the panel-list, (so > maybe a panel would be a list of untyped "objects" with an attribute > of type [Operation]). I wouldn't attach a list of operations to each /object/; I should think the list of operations wouldn't change across the type, and in any case you would want to allow the user to dynamically load new operations. So, I would attach a list of named operations of type (Dynamic -> Result) to each type, and offer the operations for a given type to the user. > But, to fully exploit the power of a "functionally-programmed" > desktop, the interface should allow the user to map an operation onto > all the objects of the panel; in this case the allowed operations > should be those that all the object share. This is fairly easy if you name the operations; then you can use that to compute the intersection of the operations for all the types. If you don't name the operations, then of course the problem becomes undecidable. > This is what I think, however I can't realize the connection between > the haskell type system and what I wish to have. Can someone lead me > to a clearer vision of the topic? > Vincenzo Jon Cast

2 2

Stupid questions...
by Sarah Thompson 23 Jan '03

23 Jan '03

Sorry about such lame questions. I'm currently using Haskell 'in anger' for the first time, so differences with other functional languages are biting me occasionally. I need to convert Ints to Strings and vice-versa. What's the best way to do this? I've not found library functions for this. Second question: Using division over integers. I appreciate that a division operator with integers as arguments can not be guaranteed to return an exact integer result. However, if I *do* want to do integer division, how should I do it? Is floor(a/b) appropriate? TIA Sarah Thompson

2 2

RE: Arrays and arrays
by Simon Marlow 23 Jan '03

23 Jan '03

> Since you're on the line, could you confirm or deny that the (//) > operator is something equivalent to (roughly): > > a // ps = runST (thaw a >>= \u -> update ps >> unsafeFreeze u) > > I.e. that the list of updates are treated as an atomic operation? > Because doing it that way explicitly sure didn't seem to help. Yes, it is. > OTOH, doing lots of small (//) seems to be faster than doing a few > large ones (containing the same updates). Go figure. That's bizarre. Perhaps the results are obscured by some other optimisations which are happening. Cheers, Simon

2 1