В соответствии с http://rsdn.org/forum/flame.comp/6616369.flat

Автор: кт
Дата: 21.11.16

выкладываю восьмую, последнюю статью, не попавшую в уже исчезнувший журнал RSDN Magazine.
Правда, осталась еще одна статья, но автор попросил подождать ее выкладывать: он нашел издание, куда пробует с ней толкнуться.
Так, что все свободны, всем спасибо
Даже тем, кто просматривал статьи под девизом: «Кто писал не знаю, а я, дурак, читаю» (А.Чехов «Жалобная книга»)
По обсуждениям статей, правда, удалось достичь консенсуса только по регистру SPL: нет несогласных с тем, что он на фиг не нужен

Сама статья, написана почти два года назад:
http://files.rsdn.org/122727/pl1ex19.doc

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

Здравствуйте, кт, Вы писали:

кт>По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят.
кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.

Почему сразу лох? Делать специальные операторы для таких мелочей — ненужное усложнение языка. Делать препроцессор — серьёзное решение, которое потом может сильно аукнуться, у большинства современных языков препроцессоров нет.

Собственно какие языки вообще имеют такую возможность? Я вот ни одного такого языка не знаю. Только C/C++ за счёт препроцессора.

Так-то я согласен, удобно. Но можно много таких удобств придумать. Мне вот в Java не хватает захвата значений всех локальных переменных в Exception в каждом фрейме (и потом распечатывание их). Насколько проще была бы отладка.

Здравствуйте, vsb, Вы писали:

vsb>Собственно какие языки вообще имеют такую возможность? Я вот ни одного такого языка не знаю. Только C/C++ за счёт препроцессора.
Вот все и лохи Шучу, шучу. Просто в стародавние времена, когда не было интерактивных отладчиков и IDE с "распахиванием структур" больше внимания уделялось удобству вывода при отладке.
Ведь вывод с именами это действительно мелочь, но экономящая время. И нервные клетки.

vsb>Так-то я согласен, удобно. Но можно много таких удобств придумать. Мне вот в Java не хватает захвата значений всех локальных переменных в Exception в каждом фрейме (и потом распечатывание их). Насколько проще была бы отладка.
Да, и в Яве ведь стандартный вывод довольно развитой. Но почему-то опыт старых языков отвергли

Здравствуйте, кт, Вы писали:

кт>Сама статья, написана почти два года назад:
кт>http://files.rsdn.org/122727/pl1ex19.doc
IMO в интерактивном отладчике такая фича просто не нужна.
В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику.
Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора.
Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.

Здравствуйте, vmpire, Вы писали:

V>IMO в интерактивном отладчике такая фича просто не нужна.
V>В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику.
V>Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
Речь идет в основном об отладочных выводах. Если у меня массив S из 10 строк, что я должен увидеть? 10 раз "unparsed string:" или S(1)=.. S(2)=...
в первом случае толку от такого вывода мало и легко ошибиться при анализе.

V>Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
Это я вообще не понял. Если меняются даже названия переменных, зачем читать старые логи?

V>Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора.
V>Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
Описанная доработка потребовалась автору для приведения компилятора к стандарту языка. В языке это было предусмотрено.

V>Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.
Вольному — воля. Описанная возможность встроена в язык и ляпать ничего уже не надо.

Здравствуйте, кт, Вы писали:

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

На самом деле™, никто в логи просто так что попало не выводит. Нормальные логи имеют определенную структуру записи. Например: дата и время записи, ID текущего thread-а. Определенные требования могут предъявляться и к выводимым данным. Простой PUT DATA такое не потянет. Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов. Тем более, что на них часто приходится натравливать всякие парсеры, которые могут упасть на непонятных записях.

Здравствуйте, Privalov, Вы писали:

P>Простой PUT DATA такое не потянет.
Да он, собственно, никогда и не претендовал. Всеобъемлющего оператора вывода до сих пор нет

P>Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
Это да, лучше бы сделали PUT EDIT DATA

P>Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов.
[испуганно] А где я нарушил? Кстати, что такое "единый формат логов"? ГОСТ что-ли ввели? Вот сволочи, людей им не жалко...

Здравствуйте, кт, Вы писали:

P>>Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
кт>Это да, лучше бы сделали PUT EDIT DATA

А еще лучше, как сейчас. Когда весь ввод-вывод вынесен в библиотеки. Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.

