1. 15
  1.  

  2. 2

    Perhaps unsurprisingly, perl has both lexical (“my”) and dynamically (“local”) scoped variables.

    Also, no need for an imaginary language, perl also implements the “dynamic control flow” scoping, which is - frankly - my least favourite part of the language:

    $ cat tt.pl
    #!/usr/bin/perl
    use strict;
    
    foreach my $i (1..10) {
      doit($i)
    }
    
    sub doit {
      my ($i) = @_;
      next if $i % 3 == 0;
      print "$i\n";
    }
    $ ./tt.pl
    1
    2
    4
    5
    7
    8
    10
    

    The dynamically scoped variables are a useful tool to have in the toolbox, but the above code is frankly a footgun with no reasonable upside I can see.

    1. 2

      but the above code is frankly a footgun with no reasonable upside I can see.

      I believe the argument is: why should you not be able to abstract parts of one function into another simply because they contain control flow?

      1. 1

        Makes sense. You can easily get this behavior in Haskell if you want it, since side effectful computations like control flow are just values (with a type that is usually a M-word) so you can manipulate them, pass them around and return them from functions.

    2. 1

      Given the title, it would also be nice to see a discussion of DWIM name resolution to talk about fuzzy matching.

      IDEs do this a lot “you typed ‘num_pad_bytes’, did you mean ‘num_padding_bytes’” and ask the coder to be more specific. There’s no reason (other than insanity) why a dynamic language couldn’t have a DWIM name resolution algorithm in play as it walks the stack of scopes looking for a match.

      1. 1

        I did not find this explicitly mentioned, but surely the name resolution in OOP is dynamic rather than lexical?

        1. 2

          Depends on the language doesn’t it?

          1. 1

            I would argue that message passing, with the objects deciding what to do about a message received at runtime captures the essence of dynamic binding.

            However, I agree with your point. OO is somewhat amorphous at this point, and one may very well implement a language without late binding and call it OO.

            Edit: To clarify what I meant; dynamic binding is where the execution path rather than the lexical ordering determines how a method or variable is resolved. When an object receives a message, the message resolution is determined by the execution path that involved that object. That is, one can not predict in advance using lexical knowledge alone what method will be called.

            1. 8

              The post talks both about name resolution (lexical and dynamic scope) and method resolution, and sometimes seems to conflate the two.

              All mainstream OO languages that I’m familiar with use lexical scope, while most of them use dynamic binding.

              1. 1

                Yes, agreed. Got muddled :/