Re: [Haskell-cafe] How did iteratees get their names?
Hi, Ertugrul wrote: Just like chatter and chattee, employer and employee, there is an iterator (usually as part of an enumerator/ee) and an iteratee. Thanks for the attempt to explain. But I, at least, remain mystified, and I agree with Douglas that the terminology is confusing. Usually, the relationship between word-pairs such as the ones above is pretty obvious, typically implying some kind of subordinate relationship. For example: * employer: the one employing employee: the one employed * tutor: the one teaching, instructing, providing care tutee: the one receiving instruction, care * caller: that which is calling callee: that which is being called And so on. The above would suggest that iterator would be something that iterates over something, and that iteratee would be (an element of) that being iterated over. However, no such simple relationship seems to emerge from the provided explanation. I also had a look at John Millikin's page on Understanding Iteratees, which is very good: https://john-millikin.com/articles/understanding-iteratees/ But, the intuition that comes across there is: * iteratee: a stream (of sorts) consumer * enumerator: a stream (of sorts) producer * enumeratee: a stream (of sorts) transformer And iterator isn't mentioned at all. I might be missing something, but the terminology is hardly crystal clear. Which is a pity! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did iteratees get their names?
Hi Ertugrul, Coroutines actually capture this kind of composition (where some code interrupts itself to hand control over to some other code) very well. Perhaps it would be better to use terms from that abstraction instead. In fact, iteratees are a special case of coroutines. That would seem to make sense, if there is appropriate terminology. And if we are indeed talking about co-routines, i.e. cooperation between peers, routines of equal status, that would in itself suggest that the X-or and X-ee names that imply an asymmetric relationship are somewhat unfortunate choices conveying the wrong intuition. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD Studentships in Functional Programming
Apologies for multiple copies. -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk +--+ PhD Studentships in Functional Programming School of Computer Science University of Nottingham, UK The Functional Programming Lab (FP Lab) in the School of Computer Science at the University of Nottingham is seeking to appoint up to two new PhD students, starting on 1st October 2011. The topics for the studentships are open, but will be within the general area of functional programming. The studentships are for 3.5 years, include a maintenance grant of 13,590 UK pounds per year and UK/EU tuition fees, and are open to UK and EU applicants. Particularly strong candidates from outside the EU may also be considered, subject to additional funds being available. Applicants will require a first-class Honours degree (or equivalent) in Computer Science, Mathematics, and/or Physics, experience in functional programming, and an aptitude for mathematical subjects. A higher degree (e.g. Masters) would be desirable. Additionally, experience in one or more of the following will be particularly welcome: formal semantics, type theory, program verification, theorem provers, domain-specific languages, languages for physical modelling, programming language implementation and tools. Successful applicants will work under the supervision of Dr Graham Hutton or Dr Henrik Nilsson in the FP Lab in Nottingham, a leading centre for research on functional programming. The group currently comprises 5 academic staff, 1 research fellow, and 10 PhD students. In order to apply, please submit the following to Dr Graham Hutton (g...@cs.nott.ac.uk) or Dr Henrik Nilsson (n...@cs.nott.ac.uk) by 1st March 2011: an up-to-date copy of your CV (including the results of all your University examinations to date) along with a brief covering letter that describes your experience in functional programming, your reasons for wishing to pursue a PhD in this area, and any ideas you have regarding possible research directions. Note: applicants to the FP Lab should follow the procedure above, rather than applying directly to the School or University, e.g. in response to a general advert for PhD studentships. Closing date for applications: 1st March 2011. +--+ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD Studentships in Functional Programming, Nottingham
Apologies for multiple copies. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk +--+ PhD Studentships in Functional Programming School of Computer Science University of Nottingham, UK The Functional Programming Lab (FP Lab) in the School of Computer Science at the University of Nottingham is seeking to appoint up to two new PhD students, starting on 1st October 2011. The topics for the studentships are open, but will be within the general area of functional programming. The studentships are for 3.5 years, include a maintenance grant of 13,590 UK pounds per year and UK/EU tuition fees, and are open to UK and EU applicants. Particularly strong candidates from outside the EU may also be considered, subject to additional funds being available. Applicants will require a first-class Honours degree (or equivalent) in Computer Science, Mathematics, and/or Physics, experience in functional programming, and an aptitude for mathematical subjects. A higher degree (e.g. Masters) would be desirable. Additionally, experience in one or more of the following will be particularly welcome: formal semantics, type theory, program verification, theorem provers, domain-specific languages, languages for physical modelling, programming language implementation and tools. Successful applicants will work under the supervision of Dr Graham Hutton or Dr Henrik Nilsson in the FP Lab in Nottingham, a leading centre for research on functional programming. The group currently comprises 5 academic staff, 1 research fellow, and 10 PhD students. In order to apply, please submit the following to Dr Graham Hutton (g...@cs.nott.ac.uk) or Dr Henrik Nilsson (n...@cs.nott.ac.uk) by 1st March 2011: an up-to-date copy of your CV (including the results of all your University examinations to date) along with a brief covering letter that describes your experience in functional programming, your reasons for wishing to pursue a PhD in this area, and any ideas you have regarding possible research directions. Note: applicants to the FP Lab should follow the procedure above, rather than applying directly to the School or University, e.g. in response to a general advert for PhD studentships. Closing date for applications: 1st March 2011. +--+ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
Hi Tom, In reactive, one doesn't. All behaviors and events have the same absolute 0 value for time. Right. I believe the possibility of starting behaviors later is quite important. And from what Conal wrote in a related mail, I take it that this is recognized, and that this capability is something that is being considered for reactive? Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
continuous time. On the other hand, ANY implementation will have to do sampling at some point. But I suppose what you're saying is that Reactive allows different part of a system to be sampled at different rates in a transparent manner? Which is nice. But the tradeoffs are not clear to me. * Reactive is push based. The result of this is that we will not waste CPU cycles for example refreshing the screen when nothing has changed on the output. The optimizations of Yampa also achieves a fair amount of pushing. But granted, Yampa is fundamentally pull-based. That said, for truly hybrid systems, that do a lot of continuous computation, it is not at all clear that push is a clear winner. Only extensive benchmarking can really provide genuine insight into the actual pros and cons here of different FRP implementations for various applications, I'd say. Also, when there is a need to combine output from different parts of a system, and this is done by combining the various outputs into a tuple or record, then one have to push combined output whenever any one of the constituent parts changes, which means one lose track of the changes down the line, possibly resulting in redundant computations anyway. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
Hi Tom, I don't think this is really true. Behaviors and Events do not reveal in their type definitions any relation to any system that they may or may not exist in. OK. So how does e.g. mousePoint :: Behavior Point get at the mouse input? unsafePerformIO? I.e. it is conceptually a global signal? I'm not sure I understand you clearly. If I wish to apply a constant function to a signal, can I not just use fmap? The question is why I would want to (conceptually). I'm just saying I find it good and useful to be able to easily mix static values and computations and signals and computations on signals. You would certainly need to ask Conal on this point, but I have no reason to suspect that b' = [1,2,3,4,5] `stepper` listE [(1,[])] would not deallocate the first list once it had taken its step. It's not the lists that concern me, nor getting rid of a collection of behaviors all at once. The problem is if we ant to run a collection of behaviors in parallel, all potentially accumulating internal state, how do we add/delete individual behaviors to/from that collection, without disturbing the others? For the sake of argument, say we have the following list of behaviours: [integral time, integral (2 * time), integral (3 * time)] We turn them into a single behavior with a list output in order to run them. After one second the output is thus [1,2,3] Now, we want to delete the second behavior, but continue to run the other two, so that the output at time 2 is [2,6] Simply mapping postprocessing that just drops the second element from the output isn't a satisfactory solution. let n :: Behavior Int n = behaviour that counts left mouse button clicks in n `until` some event -= n I'm not sure I got the syntax right. But the idea is that we output the number of left mouse button clicks, and then at some point, we switch to a behavior that again output the number of left mouse button clicks, notionally the same one n. The question is, after the switch, do we observe a count that continues from where the old one left off, i.e. is there a single *shared* instance of n that is merely being *observed* from within the two branches of the switch, or is the counting behavior n restarted (from 0) after the switch? Yes, we really do get a shared n -- without doing that we certainly would see a large space/time leak. Interesting, although I don't see why not sharing would imply a space/time leak: if the behavior is simply restarted, there is no catchup computation to do, nor any old input to hang onto, so there is neither a time nor a space-leak? Anyway, let's explore this example a bit further. Suppose lbp is the signal of left button presses, and that we can count them by count lbp Then the question is if let n :: Behavior Int n = count lbp in n `until` some event -= n means the same as (count lbp) `until` some event -= (count lbp) If no, then Reactive is not referentially transparent, as we manifestly cannot reason equationally. If yes, the question is how to express a counting that starts over after the switch (which sometimes is what is needed). Yep, such Behaviors are seperated in Reactive only by the method you create them with. I may use the `stepper` function to create a behavior that increases in steps based on an event occurring, or I may use fmap over time to create a continuously varying Behavior. But the question was not about events vs continuous signals. The question is, what is a behavior conceptually, and when is it started? E.g. in the example above, at what point do the various instances of count lbp start counting? Or are the various instances of count lbp actually only one? Or if you prefer, are beahviours really signals, that conceptually start running all at once at a common time 0 when the system starts? The answers regarding input behaviors like mousePosition, that n is shared, and the need to do catchup computations all seem to indicate this. But if so, that leaves open an important question on expressivity, examplified by how to start counting from the time of a switch above, and makes if virtually impossible to avoid time and space leaks in general, at least in an embedded setting. After all, something like count lbp can be compiled into a function that potentially may be invoked at some point. And as long as this possibility exists, the system needs to hang on to the entire history of mouse clicks so that they can be coounted at some future point if necessary. These are all questions that go back to classical FRP, which we didn't find any good answers to back then, and which also were part of the motivation for moving to AFRP/Yampa. If Reactive has come up with better answers, that would be very exciting indeed! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked
Re: [Haskell-cafe] Yampa vs. Reactive
Hi Tom, I'm not sure why mapping the function is not satisfactory -- It would create a new Behavior, who's internals contain only the two elements from the list -- that would expose to the garbage collector that the second element has no reference from this behavior any more, and thus the whole behavior could be collected. We must be talking at cross purposes here: there is no way that deleting the *output* from one of the behaviours from a list of outputs would cause the underlying behavior whose output no longer is observed to be garbage collected. After all, that list of three numbers is just a normal value: why should removing one of its elements, so to speak, affect the producer of the list? But if we have a list of running behaviors or signals, and that list is changed, then yes, of course we get the desired behavior (this is what Yampa does). So maybe that's what you mean? That's a yes. My first answer to how to implement the resetting counter would be someting along the lines of this, but I'm not certain it's dead right: e = (1+) $ mouseClick e' = (const 0) $ some event b = accumB 0 (e `mappend` e') i.e. b is the behavior got by adding 1 every time the mouse click event occurs, but resetting to 0 whenever some event occurs. Hmm. Looks somewhat complicated to me. Anyway, it doesn't really answer the fundamental question: how does one start a behavior/signal function at a particular point in time? I consider the fact that Yampa, through supporting both signals and signal functions, provides simple yet flexible answers to the question when a signal function starts to be one of its key strengths over Classical FRP and maybe then also over Reactive. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa vs. Reactive
is similar in style to Classical FRP, I think Reactive also needs to address those questions. All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implementing PacMan
Hi, What do we think of this, folks? http://prog21.dadgum.com/23.html (And the rest in the series, obviously.) To me, it seems that this plan would *work*... but it wouldn't be very eligant. You'd have the code to respond to user input and move PacMan in one place, the code for collision detection in other place, the code that decides what to *do* about a collision somewhere else, the code for drawing the animations in yet another place... If you wanted to change one game element, you'd have to make changes scattered all over the place. The whole thing seems messy, non-modular and non-composible to my ears. Thoughts, people? Functional Reactive Programming (FRP) tends to, in principle, work pretty well for this kind of application. At least it allows for code that is very modular in many ways, includig when it comes to the game state. See e.g. the paper The Yampa Arcade or the Haskell game Frag which uses FRP for the game logic: http://www.haskell.org/haskellwiki/Frag The page you referred to didn't seem to consider FRP? Don't know if FRP would address all of your concerns. But as to collisions, we can observe that this involves two or more entities and is, from the perspective of each entity, something external. Thus I don't think it's unreasonable that code handling collision detection is done somewhere else, meaning outside the code describing the game entities themselves. As to how to respond to collisions, that can be a great deal trickier, and may involve devising suitable interfaces to allow the proper interaction of a set of object to be computed, e.g. in a physical simulation, the masses and velocities of the involved objects must be known. There was an interesting article about building a Physics Engine in Haskell in issue 12 of the monad reader that touched on physical collision detection and response: http://www.haskell.org/sitewiki/images/f/f0/TMR-Issue12.pdf For a game like PacMan, I should think collision response is fairly straightforward, though! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 2 modules in one file
Hi, Yitzchak Gale wrote: But for large and complex projects, this policy really complicates the task of the project manager who wants to be able to present various views of the source to teams working on different subprojects, while juggling the version control in an intelligent way. Directory tree structure is sometimes the perfect tool for that, but Haskell has stolen it away. It would be nice if compilers would offer, as an optional alternative, a system of locating modules based on manifest files. That would then allow multiple modules per source file. Not that it is of any practical relevance now, but this was exactly the thinking behind the design (some 10 - 15 years ago, time flies!) of how Freja manages files and modules, as Malcolm mentioned. I believe a clear separation between a language and aspects of the environment in which programs are developed, such as file systems, is a good thing. And while the Haskell standard as such respects this, I've always found the fact that most tools rely on naming conventions for mapping names of modules to names of files very unfortunate. Hierarchical modules makes this even worse: what says that I necessarily want the module hierarchy reflected in the directory hierarchy? And indeed, as Yitzchak said, what about non-hierarchical file systems, or maybe storing source code by completely different means? And there are also potential issues with not every legal module name being a legal file name across all possible file systems. So, yes, a system of locating modules based on manifest files would be great. I'd use it all the time whenever possible, and never look back! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa / AFRPVectorSpace.hs
Hi Peter, Oops! Yes, as Paul says, clearly an error. My best guess is that it was commented out at some point for testing something, and then forgotten! The error does not occur in my local copy of the code, so a version skew problem to boot, I'm afraid. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
Hi Peter, About continuous time; it is in fact, not really continuous is it, since floats are used to approximate time. So the longer your program runs, the less accurate an absolute time value will become no? Well, yes and no. Yampa, at least, does not use absolute time internally, only time deltas, so the problem you describe only occurs if the programmer *explicitly* choose to accumulate absolute time, or *explicitly* make use of very large relative time intervals (e.g. combinators like after that emits an event after a given, relative, time interval). So, as always with floating point, or with any finite representation of numbers, the programmer has to understand the limitations and implications of the chosen representation. But this is not any inherent flaw of FRP or its Yampa incarnation as such. One could also imagine using some infinite-precision number representation with FRP instead of floating point. The fact that Yampa uses floating point is merely a pragmatic implementation choice. I believe I also saw someone asking about Modelica in this context. Modelica is a hybrid modelling and simulation language. Efficient simulation and accurate results are of key importance, and for that reason Modelica implementations use sophisticated numerical and symbolic methods. Unfortunately, this also limits the expressiveness of the language. In particular, Modelica cannot handle systems with highly dynamic structure like video games. Thus I don't think we'll see video games written purely in languages like Modelica any time soon, even if there is active research on making such languages cope better with structurally dynamic systems. (One could probably imagine using Modelica for handling game physics, though, i.e. as a component of a games programming suite.) Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] modelling problem
Dear Kurt, I'm trying, more as a first excercise in Haskell than anything else, to code a simulation framework in Haskell. I don't have the time to respond to your mail in detail right now, but you might want to have a look at the work on Fran (functional reactive animation), FRP (Functional Reactive Programming), and Yampa, all very much related to the application area you're interested in. E.g. see http://www.haskell.org/frp/ All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GADTs vs arrows/typeclasses
Dear all, S. Alexander Jacobson wrote: I don't think I'm the only one confused here. Henrik Nilson in his paper on adding GADTs to Yampa comments that: ... In particular, GADTs are just what is needed to address the problem discussed above since the key idea is to allow constructors that have more specific types than usual, and to take that extra type information into account in individual case branches. GADTs would no doubt also offer an interesting alternative to the methods described by Baars and Swierstra [1] and Hughes [19]. [1] and [19] are papers about Arrows. I categorically deny being confused! :-) The comment refers to the methods Baars, Swierstra, and Hughes employ to encode type equality in order to be able to perform optimizations along similar lines as outlined in my paper. I was not at all proposing to use GADTs in place of arrows, and I cannot really see how the quote can be read as suggesting that. As Neil has already said: GADTs and arrows are just different kinds of entities. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arr f
Hi Sven, since this is my first post, Hello all Welcome! I have a problem with a function taken from class Arrow. arr :: (b - c) - a b c To build my own arrow, i need to distinguish between different kinds of b or c. For instance, if b has the form (d,e), i want to construct something different as when having form (d,e,f). I'm not quite sure I understand what you mean. Are you saying that you you want the input to be either a pair or a triple? Then one possibility would be to wrap up the input in the standard Haskell type Either. For reference, Either is defined like this: data Either a b = Left a | Right b Assume g :: T1 - T2 - T h :: T1 - T2 - T3 - T for some specific types T1, T2, T3 and T. Now you can define a function f: f :: Either (T1,t2) (T1,T2,T3) - T f (Left (x,y)) = g x y f (Right (x,y,z)) = h x y z Thus f distinguish[es] between different kinds of input. If it is applied to what essentially is a pair, it will compute a result of type T using the function g, whereas if it is applied to what essentially is a triple it will compute a result using the function h, again of type T. Lifting f into an arrow yields: arr f :: Arrow a = a (Either (T1,T2) (T1,T2,T3)) T I don't know if that was what you really ment by construct[ing] something different depending on the input type? Hope that helps, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
