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
With the #1973 change to FUNCTION, it would make sense to make a similar change to CLOSURE, to make it collect locals and have options like FUNCTION, but generate a closure instead. We would also want to add a CLOS function that, like FUNC for functions, be a minimal function that doesn't grab locals or have options, for those who want more control and less overhead.
The source of CLOSURE would be similar to the source of FUNCTION, but with function! replaced with closure! at the end. It's a small enough function that the code duplication won't matter.
This would bring a bit of balance to the user function model. No need to make closure versions of DOES and HAS though.
This and #1973 would effectively revert #2001 with no loss of functionality.
>> closure [] [a:1]
== make closure! [[/local a] [a:1]]
>> clos [] [a:1]
== make closure! [[] [a:1]]
We don't have to worry about backwards compatibility here because closures are a new feature in R3, and as such their API and behavior won't be considered standardized until 3.0 comes out. So, we have a relatively short time to make this change, but we can make it. If you are worried about the version of CLOSURE included in R2, show that it is widely used in R2 code by people who require it to retain the same semantics in code that must also run in R3 without changes (similar to #1973 and the almost-never-used old FUNCTION).
If we like we could keep the #2001 /closure option to the FUNCT function builder, rather than just having it be another name for the FUNCTION function builder. However, with #1973 implemented we might want to consider the FUNCT name for that function to be optional and deprecated, since making that name go away is part of the reason for #1973 in the first place. We probably don't want to give FUNCTION a /closure option.
Submitted by: BrianH
With the #1973 change to FUNCTION, it would make sense to make a similar change to CLOSURE, to make it collect locals and have options like FUNCTION, but generate a closure instead. We would also want to add a CLOS function that, like FUNC for functions, be a minimal function that doesn't grab locals or have options, for those who want more control and less overhead.
The source of CLOSURE would be similar to the source of FUNCTION, but with function! replaced with closure! at the end. It's a small enough function that the code duplication won't matter.
This would bring a bit of balance to the user function model. No need to make closure versions of DOES and HAS though.
This and #1973 would effectively revert #2001 with no loss of functionality.
Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Mezzanine Reproduce: Always Fixed-in:r3 master ]
Imported from: metaeducation#2002
Comments:
Submitted by: BrianH
We don't have to worry about backwards compatibility here because closures are a new feature in R3, and as such their API and behavior won't be considered standardized until 3.0 comes out. So, we have a relatively short time to make this change, but we can make it. If you are worried about the version of CLOSURE included in R2, show that it is widely used in R2 code by people who require it to retain the same semantics in code that must also run in R3 without changes (similar to #1973 and the almost-never-used old FUNCTION).
If we like we could keep the #2001 /closure option to the FUNCT function builder, rather than just having it be another name for the FUNCTION function builder. However, with #1973 implemented we might want to consider the FUNCT name for that function to be optional and deprecated, since making that name go away is part of the reason for #1973 in the first place. We probably don't want to give FUNCTION a /closure option.
Submitted by: BrianH
Pull request for this and #1973 here: rebol/rebol#109
Set the ticket to pending because of the pull request.
Submitted by: abolka
For reference, Carl's first take on the issue:
"Ah, well that's the advantage of R3 not yet being final. These are good issues to decide."
Source: http://chat.stackoverflow.com/transcript/message/9657784#9657784
The text was updated successfully, but these errors were encountered: