Blockly variable scope

[Neil Fraser]

It's time to think about how to handle scope properly in Blockly.  I'm looking for input.

As software engineers it is blatantly obvious to us what we expect should happen.  All languages have the same language scoping rules at a gross level.  But I've been trying to avoid falling into the trap of just doing what other languages do simply because that's what other languages do.  Blockly is designed to be simpler and more intuitive.  Maybe conventional scoping is the right way to do it, but I really want to think through alternatives before falling into that rut.

Let's start by gathering a list of options.  Forget about what's intuitive or feasible or compatible.

* All globals.

Blockly is mostly like this, but to really be all global we'd need to global-ize the procedure arguments.  Exported code could translate this:

  var a, b;

  add(1, 2);

  function add(a, b) {

    return a + b;

  }

to this:

  var a, b;

  add(1, 2);

  function add(param1_, param2_) {

    a = param1_;

    b = param2_;

    return a + b;

  }

This means that changing 'a' in the function would change its value outside (not currently the case in Blockly).

This would result in a 100% consistent experience that's conceptually extremely simple.

* All locals.

Scope is locked to the context.  There are a separate set of variables for each function and for the outside scope.  The only way to transmit information into and out of a function is to pass it in or return it.

This would also result in a 100% consistent experience that's conceptually very simple.

* Globals and locals.

There are a few ways to mix globals and locals.  One is to have all variables used outside a procedure be globals, and all variables used inside a procedure be locals (similar to JavaScript).  Another way is to choose whether each variable is supposed to be local or global (similar to Python).  Things get more complicated when variable names collide across different scopes.  This leads to bizarre behaviour in most languages:

var x = 2;
var y = 3;

function foo() { alert(x + " " + y); var x = 9; }

foo();

Both of these would result in a rather inconsistent experience.  However, as programmers this is what we are used to.

Are there alternatives to the above?  At this point I don't want to judge which ones are good or bad, I just want to know if these are our only options.  In particular, we are building a graphical programming language; is there a graphical way to represent variables that we're not currently considering?

--
Neil Fraser
http://neil.fraser.name

[gasolin]

How about add the procedure-scope variable blocks. 

The scenario is: 

When user drag a procedure into workspace (ex: 'foo' procedure), 

in flyout variables panel, there will be another two default "set foo:", "get foo:" blocks there. 

these procedure-scope variable blocks must be placed within the 'foo' procedure. (when user select the set foo:/get foo: blocks, the foo procedure block in workspace can be highlighted)

User can set global variable with usual get/set block within the 'foo' procedure, and they can use "foo:set", "foo:get" to operate as procedure local variables. Language generators can also benefit by getting more metadata from "foo:get/foo:set" blocks.

Generally it's all globals, but some variable usage are constrained by the visual design tool.

--

Fred

[Blake]

Hey all,

I've just discovered Blockly and I'm really excited.

I hope it is alright if I throw my 2 cents in here.

What do you think about defaulting the variables to local scope, but if the user tries to access them outside the scope the are defined in they are made global variables?

For example, if a user wrote code like this:

for (var a = 0; a <= 15; a++) {

  window.alert('Hello World');

}

Then later came back and added an output line, the variable would be moved to the global scope.

var a;

for (a = 0; a <= 15; a++) {

  window.alert('Hello World');

}

window.alert(a);

Even though global variables are generally considered "bad", I think this approach helps clean up the mess of variable declarations at the top of ones code, especially the ones that are never used again.

Thanks for all the great work,

Blake

[Viktor Takács]

Hi,

var x = 2;
var y = 3;

function foo(fncX, fncY) {

var locX = fncX + ' pcs', locY = fncY + 'pcs';

alert(locX + " " + locY); }

foo(x, y);

I think there are 3 main 'type' in the above example:

1.) the x and y variable declarations are outside of any other block (maybe alone in the design canvas). global

2.) the fncX and fncY variable are parameters and should be local 

3.) locX and locY var's block are connected other block NEXT_STATEMENT, and should be local.

I think we (you) could insert a dropdown local/global attribute to the setVariable block as a compiler directive and if you could automatize the behavior (to refer the above 3 main type) it could be user friendly. 

