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

Question

Мне было бы интересно выучить язык, который обрабатывает объекты внутри себя как хеш-таблицы (например, JavaScript), но может обернуть их сильными типами, чтобы предложить преимущества автозавершения кода / intellisense во время разработки. Вот как я хочу, чтобы язык этой мечты работал:

public class Lion
{
  public void Roar() { Console.WriteLine("Aaarrgghh");}
} 

public static Main(string[] args)
{
  object myCat = new object(); // just plain object, no type!
  // adding a Roar() method to the myCat instance 
  myCat.Roar += delegate() {Console.WriteLine("Miauew");}
  // At this point myCat should qualify to be a Lion.
  // So we should be able to successfully duck-type-cast 
  // her to a lion
  Lion myLion = myCat as Lion;
  // now the myLion reference is strongly typed, 
  // so I expect the Intellisense window pop up 
  // and offer me the Roar() method when I hit the dot after "myLion"
  myLion.Roar();
}

Я хочу, чтобы эта программа без ошибок компилировалась, работала без ошибок и печатала "Miauew" на консоли. Есть ли язык, который может это сделать? Может быть C # 4.0?

Answer 1

Может быть, новый динамический тип в C # 4.0. посмотрите на это: http://blogs.msdn.com/cburrows/archive/2008/10/27/c-dynamic.aspx

Answer 2

Каждый раз, когда я пытался спланировать что-то подобное, проблема в актерском составе. Конечно, вы можете просто поверить на слово программисту, но это сочетает в себе худшие возможности обеих систем ввода. Может быть, приведение может проверить во время выполнения, реализует ли объект интерфейс Lion, но это в принципе невозможно. В этом случае это выглядит правдоподобно, поскольку все, что вам нужно, это наличие функции void (*)(). Но в целом, что если у Lion есть метод getHabitat, который возвращает объект, который должен иметь другой интерфейс? Строго типизированный язык должен быть в состоянии точно сказать, что он действительно делает, но, фактически не вызывая метод, вы не можете вообще сказать, возвращает ли нетипизированный код Habitat, и, следовательно, в условиях строгой типизации вы не можете работать вне, будь то лев.

Так что я никогда не решал проблему, заключающуюся в том, что при смешивании фрагментов кода со слабой и сильной типизацией вы в конечном итоге получаете код со строгой типизацией, который в любой момент может вызвать метод и вернуть объект, который не реализовать интерфейс, который он должен. Это не строгая типизация, это динамическая типизация с вводящими в заблуждение комментариями кода.

Answer 3

Скорее, это зависит от того, что вы намеревались сделать, если тип Lion реализует не виртуальный метод.

Расширение типа (набор объектов, которые имеют данный тип, являются теми, которые имеют свойства типа, который близок к тому, чтобы быть статическим эквивалентом утиной типизации), требует, чтобы структура объекта подразумевала его тип, но ваш тип Льва не имеет структуры - он только говорит, что у всего, что является львом, есть тот особый метод Рев. Поэтому для вашего примера я не вижу, как вы можете сделать так, чтобы ваша кошка была Львом, поскольку она не обладает единственной структурной характеристикой, которую, как вы сказали, имеют Львы.

Если, с другой стороны, вы намеревались сказать, что все, что вы говорите, является Львом, может иметь либо собственный метод Роара, либо будет использовать метод в Льве, это ничего не говорит о типе объектов, которые являются Львами, и AFAIK может получить то же поведение с методом расширения объекта (хотя я не знаю достаточно C #, чтобы знать, переопределяют ли собственные методы методы расширения в C #).

В динамической среде IDE нет причин, по которым вам необходимо привести к Lion, прежде чем среда IDE сможет определить, что myCat имеет свойство Roar - эта информация является статически выводимой.

Причина, по которой поддержка IDE трудна в языках с динамически создаваемыми типами, таких как JavaScript, заключается в том, что вы можете сделать это:

let myCat = {}

if ( locale.name == 'en' )
    myCat.roar = function () { alert ( "Miauew" ); }
else
    mCat[ resources.getString( 'roar' ) ] = 
        function () { alert ( resources.getString ( 'Miauew' ) ); }


// the structure of the type of myCat depends what locale the code
// is running in, so you can't deduce the Intellisense
myCat.

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

Если Intellisense не может определить структуру объектов, структура которых является статически выводимой, то это слабость в Intellisense, а не в динамической типизации.

Что бы вы посчитали преимуществом строгой типизации в вашем примере?

Answer 4

Это интересная идея, и она была исследована ранее. Я свяжусь с некоторыми исследованиями и существующей работой, после того, как дам вам свое мнение Я буду говорить о языках сценариев и статических императивных языках, так как я думаю, что это то, о чем вы говорите.

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

Статические типы в динамических языках

Проблема возникает, когда вы смотрите на то, как объекты используются в языках сценариев - все они имеют утку. Это означает, что имя типа ( nominal-typing ) не полезно. Все современные императивные языки (Java, C #, C ++, C) используют системы номинальных типов. Так что в C ++ вы можете сказать, что ожидаете Duck, но в Python вы действительно хотите что-то, что идет quack().

Так что рассмотрите возможность добавления статической типизации к языку с утиной типизацией. Так как функция выставит параметр в значение quack(), но не может сказать, что ожидает значение Duck, объединить их сложно. Вы можете определить интерфейс с именем quacks, который может quack(), и использовать его в качестве типа. Но на самом деле это немного многословно, что убивает преимущества динамической типизации. Возможно, что-то в этом роде (какая-то система структурных типов ) может это сделать.

В качестве альтернативы можно было бы просто потребовать от программиста указать Duck, и в любом случае, черт побери, это дело типизации утки - никто его не использует, не так ли? Но тогда вы просто пишете Java на Python, и как человек, который однажды попробовал это, позвольте мне сказать вам, что это очень контрпродуктивно.

Динамические типы в статических языках

Итак, давайте посмотрим на это с другой стороны. Какую выгоду получит C # от ключевого слова dynamic? Простой ответ - это не так. Честно говоря, я не вижу никакой красоты и свободы, которые вы получаете от Python в C # dynamic. Теперь, единственное, что я знаю об этом, происходит из выступления Джона Скита, но у меня сложилось потрясающее впечатление, что он многословен и не элегантен. И я думаю, что это не ошибка реализации из C # народа. Я думаю, потому что проблемы, которые решает динамическая типизация в Python, уже решены в C # (хотя и многословно), и dynamic просто ничего не приносит участнику.

Исследования статических / динамических материалов

Посмотрите Постепенный набросок Джереми Сика , о самых продвинутых статических и динамических исследованиях. Хотя это немного трудно читать, и я сам лишь сделал это поверхностно, поэтому я не могу подвести итог. Тем не менее, интересно пролистать только его связанные работы, и конференция STOP , вероятно, будет иметь хорошие вещи.

Answer 5

Не тесно связано с вашим примером, но неявное преобразование в Scala - это хорошо продуманный (хотя иногда и трудный для понимания) механизм для расширения функциональности класса полностью контролируемым, статически проверенным способом.

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