Features
Features:

Product Tour >

Edraw AI >

Paid Plans:

Individuals >

Business >

Eduaction >
Resources
Blog

History

How-tos & Tips

Discovery

Biography

Business Analysis

Examples

AI concept Map

Free AI Mind Map Generator

Onenote Mind Map

Bcg Matrix Examples

Nike Marketing Strategy

Unilever SWOT Analysis

Make Mind Maps in Google Docs

Guide

FAQs

What's New

Resource Center
Templates
All Templates

Brain Storming Templates

Strategy and Planning Templates

Project Management Templates

Product Management Templates

Human Resources Templates

Agile Workflow Templates

Marketing Templates

Education Templates

Fun and Games Templates

User Gallery
Download
Pricing
Enterprise

variable

This is a mind map about object variable variable namespace names. The main content includes: first principles, derivation of variable mechanism, python, variable variable, lisp, lifetime extent, scope scope, reference, binding, variable name variable name, namespace namespace, object object, Hongmeng first opened, with memory and CPU.

Edited at 2024-02-06 16:34:48

PlotWizard

Recent works View more works>>

variable

PlotWizard

Recent works View more works>>

Recommended to you
Outline

taxonomia de las variables
- 13
WS60I6fl
Las variables
- 38
cristina mondes de oca
Algebra
- 478
- 1
eastandbull@yahoo.com

object object variable variable namespace namespace variable name variable name bindingbinding referencing scope scope lifetime extent

First Principles Derivation of Variable Mechanisms

Hongmeng is first launched, with memory and CPU

Memory is a piece of hardware that can store binary states 010101... The memory can be divided into an area to store a data object, such as an integer 123

CPU is computing hardware that can perform operations on data in memory. For example, multiply 123 by 2 to get 456. The operation result can be returned to the memory and divided into an area for storage.

object object

An object is a segment allocated in memory that represents a value. It exists in memory after creation until it is manually destroyed or destroyed by the mechanism (gc)

variable variable

After an object is created, it needs to be referenced in other parts of the program. Other parts include distance in space and distance in time. A variable is a name referring to a value. A variable is a name referring to a value. The mapping relationship from name to object. The variable below refers to the mapping relationship itself. The symbol/string used as the name is called the variable name.

variable name variable name

A unique, non-repeating identifier in the namespace, used as the name of the variable. Python uses strings, and Lisp uses symbols.

Naming rules

1 snake-shaped underline connection

happy_ hacker

2 hump capitalize the first letter of a word

HappyHack

3 Spine - No. connection

happy-hacker

namespace namespace

A container that stores variable names to object addresses and mapping relationships. Python uses dictionary as the implementation of namespace. Key is the variable name string. Value is the address of the object.

binding binding

Add a mapping relationship from variable name -> object and store it in the namespace

reference

Retrieve the bound object from the namespace using the variable name

Scope scope

Scope refers to the places in a program where a variable is visible and can be referenced. A scope is a range of text in a program where variables are visible and references to variable names can take effect.

initial scope A globally valid scope dictionary The variable name is the global variable name Duplicate name overwrites previous binding

A scope takes effect globally and its lifetime is also equal to the global scope (until it is manually deleted) Early languages were like this: assembly BASIC FORTRAN

Problem Variable name conflict Unable to modularize development

There cannot be variables with the same name in all parts of the program, otherwise the previous binding will be overwritten. When the program becomes larger, it will be difficult to collaborate on development. Variable names are becoming increasingly insufficient.

It is considered good programming practice to make the scope of variables as narrow as feasible so that different parts of a program do not accidentally interact with each other by modifying each other's variables.

Modular needs

The entire program is divided into different areas (blocks and functions). The variables inside the area are not visible to the outside. There is no need to consider the problem of variable names in different areas, and multiple people can develop in parallel and modularly. Idea 1: Each sub-area is given a scope dictionary, which takes effect within the area. It can be nested. The overlapping part is the innermost one that takes effect. A variable name can exist in multiple scope dictionaries at the same time. Idea 2 The variable name is globally unique, and each variable name has a FILO binding stack. The global binding is at the bottom of the stack. After entering each area, the assignments in the structure are added and bound to the top of the stack. When exiting the structure, it pops up. Added binding. In effect, it can also be nested, and the binding currently pushed into the innermost layer will take effect.

After modularization, variables can be divided into global variables and local variables, bindings that are effective globally and those that are effective within the local substructure. For variables in local structures, they can be divided into locally bound (bound) and free (free). The former is assigned a value inside the structure, and the latter is not found inside the structure and needs to be found outside.

Modular idea 1 Lexical/static scope Outside the global scope (dictionary) Each substructure has its own scope (dictionary) The structure takes effect internally and is determined at compile time. The area is fixed, so it is called lexical scope. A fixed area is fixed at compile time and unchanged at runtime, so it is called a static scope. When nested, the innermost one takes effect.

C Algol-like languages Most modern languages are like this

The advantage is that people/compilers can determine the definition of the object pointed to by the variable name by checking the code, although the value is not necessarily certain.

Structures with their own scope

global scope global scope

global namespace a dictionary

block scope block scope

Bindings that take effect inside a code block. For example, inside a function, inside a conditional statement, or inside a loop statement.