Anyway it could be as simple as default value be 'global' for the best error free newbie experience, and after the user learn the variable scope term, then he could choose the proer type. I think it could beeasily implement. The automatic behavior sould indiacate complex formal language ruleset (maybe, i'm not sure)

Therefore this attribute should be managed in the generator variable.js.

Viktor Takács

[gasolin]

Once we drag a procedures block to workspace and rename it to "foo", there will be a new "do foo" block appear in the panel.

And if you set a variable 'x' in workspace , there will be "set x/get x" block in workspace. (panel now contains: set[item], get [item], set x, get x)

My proposal is majorly effect the variable panel:

1. Once we drag a procedures block to workspace and rename it to "foo",  there will be a new "do foo" block appear in the panel. (same as current blockly behavior)

2. AND blockly will generate new "set foo:[item]/get foo:[item]" blocks in the variables panel, just below the default  "set [item]/get [item]" blocks. (panel now contains: set[item], get [item], set foo:[item], get foo:[item], set x, get x)

3. Once we drag a "set foo:[item]" block into workspace, it will be restricted to only able to be connected in the 'foo' procedure.

4. The foo:item name array will be separate from global set variables array. if we rename foo:'item' to 'y', the "set foo:y/get foo:y" blocks will appear in the panel. 

(panel now contains: set[item], get [item], set foo:[item], get foo:[item], set x, get x, set foo:y, get foo:y)

In this case, set x, set y can be used inside or outside of the foo procedure, which naturally denotes to the global variable. 

the foo:item is global variable itself, but the blockly UI restrict foo:item to be act inside of foo procedure, which let foo:item act like local variable.

--

Fred

cireyoretihw於 2012年10月29日星期一UTC+8上午12時41分43秒寫道：

sorry gasolin
but i did miss your initial response

i think your close but i need a example because i not sure how "set foo:" would apply

See comments above

 

my point is that functions should be isolated and not be able to change the global variables

now class methods are the allowed to change the class variables status

I think we'd better open mind for the variable usage of blockly rather than restricting in some language specific pattern. 

Therefore we will keep the flexibility to generate any kinds of programming languages.

 

[Andrei Faber]

I'd choose the "Globals and locals" approach, disabling variables in inner scope to have the same names as in outer scopes and thus eradicating bizarre behavior. "All locals" approach is ok too. However, I believe that the current "All globals" approach is the worst possible.

[Jason Kridner]

What was the final result? I'm looking at generating some blocks and I seem to be stuck with global-only variables---just looking to confirm that is the only way. I've got a library full of callbacks and most things web-based or physical world-based are highly focused on callbacks or events. I'd ideally have a mutator that would create a procedure that could be filled in with some helpful information for working with the local variables passed-in.

[Robrecht Dumarey]

Dear Niel,

In my exerience, when your target audience is young kids, the all globals strategy is the only feasible strategy.

It might be an idea to prohibit identifiers of (global) variables to be used as identifiers for procedure arguments at the level of the procedure definition, or vice versa.

These situations are crystal clear to even the youngest programmers:

Here c will be 4:

var a, b, c;

a=1;

b=1;

function add(param1 , param2) {

  return param1 + param2;

}

c= add(2 , 2);

Here c will be 2:

var a, b, c;

a=1;

b=1;

function add(param1 , param2) {

  return a + b;

}

c= add(2 , 2);

As soon as you start with things like

function add (a, b) {

...

}

you start confusing them.

This does not mean that they can't handle:

var a, b, c;

a=1;

b=1;

function add(param1 , param2) {

  return param1 + param2;

}

c= add(a , b);

Hope this is of any use.

kind regards,

Robrecht

[Jason Kridner]

I need to do some things asynchronously due to hardware interactions. The approach I settled on was to reassign the parameters to globals within the callback such that the user could access the data. It is a bit verbose for reference if used to learn JavaScript, but it works. 

 

kind regards,

Robrecht

On Thursday, October 25, 2012 3:16:34 AM UTC+2, Neil Fraser wrote:

It's time to think about how to handle scope properly in Blockly.  I'm looking for input.

As software engineers it is blatantly obvious to us what we expect should happen.  All languages have the same language scoping rules at a gross level.  But I've been trying to avoid falling into the trap of just doing what other languages do simply because that's what other languages do.  Blockly is designed to be simpler and more intuitive.  Maybe conventional scoping is the right way to do it, but I really want to think through alternatives before falling into that rut.

Let's start by gathering a list of options.  Forget about what's intuitive or feasible or compatible.

* All globals.

Blockly is mostly like this, but to really be all global we'd need to global-ize the procedure arguments.  Exported code could translate this:

  var a, b;

  add(1, 2);

  function add(a, b) {

    return a + b;

  }

to this:

  var a, b;

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mikhail Semionenkov]

From my prospective, a clear philosophy of the whole system should be formulated, and solution can be discussed based on it.

I see it that way:

1. Blockly shouldn't be considered as an environment for kids but environment kids can start with. Any significant programming concept should be implemented there unless it can't be done with reasonable efforts. 

2. Think Pascal: Pascal is not about sacrificing  concepts but about reaching simplicity and transparency of their forms.

3, Think 'inverted matryoshka' - start on lowest level, which looks enough self-sufficient, move to following level, which organically includes  previous one, etc.

I would consider 3 levels of variable presentation:

1) for very beginners - no procedures, no scope

2). introduction of procedures - introduction of local scope (the concept is actually very easy and intuitive: compare with first names in different families)

3). introduction of global variables, which may be referred as <scope>.<name>  (.i.e., with 'last name')

[Jos Flores]

Hi Mikhail,

I might be reading this wrong but your two paragraphs seem to
contradict each other.

In point 1 you state that all programing concepts should be
implemented, but then in 'levels of presentation' you talk about
restricting some of those concepts.

I see Blockly as a toolkit, and as such I agree that all concepts
should be represented (within reasonable effort).
Whatever you build with Blockly can incorporate the ideas you present
as 'levels of presentation'. You can have a tool that adapts to a
level, or multiple tools created for different levels, and present or
restrict the concepts you deem should be available at that level. But
I don't think that should affect the design of Blockly as a toolkit.

One of the problems we are having in App Inventor right now is the
concept of global variables. One of our programs can have several
Blockly scripts (different screens in a mobile app), so globals are
not really globals to the app, but to the screen (they really are
instance variables in Java). Some of our users with basic programming
knowledge find these globals very confusing because they are not
reachable from other screens.

So the discussion should also consider if a Blockly program can
contain more than one script. Up to now most applications I've seen
are restricted to one script, but will that be the case in the future?

cheers,
José

[M Semionenkov]

Jose,

not sure I get it correctly.

Anyway, on presentation in second part I meant presentation to students.

The system may have local variables and mechanism of global addressing scope.name out of box.

And for students it presented 3 times, as naturally developing concepts: variables. local variables, globally available variables.

If it were implemented the way I suggested, I don't see what kind of confuse it may produce. 

MS 

---

From: Jos Flores <josmas...@gmail.com>
To: blo...@googlegroups.com
Cc: ro...@neil.fraser.name
Sent: Friday, January 17, 2014 10:46 AM
Subject: Re: Blockly variable scope

[Jos Flores]

Hi Mikhail,

yes, we agree on that. I think we disagree on how we see Blockly. I
see it as a toolkit to create other applications. Those other
applications could be teaching tools, and can be created at the
different levels of presentation that you talk about for students. But
you wouldn't be using Blockly directly, you would create a tool that
uses Blockly. Does that make sense?

cheers,
José

[Mikhail Semionenkov]

I wonder how do you know know that I disagree :-)

As a matter of facts, I've already suggested to describe interface of Blockly for applications and requirements for applications, thus Blockly could be treated as a container for apps, instead of web application which should be modified for extension of functionality. 

On Friday, January 17, 2014 2:01:36 PM UTC-8, Jos wrote:

Hi Mikhail,

yes, we agree on that. I think we disagree on how we see Blockly. I
see it as a toolkit to create other applications. Those other
applications could be teaching tools, and can be created at the

different levels of presentation that you talk about for students. .

[Eric Miller]

