Output and next statement

[Neil Fraser]

Currently blocks may contain both a left output and a next statement connector:

Although this is technically legal, the Block Factory has never allowed this combination.  There are no known blocks of this shape in any Blockly instance.  We'd like to formally disallow this combination, raising an error if such a block is loaded.  Is there anyone out there using this block?  Can anyone think of why it should be allowed?

Note that the block below is perfectly legal and will continue to be.  App Inventor uses a block like this as one of their conditionals.

​

--

Neil Fraser, Software Engineer
Google, Mountain View, California

[Alistair Lowe]

I agree. The notion of returning information yet continuing is a confusing one and likely sends the wrong message. It reminds me a little of Javascript Closures... so I guess it could be used in this kind of manner but I don't really think they have a role outside of JS.

[Carlos Pereira]

Can you have a "before block" as well? The only reason I've ever though about having a block similar to this is when there are function calls added as blocks (so I am not referring to creating a function in Blockly) where most of the time the return value is ignored, but can still be useful to save it in a variable for whatever reason.

[Neil Fraser]

No, having both a previous statement tab and an output tab is strictly disallowed in Blockly.  That's not just a UX choice, it is core to the block model.

Ignoring return values is an interesting problem.  One approach is to mutate a block so that the shapes change as needed.  See the two block below as an example, they are actually the same block, but change depending on the dropdown setting.

​Another approach is to create a 'pipe block' that eats the value.  App Inventor version 1 had this block, but i don't see it in the latest version.  It looked like this:

​

--
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.

--

Neil Fraser
https://neil.fraser.name

[Matthieu Muffato]

Hi Neil,

I agree with your proposed change in a software-development context, but
we use Blockly differently.
We have started using Blockly to make a GUI to design workflows and
generate a plain-text config file. In this context, the connectors don't
have the same meanings (output / next statement) but are rather chosen
to make the workflow look good. I can't remember if there was a
technical reason why we didn't choose the other block (the "callback
block"). I would have to dig into the code to check that.

Matthieu

On 19/09/15 00:05, Neil Fraser wrote:
> No, having both a previous statement tab and an output tab is strictly
> disallowed in Blockly. That's not just a UX choice, it is core to the
> block model.
>
> Ignoring return values is an interesting problem. One approach is to
> mutate a block so that the shapes change as needed. See the two block
> below as an example, they are actually the same block, but change
> depending on the dropdown setting.
>

> ​Another approach is to create a 'pipe block' that eats the value. App
> Inventor version 1 had this block, but i don't see it in the latest
> version. It looked like this:
>
> ​
>

> On 18 September 2015 at 13:15, Carlos Pereira <carlos...@gmail.com

> <mailto:carlos...@gmail.com>> wrote:
>
> Can you have a "before block" as well? The only reason I've ever
> though about having a block similar to this is when there are
> function calls added as blocks (so I am not referring to creating a
> function in Blockly) where most of the time the return value is
> ignored, but can still be useful to save it in a variable for
> whatever reason.
>
>
>
> On Thursday, 17 September 2015 19:44:22 UTC+1, Neil Fraser wrote:
>
> Currently blocks may contain both a left output and a next
> statement connector:
>

[Neil Fraser]

So just to confirm, you do have the output and next statement combination in your existing blocks?

BTW, I'd love to see a screenshot of this.  Feel free to email fra...@google.com if you don't want to post to the group.

--
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.

[Matthieu Muffato]

Yes we use both in the same block.

The prototype is on github:
http://muffato.github.io/eHive-Blockly/index.html

In short, an eHive workflow is a graph of analyses. The edges are
directed and are labelled with a "branch number".
A usual run of a workflow starts by a "seed" job in an analysis that
will run, trigger events on such branches (also called "dataflow") and
percolate through the graph. We use eHive to manage many of our
bioinformatics / genome analysis workflows, but eHive can work as well
with any kind of automated workflow.

