Open uliwitness opened 4 years ago
Alternate spelling that looks neat would be
take <parameters>|nothing and -- single command goes here
as well as
take <parameters>|nothing and do
-- commands go here
end take
and maybe even
take <parameters>|nothing and
-- single command goes here
Considerations
then
re-used in something not conditional (will this lead to the same kind of confusion as people talking of "if loops"?)and
that isn't a boolean operator, or do
that isn't a do
command. OTOH this could be used in many places where do
used to be used, and we haven't implemented do
yet.take
followed by a do
command from a multi-line take
is whether there's a return after the do
or an argument, so no ambiguity.then
for if
, so using it here again kinda makes it more consistent.Implementation Notes
do
command or the like) as properties, re-map their uses to be property accesses (implicitly adding the my
or of me
), then calling a closure would just invoke a certain handler on that object. That would not require a new data type, but would require the ability to "attach" additional objects to an object's script. function takeHandler:15 of cd btn 5
as its object descriptor, then only permit calling function objects. All other object descriptors would result in an error. Can always widen this, but having put "cd btn 5" into myHandler; get myHandler(43)
invoke a function run
on a button seems very confusing and un-intuitive. Very programmerish, but violating the illusion of buttons being buttons and functions being functions. Just because closures are ad-hoc objects under the hood doesn't mean we should force scripters to be aware of that.take nothing then return gMyName
etc.do
command makes that hard (do all variables become properties just in case someone uses do
to declare a variable, change it in the closure, expecting it to be modified)? But it would still be nice if we could explicitly capture variables for a safer programming style.If anyone has suggestions, it would be appreciated. Especially something that reads English in most cases, doesn't use nerdy terminology or big words, and fits into HyperTalk's "the value has the type, not the variable" (aka "everything is a string") world.
TBD - Can we make closure parameters more self-explanatory? Right now if a command expects errorCode, errorMessage in that order, and I reverse them, there's no way to detect that.
We want an English-like syntax. Best I could come up with is
and
and
This reads fairly well when e.g. used in a function: