Inline variable declarations

[Nathaniel Virgo-2]

Hi List

Just a random question:  Why doesn't the SuperCollider language allow inline variable declarations (i.e. 'var' statements not at the top of a function block)?  Even ANSI C allows them these days... Is there an argument against it?  Is it something that could be considered for implementation?

I understand that the reason might have to do with the efficiency of parsing and interpreting code, but inline declarations would be of benefit people doing live coding as it would allow code like this:

{
   var sig;
   sig = Saw.ar;
   // more code to filter sig...

   var dry = sig;
   sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
   sig = (0.9*dry) + (0.1*sig);
}

Having to go back up to the top the current function block to declare a new variable sometimes means I fall back on interpreter variables when I shouldn't - and I've seen SynthDefs posted to this list where every line is a variable declaration, presumably to get around having to declare them all at the top otherwise.

Anyway, not a huge deal, I'm mostly just wondering what the reason is for not allowing them.

Nathaniel

[Josh Parmenter]

Why not use Environments and Environment variables?

~dry = sig;

Josh

On Jun 28, 2008, at 7:38 AM, Nathaniel Virgo wrote:

Hi List

Just a random question:  Why doesn't the SuperCollider language allow inline variable declarations (i.e. 'var' statements not at the top of a function block)?  Even ANSI C allows them these days... Is there an argument against it?  Is it something that could be considered for implementation?

I understand that the reason might have to do with the efficiency of parsing and interpreting code, but inline declarations would be of benefit people doing live coding as it would allow code like this:

{
   var sig;
   sig = Saw.ar;
   // more code to filter sig...

   var dry = sig;
   sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
   sig = (0.9*dry) + (0.1*sig);
}

Having to go back up to the top the current function block to declare a new variable sometimes means I fall back on interpreter variables when I shouldn't - and I've seen SynthDefs posted to this list where every line is a variable declaration, presumably to get around having to declare them all at the top otherwise.

Anyway, not a huge deal, I'm mostly just wondering what the reason is for not allowing them.

Nathaniel

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

[Marinos Koutsomichalis]

Hi Nathaniel,

I surely don't know how to answer your question, but surely you don't  
need to declare variables in a live coding session.. It's very awkward..

Instead you can use environmental variables or proxy spaces and  
objects.  Instead of a varible for example use an environmental one,  
and if you don't feel sure about it, don;t use the default current  
environment but one of your own.

Now about your code, I think you should use proxy spaces for  
efficiensy there, since you redefine an abject in terms of himself  
plus something else, and I guess that you would like to be able to do  
it before the actual signal starts.

Check the JTLib documentation, this exactly what it is made for.

Hope I helped




On 28 Ιουν 2008, at 5:38 ΜΜ, Nathaniel Virgo wrote:

>
> Hi List
>
> Just a random question:  Why doesn't the SuperCollider language  
> allow inline variable declarations (i.e. 'var' statements not at  
> the top of a function block)?  Even ANSI C allows them these  
> days... Is there an argument against it?  Is it something that  
> could be considered for implementation?
>
> I understand that the reason might have to do with the efficiency  
> of parsing and interpreting code, but inline declarations would be  
> of benefit people doing live coding as it would allow code like this:
>
> {
>    var sig;
>    sig = Saw.ar;
>    // more code to filter sig...
>
>    var dry = sig;
>    sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
>    sig = (0.9*dry) + (0.1*sig);
> }
>
> Having to go back up to the top the current function block to  
> declare a new variable sometimes means I fall back on interpreter  
> variables when I shouldn't - and I've seen SynthDefs posted to this  
> list where every line is a variable declaration, presumably to get  
> around having to declare them all at the top otherwise.
>
> Anyway, not a huge deal, I'm mostly just wondering what the reason  
> is for not allowing them.
>
> Nathaniel
>

_______________________________________________
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]

So maybe you (oh yes, I mean, sometimes me) would like to have a Python's style way of handling vars. 

You simply do not declare variable, but you use them.

myvar = 4

another = myvar *5

Fast and furious, but I suspect I will lead you to live crashing...:)

-a-

On 28 Jun 2008, at 16:38, Nathaniel Virgo wrote:

Hi List

Just a random question:  Why doesn't the SuperCollider language allow inline variable declarations (i.e. 'var' statements not at the top of a function block)?  Even ANSI C allows them these days... Is there an argument against it?  Is it something that could be considered for implementation?

