use Perl

• Dynamic Features (Score:2)

  by ziggy (25) on 2005.04.08 21:47 (#39518) Journal

  You missed three key features:

  • No Closures (Tcl messes this up; I think Python does too...)
  • No eval (C, C++, Java; makes it much harder to do macros and code generation...)
  • No variable interpolation (printf is just soooo lame)

  Now, with interpolation and eval, you can fake closures, but it's a royal PITA. Here's the classic make_adder example in Perl:

  sub make_adder ($) {
       my $i = shift;
       return sub {
           return shift() + $i;
       }
  }
  
  $add1 = make_adder (1);
  print $add1->(2);  ## 3

  Here's a simplistic translation in Tcl. Procs aren't first class, but you can create new procs dynamically. This code is broken, because Tcl has lexical variables, but no closures:

  proc make_adder {procname value} {
      proc $procname {n} {
          return [expr {$n + $value}]
      }
  }
  make_adder add1 1
  add1 2  ## can't read "value": no such variable

  But you can work around that problem fairly easily with interpolation:

  proc make_adder {procname value} {
       proc $procname {n} "return \[expr {\$n + $value}\]"
  }
  make_adder add1 1
  add1 2

  It'd be a lot better if you could make an accumulator (i.e., true closures), but even without, you can still get a decent boost in power with dynamic code generation.

  I'm still on the fence whether or not you absolutely need macros. If you can construct classes, methods, and closures at runtime, you can fake it pretty well. And you can even work around the lack of closures if you absolutely must. But without all three of these features, you might as well be programming in C.

  (Yeah, [expr ...] is an wart in Tcl, but them's the breaks.)

  Reply to This

  • Re:Dynamic Features (Score:2)

    by schwern (1528)

    I think much of that can be summed up as "allow dynamic code generation" and "have code with some data attached". And to be able to do these things easily. Java, for example, limps along using pre-processors (IDEs, AspectJ, ...) for the former and anonymous classes for the latter.
    
    • Re:Dynamic Features (Score:2)

      by ziggy (25)

      Respectfully, no it's not. You really do need closures. Hey, it's 21st century -- get with the program! ;-)

      Reducing this down to "allow dynamic code generation" and "attach data to code" is a false economy in specification. Once you have true closures (which imply lexical scoping), a whole new way to code is opened up for you. Instead of writing ridiculously long classes to, say, find files, you can have small simple classes that are responsible for the algorithmic structure of finding files and nothi
      • Re:Dynamic Features (Score:2)

        by schwern (1528)

        I think we're having a violent agreement.
        
        By changing the wording from "have closures" to "easily attach data to code" (with the implied "at runtime") I was attempting to restate the problem as a problem rather than as a solution. Closures are a solution to the problem and you've layed out the problem quite well. I would rather not assume that closures are the only way to do it. Or eval. Or pluggable functions (*foo = \&bar). Maybe there is a way to do it efficiently and concisely with anonymous cl
        • Re:Dynamic Features (Score:2)

          by ziggy (25)

          Hm.

          As you stated the problem above, there are some design decisions that are fundementally wrong in language design today. Like no namespaces, no way to include files, etc.

          "No Closures" is as big a design flaw as "no anonymous functions", "no eval" and "no interpolation". You can find all sorts of ways around that problem, but fundementally, there's no good reason to not have closures. Rephrasing that, there's no defensible reason for asking your users to jump through hoops to achieve the same result
        • Re:Dynamic Features (Score:2)

          by ziggy (25)

          Re-reading your comment, this stands out:

          Maybe there is a way to do it efficiently and concisely with anonymous classes, dunno.

          Anonymous classes are a form of closure. It's how Java fakes closures in particular, and it's a cleaner solution for some problems. (You could define anon classes with dynamic scoping rules a la Tcl, but why?)

          The issues are very closely related, but not identical.

          If you say no to closures and yes to anon classes, you're really saying no jam! and more orange marmalade!