Lambda the Ultimate

autrijus, you have won yourself the right to be called by name, and it's a well deserved right, yessir!

Pugs is fascinating, (I gotta yet get the lastest version and I also gotta dig into the technical documentation). I see there are many things that aren't working quite yet, which is understandable, but it's already a really brilliant work (and an excellent proof by crafting of FPL on the works)

A quick question I have, however, that maybe you may brief for me (and the rest of us). Monads: all that out put and input, you are using them, right? How???

(N.B. obviously I'm just amateurish in Haskell)

thanks for your hard work, and keep it up!

I'd like to refer you to the Pugs READTHEM file; in the "Some Online Haskell Resources" section there are numerous URLs that explains monads. :-)

Explaining monads

Although I understand the concept of monads, and I have used them in projects, I don't understand how they can shelter me for introducing bugs in my code. So please consider this as an honest question: how do monads save me from bugs? and what kind of bugs do monads prevent?

[See remark below, given my own opinions, I guess this is better answered by a true Haskell evangelist]

As far as I got it: separation of concerns by very explicitly dividing the program into impure parts which deal with the outside world, and pure parts which don't. This is good software engineering practice: the assumption being that it is easier to maintain strong invariants over pieces of code (sometimes, just by looking at the type) which are pure.

As far as I understand it, (a) as a rule of thumb this is an excellent practice, (b) it doesn't help if you don't separate, (c) separation isn't always that easily feasible or (imho) wanted, (d) it doesn't prevent you from introducing other bugs and (e), well, let's say it's an open question and a matter of belief whether you should use monads for that in a general purpose language. [P. Wadler once thought it was a good idea, so that's actually an opinion hard to disagree with]

...monads let you treat computations as first-class values. This lets you define new control structures by writing functions that manipulate computations. For example, you might have a monad type for computations that may fail:

type 'a m = unit -> 'a option

(* unit : 'a -> 'a m *)
let unit v = (fun () -> Some v)

(* fail : 'a m *)
let fail = (fun () -> None)

(* bind : 'a m -> ('a -> 'b m) -> 'b m
let bind v f = 
  (fun () -> 
    match v() with 
    | None -> None
    | Some x -> (f x)())

Now, you can define an operator "$" which takes two arguments, and tries the first one, and if it fails runs the second one and returns that:

(* ($) : 'a m -> 'a m -> 'a m *)
let ($) c c' = 
  (fun () -> 
    match c() with
    | None -> c'()
    | Some x -> Some x)

This kind of thing can make structuring your programs very pleasant, because you can manipulate the program with the operations that make sense with your semantics, rather than just the control structures you have lying around.

This question keeps popping up. What do you mean?

Informal explanation in short: [IO] monads are a typesafe manner of sequencing actions which interact with the outside world - the operational semantics of the monad make sure that they are sequenced in proper order.

Personally, I find it an abhorrent hack; but most people will fervently disagree with that view ;-P

One of the things I don't like at all about Parrot Assembly is the mixing between opcodes and API. That makes a lot bytecode to learn and remember, and does not clearly separate what is an optimized opcode or what is an API function.

The opcodes are parrot's API -- it's tough to interface with a machine, virtual or not, without using machine code.

If you dislike that much of what falls into a traditional runtime library is, instead, built into the machine... I've got to admit to a distinct lack of sympathy. The functionality has to go somewhere, and if you're writing compilers you need to know it all anyway. Where the functionality lives really doesn't matter, and while Parrot's got a relatively large amount of semantic stuffed into it that's because the minimum problem space it needs to guarantee coverage for.

When you're writing compilers for a target system you need to wrap your brain around the whole thing, CPU and runtime libraries. Where things live rarely matters, and when it does it only matters briefly. (If it matters for longer than that you've got some significant issues with your compiler)

The hard part is remembering what functionality is provided. Past that it's straightforward and not a big deal. (Broadsides levelled at documentation, or lack thereof, that makes finding the functionality is warranted, but that's a separate complaint)

Do you think that having the whole standard library into the language specification is a good thing ? I don't think so.

And actually most of the standard library itself could (should) be written in the language itself when possible. And when not possible, using the FFI is the way to go.