It should be possible to encourage users to use limited-scope variables simply as a way to shorten the drop down list when accessing a variable. In any case, it is probably useful to, at least as a tooltip, give each local variable a semi-unique name ex: "foo:loop:else:myVariable", autofilled after typing myVariable and usually displayed as "...else:myVariable". This makes it always clear which local/global variable is being accessed and still uses globals in exactly the same way as the current implementation I.e. "myVariable" is still global.
This still needs some way to declare a scoped variable that isn't an argument, which could be similar to a possible commenting system that allows "tacking on" comments or variable declarations to a block (maybe by dragging the variable declaration on top of the parent of the scope it should have?)

[Eric Anderson]

I second the idea to encourage users to use limited-scope variables.  This is not a condemnation of global variables, just a voiced support of another paradigm of development.

In order to accomplish this, I suggest that blocks which create "code blocks" (e.g. loops, if/then, procedures, etc.) have a top section where local-scoped variables would be defined.  Yes, it hearkens back to the day of declaring all of your variables at the top of the procedure, but it cleanly delineates the variable declaration from the rest of the code.  And, if you don't want to use local-scoped variables, then you simply leave the section empty and continue using global variables (or higher-scoped variables).  

I also encourage an option to prevent shadowing as you go down in scope (i.e. prevent declaration of variables which are named the same as higher-scoped variables).  Make it a "blockly" option so those who wish to do so still can, while those who wish to avoid the uncertainty (I am think of those who use blockly as a training tool) can have blockly lend a helping hand.

[Mikhail Semionenkov]

One more time I would challenge declared in Philosophy problem for beginners with local variables. The concept of local variable is rather simple ("first name").

At the same time, 'all globals'  is a clear dead end to me: no serious tool can be built around it. Once a language is complex enough to have procedures, it should have local variables.

Thus, I would consider local variables a must.

Global stuff is needed for really complex development to use independently developed libraries thus may be considered optional, as long as complex development is not a goal. 

[Eric Miller]

Would it be acceptable for local variables to only exist in the context of functions? It makes the concept a little simpler to understand (never "this variable belongs to the else part, but not to the if part") and, at worst, forces users to extract code into smaller functions (generally good programming practice anyway). 

Perhaps functions should also be able to be "scoped" (nested) so users can more easily create large numbers of little-used helper functions. Perhaps this could happen automatically if a function tries to access a local variable of another function. This probably isn't necessary until Blockly starts being used for larger projects (maintaining the Linux kernel). 

On Monday, January 20, 2014 3:33:54 PM UTC-5, Eric Anderson wrote:

I second the idea to encourage users to use limited-scope variables.  This is not a condemnation of global variables, just a voiced support of another paradigm of development.

In order to accomplish this, I suggest that blocks which create "code blocks" (e.g. loops, if/then, procedures, etc.) have a top section where local-scoped variables would be defined.  Yes, it hearkens back to the day of declaring all of your variables at the top of the procedure, but it cleanly delineates the variable declaration from the rest of the code...

[Eric Anderson]

It certainly would simplify the UI insofar as not having "variable openings" on some of the more basic blocks (e.g. the IF..THEN block).  I think it is a good starting point.

Perhaps the most beautiful thing about blockly is that any of us _could_ write our own blocks with "variable openings" as we found need.  While the complexity arises when the UI displays the appropriately available variable get/set blocks, if the core functionality for "variable openings" and dependent variable get/set blocks were put in for the function/procedure block, we could model our own adaptations using it for reference.

[cireyoretihw]

i am a lazy programmer so i look for easy ways

don't let me SET local variables ... i mean never

the PULL down VARIABLE should not have any FUNCTION or BLOCK defined variable's show a SET variable that user can use

i think this is the quickest and easy way .....

like when a language dose have GOTO just don't show it to a beginner programmer and they will not get into a bad habit 

maybe its just to simple and idea

only the CREATE VARIABLE or DUPLICATE VARIABLE can turn the SET VARIABLE block on otherwise it OFF

[cireyoretihw]

this is a example of what i was trying to suggest

https://groups.google.com/forum/#!searchin/blockly/scope/blockly/QriaimURI3w/JBkkfFD4jhIJ

[zejian ju]

Dear Neil,

Prefer "Globals and Locals". Personally I like the scope style of Lua. The drop down list of items in "set [item]" and "get [item]" should be different if they appears in different context.

Regards,

Zejian Ju

在 2012年10月25日星期四 UTC+8上午9:16:12，Neil Fraser写道：

