Re: if and while in SC

[Wouter Snoei-2]

I could imagine 'while' testing wether the testFunc is a Boolean, and  
throw an error if it is. Maybe by adding a Boolean:while containing  
an error message? That should rescue users from at least a bunch of  
possible infinite-loop mistakes.

In the same manner a Object:if could be added, containing { |
trueFunc, falseFunc| ^if( this.value, trueFunc, falseFunc ) },  
enabling the use of functions and other 'value' results in if  
statements. That could be a source for new infinite loops though,  
when object.value doesn't return a Boolean..

> ... conceptually the receiver is not expected to be an
> instance of
> Function, but an Object responding to the `value' protocol (also see
> Object:while) ...

Isn't it true that *every* object responds to 'value' ?  :-)

cheers,
Wouter

ps- just noticed we've been sending and replying to the wrong list,  
included rest of thread below


Op 27-jun-2008, om 14:24 heeft stefan kersten het volgende geschreven:

> On 27.06.2008, at 12:44, Eric Lyon wrote:
>> In any case, since I've given "while" a boolean rather than a
>> function, shouldn't it throw an error here, rather than go into an
>> infinite loop?
>
> no, because conceptually the receiver is not expected to be an
> instance of
> Function, but an Object responding to the `value' protocol (also see
> Object:while), such as an instance of Ref:
>
> fork {
>      while (Ref(true)) {
>          12.postln;
>          0.5.wait
>      }
> }
>
> more precisely, `while' expects an instance from the subset of
> Objects that
> return a Boolean when `value' is called:
>
> fork {
>      while (Ref(\yadda)) {
>          12.postln;
>          0.5.wait
>      }
> }
>
> <sk>
>
> _______________________________________________
> sc-users mailing list
> sc-users@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-users

Thanks, Wouter,

That makes a lot of sense, if a boolean is only evaluated once. If I  
understand this correctly, in my example below, the boolean is  
evaluated just once, as "true", then on repeated runs through the  
loop, even though "val" has changed, the boolean never gets evaluated  
again, so it's an infinite loop. In any case, since I've given  
"while" a boolean rather than a function, shouldn't it throw an error  
here, rather than go into an infinite loop?

// boolean instead of function, sends SC to infinite loop. Save  
everything before trying this!

(
var val = 0;
while( val == 0, { val = val + 1 });
val;
)

Also, it is possible to send a function to if:

(
var val = 0;
if( {val == 0}.value, { val = val + 1 });
val;
)


Your AutoBackup class sounds quite useful!

Cheers,

Eric


On Fri, Jun 27, 2008 at 11:26 AM, Wouter Snoei  
<mailinglists@...> wrote:
Hi Eric,

I think it is quite logical that 'while' needs a function and 'if'
doesn't. I wouldn't mind though if 'if' would be able to take a
function as well, but I could imagine that would be at cost of
efficiency. 'while' on the other hand will always need to take a
function, since it needs to be evaluated again every time the
bodyFunc is evaluated. If it is not a function it is evaluated only
once and thus if true an infinite loop is created. I know this can be
quite an annoying thing when working with 'while' for the first time,
but it is just the way it works.. I suggest people use my AutoBackup
class :-)

cheers,
Wouter

Op 27-jun-2008, om 12:09 heeft Eric Lyon het volgende geschreven:


 > The synopses for if and while are as follows:
 >
 > if ( boolean, trueFunc, falseFunc );
 > while ( testFunc, bodyFunc );
 >
 >
 > I'm curious as to why the "if" control structure evaluates a
 > boolean but the "while" evaluates a function. All things being
 > equal, it would be easier to remember how these structures work if
 > both evaluated a function or both evaluated a boolean.
 >
 > "If" and "while" also behave differently when receiving a
 > conditional in the wrong form. "If" throws an error but "while"
 > apparently evaluates its boolean and then does not evaluate the
 > body function, which can easily lead to unexpected infinite loops.
 > Examples below.
 >
 > Tested on OS X version 3.2 (rev 7362)
 >
 > Any explanations much appreciated.
 >
 > Cheers,
 > Eric
 >
 > ===
 > // correct input, works as expected
 > (
 > var val = 0;
 > if( val == 0, { val = val + 1 });
 > val;
 > )
 > // function instead of boolean, throws an error
 > (
 > var val = 0;
 > if( {val == 0}, { val = val + 1 });
 > val;
 > )
 > // correct input, works as expected
 > (
 > var val = 0;
 > while( {val == 0}, { val = val + 1 });
 > val;
 > )
 > // boolean instead of function, sends SC to infinite loop. Save
 > everything before trying this!
 > (
 > var val = 0;
 > while( val == 0, { val = val + 1 });
 > val;
 > )
 >
 > _______________________________________________
 > sc-users mailing list
 > sc-users@...
 > http://lists.create.ucsb.edu/mailman/listinfo/sc-users


Wouter Snoei

info@...
http://www.woutersnoei.nl


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[stefan kersten-2]

On 27.06.2008, at 19:24, Wouter Snoei wrote:
> I could imagine 'while' testing wether the testFunc is a Boolean, and
> throw an error if it is. Maybe by adding a Boolean:while containing
> an error message? That should rescue users from at least a bunch of
> possible infinite-loop mistakes.

i think it would be better to add some kind of panic escape mechanism  
to the
interpreter (even the linux kernel does it ;).

<sk>


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Dan Stowell]

2008/6/27 stefan kersten <sk@...>:
> On 27.06.2008, at 19:24, Wouter Snoei wrote:
>>
>> I could imagine 'while' testing wether the testFunc is a Boolean, and
>> throw an error if it is. Maybe by adding a Boolean:while containing
>> an error message? That should rescue users from at least a bunch of
>> possible infinite-loop mistakes.
>
> i think it would be better to add some kind of panic escape mechanism to the
> interpreter (even the linux kernel does it ;).

I like Wouter's suggestion actually. It would catch the horrible
lockup that scares people when they first try and use 'while', yet
doesn't imply extra overhead or pollution in the Object class etc.

Anyone disagree with the addition of something like this?

+ Boolean {
while {
^"While was called with a fixed (unchanging) boolean as the condition.
Please supply a function instead.".error;
}
}


Dan

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[stefan kersten-2]

On 28.06.2008, at 11:09, Dan Stowell wrote:
> Anyone disagree with the addition of something like this?
>
> + Boolean {
> while {
> ^"While was called with a fixed (unchanging) boolean as the condition.
> Please supply a function instead.".error;
> }
> }

actually i strongly disagree. people should be aware of the language's
evaluation and execution semantics. there is no such thing as an  
implicit
block with deferred evaluation as in C or java, and catching some  
special
cases makes things inconsistent, harder to understand and uglier (as  
in less
beautiful).

<sk>


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Dan Stowell]

2008/6/28 stefan kersten <sk@...>:

> On 28.06.2008, at 11:09, Dan Stowell wrote:
>>
>> Anyone disagree with the addition of something like this?
>>
>> + Boolean {
>> while {
>> ^"While was called with a fixed (unchanging) boolean as the condition.
>> Please supply a function instead.".error;
>> }
>> }
>
> actually i strongly disagree. people should be aware of the language's
> evaluation and execution semantics. there is no such thing as an implicit
> block with deferred evaluation as in C or java, and catching some special
> cases makes things inconsistent, harder to understand and uglier (as in less
> beautiful).

What is inconsistent about this? And if you think the error message is
"harder to understand" than SC locking up with a beachball, then I'm
puzzled. I think of it as educational about the language's evaluation
and execution semantics. No?

Dan

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Eric Lyon]

I agree with Dan. From a user perspective "if" and "while" in SC are already relatively inconsistent in their behavior, certainly when compared to the equivalent control structures in C syntax. Protecting the user from the worst effects of some very understandable confusion at early stages of learning SC is an excellent idea.

Eric

On Sat, Jun 28, 2008 at 12:39 PM, Dan Stowell <danstowell@...> wrote:

2008/6/28 stefan kersten <sk@...>:

> On 28.06.2008, at 11:09, Dan Stowell wrote:
>>
>> Anyone disagree with the addition of something like this?
>>
>> + Boolean {
>> while {
>> ^"While was called with a fixed (unchanging) boolean as the condition.
>> Please supply a function instead.".error;
>> }
>> }
>
> actually i strongly disagree. people should be aware of the language's
> evaluation and execution semantics. there is no such thing as an implicit
> block with deferred evaluation as in C or java, and catching some special
> cases makes things inconsistent, harder to understand and uglier (as in less
> beautiful).

What is inconsistent about this? And if you think the error message is
"harder to understand" than SC locking up with a beachball, then I'm
puzzled. I think of it as educational about the language's evaluation
and execution semantics. No?

Dan

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[andrea valle-3]

Well, I'm not against the warning per se, but freezing SC has made understanding a lot of things...(Routines without a wait!)

I think it's a question of policy.

SC is not so verbose. Or we keep it as it is or we decide to raise a lot of warnings (e.g. all the times it fails silently). Otherwise it is difficult to understand the ratio

just 2c from a user perspective

-a-

On 28 Jun 2008, at 13:56, Eric Lyon wrote:

