Ваше запитання цікаве кількома способами, оскільки воно вимагає ретельного розрізнення у кількох питаннях. Але ваше бачення мені здається принципово правильним. Я не читав вашої довідки, перш ніж писати більшу частину цієї відповіді, щоб уникнути упередженої відповіді.
По-перше, ваше твердження Variables are symbolic names for memory
addresses, це майже коректно, але заплутує концепцію та її звичайну реалізацію. Змінна - це фактично лише контейнер, який може містити значення, яке можна змінити. Зазвичай цей контейнер реалізований на комп'ютері як сукупність простору пам'яті, що характеризується адресою та розміром, оскільки змінні можуть містити об'єкт, який потребує представлень з більшою чи меншою кількістю інформації.
Але я розгляну здебільшого більш абстрактну точку зору на семантику мов, незалежно від прийомів реалізації.
Тож змінні - це просто контейнери з абстрактної точки зору. Такий контейнер не повинен мати назви. Однак у мовах часто є змінні, які називаються шляхом присвоєння їй ідентифікатора, так що використання змінної може бути виражено ідентифікатором. Змінна може насправді мати декілька ідентифікаторів через різні механізми псевдоніму. Змінна також може бути підрозділом більшої змінної: приклад - це комірка змінної масиву, яку можна назвати, вказавши змінну масиву та індекс комірки, але також може бути пов'язана з ідентифікаторами через псевдонім.
Я навмисно використовую контейнер слів, який є дещо нейтральним, щоб не викликати інші слова, які можуть бути семантично завантажені технічно. Це насправді близьке до поняття посилання, описаного у віліпедії , яке часто плутають із адресою пам'яті. Саме вказівник на слова часто розуміють як адресу пам’яті, але я не думаю, що це має сенс при розгляді більшості мов високого рівня, і, ймовірно, недоречно в дискусійному документі, на який ви посилаєтесь (хоча адреси можуть бути використані), оскільки це недоречно посилаючись на конкретну реалізацію. Однак він підходить для такої мови, як C, яка повинна бути набагато ближчою до концепцій реалізації та архітектури машини.
Насправді, якщо подивитися на змінні чи значення на рівні реалізації, може бути кілька складних систем непрямості, "покажчиків машинного рівня", але вони (і повинні бути) невидимі для користувача, так що абстрактна точка зору Я розвиваю, може бути дійсним. Для більшості мов програмування користувач не повинен хвилюватися або навіть знати про реалізацію, оскільки реалізація може сильно відрізнятися для даної мови. Це може бути невірно для деяких мов, таких як C, які навмисно близькі до машинної архітектури, як вдосконалена заміна мов складання, які майже в прямому відношенні до явного бінарного кодування, але занадто низький рівень для зручного використання в більшості ситуацій.
Що повинен знати користувач мови, а іноді має бути навіть менше, ніж це значення та пов’язані з ними операції, де вони можуть міститися, як їх можна пов’язувати з іменами, як працює система імен, як можна створювати нові визначати види значень тощо.
Отже, ще одна важлива концепція - це ідентифікатори та іменування. Іменування сутності (значення) може бути здійснено шляхом асоціації ідентифікатора зі значенням (як правило, в декларації). Але значення також можна отримати, застосувавши операції до інших названих значень. Імена можна повторно використовувати, і існують правила (правила визначення) для визначення того, що асоціюється з даним ідентифікатором, відповідно до контексту використання. Існують також спеціальні імена, що називаються litterals, для назви значень деяких доменів, таких як цілі числа (наприклад, ) або булеві (наприклад, true ).612
Асоціація незмінного значення з ідентифікатором зазвичай називається константою. Літтерали - константи в цьому сенсі.
"Контейнери цінностей" також можна вважати значеннями, а їх зв'язок з ідентифікатором є змінною у звичайному "наївному" розумінні, яке ви використовували. Тож ви можете сказати, що змінна є "константою контейнера".
Тепер ви можете задатися питанням, в чому різниця між асоціацією ідентифікатора зі значенням (постійне оголошення) або присвоєнням значення змінній, тобто зберіганням значення в контейнері, визначеному як константа контейнера. По суті, декларація може розглядатися як операція, яка визначає позначення, що пов'язує ідентифікатор, який є синтаксичним утворенням, деяким значенням, яке є семантичним утворенням. Присвоєння - це суто семантична операція, яка змінює стан, тобто змінює значення контейнера. У певному сенсі декларування - це мета-поняття, що не має семантичного ефекту, крім надання механізму іменування (тобто синтаксичного) для семантичних сутностей.
Власне, призначення - це смислові операції, які динамічно відбуваються під час виконання програми, тоді як декларації мають більш синтаксичну природу і зазвичай повинні інтерпретуватися в тексті програми незалежно від виконання. Ось чому статичне обстеження (тобто текстове скопіювання) зазвичай є природним способом зрозуміти значення ідентифікаторів.
Зрештою, я можу сказати, що значення вказівника - це лише інша назва контейнера, а змінна вказівник - змінна контейнера, тобто контейнер (константа), який може містити інший контейнер (з можливими обмеженнями щодо гри, що містить деякі елементи, накладені деякими тип системи).
Щодо коду, ви заявляєте [pointers] might indicate the entry point
to a section of code and can be used to call that code. Насправді це не зовсім так. Розділ коду часто безглуздо поодинці (з точки зору високого рівня чи реалізації). З точки зору високого рівня, код зазвичай містить ідентифікатори, і вам доведеться інтерпретувати ці ідентифікатори в статичному контексті, де вони були оголошені. Але насправді можливе дублювання того ж статичного контексту, по суті, через рекурсію, яка є динамічним явищем (час виконання), і код може бути виконаний лише у відповідному динамічному екземплярі статичного контексту. Це трохи складно, але наслідком цього є те, що правильна концепція - це закриття, яке пов'язує фрагмент коду та оточення, де слід інтерпретувати ідентифікатори. Закриття є належним смисловим поняттям, тобто є правильно визначеним смисловим значенням. Тоді ви можете мати константи закриття, змінні закриття,
Функція - це закриття, як правило, з деякими параметрами для визначення або ініціалізації деяких його сутностей (констант і змінних).
Я пропускаю безліч варіантів використання цих механізмів.
Замикання можна використовувати для визначення структур ОО в імперативних або функціональних мовах. Насправді, рання робота над стилем OO (можливо, перед назвою) робилася саме так.
Документ, на який ви посилаєтесь, я швидко проглянув, здається, цікавий, написаний компетентною людиною, але, можливо, не з легким читанням, якщо ви не маєте значного досвіду роботи з різними мовами та їх основними обчислювальними моделями.
Але пам’ятайте: багато речей перебуває в очах глядача, доки він зберігає послідовний погляд. Точки зору можуть відрізнятися.
Чи відповідає це на ваше запитання?
PS: Це довга відповідь. Якщо ви вважаєте якусь частину її неадекватною, будь ласка, поясніть, про що йдеться. Дякую.