jstolarek / slicer

Companion code for paper "Imperative Functional Programs that Explain their Work", Wilmer Ricciotti, Jan Stolarek, Roly Perera and James Cheney, ICFP 2017, Oxford, UK
http://dl.acm.org/citation.cfm?id=3110258
GNU General Public License v3.0
6 stars 0 forks source link

Disallow holes in programs #34

Open jstolarek opened 7 years ago

jstolarek commented 7 years ago

Per email discussions "Implementing forward slicing and evaluation" (14/02) and ""Writes" question" (20/02) we should not allow holes in source programs. This is not trivial to enforce, because we still have to allow holes in the arguments to built-in operators and technically arguments are allowed to be expressions that should be possible to execute.

jstolarek commented 7 years ago

This is directly related to #15 - we want to write holes in the meta language but not in the object language.