| 00:20 | <bakkot> | nope |
| 00:20 | <bakkot> | all AOs do, though, including SDOs and host-defined AOs and so on |
| 00:20 | <bakkot> | (I believe) |
| 00:22 | <shu> | what about all static semantics that also have aoids? |
| 00:23 | <shu> | i classified all the the type="sdo" into type="static sdo" vs type="dynamic sdo", since i need that info to stop propagating the can-call-user-code annotation |
| 00:23 | <shu> | but that only works if we already exhaustively marked the SDOs |
| 03:03 | <bakkot> | I believe we have exhaustively marked the SDOs, yes |
| 03:04 | <bakkot> | SDOs have AOIDs still only because they do not yet have structured headers, since we just wanted to get that PR landed |
| 03:07 | <bakkot> | jmdyck: you should be able to speak here now if you're so inclined |
| 04:00 | <jmdyck> | cool, thanks |
| 04:06 | <jmdyck> | There are a few AOs that aren't the 'subject' of the emu-clause they appear in, so don't get a type attribute. E.g. thisBooleanValue |
| 04:06 | <jmdyck> | As for SDOs, there are a few we don't mark with type="sdo": Evaluation, regex-evaluation, MV, TV and TRV. Also, the two clauses that define HasCallInTailPosition, although their parent does. Plus there are a few emu-annex'es that extend SDOs that don't get type="sdo" |
| 04:08 | <jmdyck> | (So the rule appears to be: an emu-clause getstype="sdo" iff it contains the complete definition of exactly one SDO.) |
| 04:09 | <jmdyck> | ("complete" ignoring the existence of Annex B) |
| 04:09 | <jmdyck> | The static/dynamic (or Static/Runtime) dichotomy applies to more than just SDOs, so you might want to express it in the dl.header, unless you also want e.g. type="static abstract operation" and type="dynamic abstract operation". |
| 04:11 | <jmdyck> | Also, classifying ToString as static or dynamic is problematic, as shu has seen. You might consider duplicating the part of it that's needed for static processing, which I think would be just NumericToString. (So then you could classify NumericToString as static and ToString as dynamic.) |
| 15:05 | <shu> | jmdyck: i don't think AOs themselves need to be classified as static or dynamic, just the SDOs (for the purposes of this can-call-user-code annotation anyway) |
| 16:51 | <jmdyck> | Hm. So if you're classifying SDOs as to whether or not they can call user-code, why do you also need to classify them as static or dynamic? |
| 16:53 | <shu> | jmdyck: i'm doing a simple reachability analysis so AOs don't need to be manually classified. the idea is to mark a few leaves as "can call user code", and then propagate that up all AOs that can transitively call them |
| 16:53 | <shu> | i'd like this propagation to stop at static SDO boundaries |
| 17:47 | <jmdyck> | but why stop there? why not just continue the analysis down? |
| 17:57 | <shu> | how do you mean, by classifying all AOs? |
| 17:58 | <jmdyck> | ?? I thought the reachability analysis was already classifying all AOs. |
| 17:58 | <shu> | i'm confused |
| 17:58 | <jmdyck> | me too |
| 17:59 | <shu> | it is classifying all AOs, and i said i want the propagation to stop at at static SDOs, and you said "why not continue the analysis down" |
| 17:59 | <shu> | i'm not sure what you mean by "why not continue the analysis down" |
| 17:59 | <jmdyck> | use the same analysis to classify the SDOs |
| 18:01 | <shu> | ah i see, i suppose we could, but i wasn't planning to since there are far more static leaf nodes that we need to manually classify than "can call user code" ones |
| 18:03 | <shu> | that wasn't well expressed |
| 18:03 | <jmdyck> | (I was about to ask for clarification!) |
| 18:03 | <shu> | i mean something more like, manually classifying it seems to be 95% of the work, i'm not sure what the reachability analysis here would get us |
| 18:04 | <shu> | but it's not that much code to write, so that seems like a fine thing to do |
| 18:05 | <jmdyck> | re "manually classifying it seems to be 95% of the work": I'm not sure exactly what you mean by "it" there, or why you think the manual part is 95% of the work. |
| 18:05 | <shu> | let me start over |
| 18:06 | <shu> | the problem with "can call user code" is that there are relatively few chokepoints that can end up calling user code, like Call(), and the various internal methods e.g. [[Get]] when Proxy traps are involved. annotating only those and relying on a reachability analysis seems to be a good way forward. |
| 18:06 | <shu> | for "static or dynamic", are there also relatively few chokepoints? my inclination is there's just a bunch of static SDOs |
| 18:13 | <jmdyck> | If "can call user code" is what you're interested in, then it seems to me that that's the question you should be asking of SDOs, not "static or dynamic". |
| 18:15 | <jmdyck> | And I think you can use the same set of 'chokepoints' for SDOs as for AOs. |
| 18:34 | <jmdyck> | On second thought, it needs to be larger, maybe for both. |
| 18:36 | <jmdyck> | Or maybe not, hm. |