Lossy --parsedump
jacereda opened this issue · comments
Given
def foo(x, y):
def bar(a):
return a*a*y
let barx = bar(x)
let bary = bar(y)
return barx+bary
return foo(1,2)
--parsedump
generates:
FUNCTION: __top_level_expression() -> void
(list
struct xy:void
struct xyz:void
struct xyzw:void
struct xy_f:void
struct xy_i:void
struct xyz_f:void
struct xyz_i:void
struct xyzw_f:void
struct xyzw_i:void
enumbool:void
(return (foo 1:int 2:int):void):void)
FUNCTION: foo(x:int y:int ) -> void
(list
(barx var (bar x:int):int):void
(bary var (bar y:int):int):void
(return (+ barx:int bary:int):void):void)
FUNCTION: bar(a:int ) -> int
(list (return (* (* a:int a:int):int y:int):int):void)
Notice how bar
is referring to a non-scoped y:int
.
Is it intended to be useable as an intermediate representation for external code generators?
Also, note the missing space in enumbool
.
--parsedump
is purely meant as an easy way for the compiler developer to debug things, it is not meant to be complete or accurate representation that can be used further. It is just dumping its internal structures, where bar
sits in a list of all functions in a program, that does not involve scope. For example, if you added a second bar
function in a different scope, the --parsedump
output would probably show two bar
functions side by side that appear to be clashing, even though they are not. Scope is something the internal representation manages thru code structure, it does not have a seperate list of functions for each scope. See idents.h
where all of this is stored, in SymbolTable
.
We could add scope information to this output, but I personally haven't even looked at --parsedump
output in a while... I hardly ever use it. If you feel like improving this output, go ahead.
If you wanted to write an external code generator, you'd read the Lobster bytecode format.. which is way more useful since it contains all information needed, and it already has had all transformations done to it.