I understand that the reason might have to do with the efficiency of parsing and interpreting code, but inline declarations would be of benefit people doing live coding as it would allow code like this:

{
   var sig;
   sig = Saw.ar;
   // more code to filter sig...

   var dry = sig;
   sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
   sig = (0.9*dry) + (0.1*sig);
}

Having to go back up to the top the current function block to declare a new variable sometimes means I fall back on interpreter variables when I shouldn't - and I've seen SynthDefs posted to this list where every line is a variable declaration, presumably to get around having to declare them all at the top otherwise.

Anyway, not a huge deal, I'm mostly just wondering what the reason is for not allowing them.

Nathaniel

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

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)

[Nathaniel Virgo-2]

Hi Marinos

I do use JitLib for a lot of things - but I often find myself wanting to declare variables within the source of a NodeProxy.  In fact the code I posted is a simplification of what my proxy sources tend to end up like.  I know that I could create another proxy for the reverb, but can be even more hassle than going to the top of the block to declare a new variable.

Perhaps I'm using JitLib in a different style from most people - but that's because my aim is not so much to code in a live situation as to go from idea to sound as rapidly as possible, without losing my creative flow.

In any case there are other situations in which inline declarations would be handy -- another point I could have made in my original post is that I find long and complex functions harder to read if all the variables are declared at the top than if they're declared inline.

Nathaniel

2008/6/28 Marinos Koutsomichalis <marinos@...>:

Hi Nathaniel,

I surely don't know how to answer your question, but surely you don't need to declare variables in a live coding session.. It's very awkward..

Instead you can use environmental variables or proxy spaces and objects.  Instead of a varible for example use an environmental one, and if you don't feel sure about it, don;t use the default current environment but one of your own.

Now about your code, I think you should use proxy spaces for efficiensy there, since you redefine an abject in terms of himself plus something else, and I guess that you would like to be able to do it before the actual signal starts.

Check the JTLib documentation, this exactly what it is made for.

Hope I helped

On 28 Ιουν 2008, at 5:38 ΜΜ, Nathaniel Virgo wrote:

Hi List

Just a random question:  Why doesn't the SuperCollider language allow inline variable declarations (i.e. 'var' statements not at the top of a function block)?  Even ANSI C allows them these days... Is there an argument against it?  Is it something that could be considered for implementation?

I understand that the reason might have to do with the efficiency of parsing and interpreting code, but inline declarations would be of benefit people doing live coding as it would allow code like this:

{
  var sig;
  sig = Saw.ar;
  // more code to filter sig...

  var dry = sig;
  sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
  sig = (0.9*dry) + (0.1*sig);
}

Having to go back up to the top the current function block to declare a new variable sometimes means I fall back on interpreter variables when I shouldn't - and I've seen SynthDefs posted to this list where every line is a variable declaration, presumably to get around having to declare them all at the top otherwise.

Anyway, not a huge deal, I'm mostly just wondering what the reason is for not allowing them.

Nathaniel

_______________________________________________
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/

[Marinos Koutsomichalis]

> In any case there are other situations in which inline declarations  
> would be handy -- another point I could have made in my original  
> post is that I find long and complex functions harder to read if  
> all the variables are declared at the top than if they're declared  
> inline.



I do agree with that.... I think that using an environmental variable  
is the easiest way to keep up with all these. The only problem I face  
is when I need to reevaluate the whole code block and get a duplicate  
process.. There will definetely be some problem... But you can  
override it by using algorithmically created environments, but I  
guess you already lost your creativity flow....

_______________________________________________
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/

[Julian Rohrhuber]

>Hi Marinos
>
>I do use JitLib for a lot of things - but I
>often find myself wanting to declare variables
>within the source of a NodeProxy.  In fact the
>code I posted is a simplification of what my
>proxy sources tend to end up like.  I know that
>I could create another proxy for the reverb, but
>can be even more hassle than going to the top of
>the block to declare a new variable.

I'd also use variables wherever I don't need any
dynamic change, keeping everything as local as
possible. Using environment variables without
need can cause hard to find bugs sometimes.


Whenever you need new variables, you can simply wrap them in a function:

{
var a = 1;
...
{ var b = 2;

        a + b
}.value

};


Btw., parametrizing audio inputs of reused
functions can sometimes be tricky, for this I use
a different environment, too:

q = ();
(
q.use {
        ~filter = { |self, key ... inputs|
                SynthDef.wrap(self[key].valueArray(inputs))
        };
        ~delay = { |input|
                { |dt=0.2|
                        DelayL.ar(input, 1, dt)
                }
        };

}
);
// in proxy space:

