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
Perhaps this merits further discussion, but having gone through this a few times, I can see no genuine advantage of making the set type recursive. We currently have
typeset =
| Classofclss
| Unionofsetlist
I propose it to be rewritten as
typeset =
| Classofclss
| Unionofclsslist
That is to say, Union([Class 'A'; Union([Class 'B'; Class 'C'])]) should be treated as equivalent to Union([Class 'A'; Class 'B'; Class 'C']). The latter is much easier and cleaner to work with.
Part of my work this semester involved formally proving that dequeue-side semantics for flattened unions behave the same as recursive ones (i.e., showing that the two sets I described above behave the same way). So I'd feel confident in removing that.
The text was updated successfully, but these errors were encountered:
Perhaps this merits further discussion, but having gone through this a few times, I can see no genuine advantage of making the
set
type recursive. We currently haveI propose it to be rewritten as
That is to say,
Union([Class 'A'; Union([Class 'B'; Class 'C'])])
should be treated as equivalent toUnion([Class 'A'; Class 'B'; Class 'C'])
. The latter is much easier and cleaner to work with.Part of my work this semester involved formally proving that dequeue-side semantics for flattened unions behave the same as recursive ones (i.e., showing that the two sets I described above behave the same way). So I'd feel confident in removing that.
The text was updated successfully, but these errors were encountered: