LINUX.ORG.RU

Доказана невозможность статического парсинга Perl 5

 , неразрешимость, ,


0

0

Формально доказана неразрешимость задачи статического синтаксического анализа Perl 5. В опубликованном доказательстве задача парсинга программы на Perl сводится к задаче остановки, которая, как известно любому школьнику, неразрешима.

Этот факт имеет важное практическое значение — он означает что в общем случае выяснить, что будет делать та или иная программа на Perl, возможно только выполнив саму программу. Методы статического анализа бессильны. Возникают ли подобые проблемы в Perl 6 — неизвестно.

Статьи (pdf): [1], [2], [3].

>>> Подробности

Погодите-ка, чё-то я затупил... :)) а наличие конструкции

eval $some_code_string;

и наличие возможности сформировать эту самую $some_code_string динамически разве не доказывает исходный тезис в одну строку, а не в три умных статьи?

Это ж типичный самомодифицирующийся код... Какой уж тут статический парсинг...

gns ★★★★★
()
Ответ на: комментарий от Again

>> что Перл выучить несколько проще, чем тот же Питон

>Наглое враньё (пользуюсь обоими, Питоном сейчас больше).

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

Gukl ★★★
()
Ответ на: комментарий от JackYF

>Не я, а интерпретатор. До парсинга всех не-BEGIN/INIT блоков. Так яснее?

Ты хоть понимаешь какую мистическую чушь несешь?

=======mystic.pl=========
sub mystic {
print shift
}

BEGIN {
mystic "ogogo mystca\n"
}

mystic "ohrenet'\n"
=========================


> perl -c mystic.pl

ogogo mystca
mystic.pl syntax OK

> perl mystic.pl

ogogo mystca
ohrenet'

Мистика да?

PS: Мля - я даже на перле не пишу, но для меня очевидно, что черной магии там нет и чтобы функция в бегине исполнился - она должна как минимум откомпилиться раньше.

r ★★★★★
()
Ответ на: комментарий от JackYF

> Деревня. Уборка урожая. Люди-перловщики неспеша работают. Подходит питоновец.

Это потому, что он уже закончил работу %)

> Питоновец с грустью ещё немного понаблюдал за людьми, которые его больше не слушали

Почему с грустью-то? %)

P.S. это троллинг, не воспринимай всерьез.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Почему с грустью-то? %)

Ну как - птичек жалко. Он пошел пиво пить грусный и одинокий - а перлопроходцы все еще гнули спину на полях... :)

r ★★★★★
()
Ответ на: комментарий от r

Что такое print shift?

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

Xenius ★★★★★
()
Ответ на: комментарий от Xenius

>Кстати, а если есть машина, которая имеет бесконечную тактовую частоту...

Для нее нет времени(время - это мера процессов), и нельзя отмерить 1 мс.

roller ★★★
()
Ответ на: комментарий от r

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

вот же ж... два/три поста назад я писал "блок BEGIN _компилируется_ и исполняется", так нет же ж, у кого-то проблемы то ли с вниманием, то ли со зрением...

JackYF ★★★★
()
Ответ на: комментарий от yk4ever

>Поэтому его крайне неудобно использовать в командах из более чем одного человека.

Ну таки скриптовый язык ;) для своего круга задач. Есть например такая удобная штуковина как переменная $_
Для прототипов ИМХО Питон удобнее так как ближе к классическим языкам по синтаксису.
Для мартышкокодинга есть жаба. Все счастливы.

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от roller

Таки есть прерывания по сигналу таймера

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от anonizmus

> yk4ever, вот от тебя и твоих красноглазых братьев каждый год одно и то-же, неужели не надоело ?

Почему красноглазых? Мы ж не перлисты :]

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

yk4ever
()

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

iZEN ★★★★★
()
Ответ на: комментарий от sun

> А где вы видели чтобы стандарт кодинга шел в самом языке программирования?

"There should be one-- and preferably only one --obvious way to do it." (c) Tim Peters

> Может ещё там написано как переменные называть?

http://www.python.org/dev/peps/pep-0008/

> Я каждый год через свои руки пропускаю по 3-4 web-программера, так вот знаете что я скажу... нормальные программеры себя никогда так не назовут

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

yk4ever
()
Ответ на: комментарий от Gukl

> Ну так считание пробелов отнимает немало энергии,

Считание пробелов - это классический FUD, типа микрософтовского get the facts. У меня никогда в питоне не было проблем с отступами. А вот потерявшуюся при рефакторинге скобку в {}-языках приходится искать частенько.