for (i = 0; i < N; i) { /******************************/ /* printf("%d ", i); */ /* i = i 1; */ /******************************/ //scope of i } int n = 1; { int n = 2; /************************/ /* n = n 1; */ /* n = n 2; */ /* n = n 3; */ /* printf("%d", n); */ /************************/ // scope of inner n } int factor(int n) { int i = 0; /************************************/ /* int res = 1; */ /* for (i = 1; i < n; i ) */ /* { */ /* res = res * i; */ /* } */ /* return res; */ /**********************************/ // scope of i }

function scope function scope

When the function is called, the formal parameters are bound to the actual parameters passed in, and the scope is the function body.

int add (int a, int b) { /************************************/ /* int i = 0; */ /* for (i = 0; i < a; i ) */ /* { */ /* b = b 1; */ /* } */ /* return b a - a; */ /************************************/ //scope of a and b }

module scope module scope

The scope of the name is a module, python is a typical example

Another idea of modularization: global/dynamic scope Not a name that exists in multiple scope dictionaries at the same time Instead, it is a global name, and each name has a binding stack of FILO. When entering the substructure, you can assign a value and push the binding, and it will pop up when exiting the structure. The effect is also effective when the innermost layer is pressed. Global means the name takes effect globally Dynamic means that the text range is not determined at compile time, but is checked in the binding stack at runtime.

The early lisp only had this (emacs lisp). Later, the scheme switched to lexical scope. Later common lisp was lexical by default and could declare dynamic global variables.

The variable name at any time points to the value last bound (and not popped from the stack) The scope is globally available. The text range of the scope cannot be determined at compile time. At runtime, the most recently pushed one is found on the top of the stack to take effect.

Comparison of Lexical and Dynamic

For non-free variables (with local assignments) in a structure, dynamic scope has the same effect as lexical scope, and both are based on the innermost binding. For free variables, the lexical scope will capture the binding (closure) of the nested outer dictionary, but the dynamic scope will not. You can still check the binding stack.

Because the nesting relationship of text is fixed, the binding relationship captured by the closure is also determined at compile time. The lexical scope is the static text scope. The binding stack of dynamic scope can push/pop bindings at runtime. It is impossible to confirm which text area binding is in effect at compile time. When referencing, it takes the top of the stack at that time, so it is called dynamic.

Lifetime extent

The time range from start to expiration of a binding The time range within which the binding can refer to the object Equal to the time range that the object exists in memory

In typical C language, the lifetime of a function parameter starts from the function call and ends when the function returns.

Dynamic lifetime

Started when entering the structure and destroyed when exiting the structure, such as function parameters in C language

undefined lifetime

There is no fixed start and end position. If the reference count is not zero, it will continue to exist. The reference count will be cleared by gc when it reaches zero.

lisp

bound scope

Lexical static scope lexical/static scope

Lexical means that the binding only takes effect within a fixed text range. For example, the scope of a function parameter is the function body. Static means that the effective range is determined at compile time and does not change at runtime, so it is static. If there is no bound object, an error will be reported during compilation. The implementation is a nested dictionary, one dictionary for each substructure

Variable default lexical scope in lisp

global undefined dynamic scope global/indefinite/dynamic scope

Global means that there is no fixed text range, and the entire program can search for the current binding. Undefined means that it is not a range determined at compile time, but at runtime, the symbol is searched in the global binding stack, and the latest one on top takes effect. The content of the binding stack at that time is not determined by the compiler. If there is no binding stack, no error will be reported during compilation, but an error will be reported at runtime. Each intern symbol is implemented with a global binding stack that can be indexed from inside using symbol-value.

Declared as a special variable defvar defparamerter

object lifetime

Dynamic lifetime dynamic extent

An object is created at the beginning of the structure and destroyed on exit

Function input parameters in C language are created when the function is called and destroyed when the function returns.

Binding of special variables in lisp. The inner structure is created when entering and destroyed when exiting. It cannot be captured by closures.

undefined lifetime indefinite extent

An object persists as long as its reference count is non-zero. The reference count is cleared by gc after it reaches zero.

Global variables in C language

Most objects in lisp are like this

Ordinary variables

Lexical scope undefined lifetime It takes effect in the static code scope. During the lifetime, the reference count is reset to zero and cleared. Can be captured by closures

When referencing an ordinary variable, it is fixed at the definition position and the binding in the lexical scope takes effect.

special variables

undefined scope dynamic lifetime The scope has no fixed scope. In theory, it can be globally refed. At runtime, it will find the top one from the binding stack. When the inner layer of the binding is assigned, it is pushed into the global binding stack. When the inner layer exits, it is popped from the binding stack and destroyed. The inner binding structure must be destroyed after exiting. The lifetime is dynamic and cannot be captured by closures.

When referencing a special variable, the latest innermost binding takes effect before the reference time.

catch throw tag

Undefined scope Dynamic lifetime (same as special variables)

Exit name of block do prog

Lexical Scope Dynamic Lifetime

go tagbody's tag

Lexical Scope Dynamic Lifetime

When the variables have the same name, the inner one takes effect and shadowing the outer one takes effect.

The lambda function can capture ordinary variables used in the environment as closures, but it cannot capture those declared as special variables. Therefore, special variables need to be explicitly distinguished in the name by adding asterisks before and after.

*global-var1*

python

Scope is only lexical scope

By default, search is performed in LEGB order from the inside out.

Keywords can specify the search location

global only found in Global

nonlocal only found in Enclosing

The survival period is only undetermined.

The reference count exists without being reset to zero. It is cleared by gc when reset to zero.