[ prog / sol / mona ]

prog


Lexical Scoping == Tyranny

1 2020-10-29 16:49

Cast aside your crutches.

2 2020-10-29 17:19

Tyranny is global and local only, with no access to either the lexical or dynamic environment.

3 2020-10-29 17:30

>>2

Show me an example.

4 2020-10-30 19:07

I was thinking of python before python 3 when they added nonlocal. (I'm not really familiar with dynamic scoping so...)

5 2020-10-30 21:38

>>4

Python nonlocal allows us to explicitly choose scope behavior in nested function definitions.

def outer():
    x = 1
    def inner():
        x = 2
        print(x)
    inner()
    print(x)

def outer_nl():
    x = 1
    def inner():
        nonlocal x
        x = 2
        print(x)
    inner()
    print(x)

outer()    # 2 1
outer_nl() # 2 2

We can achieve the same behavior without nonlocal.

def outer():
    context = {}
    context['x'] = 1
    def inner():
        context['x'] = 2
        print(context['x'])
    inner()
    print(context['x'])

Basic lexical vs. dynamic scoping...

MIT Scheme(lexical):

(define (definer)
  (define x 1))

(define (printer)
  (display x))

(define (letter)
  (let ((x 2))
    (printer)))

(definer)
(printer) ; error undefined variable
(letter)  ; error undefined variable

Common Lisp(dynamic):

(defun definer ()
  (defvar x 1))

(defun printer ()
  (print x))

(defun letter ()
  (let ((x 2))
    (printer)))

(definer)
(printer) ; 1
(letter)  ; 2
6 2020-10-31 09:23

>>5 I guess it's something to get used to, and it does explain why in some lisp forums people have warned me that my local defines were actually global.

But, I mean, surely you can see calling these procedures without arguments and expecting to get different results depending on the context of the call kind of goes against Scheme's functional tendencies.

If you don't want to write in a functional style, Common Lisp is a much better choice. But that's not a deficiency of scheme (or Common Lisp), it's just a philosophical difference between the two languages.

7 2020-10-31 16:58

>>6

With dynamic scoping the concept of global and local is abolished. Full control is given to the programmer. If one wants a different scope one has to explicitly create it. Once created, anything in that scope behaves as expected without magical implicit omissions or additions.

Scheme can be made to create similar non-functional side effects with (set!), but this is more complex and less useful than dynamic scoping.

8 2020-11-01 05:53

>>7 You can also always use hash-tables or alists like in the python example. But different varieties of lisp are defined by different properties. Some have the everything in one name-space, some have different namespaces for functions and variables, and I think some add more after that. Some have fexprs, some don't. Some support tail recursion and some don't.

If you would prefer to stick to those dialects that allow dynamic scope, then by all means, do. But I don't see why the rest of us should take your preferences as anything more than that: your preferences. And we all have our preferences.

9 2020-11-01 20:37

MIT Scheme:

(define s "I ENJOY TYRANNY")

(define (set-me-free)
  (display s))

(let ((s "I AM FREE"))
  (set-me-free))

Common Lisp:

(defvar s "I ENJOY TYRANNY")

(defun set-me-free ()
  (print s))

(let ((s "I AM FREE"))
  (set-me-free))
10 2020-11-01 20:53

>>9 Not so fast.
(setf s "I ENJOY TYRANNY")

(defun set-me-free ()
(print s))

(let ((s "I AM FREE"))
(set-me-free))

11 2020-11-01 21:18

>>10

Same result as second example assuming this is also Common Lisp.

12 2020-11-01 21:36

>>11
https://rextester.com/BQX34910
https://rextester.com/XLJIR13883

13 2020-11-01 21:58

>>12

You are correct. I was running the wrong script like a dummy.

http://www.lispworks.com/documentation/lw50/CLHS/Body/m_defpar.htm

defparameter and defvar establish name as a dynamic variable.

http://www.lispworks.com/documentation/lw50/CLHS/Body/m_setf_.htm

setf changes the value of place to be newvalue.

When you use setf you are specifically requesting that dynamic scoping not be used. Common Lisp gives us the choice, aka freedom from lexical tyranny.

14 2020-11-02 13:10

>>13
Wow, how exotic and unique.

(define s (make-parameter "I ENJOY TYRANNY"))

(define (set-me-free)
  (display (s)))

(parameterize ((s "I AM FREE"))
  (set-me-free))

; => I AM FREE
15 2020-11-02 16:42

>>14

This is an emulation of dynamic scoping not actual dynamic scoping. The variable has become a procedure.

16 2020-11-02 17:04

>>15
So what? Just because Common Lisp uses the same syntax for lexical and dynamical/special variables, has not meant that all lisp have done this, nor that Scheme has to do it. It's not like dynamic scoping it inherintly more powerful, you could probably do something like that in C too (pinging FrozenVoid for a stupid and malformated example).

17 2020-11-02 17:39

>>15

So what?

(define (create-me)
  (define s (make-parameter "I AM BROKEN")))

(define (set-me-free)
  (display (s)))

(create-me)

(parameterize ((s "I AM FREE"))
  (set-me-free))

It's not like dynamic scoping it inherintly more powerful

Dynamic scoping is not arbitrarily limited, thus less tyrannical.

18 2020-11-02 17:42

>>15
There's nothing emulated here, but there is some confusion of terminology. Parameters are first class objects, which makes them more powerful than plain old dynamically scoped variables. But they are not exactly variables. If you need variables, have a look at how fluids are built in Guile or make your own with dynamic-wind and some binding macro to hide the magic. It's done in a few minutes.

(It's not an emulation if it's just a real implementation. Here we're not building a meta-level where the new thing is possible, we're just doing it on the same level as everything else.)

19 2020-11-02 19:18

>>18

MIT's fluid-let seems much more useful than guile's fluid system of explicit declarations. One still cannot define within a define though. There are most likely other limitations too because we are creating a dynamic environment within lexical environment.

20 2020-11-03 05:19 *

muh freedom to shoot myself in the foot

21 2020-11-03 05:46

>>16
https://github.com/FrozenVoid/C-techniques/blob/master/scope.c

22 2020-11-03 05:50

>>21

Lack of indentation has progressed to actual intentional obfuscation.

23 2020-11-03 07:56

>>22
I specifically indented the nested block scope example for pedants like you.

24 2020-11-03 07:57

see raw text:
https://raw.githubusercontent.com/FrozenVoid/C-techniques/master/scope.c

25 2020-11-03 12:06 *

>>24
What does that change?

26 2020-11-03 12:36

>>25 Raw text preserves indentation as is, no browsers differences or css stylesheets will alter the appearance/indent/white-space/word-wrap/etc.

27 2020-11-03 15:52

>>25

FrozenVoid is a shtick. He always posts unreadable C code.

28 2020-11-03 19:19

>>27 thats not "unreadable", its code for public consumption.
I can write code with shorter variables and more macros.
Indentation also not used at all. Compare this with https://raw.githubusercontent.com/FrozenVoid/C-techniques/master/scope.c

#include "Util/void.h"
int g=4,l=50;
#define prscope(s) print(s,g,l)
void f(char*s){prscope(s);}
#define ex(s) ({prscope(s);})
void of(char*s){prscope(s);}
void f2(char* scope){int g=2000,l=6000; 
void f3(char*s){prscope(s);};f3(scope);//2000,6000
atype fptr=of;fptr("\nGlobals again:");
ex("\nContext scope again:");}
int main(int argc,char**argv){
int g=5,l=100;
ex("\nContext scope:");
with(int g=1,l=2,prscope("\nLocal scope:"));
prscope("\nOuter scope:");
f("\nGlobal scope:");f2("\nDynamic scope:");
do{int g=-1,l=-400;prscope("\ndo loop context:");}while(0);
//inline block context {}
{int g=-44,l=-233;prscope("\nBlock scope:");
{int g=-20000,l=5055;prscope("\nNext layer of block scope:");
{int g=-201,l=654654;prscope("\nNesting of block scope:");}
prscope("\nNext layer of block scope returns:");}
prscope("\nBlock scope returns:");}
prscope("\nback to main context:");}
29 2020-11-03 19:47

>>28

y
es
itm
ostd
efini
telyis
unreada
blebutyo
ualreadyk
newthatwha
tagreatshti
ckyoucreated
30 2020-11-03 20:08

>>29 Perhaps, there is something like a mental block that blocks you from reading punctuation and instead relies on spatial cues like shape of text?

31 2020-11-03 20:42

>>29,30 I see two major system of reading code:
A.By segmenting data by punctuation. This created a context for every block by parens/brackets/quote/etc used to delimit block boundaries.
A relies on simply counting current 'bracket level' +1/-1.

B.By segmenting data by spatical cues, such as indentation level(if all code fits on screen at once) from left side of content and its distance from nearby lines.
B system relies on monospace fonts, proper indentation and code fitting in one screen. It looks to me as fragile system where all conditions have to be met, so code will look "unreadable" if indentation is lost without becoming useless(Python code represents a code-decoding-form enforcing system B into compiler.)

32 2020-11-03 20:54

>>31
Additionally, i see LISP code read through system A as expressions with deeply nested parens, which scales poorly vs system B. I assume all LISPers are forced to use system B or read parens levels instinctively without counting by using system B "visual line-length estimation" in monospace font like mentally comparing length of )))) vs ))). is that correct?

