5.June.2022
Some time ago I have sent short version [0] of an article "Program structure" (long initial version back to 2009 see [1], [2]) to https://www.macs.hw.ac.uk/mpc22/.
I was fascinated by the name of the conference and didn't pay enough attention to the abstract which suggests that the community is more interested not in the theoretical part, for example, in new structures for presenting programs, but rather in ways of constructing programs using already known structures. I am writing this after reading the reviews. It is important that the approach itself met no objections.
From the conference abstract "The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs."
[0] google-drive --I'll put it later to RG I think.
[1] arxiv https://www.academia.edu/78987727/Program_structure
https://www.researchgate.net/publication/45865036_Program_structure
[2] Studia Humana https://www.academia.edu/5325385/Program_Structure
SUBMISSION: 2
TITLE: Program structure
AUTHORS: Alex Shkotin
----------- Overall evaluation -----------
SCORE: -3 (strong reject)
----- TEXT:
The paper title "Program structure" by Alex Shkotin looks at the structure of programs, given as source code.
It is claimed that a program is usually represented as a word chain and then argues that a program can also be syntactically represented as an oriented word tree.
However, the contribution of the paper remains unclear, as it is well known that programs can be represented as Abstract Syntax Trees (ASTs); relationships between statements (e.g. allocation) can be done by Control Flow Graphs (CFGs) and dependencies can easily be added as well. ASTs, CFGs and dependencies have been studied intensively over the previous 40-50 years. For this referee it is unclear what this paper adds to this knowledge.
The paper massively lacks related work on any topic, such as ASTs or CFGs - in fact the newest paper cited is from 1990.
Last, but not least, the paper contains several typos and grammatical errors - hence the paper would need a proper proof-reading in case the paper is accepted.
гутранс
«В названии статьи «Структура программы» Алекса Шкотина рассматривается структура программ, представленных в виде исходного кода.
Утверждается, что программа обычно представляется в виде цепочки слов, а затем утверждается, что программу также можно синтаксически представить в виде ориентированного дерева слов.
Однако вклад статьи остается неясным, поскольку хорошо известно, что программы могут быть представлены в виде абстрактных синтаксических деревьев (AST); отношения между операторами (например, распределение) могут быть выполнены с помощью графов потока управления (CFG), а зависимости также могут быть легко добавлены. AST, CFG и зависимости интенсивно изучались в течение предыдущих 40-50 лет. Для этого рецензента неясно, что эта статья добавляет к этим знаниям.
В документе массово отсутствуют связанные работы по какой-либо теме, такой как AST или CFG - на самом деле самая новая цитируемая статья относится к 1990 году.
И последнее, но не менее важное: статья содержит несколько опечаток и грамматических ошибок, поэтому в случае принятия статьи потребуется надлежащая корректура.»
SUBMISSION: 2
TITLE: Program structure
AUTHORS: Alex Shkotin
----------- Overall evaluation -----------
SCORE: -2 (reject)
----- TEXT:
This paper takes Turingol as an example language and defines valid programs via a syntactic schema for Turingol. The schema is built such that implicit requirements in Knuth's paper (e.g., the same identifier is never used twice as a label) can be checked afterwards. Finally, syntactic trees are transformed to control flow graphs.
From the paper, it is unclear to me what the goal, motivation, and - most important - the contribution is: Is it giving a formal specification of Turingol together with its implicit requirements? Is it proposing to write programs not as text but as syntactic program trees in an editor? When and where would programs be represented as syntactic program trees? They look (and seem to be used) very similar to abstract syntax trees or parse trees, and the paper doesn't compare them /explain the advantages of why one should prefer the representation on hand compared to what is standard everywhere else. (E.g., in the introduction, it is mentioned that the program as a tree enables a new view of the description of its semantics/attributes may be assigned to tree nodes. Why is this different to existent abstract syntax trees?)
Hence, it is necessary to make the contributions more explicit and compare the present-used techniques to the existing literature and practice. As such, I recommend rejecting this paper.
On a minor note: I found several parts hard to read for easily fixable reasons: E.g., for several of Knuth's AST-paper, it is assumed that the user knows exact definitions. In the technical section, pseudo-code or explicit variables could simplify the description of the transformations.
гу-транс
«В этой статье Turingol используется в качестве примера языка и определяются корректные программы с помощью синтаксической схемы для Turingol. Схема построена таким образом, что неявные требования в статье Кнута (например, один и тот же идентификатор никогда не используется дважды в качестве метки) могут быть впоследствии проверены. Наконец, синтаксические деревья преобразуются в графы потоков управления.
Из статьи мне неясно, какова цель, мотивация и, самое главное, вклад: дает ли она формальную спецификацию Турингола вместе с его неявными требованиями? Предлагает ли писать программы не как текст, а как синтаксические деревья программ в редакторе? Когда и где программы будут представлены в виде синтаксических программных деревьев? Они выглядят (и, кажется, используются) очень похожими на абстрактные синтаксические деревья или деревья синтаксического анализа, и статья не сравнивает их и не объясняет преимущества того, почему следует предпочесть представление на руках по сравнению с тем, что является стандартным везде. (Например, во введении упоминается, что программа как дерево позволяет по-новому взглянуть на описание ее семантики/атрибутов, которые могут быть назначены узлам дерева. Почему это отличается от существующих абстрактных синтаксических деревьев?)
Следовательно, необходимо сделать вклад более явным и сравнить используемые в настоящее время методы с существующей литературой и практикой. Поэтому я рекомендую отказаться от этой статьи.
Небольшое примечание: я обнаружил, что несколько частей трудно читать по легко устранимым причинам: например, для некоторых статей Кнута по AST предполагается, что пользователь знает точные определения. В технической части псевдокод или явные переменные могут упростить описание преобразований.»
SUBMISSION: 2
TITLE: Program structure
AUTHORS: Alex Shkotin
----------- Overall evaluation -----------
SCORE: -2 (reject)
----- TEXT:
This paper discusses the structure of programs in the Turingol language, describing how syntactic schema can be used to describe families of programs. The paper describes various observations and constructions related to the syntax and semantics of Turingol programs.
The author seems to have a clear idea of important observations and constructions tying the syntax of Turingol programs to the semantics of the programs through schema. The paper contains a running example with figures, which helps with the exposition.
The paper may very well contain important new ideas, ideas that may be useful for building programming languages tools. Alas, I found the structure and writing of paper very difficult to follow, and the paper does not provide enough context or motivation for me to understand to what extent the contributions are new or important. In fact, I'm not even sure which aspects of the paper the author thinks are new.
The two biggest problems with the paper are the lack of motivation and the lack of context. The first three paragraphs of the introduction don't make sense without first reading the abstract. The 4th paragraph of the introduction is the first paragraph that actually describes what the paper is about, but that paragraph still does not motivate *why* we are studying this approach to program structure. This paper would be much stronger with motivating examples up front. Only a single sentence, in the paper's conclusion, provides a clear application for the work, as far I can tell.
The paper does not have a related work section, which surprises me, given the tremendous amount of work that has been done on parsing, program schema, grammars of various sorts (such as attributed grammars), structured editors, smart IDEs, language workbenches, etc. Which of the observations in the paper are new? How does this approach relate to the existing approaches and techniques?
The writing of the paper could use significant improvement. Many of the sentences are ungrammatical, missing articles, or awkwardly worded. I often did not understand *why* the author was describing an observation or construction. More explanation as to *why* a certain topic is important, and *how* that topic relates to the main themes of the paper, would be extremely helpful.
гу-транс:
«В этой статье обсуждается структура программ на языке Turingol и описывается, как синтаксическая схема может использоваться для описания семейств программ. В статье описаны различные наблюдения и конструкции, связанные с синтаксисом и семантикой программ Turingol.
Автор, похоже, имеет четкое представление о важных наблюдениях и конструкциях, связывающих синтаксис программ Turingol с семантикой программ через схему. Статья содержит бегущий пример с рисунками, который помогает с изложением.
Документ вполне может содержать важные новые идеи, идеи, которые могут быть полезны для создания инструментов языков программирования. Увы, я обнаружил, что структура и написание статьи очень трудны для понимания, и статья не дает мне достаточного контекста или мотивации, чтобы понять, в какой степени вклад является новым или важным. На самом деле, я даже не уверен, какие аспекты статьи автор считает новыми.
Две самые большие проблемы с документом — отсутствие мотивации и отсутствие контекста. Первые три абзаца введения не имеют смысла без предварительного прочтения аннотации. Четвертый абзац введения — это первый абзац, который на самом деле описывает, о чем статья, но этот абзац по-прежнему не мотивирует *почему* мы изучаем этот подход к структуре программы. Эта статья была бы намного сильнее, если бы заранее приводились мотивирующие примеры. Насколько я могу судить, только одно предложение в заключении статьи дает четкое представление о работе.
В документе нет a related work section, что меня удивляет, учитывая огромный объем работы, проделанной по анализу, схеме программы, грамматикам различных видов (например, атрибутивным грамматикам), структурированным редакторам, интеллектуальным IDE, языковым инструментам и т. д. и т.д. Какие из наблюдений в статье являются новыми? Как этот подход соотносится с существующими подходами и методами?
Написание статьи могло бы использовать значительное улучшение. Многие предложения не грамматичны, в них отсутствуют артикли или неуклюже сформулированы. Я часто не понимал *почему* автор описывает наблюдение или конструкцию. Чрезвычайно полезными были бы дополнительные объяснения того, *почему* определенная тема важна и *как* эта тема связана с основными темами статьи.»