P>>Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов.
кт>[испуганно] А где я нарушил? Кстати, что такое "единый формат логов"? ГОСТ что-ли ввели? Вот сволочи, людей им не жалко...

ГОСТ не ввели, не надо пугаться. Но в любой нормальной программной системе логи имеют определенный формат. И нарушать его не стоит. Просто потому, что можно не найти требуемую запись. С учетом использования автоматиированных анализаторов.

Здравствуйте, Privalov, Вы писали:

P>А еще лучше, как сейчас. Когда весь ввод-вывод вынесен в библиотеки.
Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.


P>Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.
Да, думаю, так же как в статье. Только в списке форматов нужно через один добавлять формат "A" (надо будет автору идею кинуть )


P>ГОСТ не ввели, не надо пугаться. Но в любой нормальной программной системе логи имеют определенный формат. И нарушать его не стоит. Просто потому, что можно не найти требуемую запись. С учетом использования автоматиированных анализаторов.
Да я пошутил. Речь-то шла об отладке. Т.е. об обычно разовых выводах, которые программист посмотрел и выкинул (выкинул оператор вывода). Здесь вывод полностью определяется программистом и его понятием об удобстве и наглядности. Лог, который будут смотреть во время эксплуатации — это уже другое. Хотя и там PUT DATA пригодится. Особенно, если имена переменных хорошо продуманны.

Здравствуйте, кт, Вы писали:

кт>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
Это по тому что у вас языки не правильные. А в правильных языках библиотеки ещё не такое умеют.
http://www.nemerle.org/

Здравствуйте, кт, Вы писали:

кт>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.

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

А почему для записи логов используется PUT? WRITE был бы логичнее, нет? К тому же, файл можно сделать индексно-последовательным. Современные версии PL/1 такое поддерживают, правда? Сразу поиск легче станет. В качестве ключа использовать время записи.

P>>Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.
кт>Да, думаю, так же как в статье. Только в списке форматов нужно через один добавлять формат "A" (надо будет автору идею кинуть )

кт>Да я пошутил. Речь-то шла об отладке. Т.е. об обычно разовых выводах, которые программист посмотрел и выкинул (выкинул оператор вывода). Здесь вывод полностью определяется программистом и его понятием об удобстве и наглядности. Лог, который будут смотреть во время эксплуатации — это уже другое. Хотя и там PUT DATA пригодится. Особенно, если имена переменных хорошо продуманны.

На самом деле™ удобно, когда лог выводится в едином формате. Уровни логирования не зря придумали. Если возникает нештатная ситуация в production, просто меняется в конфиге уровень с error на debug, и все дела. Сразу, не сходя с места, получаем расширенную информацию.
Я надеюсь, для логирования используются специальные модули? А то я знаю пару любителей пихать запись в лог прямо в код. Добавит такой любитель оператор вывода в лог, а в конце убрать забудет. А с нормальными логгерами и далать ничего не надо. Только уровни расставить.

А не так много реального кода на PL/1 видел. Но везде использовался только PUT EDIT для печати.

Здравствуйте, WolfHound, Вы писали:

кт>>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
WH>Это по тому что у вас языки не правильные. А в правильных языках библиотеки ещё не такое умеют.
WH>http://www.nemerle.org/

Я, кстати, оговорился. Компилятор имеет ИМЕНА и свойства.
Я же не написал создание невозможно. Я написал, что затруднено. Ведь сколько лишней информации нужно иметь и передавать туда-сюда только, чтобы вывести имя объекта в динамике. А если не нужен отладочный вывод? Все равно все иметь?

Здравствуйте, кт, Вы писали:

V>>В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику.
V>>Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
кт>Речь идет в основном об отладочных выводах. Если у меня массив S из 10 строк, что я должен увидеть? 10 раз "unparsed string:" или S(1)=.. S(2)=...
кт>в первом случае толку от такого вывода мало и легко ошибиться при анализе.
"временный отладочный вывод" — это как раз то единственное применение, которое я могу представить (о чём и написал в конце поста).
А если уж говорить о массиве, то мне, например, был бы удобен более компактный вид (Например как в JSON), а уж никак не "S(1)=.. S(2)=..."