33 2020-11-03 21:01 *

Is functional tyranny?

34 2020-11-03 21:07

FrozenVoid giving us his detailed opinion, broken into as many posts as possible, about why code should be completely unreadable... In a thread about dynamic scoping. What a treat.

35 2020-11-03 21:14

I'd like to see how System B readers interpret this:
https://i.postimg.cc/kGPVL8cF/Code-Example.png

36 2020-11-03 22:59

>>28
I'd say try participating in the IOCCC, but your code never does anything, it's just unreadable, without any interesting side effects.

37 2020-11-04 00:02

>>33

Functional programing is more like a consensual BDSM type of situation.

38 2020-11-04 08:40

>>37
Have you notarized your consent forms(printed (in triplicate))?

39 2020-11-04 13:56

>>31
Or C.: Recognizing and assuming conventional styles of programming. We are not computers that have to reparse a file again and again, instead we can remember patterns we are already familiar with. When someone uses a variable named "i", I'll assume it's a counter in C, until proven otherwise. Respecting style makes it easier for you and others to quickly gain an approximate understanding of what you are trying to do, defying usually looks like a infantile desire to be special.

40 2020-11-04 16:01

>>39
Sounds robotic as fuck:
"Be conventional like every NPC, rely on memorized patterns, don't be special,approximate understanding, follow the crowd".(P.S. "We're totally not computers")

41 2020-11-04 16:32

>>37

Master, I've made naughty side effects. I need a spanking!

42 2020-11-04 17:21

Are you a programmer or a programmed code monkey?

43 2020-11-04 18:03

>>40
Sounds like not wanting to create issues where it isn't necessary.

44 2020-11-05 05:49

Hello?

45 2020-11-05 06:26

>>44
Beep boop.

46 2020-11-05 06:28

Boop beep

47 2020-11-05 08:20

>>46
Syntax error.

48


VIP:

do not edit these