> А выучить Перл таки проще.

О, ну конечно. Каждый оператор ведёт себя несколькими разными способами, в зависимости от погоды в Занзибаре. Хрен ли там учить.

Читайте лучше Стива Егге, он умные вещи говорит, когда выжрет:

http://steve.yegge.googlepages.com/ancient-languages-perl

yk4ever
()
Ответ на: комментарий от DNA_Seq

> Ну таки скриптовый язык ;) для своего круга задач.

Простые скрипты надо переводить на bash, сложные - на python/ruby.

yk4ever
()
Ответ на: комментарий от yk4ever

>Простые скрипты надо переводить на bash, сложные - на python/ruby.

Да, вроде бы никто и не мешает?! Переводите...

ddt
()
Ответ на: комментарий от yk4ever

>по причине тотального отсоса у питона и руби

жж0шь, пеши исчо !! %-)))

anonizmus
()
Ответ на: комментарий от r

>>Так что, мы тут выясняем, что "перл плохой" потому что для него нельзя написать редактор с подсветкой синтаксиса для программеров, которые ничего не знают о хорошем стиле программирования?

> Нет - мы тут выясняем что он не поддается статическому анализу. Какие буквы непонятны?

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

name_no ★★
()

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

winger
()
Ответ на: комментарий от name_no

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

Ты по ходу вобще не понимаешь о чем говоришь. При чем тут тьюринг-полнота?

r ★★★★★
()
Ответ на: комментарий от JackYF

> так нет же ж, у кого-то проблемы то ли с вниманием, то ли со зрением...

Ты что не видишь что функция mystic определена _вне_ блока BEGIN? Что ты там говорил про зрение?

r ★★★★★
()
Ответ на: комментарий от r

Задача останова - определить, остановится ли заданная на входе машина Тьюринга на заданном на входе наборе данных. Если мы для любой программы на тьюринг-полном языке X умеем определять, останавливается ли она, то мы умеем решать и задачу останова. А она, как известно, не разрешима в рамках модели машин Тьюринга.

winger
()
Ответ на: комментарий от yk4ever

>А вот потерявшуюся при рефакторинге скобку в {}-языках приходится искать частенько.

Потерявшийся пробел (который не видно, ибо на то он и пробел) найти, конечно же, проще в сто раз.

>Каждый оператор ведёт себя несколькими разными способами, в зависимости от погоды в Занзибаре. Хрен ли там учить.

Гет зе фактс типичнейший :) Вы не поверите, операторы зависят от контекста во всех языках, включая Питон. Признайтесь, наконец, что ваша нелюбовь к Перлу иррациональна, легче будет.

Gukl ★★★
()
Ответ на: комментарий от r

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

> Ты по ходу вобще не понимаешь о чем говоришь. При чем тут тьюринг-полнота?

Ты вот скажи, мне тоже достаточно такую ахинею в обсуждении новостей пороть, чтоб 4-5 звёзд заработать, или надо всё-таки иногда что-то полезное постить? Ты всё это время вот в таком стиле новости комментишь или было что-то осмысленное?

name_no ★★
()
Ответ на: комментарий от Gukl

> Потерявшийся пробел (который не видно, ибо на то он и пробел) найти, конечно же, проще в сто раз.

Вот по таким фразам и вычисляются те, кто о Питоне только слышал.

tailgunner ★★★★★
()
Ответ на: комментарий от Gukl

>Гет зе фактс типичнейший :) Вы не поверите, операторы зависят от контекста во всех языках, включая Питон. Признайтесь, наконец, что ваша нелюбовь к Перлу иррациональна, легче будет.

а что скажите про 24 уровня приоритетов операций? или 16 операторов присваивания?

stave ★★★★★
()
Ответ на: комментарий от r

>> так нет же ж, у кого-то проблемы то ли с вниманием, то ли со зрением...

>Ты что не видишь что функция mystic определена _вне_ блока BEGIN? Что ты там говорил про зрение?


Что характерно, ты квотишь мои предложения частями уже второй раз (это конечно, не возбраняется, но в данном случае важные части, образующие мысль, ты выкинул). Потрудись читать мои ответы полностью. Твоя полная фраза была ложна, в моей полной фразе было дано объяснение, почему. Я, что опять-же таки характерно, про переменную mystic вообще ничего не говорил, к ней у меня претензий нет. Ещё вопросы будут?

