Announcing Pan# 1.0 Pan# is a new front end for Conal Elliott's Pan system. Pan# is a stand-alone system that displays interactive functional images expressed in a slightly augmented Haskell subset. Pan# is ideal for demonstrating the core principles of functional programming in an interesting and creative manner. Features of this release include: * All examples from Conal's Fun of Programming chapter * Many examples stolen from Jerzy Karczmarczuk's functional textures work * Full type checking * New user interface controls (random numbers, Haskore timing tracks) * More Haskell features * Movie making capabilities * Improved viewer * Simplified syntax for monadic code Pan# runs on Windows and uses the .NET system for dynamic compilation. It has not yet been ported to Linux or Macs but if you're familiar with the open source .NET systems we would be glad to help someone move Pan# to other operating systems. Pan# is easy to install and use. It has been tested with high school students and has proven to be an effective vehicle for introducing novices to the basics of computer programming without getting wrapped up in the endless details of visual Basic or other "industrial strength" computer languages. Because functional programming is very close to mathematics, Pan# does not need to introduce unfamiliar computational paradigms to students. We are also investigating the use of Pan# as an instructional tool for high school mathematics - some examples of this are included in the distribution. You can download Pan# at http://haskell.org/edsl/pansharp.html Thanks to Microsoft Research for supporting this project. John Peterson, Yale Haskell Group peterson-john@cs.yale.edu
The difference between Pan and Fran is that Pan is stateless: the image is a pure function of the current control settings (system stimulus) rather that a stateful signal function as in Yampa or Fran. So you couldn't really do the infamous paddleball game or make use of switching or integrals or other stateful signal functions. If you're clever you can factor out the state - for example, you could do the "bouncing ball" example by finding a closed form solution to the ball trajectory instead of using a stateful integrator at runtime. But you couldn't do something like the traffic light program (an animation which switches colors with each mouse click) since there's no way to remember the current color of the light on each button press. That being said, you can still express many animations in a natural way - it's really the interaction that can't be done. There are many stateful control objects in Pan - it's just that the state lives in the controllers (such as the position of the sliders or movable points) rather than in the animation language. One of the cool things we've added is the ability to take event streams generated by other programs (in this case Haskore) and use these to drive an animation. So you could express something in a stateful way, either in Haskore or Yampa or whatever, and save the generated event streams for animation by Pan. Unfortunately I don't have a releasable version of Haskore + Pan event stream output stuff yet but it should be ready soon. John
participants (2)
-
John Peterson -
Vincenzo aka Nick Name