~out2 = { q.filter(\delay, ~x.ar) };

>Perhaps I'm using JitLib in a different style
>from most people - but that's because my aim is
>not so much to code in a live situation as to go
>from idea to sound as rapidly as possible,
>without losing my creative flow.
>
>In any case there are other situations in which
>inline declarations would be handy -- another
>point I could have made in my original post is
>that I find long and complex functions harder to
>read if all the variables are declared at the
>top than if they're declared inline.
>
>Nathaniel
>
>2008/6/28 Marinos Koutsomichalis
><<mailto:marinos@...>marinos@...>:
>
>Hi Nathaniel,
>
>I surely don't know how to answer your question,
>but surely you don't need to declare variables
>in a live coding session.. It's very awkward..
>
>Instead you can use environmental variables or
>proxy spaces and objects.  Instead of a varible
>for example use an environmental one, and if you
>don't feel sure about it, don;t use the default
>current environment but one of your own.
>
>Now about your code, I think you should use
>proxy spaces for efficiensy there, since you
>redefine an abject in terms of himself plus
>something else, and I guess that you would like
>to be able to do it before the actual signal
>starts.
>
>Check the JTLib documentation, this exactly what it is made for.
>
>Hope I helped
>
>
>
>
>
>On 28 ÉßÉÕÉ"ÉÀ 2008, at 5:38 ɁɁ, Nathaniel Virgo wrote:
>
>
>Hi List
>
>Just a random question:  Why doesn't the
>SuperCollider language allow inline variable
>declarations (i.e. 'var' statements not at the
>top of a function block)?  Even ANSI C allows
>them these days... Is there an argument against
>it?  Is it something that could be considered
>for implementation?
>
>I understand that the reason might have to do
>with the efficiency of parsing and interpreting
>code, but inline declarations would be of
>benefit people doing live coding as it would
>allow code like this:
>
>{
>   var sig;
>   sig = Saw.ar;
>   // more code to filter sig...
>
>   var dry = sig;
>   sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
>   sig = (0.9*dry) + (0.1*sig);
>}
>
>Having to go back up to the top the current
>function block to declare a new variable
>sometimes means I fall back on interpreter
>variables when I shouldn't - and I've seen
>SynthDefs posted to this list where every line
>is a variable declaration, presumably to get
>around having to declare them all at the top
>otherwise.
>
>Anyway, not a huge deal, I'm mostly just
>wondering what the reason is for not allowing
>them.
>
>Nathaniel
>
>
>
>_______________________________________________
>sc-users mailing list
>
>
>info (subscribe and unsubscribe):
><http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880>http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
>archive:
><http://www.listarc.bham.ac.uk/marchives/sc-users/>http://www.listarc.bham.ac.uk/marchives/sc-users/
>search:
><http://www.listarc.bham.ac.uk/lists/sc-users/search/>http://www.listarc.bham.ac.uk/lists/sc-users/search/

--





.

_______________________________________________
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/

[Nathaniel Virgo-2]

2008/6/28 Julian Rohrhuber <rohrhuber@...>:

Whenever you need new variables, you can simply wrap them in a function:

That's quite a good idea, I might use that one.  But I guess my original point is that things like this, or using environment variables, or putting a variable declaration on every line, all seem like slightly inelegant hacks to get around a restriction that seems somewhat arbitrary in the first place.

So I guess what I'm really interested in is the reason why all variable declarations have to be at the top of a function block, and whether it would be easy to allow them to be put in the middle of the function, as in most modern programming languages.

Nathaniel


 

{
var a = 1;
...
{ var b = 2;

       a + b
}.value

};


Btw., parametrizing audio inputs of reused functions can sometimes be tricky, for this I use a different environment, too:

q = ();
(
q.use {
       ~filter = { |self, key ... inputs|
               SynthDef.wrap(self[key].valueArray(inputs))
       };
       ~delay = { |input|
               { |dt=0.2|
                       DelayL.ar(input, 1, dt)
               }
       };

}
);
// in proxy space:

~out2 = { q.filter(\delay, ~x.ar) };

Perhaps I'm using JitLib in a different style from most people - but that's because my aim is not so much to code in a live situation as to go from idea to sound as rapidly as possible, without losing my creative flow.

In any case there are other situations in which inline declarations would be handy -- another point I could have made in my original post is that I find long and complex functions harder to read if all the variables are declared at the top than if they're declared inline.