V>>Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
кт>Это я вообще не понял. Если меняются даже названия переменных, зачем читать старые логи?
Ну так логика-то не меняется. Пример:
Пришло на вход сервиса XML сообщение. В лог полезно вывести информацию о нём (скажем, URI схемы, чтобы понимать, какой блок кода будет с ним работать).
Это не меняется с версиями программы.
Но, например, в первой версии это была одна переменная, в следующей — другая, а потом мы поменяли парсер и надобность в переменной отпала.
А информация по прежнему есть и её надо выводить.
В такой ситуации имена переменных будут только путать.
"зачем читать старые логи" — вопрос, видимо, риторический, так как ответ на него очевиден.

V>>Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора.
V>>Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
кт>Описанная доработка потребовалась автору для приведения компилятора к стандарту языка. В языке это было предусмотрено.
Ну тогда ок. Видимо, тогда это местные проблемы PL\1, а не общие вопросы (как можно предположить из темы).

V>>Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.
кт>Вольному — воля. Описанная возможность встроена в язык и ляпать ничего уже не надо.
как это не надо? Язык сам догадается, какие переменные мне нужно записывать и в какой файл?

Здравствуйте, Privalov, Вы писали:

P>На самом деле™ удобно, когда лог выводится в едином формате. Уровни логирования не зря придумали. Если возникает нештатная ситуация в production, просто меняется в конфиге уровень с error на debug, и все дела. Сразу, не сходя с места, получаем расширенную информацию.
P>Я надеюсь, для логирования используются специальные модули? А то я знаю пару любителей пихать запись в лог прямо в код. Добавит такой любитель оператор вывода в лог, а в конце убрать забудет. А с нормальными логгерами и далать ничего не надо. Только уровни расставить.

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

Исследовать распечатку? А почему нет. Цифирки большие. От электричества не зависит

P>А не так много реального кода на PL/1 видел. Но везде использовался только PUT EDIT для печати.
Может о PUT DATA не слышали Или это не отладочный вывод был.

Здравствуйте, кт, Вы писали:

кт>Я, кстати, оговорился. Компилятор имеет ИМЕНА и свойства.
кт>Я же не написал создание невозможно. Я написал, что затруднено. Ведь сколько лишней информации нужно иметь и передавать туда-сюда только, чтобы вывести имя объекта в динамике. А если не нужен отладочный вывод? Все равно все иметь?
Как нужно, так и будет.
Библиотеки немерла в общем случае состоят из двух частей.
Той что выполняется во время исполнения и той что может поговорить с компилятором во время компиляции и сгенерировать, изменить или удалить код.
https://github.com/rsdn/nemerle/wiki/Macros-tutorial

Здравствуйте, кт, Вы писали:

кт>По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят.
кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.

Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.

Здравствуйте, WolfHound, Вы писали:


WH>Библиотеки немерла в общем случае состоят из двух частей.
WH>Той что выполняется во время исполнения и той что может поговорить с компилятором во время компиляции и сгенерировать, изменить или удалить код.
WH>https://github.com/rsdn/nemerle/wiki/Macros-tutorial

Ну вот пример в терминах PL/1
declare
x fixed(31) based(p),
y bit(32) based(p),
p ptr;

allocate x;
put data(x);

в библиотеке выполнения известен адрес. А то, что я хотел вывести именно как X, а не как Y довольно сложно определить, поскольку имеется только содержимое указателя P.
А здесь никаких заморочек не надо — внутри программы автоматически запишется "X=" и дело с концом.

Здравствуйте, кт, Вы писали:

кт>Видите ли, у Вас вся отладочная печать почему-то, исключительно что-то вроде телеметрии (недавно у Прогресса отладочная печать прервалась на 383 секунде, слышали?) или протокола работы сервера. А при создании программ отладочный вывод совершенно разный можеть быть. Какую-нибудь матрицу и вектор один раз вывести. В процессе создания может еще и логов-то и в проекте нет.

Так логи — это и есть телеметрия, нет? И в разных ситуациях нужны разные уровни детализации выводимой информации.
Вывод может быть разным по содержанию. А форма должна быть стандартизована в рамках разрабатываемой системы.
Вот так это может выглядеть:

2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - font is changed
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - page height is changed
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - page width is changed
2385/12/20 15:43:43.3440 INFO ldomDocument::openCacheFile() - looking for cache file
2385/12/20 15:43:43.3440 TRACE getPersistenceFlags() returned 0
2385/12/20 15:44:33.4850 TRACE Updating screen after key event
2385/12/20 15:44:33.4850 TRACE animatePageFlip( 256 -> 258 )
2385/12/20 15:44:33.4850 TRACE CRUIReadWidget::prepareScroll(1)

Лог CoolReader-а. Нормально читается. PUT DATA так не умеет.

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

кт>Исследовать распечатку? А почему нет. Цифирки большие. От электричества не зависит

Во-первых, как я уже писал, это банально неудобно. Исследуется не одна-две строки, а десятки или сотни. Тупой поиск глазами с карандашиком лично меня напрягает.
Во-вторых, при чтении по распечатке легко ошибиться. Ну там 0 и О. Или 1 и l или I.
В-третьих, от электричества-таки зависит. Лампа какая-нибудь обязательно нужна. Наощупь в темноте у меня почему-то не очень получается.

кт>Может о PUT DATA не слышали Или это не отладочный вывод был.

Про PUT EDIT, WRITE, ISAM слышал, а про PUT DATA — нет? Я таких не встречал.
offtopic: Кстати, а ISAM поддерживается в языке?

Здравствуйте, Privalov, Вы писали:


P>Так логи — это и есть телеметрия, нет? И в разных ситуациях нужны разные уровни детализации выводимой информации.
P>Вывод может быть разным по содержанию. А форма должна быть стандартизована в рамках разрабатываемой системы.
P> PUT DATA так не умеет.
чего-то у нас диалог глухих получается. Я-то другие примеры приводил. Допустим, я перепутал порядок умножения матриц (умножение не коммутативное). У меня программа отработала 3 секунды и закрылась по концу расчета. На хрен мне все эти логи, события и времена. Мне матрицы распечатать и посмотреть не обсчитавшись член №6 в матрице 3х3. Один PUT DATA и вперед с песнями!

P>Во-первых, как я уже писал, это банально неудобно. Исследуется не одна-две строки, а десятки или сотни. Тупой поиск глазами с карандашиком лично меня напрягает.
P>Во-вторых, при чтении по распечатке легко ошибиться. Ну там 0 и О. Или 1 и l или I.
P>В-третьих, от электричества-таки зависит. Лампа какая-нибудь обязательно нужна. Наощупь в темноте у меня почему-то не очень получается.
В темноте спать надо. А отладочная печать не обязательно миллионы строк.

P>offtopic: Кстати, а ISAM поддерживается в языке?
Это Indexed Sequential Access Method что-ли? А зачем эта древность сейчас при живых Accessaх с SQL-лями и файлами, отображаемыми на память?

Здравствуйте, кт, Вы писали:

кт>чего-то у нас диалог глухих получается. Я-то другие примеры приводил. Допустим, я перепутал порядок умножения матриц (умножение не коммутативное). У меня программа отработала 3 секунды и закрылась по концу расчета. На хрен мне все эти логи, события и времена. Мне матрицы распечатать и посмотреть не обсчитавшись член №6 в матрице 3х3. Один PUT DATA и вперед с песнями!

Это частный случай. Который несложно сделать с помощью нормальных средств логирования. И потом, ЕМНИП, PUT DATA выводил данные в одну строку. Если размерность матрицы больше, чем 2x2, читать такое будет сложно. Но тут могу наврать.

кт>В темноте спать надо. А отладочная печать не обязательно миллионы строк.

А как же "от электричества не зависит"?
И про ночь я ничего не писал. Сейчас зима, темнеет раньше, чем заканчивается рабочий день.

P>>offtopic: Кстати, а ISAM поддерживается в языке?
кт>Это Indexed Sequential Access Method что-ли? А зачем эта древность сейчас при живых Accessaх с SQL-лями и файлами, отображаемыми на память?

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

OPEN FILE(STATE_FILE) KEYED ENVIRONMENT(INDEXED);

Ну и дальше, что там требуется от индекса.
И что будет?

Как ни странно, файловые хранилища распространены достаточно широко.

Здравствуйте, кт, Вы писали:

кт>в библиотеке выполнения известен адрес. А то, что я хотел вывести именно как X, а не как Y довольно сложно определить, поскольку имеется только содержимое указателя P.
кт>А здесь никаких заморочек не надо — внутри программы автоматически запишется "X=" и дело с концом.
Прочитай статью три раза внимательно. После этого поймёшь, что возможности PL/1 по сравнению с немерле просто несравнимы.

Здравствуйте, Privalov, Вы писали:

P>Стандарт языка не требует разве?
P>Вот найдется вдруг какая-нибудь ценная программа, которая 40 лет на ленте пролежала и которую срочно надо запустить. А в ней такое:
P>

P>OPEN FILE(STATE_FILE) KEYED ENVIRONMENT(INDEXED);
P>

P>Ну и дальше, что там требуется от индекса.
P>И что будет?

P>Как ни странно, файловые хранилища распространены достаточно широко.

В стандарте подмножества "G" — индекс у файлов может быть только целое неотрицательное число.

Здравствуйте, WolfHound, Вы писали:

WH>Прочитай статью три раза внимательно. После этого поймёшь, что возможности PL/1 по сравнению с немерле просто несравнимы.

так как в Немерле получить текст вывода "x=1280 y=1024" если x,y — целые?
У автора достаточно строки put data(x,y);
а в Немерле как будет выглядеть аналогичная строка?

Здравствуйте, кт, Вы писали:

кт>так как в Немерле получить текст вывода "x=1280 y=1024" если x,y — целые?
кт>У автора достаточно строки put data(x,y);
кт>а в Немерле как будет выглядеть аналогичная строка?
Вот прямо так и будет. Нужно только библиотеку написать.
тест

using System.Console;
using PL1.Macro;

module Program
{
  Main() : void
  {
    def x = 1280;
    def y = 1024;
    put data(x, y);
    put data(x, y, x + y, x.ToString() + "asd");
    _ = ReadLine();
  }
}

результат:

x=1280 y=1024
x=1280 y=1024 x + y=2304 x.ToString() + "asd"=1280asd

библиотека:

using Nemerle;
using Nemerle.Compiler;
using Nemerle.Compiler.Parsetree;

using System.Collections.Generic;
using System.Linq;

namespace PL1.Macro
{
  public macro PutData(args)
  syntax ("put", "data", args)
  {
    PutDataImpl.Impl(args)
  }

  module PutDataImpl
  {
    public Impl(args : PExpr) : PExpr
    {
      match (args)
      {
        | PExpr.Tuple as args =>
          def code = List();
          foreach (arg in args.args)
          {
            code.Add(<[ $(arg.ToString()) ]>);
            code.Add(<[ "=" ]>);
            code.Add(arg);
            code.Add(<[ " " ]>);
          }
          code.RemoveAt(code.Count - 1);
          def code = code.Aggregate((a1, a2) => <[ $a1 + $a2 ]>);
          <[ System.Console.WriteLine($(code)) ]>
        | _ => PExpr.Error(args.Location, "Tuple expected.")
      }
    }
  }
}

декомпилированный код

// Program
private static void Main()
{
    int x = 1280;
    int y = 1024;
    Console.WriteLine("x=" + x.ToString() + " " + "y" + "=" + y.ToString());
    Console.WriteLine("x=" + x.ToString() + " " + "y" + "=" + y.ToString() + " " + "x + y" + "=" + (checked(x + y)).ToString() + " " + "x.ToString() + \"asd\"" + "=" + (x.ToString() + "asd"));
    Console.ReadLine();
}

Здравствуйте, Privalov, Вы писали:

P>Автор статьи пишет, что иногда нужно анализировать данные на распечатке. Мне такую ситуацию пердставить сложно. В 2016 году анализировать лог на бумаге просто неудобно.

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


P>Поиск по ним не сделаешь. А современные логи — штука весьма объемная.

Фильтрацию зато сделаешь. А результат распечатаешь.

Здравствуйте, vdimas, Вы писали:

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

Ни разу не приходилось. Вот фрагменты исходников печатал. И в них рисовал кружочки и стрелочки. Иногда в распечатках можно заметить то, что не видно в IDE.

V>Фильтрацию зато сделаешь. А результат распечатаешь.

В прошлом проекте у нам внедрили неплохую систему работы с логами. Там все операции проводились, как с нормальной БД: фильтрция, поиск по массе критериев. Печатать не нужно было ничего.

Здравствуйте, кт, Вы писали:

кт>В стандарте подмножества "G" — индекс у файлов может быть только целое неотрицательное число.

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

Здравствуйте, pestis, Вы писали:

P>Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
Точно! и эти, как их... ленивые вычисления не применил. А уж без привлечения монад отладочная печать с именами — все равно как пиво без водки, кино без Гоши Куценко и кучка дерьма без горки!

