Использует ли C для реализации других языков каким-либо образом ограничивает их дизайн?

Ответ 1

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

Тем не менее, есть случаи, когда есть ограничения. Дело в том, что компилятор GHC haskell имеет perl script, называемый Evil Mangler, чтобы изменить код сборки GCC, чтобы реализовать некоторые важные оптимизаций. По этой причине они перешли на сборку внутри компании и LLVM. Тем не менее, это не ограничивает языковой дизайн - только выбор компилятора доступных оптимизаций.

Ответ 2

Я не согласен.

Я так не думаю, что в C &mdash реализован компилятор или интерпретатор языка; в конце концов, вы можете реализовать виртуальную машину с C, которая совершенно не похожа на ее хост-среду, а это означает, что вы можете уйти от менталитета языка C/near-assembly.

Однако сложнее утверждать, что сам язык C не оказал никакого влияния на дизайн более поздних языков. Возьмем, к примеру, использование фигурных скобок { } для группировки операторов в блоки, представление о том, что пробелы и отступы в основном несущественны, имена родного типа (int, char и т.д.) И другие ключевые слова или способ (т.е. объявление типа сначала, за которым следует имя переменной, необязательная инициализация). Многие из сегодняшних популярных и широко распространенных языков (С++, Java, С#, и я уверен, что их еще больше) разделяют эти понятия с C. (Вероятно, они были не совсем новыми для C, но AFAIK C придумал это конкретное сочетание синтаксиса языка.)

Ответ 3

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

Это необычно для новых языков, на которые влияет их язык реализации, если только указанный язык не содержит серьезных ограничений. Хотя я определенно не одобряю C, это не ограниченный язык, просто очень склонный к ошибкам и медленный, чтобы программировать по сравнению с более современными языками. О, кроме ЭЛТ. Например, Lua не содержит функции каталогов, поскольку он не является частью CRT, поэтому они не могут выполнять его совместимость в стандартном C. Это один из способов ограничения C. Но с точки зрения особенностей языка он не ограничен.

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

Ответ 4

C-стек - это всего лишь системный стек, и это понятие предшествует C совсем немного. Если вы изучаете теорию вычислений, вы увидите, что использование стека очень мощное.

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

Многие языки используют C как клей между ними и другими вещами. Часть этого заключается в том, что многие ОС предоставляют API C, поэтому для доступа к нему легко использовать C. Кроме того, C настолько распространен и прост, что многие другие языки имеют какой-то способ взаимодействия с ним. Если вы хотите склеить два модуля вместе, которые написаны на разных языках, тогда использование C в качестве среднего человека, вероятно, является самым простым решением.

Если реализация языка в C, вероятно, повлияла на другие языки, наиболее вероятно, что это похоже на то, как выполняются escape-последовательности в строках, что, вероятно, не ограничивает это.

Ответ 5

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

Говоря об этом, есть некоторые вещи, которые легче сделать на одном языке по сравнению с другим. Многие разработчики языка учитывают это. Если язык разрабатывается так, чтобы быть, скажем, мощным при обработке строк, но производительность не вызывает беспокойства, тогда использование языка с лучшими встроенными средствами обработки строк (например, С++) может быть более оптимальным.

Многие разработчики выбирают C по нескольким причинам. Во-первых, C - очень общий язык. Проекты с открытым исходным кодом, в частности, относительно легче найти опытного разработчика на C-языках, чем найти эквивалентно-квалифицированного разработчика на некоторых других языках. Во-вторых, C обычно поддается микро-оптимизации. При написании парсера для скриптового языка эффективность парсера оказывает большое влияние на общую производительность скриптов, написанных на этом языке. Для компилируемых языков более эффективный компилятор может сократить время компиляции. Многие компиляторы C очень хорошо подходят для создания чрезвычайно оптимизированного кода (что также является частью причины, по которой многие встроенные системы запрограммированы на языке C), а критически важный для работы код может быть записан в встроенной сборке. Кроме того, C стандартизирован и, как правило, является статической целью. Код может быть записан в стандарт ANSI/C89 и не должен беспокоиться о том, что он несовместим с будущей версией C. Изменения, внесенные в стандарт C99, добавляют функциональность, но не нарушают существующий код. Наконец, C чрезвычайно портативен. Если хотя бы один компилятор существует для данной платформы, скорее всего это компилятор C. Использование переносимого языка, такого как C, упрощает максимальное количество платформ, которые могут использовать новый язык.

Ответ 6

Единственное ограничение, которое приходит на ум, - это расширение и компилятор. Рассмотрим случай С#. Компилятор написан на C/С++ и является полностью родным кодом. Это делает его очень сложным в использовании с приложением С#.

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

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

Ответ 7

Сбор мусора. Языковые реализации поверх Java или .NET используют VM GC. Те, кто находится на вершине С, имеют тенденцию использовать подсчет ссылок.

Ответ 8

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

Если нужно написать DSL в groovy (/schem/lisp/haskell/lua/javascript/и еще кое-что, что я не уверен), функции могут стать членами первого класса. Создание функций класса первого класса и использование анонимных функций позволяет писать сжатый и более понятный для человека код (как показано LINQ).

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

Ответ 9

Реализация компилятора/интерпретатора в C не имеет серьезных ограничений. С другой стороны, реализация языка X-C компилятор делает. Например, в соответствии с статьей Википедии на C--, при компиляции языка более высокого уровня на C вы не можете делать точную сборку мусора, эффективная обработка исключений или оптимизация хвостовой рекурсии. Это та проблема, которую C-- планировал решить.