News for hackers. Stuff that matters.
Re:The Mumps Programming Language by ijoker on Monday March 13, 2017 @11:15PM (#13864676)
Another thing that's really weird about MUMPS is that variables are dynamically scoped. So this bit of code prints 5:

  foo() ; declare function foo
    n x ; declare variable x
    s x=1 ; set x to 1
    d bar() ; call bar
    w x ; print x
    q ; return
  bar()
    s x=5 ; set x to 5. Since x is not declared in this function's scope, it will search the symbol table of the calling function and overwrite its x
    q
I've run into so many bugs caused by something like this.
Re:The Mumps Programming Language by david-given on Tuesday March 14, 2017 @07:04AM (#13866479)
That'll be because there's only a single namespace, and the NEW command simply copies the values of the named global variables onto the stack and copies them back again at the end of the function.

I'm actually kinda used to that; I grew up with BBC Basic, which behaves the same way:

     10 i = 0
     20 PROCtest1
     30 END
     40 :
     50 DEF PROCtest1
     60 LOCAL i
     70 i = 1
     80 PROCtest2
     90 ENDPROC
    100 :
    110 DEF PROCtest2
    120 PRINT i
    130 ENDPROC
    
    > RUN
    1
...it occurs to me that BBC Basic, at least the later versions with block IFs, is a better language than Mumps in almost every way (except the integrated database stuff)!
Re:The Mumps Programming Language by jsgrahamus53 on Tuesday March 14, 2017 @09:17PM (#13873059)
Modern use of MUMPS mandates that each subroutine use the N(EW) command to instantiate its own versions of variables. If that was done above, '1' would have been printed instead of '5'.