ОК. Но есть нюанс.
PUT DATA — в примере для простоты. А вообще-то это оператор вывода PUT.
Поэтому реальная форма будет чуть посложнее, например PUT FILE(F21) SKIP(2) DATA(x,y);
Т.е. может быть еще имя файла, число пропусков строк (в произвольном порядке).
Так что и библиотека будет чуть посложнее.
А так все правильно. Но ведь и в статье это названо мелочью. Кстати, а как насчет вывода не скаляров?
Т.е. а остальные примеры из статьи?

Здравствуйте, Privalov, Вы писали:


P>Если мы предмет обсуждения подменяем описанием его свойств, значит, он реализован?
Может я в тему не врубаюсь?
Вот пример примитивной "базы данных", допустимый в стандарте "G":

declare
1 карточка,
2(имя,
отчество,
фамилия) char(30) var,
2 возраст fixed(7),
2 дурак_ли_выпить bit,

бд file,
номер_карточки fixed(31);

open file(бд) update record direct keyed title('любители_выпить.dat');

имя ='Иван';
отчество ='Иванович';
фамилия ='Иванов';
возраст =50;
дурак_ли_выпить=нет;

номер_карточки=5_000_000;
write file(бд) from(карточка) key(номер_карточки);
...
read file(бд) into(карточка) key(номер_карточки);
возраст+=1;
дурак_ли_выпить=да;
put skip data(карточка);
...

Или вопрос был не на эту тему?

Здравствуйте, кт, Вы писали:

P>>Если мы предмет обсуждения подменяем описанием его свойств, значит, он реализован?
кт>Может я в тему не врубаюсь?
кт>Или вопрос был не на эту тему?

Я просто спросил, реализован ли ISAM в этой версии PL/1. Вместо ISAM я мог бы написать BDAM, суть от этого не поменялась бы. Просто -есть или нет? Ответ на этот вопрос не должен вызывать затруднений. Просто — да или нет.

Здравствуйте, Privalov, Вы писали:

P>Я просто спросил, реализован ли ISAM в этой версии PL/1. Вместо ISAM я мог бы написать BDAM, суть от этого не поменялась бы. Просто -есть или нет? Ответ на этот вопрос не должен вызывать затруднений. Просто — да или нет.

Грибных лесов в Европе нет (с). Индексно-последовательных файлов в смысле IBM360 с их регионами и сблокированными записями в стандарте "G" нет.

Здравствуйте, кт, Вы писали:

кт>Грибных лесов в Европе нет (с). Индексно-последовательных файлов в смысле IBM360 с их регионами и сблокированными записями в стандарте "G" нет.

Примерно такой ответ я себе и представлял. С просто "да или нет" — проблемы.

Такой стандарт нам не нужен (почти ©)
ISAM — не нужен?
Спорно. Он до сих пор используется. Btrieve, например.

Без PUT DATA прекрасно обходятся все и везде. Из PL/1 он не перешел ни в один язык. Значит, не нужен.

Здравствуйте, pestis, Вы писали:

P>Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
Отстал-то он похоже лет на 40. Но к чему монады

Здравствуйте, pagid, Вы писали:

P>>Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
P>Отстал-то он похоже лет на 40. Но к чему монады

Не все приняли тот факт, что еще в 80-е PL/1 был вытеснен Фортраном и Коболом.

Здравствуйте, Privalov, Вы писали:

P>Не все приняли тот факт, что еще в 80-е PL/1 был вытеснен Фортраном и Коболом.
Хотя в в 60-е PL/1 создавался для замены Фортрана и Кобола

Здравствуйте, pagid, Вы писали:

P>Хотя в в 60-е PL/1 создавался для замены Фортрана и Кобола

И Алгола-60. Но Алгол как-то незаметно канул в вечность.

Здравствуйте, кт, Вы писали:

кт>ОК. Но есть нюанс.
Нет никаких нюансов.

кт>А так все правильно. Но ведь и в статье это названо мелочью.
Вся статья детский сад штаны на лямке.
Там нет ничего что не может сделать толковый школьник на немерле за вечер.
И на научную статью она вообще никак не тянет. Максимум пост в бложике.

кт>Кстати, а как насчет вывода не скаляров?
https://github.com/rsdn/nemerle/wiki/Macros-tutorial
Прочитай внимательно. Там есть код, который решает почти идентичную задачу.

кт>Т.е. а остальные примеры из статьи?
Это тебе в качестве домашнего задания.
Если хочешь, чтобы я с тобой дальше разговаривал тебе придётся продемонстрировать что ты хочешь узнать что-то новое, а не тупо защищаешь статью.

Здравствуйте, WolfHound, Вы писали:

