Separate object and meta languages

[jstolarek]

When we evaluate a program we essentially convert from expression to a value. But the evaluation of pslice actually produces an expression. I introduced a new constructor of Value, VExp, to store the result of pslice. The conceptual end effect is that we end up with values and expressions getting mixed.

At the moment we can only visualize an expression that is result of a pslice, but what else might we want to do with it? Resugaring and pretty printing sounds like an obvious thing to do, which means we need a new language primitive for doing this.

I wonder where all of this leads us to. I feel something is wrong here but I can't find a way to put it into words.

[rolyp]

If I understand you correctly, this is a (mostly undesirable) consequence of having these meta-operations in the object language. Their types mention meta-types such as "expression", which then need to be injected into the object language as opaque primitives. My suggestion a while back was to take these out of the object language. However, having seen the REPL, I realised one advantage of having them in the language is that they become available in the REPL without having to introduce dedicated commands (:trace, :pslice, etc) that implement them.

…

On 6 February 2017 at 17:39, Jan Stolarek ***@***.***> wrote: When we evaluate a program we essentially convert from expression to a value. But the evaluation of pslice actually produces an expression. I introduced a new constructor of Value, VExp, to store the result of pslice. The conceptual end effect is that we end up with values and expressions getting mixed. At the moment we can only visualize an expression that is result of a pslice, but what else might we want to do with it? Resugaring and pretty printing sounds like an obvious thing to do, which means we need a new language primitive for doing this. I wonder where all of this leads us to. I feel something is wrong here but I can't find a way to put it into words. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHY8uq6TF5Qsfl9n7eluRy1jjM2qLL5ks5rZ1q6gaJpZM4L4f7k> .

[jstolarek]

If I understand you correctly, this is a (mostly undesirable) consequence of having these meta-operations in the object language.

Yes, I think this the exact cause of the problem.

My suggestion a while back was to take these out of the object language. However, having seen the REPL, I realised one advantage of having them in the language is that they become available in the REPL without having to introduce dedicated commands (:trace, :pslice, etc) that implement them.

I think that adding meta operations to the REPL would be trivial. Changing the implementation to actually consist of meta- and object languages seems like a lot of work, though. Probably not something I would want to do before the ICFP deadline.

[rolyp]

Yeah, probably best to leave it for now. I figured adding the commands to the REPL wouldn't be too hard, I was less sure about how easy it was to have "meta-values" of different types kicking around (e.g. traces, expressions).

…

On 7 February 2017 at 11:12, Jan Stolarek ***@***.***> wrote: If I understand you correctly, this is a (mostly undesirable) consequence of having these meta-operations in the object language. Yes, I think this the exact cause of the problem. My suggestion a while back was to take these out of the object language. However, having seen the REPL, I realised one advantage of having them in the language is that they become available in the REPL without having to introduce dedicated commands (:trace, :pslice, etc) that implement them. I think that adding meta operations to the REPL would be trivial. Changing the implementation to actually consist of meta- and object languages seems like a lot of work, though. Probably not something I would want to do before the ICFP deadline. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHY8qoPFMv1TvrceqOkE1psJe3VcNHBks5raFGXgaJpZM4L4f7k> .

[jamescheney]

As discussed before, the "trace" and other meta-operations are currently kind of a hack. One way to make them less of a hack could be to introduce types for "quoted" expressions and traces, so that we can work with them quasi-safely. This is beyond the scope of our current goal but I would like to come back to it at some point.

In any case, values contain expressions (in our environment/closure based semantics) anyway, so I'm not sure that this is more of a problem in the presence of the trace operations than in their absence.

[jstolarek]

Note to self: one more benefit of doing this would be easier benchmarking. We could parse and evaluate a file in the object language and then call functions like pslice through the library API and precisely benchmark performance.

[jstolarek]

I'm trying to imagine how this should look from the user's perspective. I imagine having two completely separate languages: TML (object language) programs would be stored in *.tml files, whereas meta-programs would be stored in, say, *.slc files and would refer to source files containing TML programs. Some things to consider:

• in this setting, what will be the overlap between two languages. For example, if we want to have a list as a slicing criterion then there must be a way to write lists in the meta language. Does this require duplicating the data definition in the meta-program? Or are we able to reuse data declarations of a TML program? Perhaps we can reuse them, but this seems to require parsing TML program before desugaring meta program.

• in the current setting we are able to trace only selected expressions in the program. In the proposed setting this seems impossible - we would have to slice whole programs. Is that acceptable?