- Haskell-Cafe - Haskell.org

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

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

22 Jan '03

> Hal Daume III <hdaume(a)ISI.EDU> writes: > > [snip my functions that use the ST monad to do (//)] > > > You shouldn't try to write these functions. You should do all array > > modifications within the ST monad, rather than looking for a pure > > solution. > > All right, but why? It seems an obvious trick, take some pieces that > benefit from imperative processing, and wrap them in ST, leaving the > rest of the program as it were. > > Can you (or anybody else) explain the memory behaviour I see (using > hundreds of megabytes, but only tens of K visible in the profiling > output)? That's because currently large objects aren't included in the profile. There's no really good reason for this, except that threads (including their stacks) count as large objects, and seeing them in the profile might be confusing. On the other hand, it might also be enlightening if you have a program that uses a lot of stack space. I'll look into fixing this. Cheers, Simon

2 1

Arrays and arrays
by ketil＠ii.uib.no 22 Jan '03

22 Jan '03

Hi Having written a suffix-array based program using lists, I thought I'd speed it up a bit, and perhaps more importantly, save space, using arrays. Basically, the problem is to sort all suffixes of a string, represented as an array of offsets, alphabetically. (Does anybody have such code? Efficient?) The good news is that space consumption is reduced -- except for a few weird spikes (which makes me suspect there are many of them, living for very short durations), memory use is low. But speed is another issue -- the list based version is a lot faster. Okay, I use UArrays and permute them by (//), and this operation is totally dominant in the profile. Is it correct that GHC is very naive about updating them, and even small updates cost O(n)? Is it better to (//) over few large lists than over many small ones? I'll try a IOUArray next; however, is there anything else I could/should try? I know there has been array sorts implemented previously, are anybody aware of recent results? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 10

RE: Trying to get a copy of HaskellDirect urgently...
by Simon Peyton-Jones 21 Jan '03

21 Jan '03

I've just grabbed it ok, so I'll send it to you in a separate message. It says that it's built for GHC 4.08.1 which is pretty old. I wonder if you've made a more recent release somewhere, Sigbjorn? Sarah: you can always get the sources from the CVS tree Simon | -----Original Message----- | From: sarah(a)telergy.com [mailto:sarah@telergy.com] | Sent: 21 January 2003 13:26 | To: haskell-cafe(a)haskell.org | Subject: Trying to get a copy of HaskellDirect urgently... | | Hi Folks, | | I'm currently trying to urgently get a copy of the HaskellDirect release, but I'm | finding it impossible to get to the ftp server at Glasgow (it seems to be | refusing connections - it's not a firewall problem). | | If anyone has a copy they could email me, or knows of somewhere else I can get | the release, I would be extremely grateful. | | TIA, | Sarah Thompson | | PS: Are there any known issues using HaskellDirect with the latest GHC release | (GHC 5.04.2)? | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1