HPInc / HP-Digital-Microfluidics

HP Digital Microfluidics Software Platform and Libraries
MIT License
2 stars 0 forks source link

Revisit scoping for parallel blocks #226

Open EvanKirshenbaum opened 5 months ago

EvanKirshenbaum commented 5 months ago

Currently, parallel blocks, like sequential blocks, introduce a new scope for variable names. When working on the OSU macros (#215), I found myself having to write

  drop AB;
  drop CB;
  drop DB;

  [[
    AB = combine_drops(wA, wB, mixing_time);
    CB = combine_drops(wC, wB, mixing_time);
    DB = combine_drops(wD, wB, mixing_time);
  ]]

  extract(DB, ep);
  extract(CB, ep);
  extract(AB, ep);

because if I declared AB, etc., when they are initialized, they wouldn't be available when I needed to use them in the call to extract().

Thinking about it, there really isn't any good reason for the new scope. If any of the parallel statements is a variable, the declared name wouldn't be visible until the following statement, which doesn't exist. So it looks as though it would be safe to use the calling scope and say

  [[
    drop AB = combine_drops(wA, wB, mixing_time);
    drop CB = combine_drops(wC, wB, mixing_time);
    drop DB = combine_drops(wD, wB, mixing_time);
  ]]

  extract(DB, ep);
  extract(CB, ep);
  extract(AB, ep);

The only downside I can think of is that the name would be visible in the following parallel blocks, although it would (probably) not have a value yet. It's possible that the ability to say

[[
  int x = foo();
  x = bar();
]]

and have them race one another for the assignment may be problematic enough to want to rule it out.

I guess I could special case it and simply export any top-level declarations in a parallel block to the external scope but not have them be visible in other branches.

This will warrant some more thought.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 01, 2023 at 4:43 PM PST.