Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Sounds like a great idea to me. I wish someone had taught me scheme at 11. I'd say do everything as functional as you can, though; no imperative style. That will be easy enough to learn later.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • I agree about doing it as functional as possible and I plan to.

      I think that strictly speaking, even sequencing operations is procedural, not functional.

      So,

      (html-meta ...)
      (html-table ...)
      (html-footer ...)

      Is essentially procedural in nature.

      The functional way to do this, I believe, would be something like:

      (map html-gen
            '((meta parm1 parm2 parm3)
                (table parm1 parm2 parm3)
                (footer parm1 parm2 parm3)))

      Maybe I've been writing procedural code too long, but I find the procedural sequencing more natural here.

      Should I really go to the trouble of eliminating sequencing?

      I think I'd much rather introduce small functions that do part of the project and string them together.

      Maybe I'm wrong here. I did want to push the details of specific page generation down so maybe the driver should be a (map) or an (ormap) or (and) or something.

      This would make a procedure (html-gen) that looks something like:

      (define (html-gen args)
          (cond
              ((eq? (car args) 'meta)
               (html-meta (cdr args))
              ((eq? (car args) 'table)
      .
      .
      .

      I really envisioned writing up small routines that generate bits of HTML, testing these interactively and stringing them together. The fully functional implementation seems to me to require a lot more semantic details to get past before we can produce results. For example, I've not run any of the above code and I think I'll need to be doing various quoting in various places. I think to do this "right" it might involve quasi-quoting and other complicated concepts for those lists I'm passing to (map) above.

      As I said, I'm willing to be convinced here. It does occur to me that I can still run-up the routines for HTML pieces and when we're happy, wrap them all up in a functional driver as I've outlined above.

      If I'm going to go this route, no setq's either. Just call the outer driver with literal lists.

      It's ambitious, but I'm beginning to convince myself that pure functional is the way to go and introduce imperitive later. I think I won't have to deal with the complicated quoting issues if I keep it simple.

      Another issue along the 'purity' lines is should I introduce function definition with the convenience syntax:

      (define (x a) ...)
      or
      (define x (lambda(a) ...))

      If the second, then perhaps introduce functions like:

      ((lambda(a) ...) arg)

      And then explain that define just expands a name in place:

      (define foo (lambda(a) ...)) =>
      (foo args) == ((lambda(a) ...) args)


      This is one of the beauties of Scheme, actually, the first thing in a list is evaluated by the interpreter until a function is found (or not, in which case it's an error). If I'm going to teach functional, I'd like it be clear from the start that there's nothing "magic" about functions, just another basic datatype that can be returned by a function (or special form like lambda in the case above).

      Maybe I should find a Scheme forum to discuss this, like comp.lang.scheme.

      • I'm not as into Lisp and functional programming as I want to be, so I can't provide expert insight. All I can say is what I wish. :)

        Definitely search out Paul Graham's material on the net and absorb.

        Should I really go to the trouble of eliminating sequencing?

        I am not educated enough to say on that, yet.

        If I'm going to go this route, no setq's either. Just call the outer driver with literal lists.

        I do think avoiding setq's is good.

        I learned scheme followed by Lisp, and the way I was taught mad

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
          • Definitely search out Paul Graham's material on the net and absorb.

          I'm familiar with Paul Graham, but from what I can tell, he leans heavily toward Common Lisp and is pretty advanced. I prefer stuff like SICP [mit.edu], HtDP [htdp.org], the refreshingly simple TYSiFD [neu.edu] and The Scheme Programming Language [scheme.com]. All online! None of these texts is appropriate for my 11 year old, but I'm using some of their approaches as inspiration.

          • Bah! There are plenty of scheme programmers here (and I'm not talking about folks like me who can't