Nathaniel

2008/6/28 Marinos Koutsomichalis <<mailto:marinos@...>marinos@...>:

Hi Nathaniel,

I surely don't know how to answer your question, but surely you don't need to declare variables in a live coding session.. It's very awkward..

Instead you can use environmental variables or proxy spaces and objects.  Instead of a varible for example use an environmental one, and if you don't feel sure about it, don;t use the default current environment but one of your own.

Now about your code, I think you should use proxy spaces for efficiensy there, since you redefine an abject in terms of himself plus something else, and I guess that you would like to be able to do it before the actual signal starts.

Check the JTLib documentation, this exactly what it is made for.

Hope I helped

On 28 ÉßÉÕÉ"ÉÀ 2008, at 5:38 É É , Nathaniel Virgo wrote:


Hi List

Just a random question:  Why doesn't the SuperCollider language allow inline variable declarations (i.e. 'var' statements not at the top of a function block)?  Even ANSI C allows them these days... Is there an argument against it?  Is it something that could be considered for implementation?

I understand that the reason might have to do with the efficiency of parsing and interpreting code, but inline declarations would be of benefit people doing live coding as it would allow code like this:

{
 var sig;
 sig = Saw.ar;
 // more code to filter sig...

 var dry = sig;
 sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
 sig = (0.9*dry) + (0.1*sig);
}

Having to go back up to the top the current function block to declare a new variable sometimes means I fall back on interpreter variables when I shouldn't - and I've seen SynthDefs posted to this list where every line is a variable declaration, presumably to get around having to declare them all at the top otherwise.

Anyway, not a huge deal, I'm mostly just wondering what the reason is for not allowing them.

Nathaniel



_______________________________________________
sc-users mailing list

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

--

.

_______________________________________________
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/

[Julian Rohrhuber]

>2008/6/28 Julian Rohrhuber
><<mailto:rohrhuber@...>rohrhuber@...>:
>
>
>Whenever you need new variables, you can simply wrap them in a function:
>
>
>That's quite a good idea, I might use that one.
>But I guess my original point is that things
>like this, or using environment variables, or
>putting a variable declaration on every line,
>all seem like slightly inelegant hacks to get
>around a restriction that seems somewhat
>arbitrary in the first place.

no, it does have implementational reasons. I
actually like it - I find it irritating to have
variables all over the place. It also does not
exactly discourage modularity..

>So I guess what I'm really interested in is the
>reason why all variable declarations have to be
>at the top of a function block, and whether it
>would be easy to allow them to be put in the
>middle of the function, as in most modern
>programming languages.

Do you have an overview of this? It seems to me
that it is rather the more c-oriented ones that
do this.