The best is probably to paste the following JSON structure in the edit
box on the right and click the button to render it:
{
"pipeline_name": "pipeline name",
"pipeline_analyses": [
{
"analysis_name": "analysis_1",
"module": "Hive::RunnableDB::SystemCmd",
"analysis_parameters": {
"key_0": "value_0"
},
"dataflows": [
{
"branch_number": "1",
"target_chain": [
{
"analysis_name": "analysis_4",
"module": "Hive::RunnableDB::SystemCmd"
}
],
"semaphore_fan": [
{
"branch_number": "2",
"target_chain": [
{
"analysis_name": "analysis_5",
"module": "Hive::RunnableDB::SystemCmd"
}
]
}
]
},
{
"target_ref": "analysis_2"
}
]
},
{
"analysis_name": "analysis_2",
"module": "Hive::RunnableDB::SystemCmd"
}
]
}


The purple block is the one you proposed to ban from Blockly.
This interface is very much work-in-progress and may change. We worked
quite a lot on that in November / December last year, but we moved on to
other things this year. We plan to come back to using Blockly later on.
I'm very pleased with the Zooming feature, because several of our
workflows have >50 or even >100 analyses and are difficult to render,
but we haven't had time to try it yet.


All the best,
Matthieu

On 19/09/15 01:29, Neil Fraser wrote:
> So just to confirm, you do have the output and next statement
> combination in your existing blocks?
>
> BTW, I'd love to see a screenshot of this. Feel free to email

> fra...@google.com <mailto:fra...@google.com> if you don't want to post

> to the group.
>
> On 18 September 2015 at 17:11, Matthieu Muffato <muf...@ebi.ac.uk

> <mailto:carlos...@gmail.com

> <mailto:blockly%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Neil Fraser
> https://neil.fraser.name
>

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

> <mailto:blockly+u...@googlegroups.com>.

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

--

Matthieu Muffato, Ph.D.
Ensembl Compara and TreeFam Project Leader
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus, Hinxton
Cambridge, CB10 1SD, United Kingdom
Room A3-145
Phone + 44 (0) 1223 49 4631
Fax + 44 (0) 1223 49 4468

[Austin Bart]

BlockPy has a few places where it'd be great to do a previous+output (since it's more common in python to have a function that optionally returns a value but can also work like a statement), but I've learned to live without since its apparently impossible by design. In the most recent version, we have a "pipe block" (or rather, an "empty block") that allows you to use an expression block as a statement in a nested block - however, the course instructor using blockly was not a big fan of having to explain that mysterious block to students (we haven't deployed yet, so no word yet on whether any students will actually be confused by it). I don't know if we'll keep having that block, but I don't know of a better way of treating expression blocks as statements.

~Cory

[Mark Friedman]

The version of the 'pipe block' in App Inventor 2 looks like this:

​-Mark
​

[Carlos Pereira]

Thanks for pointing out App Inventor's solution to the ignore the return problem, I've considered something like that myself, but it just seems way to verbose and unclear for  anybody not already familiar with programming principles. Having a mutator seems like a better solution, but it still feels quite verbose, it's not a natural action if you have to explain it on the block (although it does work in the case illustrated be Neil with lists, as the action has to be described anyway).

Just a thought, we could implement a mutator that changes when it reaches a "connection radius". So we could have a block set to a default state on the toolbox (output, or before and after blocks), that could mutate on-the-fly as it approaches a connection of the other type of state.

[Neil Fraser]

Mid-drag mutation is an interesting idea, haven't seen that before.  I'm not sure that it would be discoverable by users.  Worse, if users did discover it, they might start dragging all kinds of blocks around hoping for a mutation.  To make mid-drag mutations work there would have to be a visual indication of the non-existant output tab.  Maybe have the tab ghosted (semi-transparent) or something.

[Carlos Pereira]

I completely agree with the visual clue and semi-transparent connectors could probably do the job, although it could be quite hard to notice connectors that dig into the block (like the previous block connector and inputs). What if the block had all connectors visible while it's on its own and while it is dragged and then mutate it to show only the relevant connectors once it gets close to a "snap area"?

[Erik Pasternak]

If blocks with previous and output end up being supported would it need to be a mutator or would it be better to update the Blockly UI to render both when detached and one or the other when attached?

[Jay Bloodworth]

I submitted a patch about a year ago to replace or supplement mutator based lists with self mutating ones that simply grew and shrank as blocks member were connected and disconnected. It was rejected, but for what it's worth that kind of interface feels a lot more intuitive to me than explicit mutation.

In any event, I think Blockly could stand to support a few more visual metaphors for common coding idioms. I've been thinking lately about how you might handle object orientation in Blockly, defining and accessing custom properties and methods within the block model. Haven't figured it out yet.

Jay