| 00:31 | <jmdyck> | I'm wondering about Abstract Closures in a post-2547 spec. E.g. CreateListIteratorRecord defines a closure that uses ?, so it can return an abrupt completion. So when it says Return *undefined*, should that be Return NormalCompletion(*undefined*)? |
| 00:32 | <jmdyck> | Or should the closure have a return-type, so that the NormalCompletion() is implicit? |
| 00:39 | <jmdyck> | (Currently, we don't have a syntax to declare an AC's return-type. Closest is that CompilePattern's return-type is an Abstract Closure that takes <X> and <Y> and returns a MatchResult) |
| 17:19 | <Michael Ficarra> | I'm wondering about Abstract Closures in a post-2547 spec. E.g. CreateListIteratorRecord defines a closure that uses |
| 17:35 | <shu> | good catch, we should audit ACs for that |
| 17:35 | <shu> | possibly need to amend the AC creation language to talk about return types as well |
| 18:13 | <jmdyck> | Syntax possibilities: (1) "... a new Abstract Closure with parameters <P> that captures <C> and returns <R>, performing the following steps when called:" |
| 18:13 | <jmdyck> | (2) "... a new Abstract Closure with parameters <P> that captures <C>, returns <R>, and performs the following steps when called:" |
| 18:15 | <jmdyck> | (3) "... a new Abstract Closure with parameters <P> that captures <C> and performs the following steps when called, returning <R>:" |
| 18:26 | <jmdyck> | Given that <R> might be something like "either a normal completion containing an ECMAScript language value, or a throw completion", I think I prefer (3), where you don't have to resume parsing the step after getting through <R>. But (1) and (2) wouldn't be terrible on that score. |
| 18:28 | <jmdyck> | so another criterion might be more decisive. |
| 18:33 | <jmdyck> | (2) sounds a bit odd to me, like it returns <R> and then performs these steps, which makes no sense. |
| 18:57 | <shu> | agreed, (2) sounds odder than (1) or (3) |
| 18:57 | <shu> | (3) is the most radical, but i kind of like it |
| 18:57 | <shu> | it reads naturally |
| 18:57 | <shu> | there's no real reason to have the return type be co-located next to the parameters or anything |
| 20:10 | <Michael Ficarra> | I prefer 1 or 2 |
| 20:11 | <Michael Ficarra> | are you thinking that if we standardise a declaration of the return type for ACs that we can just add an automatic NormalCompletion provision? |
| 20:11 | <jmdyck> | Yup |