Почему интерпретируемые langs главным образом ducktyped, в то время как скомпилировано имеют строгий контроль типов?

То, что вы попробовали, почти правильно, но вам также нужно вернуть новый файл data.frame, а также сохранить его в вашей существующей переменной:

ChangeType <- function(DF){

 DF[,2] <- as.factor(DF[,2])
 DF[, "ResultAssay"] <- as.numeric(DF[, c("ResultAssay")]
 DF #return the data.frame 
}

# store the returned value to df.list, 
# thus updating your existing data.frame
df.list <- lapply(df.list, ChangeType) 
43
задан ShreevatsaR 26 December 2008 в 17:44
поделиться

9 ответов

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

Примеры:

  • Схема языка программирования с динамическим контролем типов (иначе введенный уткой), и она имеет много десятков интерпретируемых реализаций, но также и некоторые прекрасные компиляторы собственного кода включая Воровство, Гамбит и Схему PLT (который включает и интерпретатор и JIT-компилятор, делающий бесшовные переходы).

  • язык программирования Haskell со статическим контролем типов; две самых известных реализации являются HUGS интерпретатора и компилятором GHC. Существует несколько других благородных разделений реализаций о равномерно между компиляцией в собственный код (yhc) и интерпретацией (Гелий).

  • ML Стандарта языка программирования со статическим контролем типов, и он имел много компиляторов собственного кода, из которых один из лучших и наиболее активно сохраняемый MLton, но одна из самых полезных реализаций является интерпретатором ML

  • Москвы Цель языка программирования, Caml со статическим контролем типов. Это идет только с одной реализацией (от INRIA во Франции), но эта реализация включает и интерпретатор и компилятор собственного кода.

  • язык программирования Паскаль со статическим контролем типов, но это стало популярным в 1970-х из-за превосходной реализации, созданной в UCSD, который был основан на интерпретаторе Псевдокода. В более поздних годах прекрасные компиляторы собственного кода стали доступными, такие как компилятор Паскаля/VS IBM для 370 серий компьютеров.

  • язык программирования C со статическим контролем типов, и сегодня почти все реализации компилируются, но в тех 1980-х из нас удачный использовать Саблю C использовали интерпретатор.

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

  • Много новых языков определяются реализацией. Легче создать интерпретатор, чем создать компилятор. Легче проверить типы динамично, чем проверить их статически. И если Вы пишете интерпретатор, существует мало выигрыша в производительности к статической проверке типа.

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

  • На некоторых интерпретируемых языках, много фундаментальных операций являются столь дорогими, что дополнительные издержки проверки типов во время выполнения не имеют значения. А хорошим примером является PostScript: если Вы соберетесь убежать и растеризировать Кривые Безье без колебаний, Вы не передумаете относительно проверки тега типа здесь или там.

Кстати, опасаться условий "сильный" и "слабый" ввод , потому что у них нет универсально согласованного технического значения. В отличие от этого, статический контроль типов средства, что программы проверены прежде чем быть выполняемым , и программа, могли бы быть отклонены, прежде чем это запустится. Динамический контроль типов средства, что типы [1 152] значения проверяются во время выполнение , и плохо введенная операция, могли бы заставить программу останавливаться, или иначе сигнализируют об ошибке во время выполнения . Основная причина статического контроля типов должна исключить программы, которые могли бы иметь такие "динамические ошибки типа". (Это - другая причина люди, которые пишут, что интерпретаторы часто меньше интересуются статическим контролем типов; выполнение сразу происходит после проверки типа, таким образом, различие и природа гарантии не так очевидны.)

Строгий контроль типов обычно средства, что существует никакие лазейки в системе типов, тогда как слабый контроль типов означает, система типов может ниспровергаться (делающий недействительным любые гарантии). Термины часто используются неправильно для значения статического контроля типов и динамического контроля типов. Для наблюдения различия думайте о C: язык проверяется в типе во время компиляции (статический контроль типов), но существует много лазеек; можно в значительной степени бросить значение любого типа к другому типу того же размера---, в частности, можно бросить типы указателей свободно. Паскаль был языком, который был предназначен, чтобы быть со строгим контролем типов, но заметно имел непредвиденную лазейку: различная запись без тега.

Реализации языков со строгим контролем типов часто получают лазейки со временем, обычно так, чтобы часть системы во время выполнения могла быть реализована на высокоуровневом языке. Например, Объективный Caml имеет функцию, вызванную Obj.magic, который имеет эффект во время выполнения простого возврата его аргумента, но во время компиляции это преобразовывает значение любого типа к одному из любого другого типа. Моим любимым примером является Modula-3, разработчики которого назвали свою конструкцию преобразования типа LOOPHOLE.

, Таким образом:

  • Статичный по сравнению с динамическим язык .

  • Скомпилированный по сравнению с интерпретируемым реализация .

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

198
ответ дан a.lasram 23 September 2019 в 11:58
поделиться

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

Однако с поздним связыванием, необходимо пойти, ища метод, который походит на метод что клиентский названный код. И конечно, со многими, многими вызовами метода в программе, это - то, что делает динамические языки 'медленными'.

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

9
ответ дан Sam Rad 23 September 2019 в 11:58
поделиться

Это в значительной степени, потому что люди, которые пишут и используют интерпретируемые языки, склонны предпочитать ducktyping, и люди, которые разрабатывают и используют скомпилированные языки, предпочитают сильную явную типизацию. (Я думаю, что причина согласия этого была бы где-нибудь в области 90% для ошибочного предотвращения и 10% для производительности.) Для большинства программ, записанных сегодня, различие в скорости было бы незначительно. Microsoft Word работал на псевдокоде (нескомпилированном) для - что - 15 лет теперь?

лучший рассматриваемый вопрос я могу думать. Классический Visual Basic (VB6/VBA/etc). Та же программа могла быть записана в VB и выполнении с идентичными результатами и сопоставимой скоростью, или скомпилированной или интерпретируемой. Кроме того, у Вас есть опция описаний типа (на самом деле объявления переменной) или нет. Большинство людей предпочло описания типа, обычно для ошибочного предотвращения. Я никогда не слышал или читал где угодно для использования описаний типа для скорости. И это возвращается, по крайней мере, до двух полномочий величины в аппаратной скорости и способности.

Google привлекает большое внимание в последнее время из-за их работы над JIT-компилятором для JavaScript - который не потребует никаких изменений в языке или потребует любого дополнительного соображения со стороны программиста. В этом случае единственное преимущество будет скоростью.

4
ответ дан dkretz 23 September 2019 в 11:58
поделиться

Существует в основном две причины использовать статический контроль типов по утиному вводу:

  1. Статическая проверка ошибок.
  2. Производительность

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

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

  1. Шаблоны. В этом случае, если тип Вы инстанцируете своего шаблона с поддержками все методы, названные из шаблона, Ваших компиляций кода и работ. Иначе это дает ошибку времени компиляции. Это - вид подобного утиного ввода времени компиляции.
  2. Отражение. Вы пытаетесь вызвать метод по имени, и он или работает или выдает исключение.
  3. Размеченные объединения. Это в основном контейнерные классы для других типов, которые содержат некоторое пространство памяти и поле, описывающее тип, в настоящее время содержавшийся. Они используются для вещей как алгебраические типы. То, когда метод вызывается, это или работает или бросает, в зависимости от того, содержал ли тип в настоящее время, поддерживает его.

Это объясняет, почему существует немного скомпилированных языков с динамическим контролем типов.

2
ответ дан dsimcha 23 September 2019 в 11:58
поделиться

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

2
ответ дан Steven A. Lowe 23 September 2019 в 11:58
поделиться

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

, Когда Вы видите что-то как:

int a

в C++, компилятор выкладывает код, который резервирует четыре байта памяти и затем присваивает локальный символ "a" для указания на ту память. Если у Вас был язык сценариев без типов как JavaScript, интерпретатор, негласно, выделяет требуемую память. Можно сделать:

var a = 10;  // a is probably a four byte int here
a = "hello world"; // now a is a 12 byte char array

существует много, который происходит между теми двумя строками. Интерпретатор удаляет память в a, выделяет новый буфер для символов, затем присваивает var для указания на ту новую память. На языке со строгим контролем типов нет никакого интерпретатора, который управляет этим для Вас, и таким образом компилятор должен записать инструкции, которые принимают во внимание тип.

int a = 10; // we now have four bytes on the stack.
a = "hello world"; // wtf? we cant push 12 bytes into a four byte variable! Throw an error!

Так компиляторы мешает тому коду компилировать так ЦП dosn't, вслепую пишут 12 байтов в четырехбайтовый буфер и вызывают страдание.

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

:)

РЕДАКТИРОВАНИЕ-nelson

в ответ на комментарий

я не знаю много о Python, таким образом, я не могу сказать многое об этом. Но свободно typedness значительно замедляет время выполнения. Каждая инструкция, что интерпретатор (VM) вызовы должен оценить, и при необходимости, принуждает var в ожидаемый тип. Если Вы имеете:

mov a, 10
mov b, "34"
div a, b

Затем интерпретатор должен удостовериться, что переменной и числа, затем должен был бы принудить b в число прежде, чем обработать инструкцию. Добавьте, что наверху для каждой инструкции, что VM выполняется и у Вас есть путаница на Ваших руках :)

3
ответ дан 23 September 2019 в 11:58
поделиться

Языки со слабым контролем типов могут быть скомпилированы, например, Perl5 и большинство версий Lisp являются скомпилированными языками. Однако выигрыши в производительности компиляции часто теряются, потому что большая часть работы, которую должно выполнить время выполнения языка, относится к определению, что вводит динамическую переменную, действительно имеет в определенное время.

Берут, например, следующий код в Perl:

$x=1;
$x="hello";
print $x;

для компилятора очевидно довольно трудно определить то, что $x типа действительно имеет в определенный момент времени. Во время оператора печати работа должна быть сделана для понимания этого. На статически типизированном языке тип полностью известен так, производительность на времени выполнения может быть увеличена.

1
ответ дан 1800 INFORMATION 23 September 2019 в 11:58
поделиться

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

Время от времени, существует путь больше в игре, чем просто ввод. Возьмите ActionScript, например. 3.0 представил более сильный ввод, но с другой стороны ECMAScript позволяет Вам изменить классы, поскольку Вы считаете целесообразным во времени выполнения, и ActionScript имеет поддержку динамических классов. Очень аккуратный, но факт они заявляют, что динамические классы не должны использоваться в "стандартных" средствах сборок, которые это нет - нет для того, когда необходимо избежать рискованных действий.

0
ответ дан Filip Dupanović 23 September 2019 в 11:58
поделиться

Предположение:

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

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

0
ответ дан Paul Tomblin 23 September 2019 в 11:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: