in reply to Re: IO::Lambda: call for participation
in thread IO::Lambda: call for participation

That was my initial impression, then I began asking questions about how to write more complex stuff, and began thinking about how it would look. I'm also thinking of trying to write an introductory level document that should take someone who has no background in this stuff to the point where they could think about writing a complex application. (The direction I'm heading right now is a proof of concept asynchronous webserver that uses connection pooling to control how many database connections it uses.)

In that process I realized that if you indent normally, then after any complex sequence of events you are indented off of the right hand side! And what, exactly, does that indentation tell you? Basically that this happens before that happens before the other thing. Nesting of braces is carrying sequencing information, which we normally don't bother indenting at all.

So once you get past the mechanics of what it is doing under the hood and try to think in terms of this library, what you really need to do is imagine that someone added a very small vaguely Lisp-like language to Perl, and that language is used to achieve the asynchronous magic. And once you think of it that way, the indentation makes perfect sense. You indent all of your Perl in a block by 4. Then outdent all of the commands in this second language by 2 (to indicate that they are this other language). Then let your closing braces pile up. In short at this point you're formatting the Perl bits like Perl, and the IO::Lambda bits like they were Lisp. (And once I figured that out, I understood as I never have before why Lisp people universally format their code that way.)

  • Comment on Re^2: IO::Lambda: call for participation

Replies are listed 'Best First'.
Re^3: IO::Lambda: call for participation
by xdg (Monsignor) on Jan 16, 2009 at 11:27 UTC
    In that process I realized that if you indent normally, then after any complex sequence of events you are indented off of the right hand side! And what, exactly, does that indentation tell you? Basically that this happens before that happens before the other thing. Nesting of braces is carrying sequencing information, which we normally don't bother indenting at all.

    Well, rjbs got me converted to 2-space indents, so indentation is less of a beast to me. ;-)

    On the serious side, I think as long as this is used for a linear execution sequence, what you say is true. And I think all the examples are pretty linear. But if you ever do multiple predicates at the same level, I would suspect that lack of indentation would make following the execution sequence a bit challenging.

    My point is not that it can't be understood, but that one has to actually learn the library first and grok how it works before the code is "skimmable". That's an adoption barrier and probably makes maintenance in a larger team setting problematic.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
      Well if you ever do multiple predicates at the same level, you'd have to make it visually clear that you're doing something weird. Certainly the indentation would change. I don't know how though, because I haven't thought through any such examples.

      As for difficulty in trying to grok how the library works, my goal it to make that much, much easier than it is now. If I succeed then it should be a fairly short learning curve to come up to speed on the library.

      That said, I think there are some features that will turn out to be important that aren't there yet. One is that I'd like to have a "stack context" that you can keep adding to. If a problem happens, it would be nice for debugging purposes to figure out how this sequence of execution got *here*, but right now there isn't a stack backtrace that I know of. I'd like to see better facilities for exception handling, but that is likely to be hard to do. And I'm sure that there are some spit and polish issues that will become apparent once people try to use it.

      But I'm interested enough in what's there now to look at it in more depth.

[reply]
      I agree with your arguments that this is an adoption barrier. However it would be pity to abandon that style only because it is a barrier. Perhaps, introductory documents and examples indeed shall feature only the usual indentation, while formatting of all other code would be up to the programmers involved.

      On the side note, even though having multiple predicates is perfectly viable, it is very rarely needed.

[reply]
Re^3: IO::Lambda: call for participation
by dk (Chaplain) on Jan 16, 2009 at 10:02 UTC
    ++! And I think it would be a very good idea to include reasoning about indentation into the introductory document.
[reply]

In Section Meditations