type:: [[REVIEWS]]
status:: [[DONE]] 
tags:: #PYTHON #semantics 
year:: 2023
venue:: [[SLE]] 
full-title:: An Executable Semantics for Faster Development of Optimizing [[PYTHON]] Compilers
deadline-submission:: [[01-05-2023]] 
date-start:: [[30-04-2023]] - 22:53
date-submitted:: [[04-05-2023]] 
external-links:: ![sle23-paper95.pdf](../assets/sle23-paper95_1682888032661_0.pdf)

	- [[Highlights]]
		- Objects in [[PYTHON]] are defined in terms of:
			- *[[#blue]]==identity==*:  unique integer value that never changes across the life of the object and it is available [[by]] calling id(obj)
			- *[[#blue]]==type==*: it defines the operations that are allowed on that object
			- *[[#blue]]==value==*: it is the data represented [[by]] the object
		- [[#green]]==All values in a [[PYTHON]] program are objects==
		- Attributes of all built-in types are read-only. Thus, immutabiity of built-in types is part of [[PYTHON]]'s semantics
		- ((644fe378-f02f-4626-bb6b-1b797d6c12b3))
			- WHy? how is it done now?
			- ((644fe3ad-606d-4a0f-b985-8134947edfcd))
				- With respect to what? Only concerning execution time? or something else?
		- ((644fe5dc-a608-41ec-90ac-479206bfdf0c))
			- ??? Never introduced....
		- ((644fe635-ccc4-4ded-9720-af2852297010))
			- What's that???
		- ((644feb0a-3015-4266-907b-40e6abd43436))
		- ((645270f9-9991-40aa-b8cf-42d909fc85fd))
			- Not always easy to read without a running example!!!
		- ((64527182-5134-4f53-9126-eb3069193e4f))
			- The toolchain is not always easy to grasp. Many technologies are mentioned and used without introducing and motivating them (i.e., Scheme, Bigloo, Gambit, etc.)
			- This is also confirmed by the [[authors]]:
				- ((645273a0-f0c0-4759-ae0d-d9717fe0babb))
		- ((6451856b-a483-4390-8b4a-5a1513822cd2))
			- of!
		- ((6452bd0c-bde8-477e-b00a-7e3b2747b09f))
			- What do you  mean?
		- ((6452bd82-bae0-4c14-b0e2-c8a13a6dd9db))
			- It not clear!
		- ((6452beee-2cf9-4990-b595-620cd469b4e5))
			- Why? What are the characteristics not yet supported, or the other way round? What are the distinsguishing characteristics of the four benchamrks currenlty covered / supported?
		- [[question]] Are there existing approaches to compare?
			- [[question]] Optimizing [[PYTHON]] compilers?
			- So they produce a tool to optimize existing compilers?
			- What are the performance characteristics of interest?
			- It seems the [[WORK]] is focusing on the problem of optmizing the implemenation fo [[PYTHON]] compilers (to mitigate the problem written here: The effort spent getting the semantics right leaves little [[time]] for optimization)
				- automate this process to accelerate development, including that of existing compilers, independently of the [[language]] and tools chosen for its implementation.
			- This is a strong statement to be checkedif this is actually supported / implemented
			- [[question]] can you optimize any existing [[PYTHON]] compilers? What the precondition that needs to be satisfied to apply the proposed approach?
			- Maybe the answer is in the following sentence:
				- development of an executable semantics, written in the [[PYTHON]] syntax, that aims to automate part of the implementation of a [[PYTHON]] optimizing compiler.
			- interface with the semantics by using the parsing infrastructure of an existing compiler.
				- HOW????
			- The evaluation needs to be improved. Research questions are not clearly defined. The evaluation process is not precisely presented.
	- ### [[Notes]]
		- This [[paper]] is very much related to
			- [[@Reusable Semantics for Implementation of Python Optimizing Compilers]]
	- [[Comments]]
		- The [[paper]] presents an approach to support the development of [[PYTHON]] compilers. In particular, a toolchain that includes semPy and Zipi technologies is proposed to specify executable semantics and remove redundant operations that can be a [[source]] of overhead during the execution of [[PYTHON]] programs.
		- The [[paper]] discusses an interesting problem, and the [[authors]] aim to deal with it using a sophisticated approach, which is not always clearly presented. The proposed toolchain is not easy to grasp, and many technologies are mentioned and used without introducing and motivating them, such as Scheme, Bogloo, and Gambit. The complexity of the toolchain is confirmed by the [[authors]], who write that "Zipi has a significant compilation overhead because it is AOT and has a deep pipeline that compiles [[PYTHON]] [[code]] to Scheme, then to C, and finally to machine [[code]]."
		- The presentation of the evaluation needs improvement by including the following elements:
			- Research questions: What are the research questions that the [[authors]] wanted to answer through the evaluation?
			- Metrics: What are the metrics that the [[authors]] used to support the comparison of different solutions? While the execution [[time]] of Zipi is considered in Fig. 19 and Fig. 20, it is interesting to include the execution of the entire toolchain, including the efforts needed to define and execute the optimizations, in the comparison.
			- Data sets: The process that has been followed to collect and select the programs that were considered for the evaluation needs to be described.
			- Threats to validity: To convince the reader about the performed evaluation, it is necessary to discuss potential threats that can harm e.g., the internal and external validity of the experiments.
		- I understand that the current approach is limited to managing and optimizing arithmetic operators. However, the [[paper]] needs to discuss to what extent the proposed approach can cover complex operators and ideally the complete implementation of [[PYTHON]] so that reviewers can understand the applicability of the approach in practice in the (near) future.
		-
			-