[Mark Friedman]

Have you taken a look at how App Inventor's version of Blockly treats local and global variables?

-Mark

--

You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alistair Lowe]

Hi Neil,

I think it's important to highlight your future vision for Blockly to help guide this process. In software there are many right answers and which is better often depends on the context - it's a common issue that the meaning behind why something is as it is, is lost or altered because the original reason for doing something isn't recorded. I'm looking at a lot of this from an embedded hardware point of view and my reasons and priorities will undoubtedly differ.

Ultimately, I feel that if the scope of Blockly projects are ever to grow, the use of local variables is unavoidable, whether this be via a special block or is implicitly implied. For educational purposes, I don't see why the existing behaviour can't be emulated through a flag setting, after all, all variables global is a fairly straight-forward paradigm.

As an initial thought, a potentially cleaner approach, not dissimilar to MIT App Inventor, could be to promote variables to global context:

• Normal local variables, which are likely more numerous, wouldn't need any kind of special identification, keeping the block view clean.
• The user can assume all variables to be local only unless told otherwise, keeping the paradigm simple.
• The Global Promote could potentially be placed outside of program flow, allowing for users to arrange their globals together visually, separate from their other code, keeping flow clean and globals well-tracked, a possible best-practise.
• You can avoid basic scoping issues by pre-pending variable names with the local function name if they are not globally promoted when generating code for languages where this is an issue.

Many thanks,

Alistair

[Alistair Lowe]

Adding to this, variables that are globally promoted could have their block colours changed or an icon added on-the-fly to help the user keep track of where they are using globals.

[toe...@extremenetworks.com]