JackYF ★★★★
()
Ответ на: комментарий от stave

>>Гет зе фактс типичнейший :) Вы не поверите, операторы зависят от контекста во всех языках, включая Питон. Признайтесь, наконец, что ваша нелюбовь к Перлу иррациональна, легче будет.

> а что скажите про 24 уровня приоритетов операций? или 16 операторов присваивания?

Мне очень интересно, правда, не ради спора или троллинга, перечислить можете? Я про 16 операторов присваивания.

Про 24 уровня: в перле порядок взят из C, это известно всем:

> Perl operators have the following associativity and precedence, listed from highest precedence to lowest. Operators borrowed from C keep the same precedence relationship with each other, even where C's precedence is slightly screwy.

> http://search.cpan.org/~nwclark/perl-5.8.7/pod/perlop.pod

name_no ★★
()
Ответ на: комментарий от name_no

>Мне очень интересно, правда, не ради спора или троллинга, перечислить можете? Я про 16 операторов присваивания.

+= -= *= /= %= **= &= |= ^= <<= >>= &&= ||= .= x=

>Про 24 уровня: в перле порядок взят из C, это известно всем:

вы ошибаетесь, в С их 15

stave ★★★★★
()
Ответ на: комментарий от JackYF

>Потрудись читать мои ответы полностью

Я читаю их полностью.

>Ещё вопросы будут?


Да - расскажи как вот эта твоя фраза:

>Я, что опять-же таки характерно, про переменную mystic вообще ничего не говорил, к ней у меня претензий нет.


Сочетается с вот этой:

>Блок BEGIN выполняется, компилируется и исполняется до парсинга программы.


И вот этой:

>До парсинга всех не-BEGIN/INIT блоков. Так яснее?


Учитывая что mystic определен вне блока BEGIN, а следовательно относится к той программе которая у тебя "до парсинга" в первой фразе и "не-BEGIN/INIT" относительно второй фразы.

Или можешь объяснить свой юмор вот в этой фразе:

>О жесть. И кто же его определяет и когда?


на фоне вот этой фразы из мана:

>A "BEGIN" code block is executed _as soon as possible_, that is, the moment it is _completely defined_


r ★★★★★
()
Ответ на: комментарий от chorny

> sub x{}; x / 25 ; # / ; die 'not comment' gedit вполне себе статически это обрабатывает.

unname
()
Ответ на: комментарий от sun

> А где вы видели чтобы стандарт кодинга шел в самом языке программирования?

Много где. А что?

sv75 ★★★★★
()
Ответ на: комментарий от Gukl

> Потерявшийся пробел (который не видно, ибо на то он и пробел)

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

> найти, конечно же, проще в сто раз.

Вам о неправильных отступах скажет интерпретатор при парсинге :]

Вы эта, не говорите ерунды, а попробуйте реально питоном попользоваться. Бреда в голове поубавится авось.

> Вы не поверите, операторы зависят от контекста во всех языках, включая Питон.

А вложенные списки в линейный разворачиваются тоже во всех языках, м?

А вот я вам ссылочку давал на блог Стива Егге, там про Range Operator как раз писалось. Такой бред ещё в каком-то языке есть, а?

yk4ever
()
Ответ на: комментарий от r

>Блок BEGIN выполняется, компилируется и исполняется до парсинга программы.
>A "BEGIN" code block is executed _as soon as possible_, that is, the moment it is _completely defined_


Жесть. Да, в этом вопросе я оказался не прав. Приношу свои извинения.

Тогда перефразирую.

Блок BEGIN компилируется и исполняется до исполнения основной программы. Эти действия входят в процесс "компиляция основной программы". И, что оказалось для меня небольшой новостью, в ряде случаев интерпретатору для этого потребуется также распарсить/исполнить часть основной программы.

JackYF ★★★★
()
Ответ на: комментарий от JackYF

> И, что оказалось для меня небольшой новостью,

Перл он весь состоит из таких новостей. Каждый день - интересный сюрприз! Весело на нём кодить, ага.

yk4ever
()
Ответ на: комментарий от Gukl

> Гет зе фактс типичнейший :) Вы не поверите, операторы зависят от контекста во всех языках, включая Питон. Признайтесь, наконец, что ваша нелюбовь к Перлу иррациональна, легче будет.

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

Hjorn
()
Ответ на: комментарий от yk4ever

>Перл он весь состоит из таких новостей. Каждый день - интересный сюрприз! Весело на нём кодить, ага.

Точно. Весело, и, что важно, продуктивно.

А вышеуказанное поведение, тролль, я не видел ни в одной реальной программе.

В плюсах вон тоже триграфы есть. Какой процент людей про них вообще слышало? А использовало? А почему? Да потому что нафиг не надо. Хотя можно. Так и здесь.

JackYF ★★★★
()
Ответ на: комментарий от Hjorn

> Иррациональна скорее любовь к Перлу. Никакими практическими соображениями её не объяснить.

Огромная база существующих модулей кода. Питону/руби такое пока не снилось.

TweedleDee
()
Ответ на: комментарий от yk4ever

> Посмотрите графики TPCI.

Про TIOBE давно известно что оно не отражает реальную картину. Особенно если посмотреть на JavaScript. До них просто не доходит что словосочетание "Perl programming" в силу традиции используется редко. Если же использовать большее количество сочетаний - получаются совсем другие числа. Для Perl, в отличие от других языков, никто не занимается оптимизацией сайтов под TIOBE.

> Имею заметить, что PyPI по объёму трафика уже почти не уступает. И он будет расти, а перл будет падать

Все ждут что количество закачек на CPAN будет падать, а оно все растет и растет :). Новый рекорд - 1000 с чем-то новых дистрибутивов в месяц. И cpantesters пока еще никто не повторил.

chorny
()
Ответ на: комментарий от Gukl

> А выучить Перл таки проще.

Начать на нём кодить может и проще. Перл очень прост (и даже логичен) до тех пор пока не нужны структуры данных сложнее плоских списков, модули, объекты, рефлексия и прочие программистские плюшки. А потом начинаются проблемы. Перл плохо масштабируется, вот в чём беда. Он для этого не был изначально предназначен. "Простые задачи решаются просто, а сложные... как нибудь да решаются" (перефразируя Ларри).

Hjorn
()
Ответ на: комментарий от JackYF

> В плюсах вон тоже триграфы есть.

[зевает] не в плюсах, а в сях

> Да потому что нафиг не надо. Хотя можно. Так и здесь.

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

yk4ever
()
Ответ на: комментарий от TweedleDee

> Огромная база существующих модулей кода. Питону/руби такое пока не снилось.

Можете привести хоть три примера вида "есть для перла, нет для питона"?

yk4ever
()
Ответ на: комментарий от chorny

> Про TIOBE давно известно что оно не отражает реальную картину.

Дык отношения между языками хрен с ними. А вот динамика по одному языку...

yk4ever
()
Ответ на: комментарий от TweedleDee

> Огромная база существующих модулей кода. Питону/руби такое пока не снилось.

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

Hjorn
()

А мужики то не знают :)

zf8
()
Ответ на: комментарий от Xenius

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

Посыл неверный. Откуда взялась цифра "одна миллисекунда"? С потолка, надо полагать. А она, между прочим, вычисляется.

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

anonymous4
()
Ответ на: комментарий от yk4ever

>попробуйте реально питоном попользоваться

Ключевое слово "реально". Вот мне как-то раз и пришлось править питоноскрипт по ssh на хосте, где даже vi не нашлось.

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

>А вложенные списки в линейный разворачиваются тоже во всех языках, м?

Лично я этим часто пользуюсь. А когда не пользуюсь, тыкаю такую вот штучку: \ Не знали? Тогда, может, сначала поучить, а потом, может, и критиковать не захочется?

>Такой бред ещё в каком-то языке есть, а?

Перл тем и хорош, что что не нужно, можно не использовать.

Gukl ★★★
()
Ответ на: комментарий от Hjorn

>о тех пор пока не нужны структуры данных сложнее плоских списков, модули, объекты, рефлексия и прочие программистские плюшки

Это сложно только по контрасту с простотой решения в Перле простых задач.

Gukl ★★★
()
Ответ на: комментарий от Gukl

>Вот мне как-то раз и пришлось править питоноскрипт по ssh на хосте, где даже vi не нашлось.

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

>Питон "неральный" язык, построенный вокруг одной-двух умозрительных концепций

Сами концепции в студию, или это пустословие?

>будете считать однозначность синтаксиса хорошим делом

Однозначность синтаксиса -- хорошее дело, как бы грустно перлофагам по этому поводу не было.

anonymous4
()
Ответ на: комментарий от stave

> а что скажите про 24 уровня приоритетов операций? или 16 операторов присваивания?

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

А что вы скажете про неявную перегрузку оператора + в JS? ;)

Gukl ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.