Lambda the Ultimate

Of course, you need constructs that will allow you to write reliable code in the presence of noisy behaviour from prmitives. I can think of a couple of possible approaches for dealing with this aspect of the language design.

Why?

More to the point, it is well known that people aren't thatgreat when it come to probabilistic reasoning. Why not provide kids with a place to improve their intuition?

Is it just that adults commonly suppose themselves to have better things to do with their time?

No, it's just that adults are usually beyond help (and hope).

people aren't that great when it come to probabilistic reasoning

Why do Frequency Formats Improve Bayesian Reasoning? Cognitive Algorithms Work on Information, Which Needs Representation

Exactly. You'd want the child to be able to discover this idea for himself (but notice that the checking operations might also be noisy).

It would be interesting to run a pilot and see if it improves qualitative reasoning?

Yeah, that's pretty much the idea.

<off-topic>
Hi Andrew! Your profile doesn't have an email address - drop me a line and say hi (my web address is in my profile, and you can find my email address from there).
</off-topic>

I have written a monadic turtle package that uses OpenGL, and therefore support different pen colours and absolute positioning (it doesn't display a turtle). It is part of the lsystem package you can find at PLaneT: http://planet.plt-scheme.org/

These noisy actuators turn the deterministic world into a Markov Decision Process. I don't know if that is interesting to you but there is a lot of literature on planning and learning in MDPs

"Mondaic turtles" - must say I love the ring of that...

"A Semantics for Logo, or, Turtles All the Way Down"

Still don't grasp what you want to do with it. Turtles with build-in PID controllers, or something? Is that it?

You can easily make a library or proabilistic turtles - that's what I described above. But is that really useful enough?

Suppose you want the child to discover that he can speculatively run several turtles and average their behavior, in order to achieve greater accuracy. If it's in the context of a library we need to provide relevant procedures (get-tutrtle-pos etc.) But the building blocks are rather low-level. It might be nicer (and yes, these are *design* decisions) to provide higher level constructs such as eval which evaluates exp n times, from the same starting position. How about eval! which doesn't change the drawing but keeps other side effects (so can save info about the end-position of the turtle, perhaps).

These higher level operations can also be part of a library (if you have high order functions they pose no real difficulty). But perhaps providing syntax to cover patterns you think are important is a better way to go.

Keep in mind that the distinction between language design and library design is rather arbitrary, if you discard syntactic issues and use a powerful enough language. For example, Logo is a language, yet PLT Scheme as well as many other languages provide tutrtle graphics libraries.

Logo is more that just turtle graphics, I know.

I'll take a look.

My first thought about what a "probablistic" language would be, involved "random variables". In the sense that rather than having "exact values", a value is instead a probability distribution function describing the likelihood of it being close to particular value. This comes from my EE background where in some of my classes we started replacing component values in a circuit with random variables(e.g. 2Kohm resistor, + or - 10%, Gaussian distribution ), and then did circuit analysis with these fuzzy values, which produced random variables as the output.

The running example is precisely the computation of the impedance of a simple circuit. I should have made the Random numbers into the Num and Fractional classes so that we can use the conventional arithmetic operators *, -, etc.

We have designed a DSEL for probabilistic programming in Haskell. In addition to the Monte Carlo method employed by the parent example, our system allows the entire distribution to be computed if desired. Also, I should point out that the example given (the impedance) doesn't seem to make well use of the monad. In our system, either a Monte Carlo or full distribution computation of the given example could be done with:

impedance inductance capacitance freq resistance = do
	in 

Our system can be found on-line at http://web.engr.oregonstate.edu/~erwig/pfp/. 

Also, I should point out that the example given (the impedance) doesn't seem to make well use of the monad.

impedance inductance capacitance freq resistance = do
   in <- inductance
   ca <- capcacitance
   fr <- freq
   r <- resistance
   return ( sqrt ( ((fr * in) - 1 )**2.0 + r**2.0) )

impedance inductance capacitance freq resistance =
 sqrtM $
  (sqrM 
    (freq `mul` inductance) `sub` ((return 1) `divM` (capacitance `mul` freq)))
  `add`
  (sqrM resistance)

impedance inductance capacitance freq resistance =
 sqrtM $
  (sqrM (freq * inductance) - (1 / (capacitance * freq))) + (sqrM resistance)

The expressions look different -- but in appearance only. Once we notice that mul is defined as liftM2 (*), we see that the "do" form is equivalent to the "do-free" form. The random-var-monad article showed that we can compute the arbitrary number of moments of the distribution, that is, we compute the whole distribution. Jerzy Karczmarczuk pointed out (in the cited post to comp.lang.functional) how to compute the distribution analytically, by approximating source distributions by combinations of Gaussians.