We have done that with our fork (https://github.com/toebes-extreme/blockly).  Local variables get the color of a subroutine while global variables stay the variables color.
You can see that in the attached screen shot which is from the subroutine unit test case.
  -- John

[Alistair Lowe]

Something along these lines (pardon poor paint edit):

Many thanks

[Mark Friedman]

On Tue, Sep 15, 2015 at 5:04 AM, Alistair Lowe <alis...@skyiot.co.uk> wrote:

Hi Neil,

I think it's important to highlight your future vision for Blockly to help guide this process. In software there are many right answers and which is better often depends on the context - it's a common issue that the meaning behind why something is as it is, is lost or altered because the original reason for doing something isn't recorded. I'm looking at a lot of this from an embedded hardware point of view and my reasons and priorities will undoubtedly differ.

Ultimately, I feel that if the scope of Blockly projects are ever to grow, the use of local variables is unavoidable, whether this be via a special block or is implicitly implied. For educational purposes, I don't see why the existing behaviour can't be emulated through a flag setting, after all, all variables global is a fairly straight-forward paradigm.

As an initial thought, a potentially cleaner approach, not dissimilar to MIT App Inventor, could be to promote variables to global context:

• Normal local variables, which are likely more numerous, wouldn't need any kind of special identification, keeping the block view clean.
• The user can assume all variables to be local only unless told otherwise, keeping the paradigm simple.
• The Global Promote could potentially be placed outside of program flow, allowing for users to arrange their globals together visually, separate from their other code, keeping flow clean and globals well-tracked, a possible best-practise.
• You can avoid basic scoping issues by pre-pending variable names with the local function name if they are not globally promoted when generating code for languages where this is an issue.

App Inventor goes the extra steps of checking variable scoping, specifying only allowable variables in the Get (or Set) block dropdown and marking errors if you happen to drag a variable Get (or Set) block into a scope where the variable is not valid.  It also has the very convenient feature of allowing you to easily obtain a variable Get/Set block directly from the spot of the variable's definition, whether global or local.

-Mark

  

--

[Alistair Lowe]

Hi Mark,

Presumably this feature works on the assumption that you can't reuse variable names? For scalability I may very well want to use the same name as a different variable in multiple functions, hence why I'm supporting the notion of promoting variables to global, in this scenario there's no need to perform checking; the latter feature, to quickly grab a set/get, sounds very useful.

[Mark Friedman]

App Inventor lets you reuse locally scopes variable names (including procedure parameters) just fine.

-Mark

[Alistair Lowe]

Sorry, I was just trying to understand your previous comment. In the approach I suggest, variables are defined when they're first set as they currently are in Blockly (keeping the simplicity), at which point they are local to the function/proc/event they're defined in, there are no extra steps or blocks such as initialize local, keeping the paradigm and program flow nice and simple until you WANT a global, then you have to do the one extra step of declaring a global.

I think the App Inventor is of the right line of thinking, but has made things more complicated as a matter of course.

[Mark Friedman]

On Tue, Sep 15, 2015 at 1:37 PM, Alistair Lowe <alis...@skyiot.co.uk> wrote:

Sorry, I was just trying to understand your previous comment. In the approach I suggest, variables are defined when they're first set as they currently are in Blockly (keeping the simplicity), at which point they are local to the function/proc/event they're defined in, there are no extra steps or blocks such as initialize local, keeping the paradigm and program flow nice and simple until you WANT a global, then you have to do the one extra step of declaring a global.

I like the explicit initialize-local block in App Inventor because it does a couple of things nicely:

• It specifies an explicit scope for the variable.  I.e., you're not tied to function/proc/event.  This makes it similar to for-loops and similar blocks, which also define both local variables and their scope at the same time.
• It provides a nice place to hang those easy-to-use variable Get/Set blocks.

As far as I can tell it's just as simple for the user as the current Blockly default.  You still need some block to either set (in the Blockly default) or initialize (in App Inventor) the local variable.  I understand that using a scope creating block may not be as natural to developers who are familiar with JavaScript (where such a thing doesn't exist) or Python (where it's a relatively new thing, i.e. the 'with' statement).

-Mark

[Alistair Lowe]

I come from an embedded C/C++ background with experience in functional safety where there are strict standards (MISRA C for example) and best practises regarding scope so I understand well the benefits of the App Inventor approach, the reason I'm not for it though is that this isn't why I approach Blockly, when I want to get that involved, I use C or C++. For me the appeal of Blockly is its simplicity, flow clarity and on-demand nature. This ties in somewhat to why I think a mission statement / vision for Blockly is needed to guide the kind of input that we look to offer, because we all have very different opinions and preferences.

I think the problem with initialiser blocks is that it does increase that initial learning curve slightly (I was puzzled at first-look about what the 'in' part actually meant) and that they do break the visual flow of code, adding bulk. If you're consistently implicit the need for explicit identification drops-off, the main remaining benefit being that you can have sub-function scopes, but then that's not supported by all languages without some trickery at the code generation level. Whilst in C89 land or in some standards you are required to declare and ideally initialize variables at the start of their scope, I think this is forcing a requirement onto users that isn't necessarily a fit-all and ideally should be left to the user's discretion.

Alistair

[Mark Friedman]

As this discussion suggests, the choices around how to handle variable scoping have to do with the particular needs of the project that is using Blockly and the characteristics of its expected user base.  I don't really think that there is a one size all solution here.  I just brought up the App Inventor case because I know a decent bit about it, it has a significant user base (especially in the novice programmer and education areas) and it wasn't mentioned by anyone else.

-Mark

[cireyoretihw]

hold on i think everyone is missing the point that BLOCKLY is a visual user activated language

?) at the moment the USER creates GLOBAL variables ( if you would like the USER to have a way to create LOCAL variables then it might be nice )

?) at the moment the blocks in BLOCKLY create GLOBAL variables ( but i think they should only make LOCAL variables with unique naming method added to the USER  name to identify the SCOPE )

?) under the VARIABLE menu the names should be reflect if its GLOBAL or LOCAL ( if USER tries to DUPLICATE a LOCAL it should become a GLOBAL )

BUT i do suggest more should be done with the core program tools to aid the generator to build code better

[cireyoretihw]

can it be as easy to define SCOPE as

BLOCKS in BLOCKLY create only LOCAL variables which means USER cannot use SET on these variables

USERS in BLOCKLY can only create GLOBAL vaiables which have SET in the variable menu

i still think it would be great if BLOCKLY allowed user to create LOCAL variables but not sure how that can be done

I am assume the any generated code produced would make unique names variables so no conflicts happen 

[David Sabine]

So, what was decided?  Is there a document somewhere which describes how scope is handled for variables in Blockly?

If it hasn't yet been decided:

- my opinion is that all variables should be global scope. I know it's sub-optimal in terms of program design and safety, but it's how children will immediately understand the interface.

- a child will place a variable onto the canvas and immediately understand that it's available to all other elements on the canvas.

Super intuitive.

[GB-)]

So, what was decided on language scope?

It might be helpful to folks like me, who are looking at Blockly late after its initial creation, to have a policy statement defining the current and near-future scope rules. I realise they might change, and a policy statement can alert folks to that too.

My reading of this thread is there are several different good solutions which depend on context and requirements. There doesn't appear to be a 'one size fits all approach' without a clear policy. for example about Blocklies target uses.

I am interested in existing languages which have their own definition of scope.
I am analysing Blockly as a key part in a larger environment. Our goal is to introduce students to existing textual programming languages.
Our aim is to  'reduce the barrier' for students to learn, understand and use existing textual programming languages.

It is not our goal to introduce programming using a scoping model which is unusual.
We are aiming to help students build knowledge and skills which are easily transferable and reusable within textual programming languages.
Simplification is okay, idiosyncratic is likely to be more problematic. (that sounds like a mini-slogan :-)


I am willing to have more than one 'level' of language scope semantics and visual 'machinery' available through the block programming interface.
In that case, I think their should be 'perfect' subsets to avoid the need to undo understanding and intuitions.

I haven't found a statement on the decision, so I'll add my $0.2.

I would prefer one scope model, but would willingly consider two or more models.
A two model approach might be:
1. an initial model with no user-defined functions/procedures and with all global variables.
This seems to minimise the need for concepts of scope, even if the target language has it. I haven't done an adequate analysis. However, off the top of my head, for the languages I've used, I think all of them can work with this without too much added complexity. By that I mean no need for more than a one-to-two expansion of textual language for each variable. I think some may have one-to-one mapping from a blockly variable to the textual language.

2. a second model with a relatively common, traditional global/local scope.
Functions/procedures with local variables and local parameters as well as global variables, with all global function/procedure names.

So, my current view is the definition and 'visual machinery' of scope may need to be 'pluggable' or have 'alternative' implementations to support the context.

That introduces extra complexity which has a cost. I can appreciate that the Blockly team might not want to go down that path.
In that case, a clear policy statement would help folks like me.

May I add, I feel uncomfortable digging through forum posts trying to discover policy. Partly it seems like a fragile approach; I might miss something, or find something which has  been changed in other posts. I don't feel that digging though code is rapid or clear enough to discern the intended contexts and uses.

Capturing decisions in policy statements seems potentially to be quite light weight; no need to write a policy if there is no question, or the answer is clear from an existing policy or mission. (I am not a fan of wishy washy mission statements)

I apologise, and ask for tolerance, if I am describing something which is not the Blockly way to get things done.

GB-)

[Andrew n marshall]

Blockly variable blocks assume all variables are global, and this is reflect in the variable implementation of our five support code generators. This includes the function parameter variables.

We have talked about supporting optional local scoping, but there are challenges to this that keep it very far down our priority list. There is no active effort to support this.

--
Andrew

--

You received this message because you are subscribed to the Google Groups "Blockly" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blockly+unsubscribe@googlegroups.com.

[cireyoretihw]

as this continues i would  like to point out the three levels of coding  that BLOCKLY persents

first the USER using the GRAPHIC BLOCKLY tools
         were i think USER created variables should be GLOBAL
         and all variables created inside BLOCKS should NOT be GLOBAL

second raw CODE of the BLOCKLY  source
         should try and keep standards of the language it is built in

third the code generated by the different language generators
         should produce code that show how programmers should best use that language
_____________________________________________________________________

the first should be easy
         that no SET option is allowed for variables not created by USER as GLOBAL

the second & third          i suggested that treating FUNCTION like CLASS
                                      so naming can convention should look something like
         GLOBAL =  variableName                    
        
         LOCAL   = BLOCK.variableName
                        :  BLOCK.FUCTION.variableName

BTW when code is used to explain how BLOCKLY works it losses the VISUAL context so please show how it would look on screen not in text file form ....

On Wednesday, October 24, 2012 at 6:16:12 PM UTC-7, Neil Fraser wrote:

It's time to think about how to handle scope properly in Blockly.  I'm looking for input.