>
>Nathaniel
>
>
>
>
>{
>var a = 1;
>...
>{ var b = 2;
>
>        a + b
>}.value
>
>};
>
>
>Btw., parametrizing audio inputs of reused
>functions can sometimes be tricky, for this I
>use a different environment, too:
>
>q = ();
>(
>q.use {
>        ~filter = { |self, key ... inputs|
>                SynthDef.wrap(self[key].valueArray(inputs))
>        };
>        ~delay = { |input|
>                { |dt=0.2|
>                        DelayL.ar(input, 1, dt)
>                }
>        };
>
>}
>);
>// in proxy space:
>
>~out2 = { q.filter(\delay, ~<http://x.ar>x.ar) };
>
>Perhaps I'm using JitLib in a different style
>from most people - but that's because my aim is
>not so much to code in a live situation as to go
>from idea to sound as rapidly as possible,
>without losing my creative flow.
>
>In any case there are other situations in which
>inline declarations would be handy -- another
>point I could have made in my original post is
>that I find long and complex functions harder to
>read if all the variables are declared at the
>top than if they're declared inline.
>
>Nathaniel
>
>2008/6/28 Marinos Koutsomichalis
><<mailto:<mailto:marinos@...>marinos@...><mailto:marinos@...>marinos@...>:
>
>
>Hi Nathaniel,
>
>I surely don't know how to answer your question,
>but surely you don't need to declare variables
>in a live coding session.. It's very awkward..
>
>Instead you can use environmental variables or
>proxy spaces and objects.  Instead of a varible
>for example use an environmental one, and if you
>don't feel sure about it, don;t use the default
>current environment but one of your own.
>
>Now about your code, I think you should use
>proxy spaces for efficiensy there, since you
>redefine an abject in terms of himself plus
>something else, and I guess that you would like
>to be able to do it before the actual signal
>starts.
>
>Check the JTLib documentation, this exactly what it is made for.
>
>Hope I helped
>
>
>
>
>On 28 ÉßÉÕÉ"ÉÀ 2008, at 5:38 É É , Nathaniel Virgo wrote:
>
>
>Hi List
>
>Just a random question:  Why doesn't the
>SuperCollider language allow inline variable
>declarations (i.e. 'var' statements not at the
>top of a function block)?  Even ANSI C allows
>them these days... Is there an argument against
>it?  Is it something that could be considered
>for implementation?
>
>I understand that the reason might have to do
>with the efficiency of parsing and interpreting
>code, but inline declarations would be of
>benefit people doing live coding as it would
>allow code like this:
>
>{
>  var sig;
>  sig = Saw.ar;
>  // more code to filter sig...
>
>  var dry = sig;
>  sig = CombN.ar(sig,0.1,0.1,1); // or some more complex reverb code
>  sig = (0.9*dry) + (0.1*sig);
>}
>
>Having to go back up to the top the current
>function block to declare a new variable
>sometimes means I fall back on interpreter
>variables when I shouldn't - and I've seen
>SynthDefs posted to this list where every line
>is a variable declaration, presumably to get
>around having to declare them all at the top
>otherwise.
>
>Anyway, not a huge deal, I'm mostly just
>wondering what the reason is for not allowing
>them.
>
>Nathaniel
>
>
>
>_______________________________________________
>sc-users mailing list
>
>info (subscribe and unsubscribe):
><<http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880>http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880><http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880>http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
>archive:
><<http://www.listarc.bham.ac.uk/marchives/sc-users/>http://www.listarc.bham.ac.uk/marchives/sc-users/><http://www.listarc.bham.ac.uk/marchives/sc-users/>http://www.listarc.bham.ac.uk/marchives/sc-users/
>search:
><<http://www.listarc.bham.ac.uk/lists/sc-users/search/>http://www.listarc.bham.ac.uk/lists/sc-users/search/><http://www.listarc.bham.ac.uk/lists/sc-users/search/>http://www.listarc.bham.ac.uk/lists/sc-users/search/
>
>
>
>--
>
>
>
>
>
>
>.
>
>_______________________________________________
>sc-users mailing list
>
>
>info (subscribe and unsubscribe):
><http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880>http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
>archive:
><http://www.listarc.bham.ac.uk/marchives/sc-users/>http://www.listarc.bham.ac.uk/marchives/sc-users/
>search:
><http://www.listarc.bham.ac.uk/lists/sc-users/search/>http://www.listarc.bham.ac.uk/lists/sc-users/search/

--





.

_______________________________________________
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/

[Nathaniel Virgo-2]

2008/6/29 Julian Rohrhuber <rohrhuber@...>:

2008/6/28 Julian Rohrhuber <<mailto:rohrhuber@...>rohrhuber@...>:

Whenever you need new variables, you can simply wrap them in a function:


That's quite a good idea, I might use that one. But I guess my original point is that things like this, or using environment variables, or putting a variable declaration on every line, all seem like slightly inelegant hacks to get around a restriction that seems somewhat arbitrary in the first place.

no, it does have implementational reasons. I actually like it - I find it irritating to have variables all over the place. It also does not exactly discourage modularity..

That's a matter of taste I guess -- personally I don't like it at all.  I prefer to be able to see at a glance whether a statement is initialising a new variable or changing one that's already been declared, perhaps in a different scope.  I am interested in what the implementational reasons for the restriction are, and whether it's something that could/would be changed, assuming I can convince someone it should (in the worst case would it really be that hard to automatically shuffle variable declarations to the top of their function blocks before compiling them?).

I think modularity should be encouraged by providing good language features to enable it (SC3 does an excellent job of this), rather than by making non-modular code more awkward.

So I guess what I'm really interested in is the reason why all variable declarations have to be at the top of a function block, and whether it would be easy to allow them to be put in the middle of the function, as in most modern programming languages.

Do you have an overview of this? It seems to me that it is rather the more c-oriented ones that do this.

Neither Python, Ruby, Perl (5 or 6), Objective C, C++, Java or C# restrict variable declarations to the top of a code block, and neither does ChucK -- what other modern procedural languages are there?  (functional ones don't count because variable declaration is fundamentally different in those languages)

I think the C based ones are the most telling actually: most of C's syntax features have been inherited by other programming languages, but the implementers of these languages did not find this one useful, and even C itself has given it up.  Since SC3 also has a C-based syntax my feeling is that it should go the same way.


In summary, my argument against the restriction is that it makes code a bit more awkward to write and a bit less readable, and brings no particular benefits to the programmer.  It's a little thing, but if the argument for it is purely implementational then it seems to me that it's worth thinking about how the implementation could be changed to relax the restriction.  But, since there hasn't been much response from other people wanting the same thing I guess I'll leave it here and wait until I'm familiar enough with SC's internals to propose a patch myself.

Nathaniel

[James Harkins-2]

On Jun 28, 2008, at 10:38 AM, Nathaniel Virgo wrote:

and I've seen SynthDefs posted to this list where every line is a variable declaration, presumably to get around having to declare them all at the top otherwise.

That's a stylistic tic of mine -- but the reason has nothing to do with avoiding limitations in sc syntax. I have two reasons for it:

- atomizing parts of the UGen graph makes it easier and more fluent to plug the same UGen into multiple units later -- instead of going along with a highly nested SynthDef style, then realizing later that I need to pull something out for reuse (which is a waste of time), I choose a style that encourages reuse.

- I find SynthDefs are much more readable this way, because every part of the UGen graph gets a label (variable name) describing the purpose.

Stylistic choices, not workarounds.

hjh

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

[Dan Stowell]

2008/7/1, Nathaniel Virgo <nathanielvirgo@...>:

>
>
> 2008/6/29 Julian Rohrhuber <rohrhuber@...>:
> >
> > > 2008/6/28 Julian Rohrhuber
> <<mailto:rohrhuber@...>rohrhuber@...>:
> > >
> > >
> > >
> > > Whenever you need new variables, you can simply wrap them in a function:
> > >
> > >
> > > That's quite a good idea, I might use that one. But I guess my original
> point is that things like this, or using environment variables, or putting a
> variable declaration on every line, all seem like slightly inelegant hacks
> to get around a restriction that seems somewhat arbitrary in the first
> place.
> > >
> >
> > no, it does have implementational reasons. I actually like it - I find it
> irritating to have variables all over the place. It also does not exactly
> discourage modularity..
> >
>
> That's a matter of taste I guess -- personally I don't like it at all.  I
> prefer to be able to see at a glance whether a statement is initialising a
> new variable or changing one that's already been declared, perhaps in a
> different scope.  I am interested in what the implementational reasons for
> the restriction are, and whether it's something that could/would be changed,
> assuming I can convince someone it should (in the worst case would it really
> be that hard to automatically shuffle variable declarations to the top of
> their function blocks before compiling them?).
>
> I think modularity should be encouraged by providing good language features
> to enable it (SC3 does an excellent job of this), rather than by making
> non-modular code more awkward.
>
> >
> >
> >
> >
> > > So I guess what I'm really interested in is the reason why all variable
> declarations have to be at the top of a function block, and whether it would
> be easy to allow them to be put in the middle of the function, as in most
> modern programming languages.
> > >
> >
> > Do you have an overview of this? It seems to me that it is rather the more
> c-oriented ones that do this.
> >
>
> Neither Python, Ruby, Perl (5 or 6), Objective C, C++, Java or C# restrict
> variable declarations to the top of a code block, and neither does ChucK --
> what other modern procedural languages are there?  (functional ones don't
> count because variable declaration is fundamentally different in those
> languages)
>
> I think the C based ones are the most telling actually: most of C's syntax
> features have been inherited by other programming languages, but the
> implementers of these languages did not find this one useful, and even C
> itself has given it up.  Since SC3 also has a C-based syntax my feeling is
> that it should go the same way.
>
>
> In summary, my argument against the restriction is that it makes code a bit
> more awkward to write and a bit less readable, and brings no particular
> benefits to the programmer.  It's a little thing, but if the argument for it
> is purely implementational then it seems to me that it's worth thinking
> about how the implementation could be changed to relax the restriction.
> But, since there hasn't been much response from other people wanting the
> same thing I guess I'll leave it here and wait until I'm familiar enough
> with SC's internals to propose a patch myself.

I'm in favour of your request - it annoys me too! It slows me down
when I have to scroll further up to the top of a function to declare a
new variable. (JR's approach is fine, but for me it would be an
unnatural style.) I have never hacked around with SC's parser so not
sure how easy it is to remove the restriction.

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/