I agree with Dan. From a user perspective "if" and "while" in SC are already relatively inconsistent in their behavior, certainly when compared to the equivalent control structures in C syntax. Protecting the user from the worst effects of some very understandable confusion at early stages of learning SC is an excellent idea.

Eric

On Sat, Jun 28, 2008 at 12:39 PM, Dan Stowell <danstowell@...> wrote:

2008/6/28 stefan kersten <sk@...>:

> On 28.06.2008, at 11:09, Dan Stowell wrote:
>>
>> Anyone disagree with the addition of something like this?
>>
>> + Boolean {
>> while {
>> ^"While was called with a fixed (unchanging) boolean as the condition.
>> Please supply a function instead.".error;
>> }
>> }
>
> actually i strongly disagree. people should be aware of the language's
> evaluation and execution semantics. there is no such thing as an implicit
> block with deferred evaluation as in C or java, and catching some special
> cases makes things inconsistent, harder to understand and uglier (as in less
> beautiful).

What is inconsistent about this? And if you think the error message is
"harder to understand" than SC locking up with a beachball, then I'm
puzzled. I think of it as educational about the language's evaluation
and execution semantics. No?

Dan

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

--------------------------------------------------

Andrea Valle

--------------------------------------------------

CIRMA - DAMS

Università degli Studi di Torino

--> http://www.cirma.unito.it/andrea/

--> http://www.myspace.com/andreavalle

--> andrea.valle@...

--------------------------------------------------

"

Think of it as seasoning

. noise [salt] is boring

. F(blah) [food without salt] can be boring

. F(noise, blah) can be really tasty

"

(Ken Perlin on noise)

[Eric Lyon]

It seems to me that SC is not completely taciturn either. If evaluate:

"Am I verbose?".normalize

SC informs me that:

ERROR: Message 'linlin' not understood.

RECEIVER:

   Character 65 'A'

ARGS:

   Character 32 ' '

   Character 118 'v'

   Float 0.0   00000000 00000000

   Float 1.0   3FF00000 00000000

CALL STACK:

DoesNotUnderstandError:reportError   15949D10

arg this = <instance of DoesNotUnderstandError>

Nil:handleError   15949CB0

arg this = nil

arg error = <instance of DoesNotUnderstandError>

Thread:handleError   15949BF0

arg this = <instance of Thread>

arg error = <instance of DoesNotUnderstandError>

Object:throw   15949B90

arg this = <instance of DoesNotUnderstandError>

Object:doesNotUnderstand   15949B30

arg this = $A

arg selector = 'linlin'

arg args = [*4]

< FunctionDef in Method Collection:collectAs >   15949AD0

arg elem = $A

arg i = 0

ArrayedCollection:do   15949A70

arg this = "Am I verbose?"

arg function = <instance of Function>

var i = 0

Collection:collectAs   159E65B0

arg this = "Am I verbose?"

arg function = <instance of Function>

arg class = class String

var res = ""

Interpreter:interpretPrintCmdLine   1591F230

arg this = <instance of Interpreter>

var res = nil

var func = <instance of Function>

var code = ""Am I verbose?".normalize"

Process:interpretPrintCmdLine   15949A10

arg this = <instance of Main>

-Eric

[stefan kersten-2]

On 28.06.2008, at 13:39, Dan Stowell wrote:

> 2008/6/28 stefan kersten <sk@...>:
>> On 28.06.2008, at 11:09, Dan Stowell wrote:
>>>
>>> Anyone disagree with the addition of something like this?
>>>
>>> + Boolean {
>>> while {
>>> ^"While was called with a fixed (unchanging) boolean as the  
>>> condition.
>>> Please supply a function instead.".error;
>>> }
>>> }
>>
>> actually i strongly disagree. people should be aware of the  
>> language's
>> evaluation and execution semantics. there is no such thing as an  
>> implicit
>> block with deferred evaluation as in C or java, and catching some  
>> special
>> cases makes things inconsistent, harder to understand and uglier  
>> (as in less
>> beautiful).
>
> What is inconsistent about this?

as has been noted before, 'while' expects an object as a test, that  
responds
with a Boolean when being sent the 'value' message. this 'protocol'  
would be
broken with your change, i.e. in a way a total function (which isn't  
total,
because not every object returns a Boolean, but that's a different  
story), is
made partial. that's what i'd consider inconsistent.

i think that detecting possible sources of infinite loops for some  
limited
number of special cases is a waste of time; instead the interpreter  
should be
made interruptible, so that programming errors don't lock up the whole
virtual machine and can be examined and fixed more easily.

just my 2 cents as always ;)

<sk>


_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/