WH>Нет никаких нюансов.
Есть ньюанс. Представленный здесь пример на Немерле (спасибо за потраченное время) годится только для частного случая выдачи на экран.

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

WH>https://github.com/rsdn/nemerle/wiki/Macros-tutorial
WH>Прочитай внимательно. Там есть код, который решает почти идентичную задачу.
почти да не совсем

WH>Это тебе в качестве домашнего задания.
Спасибо, не надо, я не работаю с Немерле, а в PL/1 уже есть готовое.

WH>Если хочешь, чтобы я с тобой дальше разговаривал тебе придётся продемонстрировать что ты хочешь узнать что-то новое, а не тупо защищаешь статью.
Я вообще-то просто обещал человеку выложить все его старые тексты (это последний), а не с кем-то разговаривать. И то лишь потому, что редакция почти по-хамски ничего ему не отвечала больше года.
Среди текстов есть и слабые, точнее мелкие вроде этого. И, не скрою, пытался защищать "честь предприятия".
А нового чего узнать в данном случае? Что можно достать имя переменной в строку? Да пожалуйста. Для этого три раза статью читать не требуется

Здравствуйте, кт, Вы писали:

кт>Сама статья, написана почти два года назад:
кт>http://files.rsdn.org/122727/pl1ex19.doc

Это... Ты ее преобразуй в RSDN ML (с помощью шаблона для верстки

Автор(ы): Брусенцев Виталий, Чистяков Владислав Юрьевич
Дата: 22.06.2011
Статья описывает шаблон для Microsoft Word предназначенный для верстки статей и преобразования их в формат RSDN ML. В статье рассматриваются вопросы использования шаблона.

) и кинь сюда ссылку, а я ее выложу как следует.

Здравствуйте, VladD2, Вы писали:

VD>Это... Ты ее преобразуй в RSDN ML (с помощью шаблона для верстки

Автор(ы): Брусенцев Виталий, Чистяков Владислав Юрьевич
Дата: 22.06.2011
Статья описывает шаблон для Microsoft Word предназначенный для верстки статей и преобразования их в формат RSDN ML. В статье рассматриваются вопросы использования шаблона.

) и кинь сюда ссылку, а я ее выложу как следует.

Упс... А я думал, что они уже все в этой разметке. Мне их в таком виде и дали. Я их просто все себе в "файлы" и переписал.

Вот все восемь ссылок http://files.rsdn.org/122727/pl1ex14.doc ,pl1ex15.doc, pl1ex19.doc-pl1ex24.doc

VD>>Это... Ты ее преобразуй в RSDN ML (с помощью шаблона для верстки

Автор(ы): Брусенцев Виталий, Чистяков Владислав Юрьевич
Дата: 22.06.2011
Статья описывает шаблон для Microsoft Word предназначенный для верстки статей и преобразования их в формат RSDN ML. В статье рассматриваются вопросы использования шаблона.

) и кинь сюда ссылку, а я ее выложу как следует.

кт>Упс... А я думал, что они уже все в этой разметке. Мне их в таком виде и дали. Я их просто все себе в "файлы" и переписал.

кт>Вот все восемь ссылок http://files.rsdn.org/122727/pl1ex14.doc ,pl1ex15.doc, pl1ex19.doc-pl1ex24.doc

Автор подтвердил, что все статьи уже были размечены по этому шаблону. Так, что должны здесь нормально отображаться без дополнительных преобразований.

Здравствуйте, кт, Вы писали:

кт>Здравствуйте, WolfHound, Вы писали:

WH>>Нет никаких нюансов.
кт>Есть ньюанс. Представленный здесь пример на Немерле (спасибо за потраченное время) годится только для частного случая выдачи на экран.

Запись в файл отличается от вывода на экран чуть менее чем никак.

Здравствуйте, hardcase, Вы писали:

H>Запись в файл отличается от вывода на экран чуть менее чем никак.

Имелось в виду, что PUT DATA(X,Y); это случай вывода в стандартный поток.
Реально операторы в программе выглядят как-то так:
PUT FILE(F) DATA(X,Y); или
PUT SKIP(2) FILE(F) DATA(X,Y); или
PUT FILE(F) SKIP DATA(X,Y); (порядок опций в операторе вывода может быть любой)

Поэтому фрагмент макро
…
public macro PutData(args)
syntax ("put", "data", args)
…
должен учитывать это и быть чуть сложнее.