что могло бы помешать созданию универсального скриптового языка типа "Europanto"?

Question

После переключения туда и обратно между несколькими языками сценариев на этой неделе я подумал, насколько они все похожи. Тем не менее, я всегда пытаюсь, чтобы Google (или в настоящее время SO) запомнил детали, такие как локальные эквиваленты «instanceof» и «конец с», или правильный синтаксис для объявления интерфейса, или что-то еще.

Это напомнило мне о (человеческом) языке Europonto . Просто выберите какой-то смутно английский синтаксис и какой-то смутно романский / германский / славянский словарь, и все это хорошо!

Что бы произошло, если бы мы попытались сделать то же самое с языком сценариев. В настроении для блоков с отступами в стиле Python сегодня? Отлично! Хотите использовать прототип объекта? Хорошо! Можно только вспомнить, как пишутся имена PHP какой-то библиотечной функции? Нет проблем!

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

Что может быть наиболее значительным конфликтом при создании языка сценариев, который разрешает все собственные синтаксис и библиотечные функции [Python, Ruby, PHP, Perl, shell и JavaScript], так что вы можете свободно смешивать блоки кода и функции имена между языками?

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

foreach( $foo as $bar )
{
   if $foo == 2:
      print "hi"
}

но не, скажем,

foreach( $foo as $bar )
{
   if $foo == 2:
      print "hi"
   endif
end

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

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

Answer 1

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

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

Answer 2

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

На уровне API у вас было бы много разных способов сделать одно и то же, но слегка другим способом или подмножеством. Так, например, у вас не могло бы быть никакого способа выполнения string.startsWith() в Java, скажем, PHP, поэтому вы могли бы сделать что-то другое или не было бы никакого способа выполнения strstr() в PHP (который возвращает часть строки из найденной стрелки до конца ) и вы могли бы реализовать что-то другое для этого или даже по-другому думать о проблеме. Тогда вам понадобится все эти разные методы API для выполнения одних и тех же вещей, и это будет огромный API для реализации, поддержки и (не дай бог) обучения.

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

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

Answer 3

Основная трудность заключается в том, чтобы позволить людям поддерживать его. С четко определенным языком вы можете print определенным образом и sys.argv определенным образом. как только вы разрешите несколько синтаксисов, не будет нормального способа поиска всех sys.argv в вашей кодовой базе.

Answer 4

Я нашел довольно подробное обсуждение замыканий в Ruby . Похоже, что для того, чтобы поведение Руби сосуществовало с JavaScript или Python, потребовалось бы какое-то уродливое устранение неоднозначности.

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

Answer 5

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

Я пошел и прочитал статью в Википедии ...

Europanto - это лингвистическая шутка, представленная как «сконструированный язык» со словарем мешанины

"Hodge-podge" звучит так, как мне описали Perl!