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

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

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

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

Ответ 1

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

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

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

Ответ 2

Вместо "типа", что Mathematica имеет понятие "голова", где любое выражение Mathematica обладает одним. Это соответствует их "все это выражение" парадигма.

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

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

f[x_Real] := x^2

f[3]
f[3]

f[3.]
9.

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

Ответ 3

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

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

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

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

Итак, имея в виду, вопрос о типе часто бывает спорным. Следовательно, мне нравится Велизарий "тип-агностик" . Поднимите его, я сделал;)

Edit

Я попытаюсь разъяснить, что я имел в виду, когда различал "нетипизированный" и "тип-агностик" .

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

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

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

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

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

Ответ 4

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

f[x_Integer]:=x+1

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

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

Ответ 5

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

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

Unprotect[Set]; 

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

а затем попробуйте:

a = 1; (*runs ok*) 

и

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

Изменить

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