Является ли Mathematica нетипизированным языком?

Question

В отличие от большинства языков программирования, каждое значение в Mathematica является выражением. Применение любой операции к любому выражению всегда дает другое выражение. Следовательно, Mathematica эффективно имеет только один тип. Mathematica не проверяет статический тип и, возможно, даже не проверяет типы динамически (во время выполнения).

Например, добавление целого числа выражения 1 к выражению строки "foo" в результатах Mathematica в (бессмысленных) выражениях 1 + "foo", но без ошибок. В других случаях Mathematica обеспечивает обратную связь о бессмысленном входе, но проверки, которые генерируют эту обратную связь, должны выполняться явно программистом.

Таким образом, справедливо ли описать Mathematica как нетипизированный язык, а не статически или динамически типизированный язык?

Answer 1

Короткий ответ: неттип или нетривиальный. Вот как Wolfram Research описывает сам продукт. See here.

Длинный ответ: Джон, я думаю, ваш вопрос действительно зависит от того, что вы подразумеваете под нетипизированным. Чтобы обратиться к определенному ресурсу, который является Wikipedia «Напротив, нетипизированный язык, такой как большинство языков ассемблера, позволяет выполнять любую операцию на любых данных, которые обычно считаются последовательностями бит различной длины».

Прочитав более ранние ответы, кажется, что суть дебатов заключается в том, что должно быть проверять тип, когда он сталкивается с ошибкой. Обычный ответ - это оценка STOP и сообщение о какой-то ошибке. Из нескольких более ранних вопросов (1) и (2) на Stackoverflow мы видим, что не существует изящного способа сделать это встроенным в Mathematica. (Я бы добавил оговорку, что с большим упором на компиляцию на C в версии 8 можно написать код типа проверенного кода, но я не уверен, что это следует считать частью основного языка.)

Answer 2

У Mathematica есть несколько типов, и это динамично. У вас есть типы String, Integer, Real, Complex, List и Symbol. Вы можете создавать функции, работающие только на один тип, делая что-то вроде

f[x_Integer]:=x+1

создать функцию, которая работает только с целыми числами.

Mathematica в значительной степени основана на узорах и заменах; типы всегда кажутся мне еще одним способом помочь вам разработать шаблоны. В случае с 1 + "foo" нет шаблона для оценки числа, добавленного в строку, поэтому результат - это просто выражение. В случае 1 + 2 существует шаблон для добавления чисел, и он оценивается. Модели Mathematica и правила замещения могут быть намного сложнее, и лучше всего читать книгу, если вам интересно.

Answer 3

Больше из практической, чем теоретической стороны вещей, я считаю, что вы можете сказать, что Mathematica более агматичен тип, чем нетипизированный.

Кроме того, вы можете легко построить типизированный суб-язык, используя такие вещи, как (очень простой пример следующим образом):

Unprotect[Set]; 

Set[a, x_] := If[Element[x, Integers], x, 0, 0]; 

, а затем попробовать:

a = 1; (*runs ok*) 

и

a = "caca" (*assigns zero to a*) 

Редактировать

Кроме того, вы можете создавать пользовательские типы как именованные шаблоны и использовать их в переопределении . Установите выше, вместо целых чисел.
Тип композиции должен работать таким же образом.

Answer 4

Если мы рассматриваем фразы «статически типизированные» и «динамически типизированные» как жаргон, ссылаясь на то, что язык проверяет правильность операций против типов, то я считаю справедливым характеризовать Mathematica с использованием жаргона «нетипизированный» - в том смысле, что он «никогда» не проверяет, действительна ли операция для типа.

Мне нравится использование Велизария термина «тип-агностик». Я говорю это потому, что, хотя почти вся проверка типов на языке является идиоматической (т.реализованный программистом, а не языком), так и концепция применения оператора к типизированным операндам!

Рассмотрите «бессмысленный» пример 1 + "foo". Я считаю справедливым сказать, что значительная часть (приближающаяся к единству) всех пользователей Mathematica путешествует по таким случаям, когда они впервые изучают язык. Проблема особенно очевидна, когда вы пишете код, например, в стиле C. В кругах Mathematica много дискуссий о том, как справляться с такими ситуациями.

С другой стороны, эта слабость также является самой большой силой Математики. Mathematica оптимизирован для создания новых обозначений. Многие, многие обозначения имеют понятие +, которое ведет себя очень похоже на добавление в элементарной арифметике. При построении таких обозначений было бы очень неудобно, если бы Mathematica вмешалась и пожаловалась, что операнды до + не были цифрами. В таком более высокоуровневом применении Mathematica «бессмысленный» пример не только «чувственный», но и в действительности имеет решающее значение.

Итак, имея в виду, вопрос типа часто бывает спорным. Следовательно, мне нравится Belisarius «тип-агностик». Upvote его, я сделал;)

Редактировать

Постараюсь пояснить, что я имел в виду, когда различие между «нетипизированным» и «тип-агностика».

Прочитав различные ответы и комментарии, я попытался выяснить, какая разница между Mathematica и LISP. Последнее, как правило, удерживается в качестве примера «динамически типизированного», хотя основной оценщик LISP очень похож на Mathematica с почти никакой проверкой типов. Ошибки типа, которые мы видим в программах LISP, в основном выдаются жестко запрограммированными проверками в (обычно встроенных) функциях. +, например, будет принимать только числовые аргументы, даже если сам оценщик не может заботиться о том, так или иначе. Сказав это, «чувство» программирования в LISP сильно отличается от «чувства» Mathematica (для меня, по крайней мере). Пример 1 + "foo" действительно отражает эту разницу.

Хотя я в целом согласен с «нетипизированным» как характеристикой Mathematica, я все еще чувствовал, что чего-то не хватает. Ассемблер кажется мне неотображенным, как и предыдущий FORTRAN и pre-ANSI C. В этих случаях бит-аргумент аргументов был всем, что имело значение, и программы продолжались бы беспечно, если бы я передал строковый аргумент, где было нужно целое число. Mathematica, безусловно, разделяет это нетипизированное поведение. Но есть разница: в ассемблере и FORTRAN и C это крайне редко, потому что отсутствие контроля типов приводит к хорошему результату. Как я уже упоминал выше, в Mathematica можно, а иногда и вообще полагаться на такое поведение.

Введите «тип-агностик». Мне понравилась его позиция без фиксации, звучащая менее резко, чем «нетипизированная». Я чувствовал, что это отражает принципиально нетипизированный характер Mathematica, но оставил некоторое пространство для маневра для тех языковых функций, которые легко поддерживают идиоматическую проверку типов в LISP, динамический стиль (то есть «голова» идиома и поддерживающая функциональность).

Итак, я считаю, что Mathematica наводит на то, чтобы быть полностью нетипизированным и динамически типизированным. «Тип-агностик» воспринял это настроение для меня. YMMV :)

Я с готовностью признаюсь, что никто, вероятно, не восстановит все, что я написал в этом ответе, просто проверяя фразы «нетипизированные» и «тип-агностик». Снова я подчеркиваю, что я считаю, что «нетипизированный» - это справедливая характеристика Mathematica, но мне также нравится тот факт, что «тип-агностик» задает много вопросов, на которые обращаются различные ответы на этот вопрос SO.

Answer 5

Вместо «типа», то, что Mathematica имеет это понятие «голова», где любой выражение Mathematica обладает одним. Это соответствует их "everything is an expression" paradigm.

Можно всматриваться в структуре выражения Mathematica через функцию FullForm[] и Head[]. Так, например, Head[3] возвращает IntegerHead[2/3], возвращает Rational, Head[I] возвращает Complex, Head[.3] возвращает RealHead[a], возвращает Symbol (предполагается, что вы до сих пор не назначен ничего к a), Head["a"] возвращает String, Head[{2}] возвращает List ... я уверен, вы уже поняли эту идею.

Красота заключается в том, что можно писать такие функции, что они могут принимать аргументы только с определенными головами. Например:

f[x_Real] := x^2 

f[3] 
f[3] 

f[3.] 
9. 

Это discussion на модели должны дать вам идеи о том, как настроить функции таким образом, что они работают только на объектах с особыми головками или наборы головок.