Examples missing

[frameworklabs]

It would be nice to have an example which demonstrates the advantages of this exciting new language.

[schorg]

Indeed. See https://github.com/boschresearch/blech/issues/1#issuecomment-573325092

[frameworklabs]

FYI - I made a small demo over in this repo: https://github.com/frameworklabs/blinker Comments welcome.

[schorg]

Your demo is perfectly fine.

2 things to mention.

1. I like to seperate concerns in separate activities in order to reduce the indentation level and to simplify testing of different concerns.

2. There is an additional way to access the environment via external memory or external functions. This allows to encapsulate environment access where it is needed and reduces the amount of parameters to be handed down from the entry-point activity to the various sub-activities.

I showed both aspects in my fork of your repository in branch comments.

I created a test program, that allows to interactively test the blinker lever

[schorg]

One more thing. Your main activity sequentializes concurrent activities moveBlinkerLever and updateBlinkerLeverFromRotation. The reason is, that both activities need to change the blinkerLeverPos. I wrote a Gist: sequentially concurrent execution where I discuss this way to organize code and propose an additional control flow statement to simplify things.

[frameworklabs]

Your demo is perfectly fine.

2 things to mention.

1. I like to seperate concerns in separate activities in order to reduce the indentation level and to simplify testing of different concerns.

Right, that makes the code better to read and to test. Is there a penalty in using too many fine grained activities or is it more or less a zero cost abstraction?

2. There is an additional way to access the environment via external memory or external functions. This allows to encapsulate environment access where it is needed and reduces the amount of parameters to be handed down from the entry-point activity to the various sub-activities.

I can see the benefit of not needing to pass data down from the entry-point especially in bigger programs. OTOH it helps testability and reuse to inject dependencies into an activity instead of them being singletons. But maybe an activity nesting like follows could allow for the best of both worlds (if needed - probably not in most cases):

activity AImpl(x: int32)
    ...
end
singleton activity A()
    extern var x: int32
    run AImpl(x)
end

I showed both aspects in my fork of your repository in branch comments.

Wow, I like those improvements! Maybe you want to open a PR to consolidate the changes.

I created a test program, that allows to interactively test the blinker lever

Are you planning to add something like "@[TestEntryPoint]" activities in the future?

[schorg]

Is there a penalty in using too many fine grained activities or is it more or less a zero cost abstraction?

Every run <activity> becomes a function call and therefore needs a stack frame and an additional program counter, to keep track of its await positions. But the code generation is currently rather simple and leaves much room for improvement and optimization in the future.

singleton activity A() extern var x: int32 run AImpl(x) end

That's a nice pattern. You have to be aware that an activity calling a 'singleton' activity becomes itself a singleton. The compiler keeps track of this and the singleton attribute can be omitted. An 'extern var' is a global variable in the environment and therefore cannot be written from concurrent threads/trails (global variables, which are not allowed to exits inside the Blech program, make a function or an activity non-reentrant).

Since the environment in many cases changes asynchronously (volatile), the Blech code reads into a copy at the beginning and writes back to the original at the end of a step.

Are you planning to add something like "@[TestEntryPoint]" activities in the future?

We are thinking about a test concept together with the module system. This should allow simple interactive tests like the given one. Or also unit tests on activities:

//test
cobegin
   run produceInputs(prev outputs)(inputs)
with
  run activityUnderTest(inputs)(outputs)   
with
  run compareWithExpectedOutputs (outputs)
end

prev outputs can be used to have feedback loops for the produced inputs.

[FriedrichGretz]

The original issue here was the lack of examples. Since the issue has been created the website was launched and contains examples as well as blog posts that showcase the use of Blech. Of course, this is an ongoing effort but I believe the original issue has now been "solved".