Чи означає "нетипізований" також "динамічно набраний" в академічному світі CS?

Я читаю слайд-колоду, де зазначено, що "JavaScript не вводиться". Це суперечило тому, що я вважав правдою, тому я почав копати, щоб спробувати дізнатися більше.

Кожна відповідь на те, чи JavaScript нетипізована мова? говорить, що JavaScript не є типовим, і пропонує приклади різних форм статичного, динамічного, сильного та слабкого введення, з яким я знайомий і задоволений .. так що це було не шляхом.

Тож я запитав Брендана Ейха, творця JavaScript, і він сказав:

академічні типи використовують "нетипізовані", щоб означати "немає статичних типів". вони досить розумні, щоб побачити, що значення мають типи (так!). питання контексту.

Чи люди, орієнтовані на академічну науку, використовують «нетипізований» як синонім «динамічно набраного» (і чи це дійсно?) Чи є щось глибше в цьому, чого я сумую? Я погоджуюсь з Бренданом, що контекст важливий, але будь-які цитати пояснень були б чудовими, оскільки мої нинішні книги "заходьте" не грають на цю тему.

Я хочу це зробити, щоб я міг покращити своє розуміння і тому, що навіть Вікіпедія не посилається на таке альтернативне використання (що я можу знайти). Я не хочу псуватися ні з використанням терміна, ні з сумнівом щодо використання терміна в майбутньому, якщо я помиляюся :-)

(Я також бачив головного Smalltalker, який каже, що Smalltalk теж "нетипізований", тому це не одноразове, що саме те, що спричинило мене на цей квест! :-))

Так, це стандартна практика в академічній літературі. Щоб зрозуміти це, допомагає знати, що поняття "тип" було винайдено в 1930-х роках, в контексті обчислення лямбда (насправді, навіть раніше, в контексті теорії множин). З цього часу виникла ціла галузь обчислювальної логіки, яка відома як "теорія типів". На цих основах базується теорія мови програмування. І у всіх цих математичних контекстах "тип" має особливе, усталене значення.

Термінологія "динамічне набору тексту" була винайдена набагато пізніше - і це суперечність термінів в умовах поширеного математичного використання слова "тип".

Наприклад, ось визначення "тип системи", яке використовує Бенджамін Пірс у своїй стандартній текстовій книзі " Типи та мови програмування" :

Система типів - це синтаксичний метод, що відстежується, для підтвердження відсутності певної поведінки програми шляхом класифікації фраз відповідно до типів значень, які вони обчислюють.

Він також зауважує:

Слово "статичний" іноді додається явно - ми говоримо про "статично типізовану мову програмування", наприклад, - щоб відрізнити види аналізів часу компіляції, які ми розглядаємо тут, від динамічного або прихованого введення тексту, знайденого на таких мовах, як Схема (Sussman and Steele, 1975; Kelsey, Clinger, and Rees, 1998; Dybvig, 1996), де теги типу запуску використовуються для розрізнення різних типів структур у купі. Такі терміни, як "динамічно набрані", є, мабуть, помилками і, ймовірно, повинні бути замінені на "динамічно перевірені", але використання є стандартним.

Більшість людей, що працюють у цій галузі, схоже, поділяють цю точку зору.

Зауважте, що це не означає, що "типізовані" та "динамічно набрані" є синонімами. Швидше, що остання є (технічно оманливою) назвою для певного випадку першого.

PS: І FWIW, я буваю як академічним дослідником систем типів, так і неакадемічним реалізатором JavaScript, тому мені доводиться жити зі схизмом. :)

Я академічний комп'ютер, який спеціалізується на мовах програмування, і так, слово "нетипізоване" часто (помилково) вживається таким чином. Було б непогано зарезервувати слово для використання з мовами, які не мають тегів динамічного типу, таких як Forth та код складання, але ці мови рідко використовуються та ще рідше вивчаються, і набагато простіше сказати "нетипізовані" ніж "динамічно набраний".

Боб Харпер любить говорити, що такі мови, як Scheme, Javascript тощо, слід вважати типізованими мовами лише одного типу: значення. Я схиляюся до цього погляду, оскільки це дозволяє побудувати послідовний світогляд, використовуючи лише один тип формалізму.

PS У чистому лямбдальному обчисленні єдиними "значеннями" є терміни в нормальній формі, а єдиними закритими термінами в нормальній формі є функції. Але більшість вчених, які використовують обчислення лямбда, додають базові типи та константи, і тоді ви або включаєте систему статичного типу для лямбда, або ви повертаєтесь до тегів динамічного типу.

PPS На оригінальний плакат: якщо мова йде про мови програмування, а особливо системи типів, інформація у Вікіпедії є низькою якістю. Не віриш.

Я переглянув це і виявив, що відповідь на ваше запитання є просто та дивно "так": академічні типи CS або, принаймні, деякі з них, використовують "нетипізовані", щоб означати "динамічно набрані". Наприклад, Мови програмування: принципи та практики , Третя редакція (Кеннет К. Луден та Кеннет А. Ламберт, опублікована 2012 р.):

Мови без систем статичного типу зазвичай називають нетипізованими мовами (або динамічно набраними мовами ). Такі мови включають схему та інші діалекти Lisp, Smalltalk та більшість мов сценаріїв, таких як Perl, Python та Ruby. Однак зауважте, що нетипізована мова не обов'язково дозволяє програмам пошкоджувати дані - це просто означає, що вся перевірка безпеки проводиться під час виконання. […]

[ посилання ] (примітка: напівжирне в оригіналі) та продовжує використовувати "нетипізований" саме таким чином.

Мені це здається дивним (майже з тих же причин, що і афришке та Адам Михалчин), але ви там є. :-)

Відредаговано, щоб додати: більше прикладів можна знайти, підключившись "untyped languages"до пошуку книг Google. Наприклад:

[…] Це основний механізм приховування інформації у багатьох нетипових мовах. Наприклад, схема PLT [4] використовує генеративні structs, […]

- Джейкоб Меттьюз та Амаль Ахмед, 2008 [ посилання ]

[…] Ми представляємо аналіз часу прив’язки для нетипової функціональної мови […]. […] Він був реалізований і використовується в частковому оцінювачі для вільного діалекту схеми, що не має побічних ефектів. Однак аналіз є загальним для того, щоб бути справедливим для не строгих типових функціональних мов, таких як Haskell. […]

- Чарльз Консель, 1990 р. [ Посилання ]

До речі, моє враження, переглянувши ці результати пошуку, полягає в тому, що якщо дослідник пише "нетипізовану" функціональну мову, він, швидше за все, вважає її "нетипізованою" в тому ж сенсі, що і нетипізована лямбда обчислення, про яке згадує Адам Михалчин. Принаймні, кілька дослідників згадують схему та обчислення лямбда на одному диханні.

Звичайно, пошук не говорить про те, чи є дослідники, які відкидають цю ідентифікацію, і не вважають ці мови "типовими". Ну, я знайшов таке:

Тоді я зрозумів, що дійсно немає циркулярності, оскільки динамічно набрані мови не є типовими мовами - це просто те, що типи зазвичай не очевидні з тексту програми.

- хтось (я не можу сказати, хто), 1998 [ посилання ]

але очевидно, що більшість людей, які відкидають цю ідентифікацію, не відчували б необхідності прямо говорити про це.

Нетипізовані та динамічно набрані - абсолютно не синоніми. Мова, яку найчастіше називають "нетипізованою", - це обчислення лямбда, що насправді є об'єднаною мовою - все є функцією, тому ми можемо статично довести, що тип усього є функцією. Динамічно набрана мова має кілька типів, але не додає компілятору можливість статично їх перевіряти, змушуючи компілятор вставляти перевірки виконання на змінні типи.

Тоді JavaScript - це динамічно набрана мова: можна писати програми в JavaScript таким чином, щоб якась змінна xмогла бути числом, або функцією, або рядком, або чимось іншим (і визначити, яка з них потребує вирішення проблеми зупинки чи якусь важка математична проблема), тому ви можете звернутися xдо аргументу, і браузер повинен перевіряти під час виконання, що xє функцією.

Обидва твердження є правильними, залежно від того, йдеться про значення чи змінні. Змінні JavaScript не типізовані, значення JavaScript мають типи, і змінні можуть коливатися в межах будь-якого типу значень під час виконання (тобто "динамічно").

У JavaScript та багатьох інших мовах переносять типи значення, а не змінні. Усі змінні можуть варіюватися за всіма типами значень і можуть вважатися "динамічно набраними" або "нетипізованими" - з точки зору перевірки типу змінна, яка не має / невідомий тип, і змінна, яка може приймати будь-який тип, є логічно і практично еквівалентною . Коли теоретики типів говорять про мови та типи, вони зазвичай говорять про це - змінні, що несуть типи, - тому що вони зацікавлені в написанні перевіряючих типів і компіляторів тощо, які працюють на тексті програми (тобто змінних), а не запущеній програмі в пам'яті (тобто значення).

На відміну від інших мов, як-от C, змінні несуть типи, але значення не мають. У таких мовах, як Java, змінні та значення обидва носять типи. У C ++ деякі значення (ті, у кого віртуальні функції) несуть типи, а інші - ні. У деяких мовах навіть значення можуть змінювати типи, хоча це зазвичай вважається поганим дизайном.

Це питання стосується семантики

Якщо я вам надам ці дані: 12 що це за тип? Ви не можете точно знати. Може бути цілим числом - може бути поплавком - може бути рядком. У цьому сенсі це дуже багато "нетипізованих" даних.

Якщо я даю вам уявну мову, яка дозволяє використовувати такі оператори, як "додавання", "віднімання" та "з'єднання" за цими даними та деякими іншими умовними фрагментами даних, "тип" дещо не має значення (для моєї уявної мови) (наприклад : можливо, add(12, a)врожайність 109, 12плюс плюс до значення asciia ).

Поговоримо С на секунду. C в значній мірі дозволяє вам робити все, що завгодно, з будь-якою довільною інформацією. Якщо ви використовуєте функцію, яка займає два uints - ви можете передавати і передавати все, що завгодно, - і значення будуть просто інтерпретуватися як uints. У цьому сенсі С є "нетиповим" (якщо ставитися до цього таким чином).

Однак - і, якщо б я сказав вам, що "Мій вік 12" - я маю 12тип - принаймні, ми знаємо, що це число. З контекстом все має тип - незалежно від мови.

Ось чому я сказав на початку - ваше питання відноситься до семантики. Яке значення "нетипізованого"? Я думаю, що Брендан вдарив цвяхом по голові, коли сказав "немає статичних типів" - тому що це все, що це може означати. Люди природно класифікують речі за типами. Ми інтуїтивно знаємо, що між автомобілем та мавпою є щось принципово інше - не навчившись ніколи робити це.

Повернення до мого прикладу на початку - мова, яка "не хвилює типи" (per se se), може дозволити вам "додати" "вік" та "ім'я", не створюючи синтаксичну помилку ... але це не означає, що це логічно обгрунтована операція.

Javascript може дозволяти вам робити всілякі шалені речі, не вважаючи їх "помилками". Це не означає, що ви робите, це логічно здорово. Це для розробника.

Чи є система / мова, яка не застосовує безпеку типу під час компіляції / складання / інтерпретації, "нетипізована" або "динамічно набрана"?

Семантика.

EDIT

Я хотів щось тут додати, тому що, здається, деякі люди потрапляють на "так, але у Javascript є деякі" типи "".

У своєму коментарі до чужої відповіді я сказав:

У Javascript я міг би мати об'єкти, які я створив, щоб бути "Мавпами", і об'єкти, які я створив, щоб бути "Людьми", а деякі функції можна було створити для роботи лише "Людей", інші - лише для "Мавп" і інші лише на "Речі зі зброєю". Незалежно від того, про яку мову ніколи не говорили, існує така категорія об'єктів, як "речі зі зброєю", так само не має значення для складання ("нетипізовані"), як і для Javascript ("динамічний"). Це все питання логічної цілісності - і єдиною помилкою було б використання чогось, у якого не було зброї з цим методом.

Отже, якщо ви вважаєте, що у Javascript є якесь "поняття про типи" внутрішньо - і, отже, "динамічні типи" - і ви думаєте, що це якимось чином "виразно відрізняється від нетипізованої системи" - ви повинні з вищенаведеного прикладу бачити, що будь-яке "поняття про типів "у неї всередині справді не має значення".

Наприклад, щоб виконати ту саму операцію з C #, наприклад, я ПОТРІБУвав інтерфейс, що викликається ICreatureWithArmsабо щось подібне. Не так у Javascript - не так у C чи ASM.

Зрозуміло, незалежно від того, чи має Javascript взагалі розуміння "типів", не має значення.

Хоча це правда, що більшість дослідників CS, які пишуть про типи, по суті, вважають лише типи мов із синтаксично-похідними типами типовими мовами, але набагато більше нас використовує динамічно / латентно набрані мови, які беруть участь у цьому використанні.

Я вважаю, що існує 3 типи [SIC] мов:

Нетипізований - лише оператор визначає інтерпретацію значення - і він взагалі працює на будь-що. Приклади: Асемблер, BCPL

Статично типізовані - вирази / змінні мають типи, пов'язані з ними, і цей тип визначає інтерпретацію / дійсність оператора під час компіляції. Приклади: C, Java, C ++, ML, Haskell

Динамічно набрані - значення мають типи, пов'язані з ними, і цей тип визначає інтерпретацію / дійсність оператора під час виконання. Приклади: LISP, схема, Smalltalk, Ruby, Python, Javascript

Наскільки мені відомо, всі мови, що динамічно набираються, є безпечними для типу - тобто лише дійсні оператори можуть працювати на значеннях. Але те ж саме не стосується мови, яка має статичний тип. Залежно від потужності використовуваної системи типу, деякі оператори можуть перевірятися лише під час виконання, або взагалі не перевірятись. Наприклад, більшість статично типових мов не обробляють належне переповнення належним чином (додавання 2-х додатних цілих чисел може призвести до від'ємного цілого числа), а посилання зв'язаного масиву або взагалі не перевіряються (C, C ++) або перевіряються лише у час виконання. Крім того, деякі системи типу настільки слабкі, що для корисного програмування потрібні вилучення люків (касти в C та сім'ї) для зміни типу виразів часу компіляції.

Все це призводить до абсурдних тверджень, наприклад, що C ++ є більш безпечним, ніж Python, тому що це (статично набрано), тоді як правда полягає в тому, що Python є справді безпечним, тоді як ви можете відстріляти ногу C ++.

Я не є вченим-комп’ютером, але був би дуже здивований, якби "нетипізовані" справді використовувались як синонім "динамічно набраних" у спільноті CS (принаймні у наукових публікаціях), оскільки ці два терміни описують різні поняття. Динамічно набрана мова має поняття типів, і вона застосовує обмеження типу під час виконання (ви не можете, наприклад, розділити ціле число на рядок у Lisp, не отримуючи помилки), тоді як нетипізована мова не має жодного поняття про типи на всі (наприклад, асемблер). Навіть стаття у Вікіпедії про мови програмування (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) робить це відмінністю.

Оновлення: Можливо, плутанина пов'язана з тим, що деякі тексти говорять про те, що "змінні не набираються" в Javascript (що правда). Але це автоматично не означає, що мова не вводиться (що було б помилково).

Погодьтеся з Бренданом - контекст - це все.

Приймаю:

Я пам’ятаю, що близько 2004 року плутався, тому що існували аргументи про те, чи була Рубі нетипізована чи динамічно набрана. Люди зі старого шкільного C + C ++ (з яких я був один) думали про компілятор і казали, що Рубі не типова.

Пам’ятайте, що в C немає типів виконання, є лише адреси, і якщо виконаний код вирішує розглядати все, що є за цією адресою, як щось таке, що не так. Це, безумовно, нетипізовано і дуже відрізняється від динамічно набраного.

У тому світі "набір тексту" - це все про компілятор. C ++ мав "сильний набір тексту", оскільки перевірки компілятора були більш жорсткими. Java та C були більш "слабко набраними" (були навіть аргументи щодо того, сильно чи слабко набрано Java). У цьому континуумі динамічні мови були "нетиповими", оскільки вони не перевіряли тип компілятора.

Сьогодні, коли ми практикуємо програмістів, ми так звикли до динамічних мов, ми, очевидно, думаємо про нетипізовані, щоб означати відсутність компілятора чи перевірки типу інтерпретатора, що було б шалено важко налагодити. Але був період, коли це не було очевидно, і в більш теоретичному світі КС це може навіть не мати сенсу.

У деякому глибокому сенсі нічого не можна типізувати (або майже нічого, все одно), тому що ви повинні мати певний намір маніпулювати значеннями, щоб написати змістовний алгоритм. Це світ теоретичного CS, який не стосується специфіки того, як компілятор чи інтерпретатор реалізується для даної мови. Тож "нетипізований" є (мабуть, не знаю) цілком безглуздим у цьому контексті.