On 11 June 2010 09:27, James Paige <[email protected]> wrote:
> On Thu, Jun 10, 2010 at 04:25:37PM -0400, Mike Caron wrote:
>> On 09/06/2010 7:50 PM, James Paige wrote:
>>> I have noticed that sometimes new users misunderstand how the "if"
>>> command works. I see someone write code like:
>>>
>>> if(condition) then(action)
>>>
>>> but this code only runs once in their "new game" script, and they wonder
>>> why "action" fails to happen each and every time that "condition" comes
>>> true
>>
>> This smells like a PEBCAK problem. At no point in my time programming
>> have I ever assumed that an if will keep "trying" after the program
>> moves on. If they want it to loop, they should let someone (i.e., the
>> compiler) know!
>
> Oh, *definitely* a PEBCAK problem. It is just that it is a common enough
> PEBCAK that it got me thinking about whether such a structure would be
> intutive.
Sure, you very occasionally see people who misunderstand "if", but you
frequently (or least did a years ago when the average OHR user was
less familiar with scripting) see people who misunderstand "while";
specifically, why they need a "wait". So by the same reasoning (in
fact, this suggestion is already on the Plan page!), we could add a
block like:
forever(...)
->
spawn script (
while (1) do (
...
wait
)
)
(Although if we add automatic exiting when the parent script exits,
which I'm still in favour of, then "forever" would be an inappropriate
name.) Notice that this is a generalisation of whenever. So I think I
prefer this suggestion to whenever.
whenever (foo) do (bar)
->
forever (if (foo) then (bar))
>>> Does that seem like a thing that would be worth having? It seems pretty
>>> cool to me... but I can't think of any other language* with a similar
>>> flow control structure, which makes me wonder if it has already been
>>> tried and declared harmful by older wiser minds.
>>
>> This idea is basically closures
>> (http://en.wikipedia.org/wiki/Closure_%28computer_science%29). In a
>> nutshell, a closure is a function that has the following properties:
>
> Nifty!
Well, no, they aren't really closures. Closures are functions. You
couldn't treat a whenever/spawnscript block as a function. But we're
close; delayed-start newscript/spawnscript blocks (which are a very
iffy part of the plan) are almost closures without arguments. Full
closures could be added for a pretty small amount of extra work over
that needed to implement the current plan. We could add them to the
plan, or add them later, though perhaps they are just too scary for
users.
>>> (* actually, I can think of one language that has something like this.
>>> The machine language for the ancient Daytronics System-10 mainframe has
>>> the EXU command which executes code any time a logic bit changes state.
>>> This is also the one and ONLY flow control of any kind that the language
>>> supports. All other flow control patterns have to be painstakingly
>>> cobbled together with a series of EXU commands and bit flips)
>>
>> That sounds insane. I can't imagine trying to make that work.
>
> My employer uses one of these to control a tensile stress testing
> machine. The operator inputs min and max values for the desired force.
> The force sensor is wired to the computer, and the computer watches the
> input and flips a logic bit for each of the min and max thresholds when
> the input crosses them. That bit flip triggers EXU commands which run
> code to run the motor in the correct direction to get the tension back
> in range.
>
> And yes it is crazy. I hate that machine.
Hah! I could tell you had personal experience with it :)
> ---
> James
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
