You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In cases like the one above, this is correct.
But this hinders readability in some cases (name_num vs name _num) and prevents simply adding/printing a filter @filter at the end.
In some cases like continuation arguments, the invalid code
.cn fun_name .Cn ... = ...
is generated.
Suggestion: always print brackets.
The text was updated successfully, but these errors were encountered:
A related thing is the following oddity: The FE currently uses the name _ as magic name to indicate that we are not interested in this entity and will happily name many things internally as _. But on top of that Def::unique_name() will generate a name consisting of Def::name() + _ + Def::gid(). For this reasons some variables end up named like __12345 (note the double underscore) in the output Oo
I think the output could be improved if we used a different separator in Def::unique_name(). Then, we would have sth like this:
.cn name_num.23 num.42: T
or
.cn name_num.23 .42: T
or
.cn name_num.23 _.42: T
This should mitigate at least some of the complaints. Now, using . doesn't really work. We would have to agree on a different separator. This was just an example to bring the point (pun intented XD) across.
Functions with only one argument are printed without brackets:
In cases like the one above, this is correct.
But this hinders readability in some cases (
name_num
vsname _num
) and prevents simply adding/printing a filter@filter
at the end.In some cases like continuation arguments, the invalid code
is generated.
Suggestion: always print brackets.
The text was updated successfully, but these errors were encountered: