Add support for automatic ports

[dancrumb]

FBP defines automatic ports diagramatically and functionally, but there doesn't appear to be defined support for them in the DSL.

I propose that they be represented by an asterisk in place of an explicit name. This is in line with conventions set by JavaFBP.

[jpaulm]

Darn! I thought I suggested that too! Probably in an answer to someone else! :-) Sorry!

[jonnor]

https://github.com/flowbased/flowbased.org/wiki/Advanced-Features#automatic-ports
http://www.jpaulmorrison.com/fbp/schedrls.shtml

[dancrumb]

Perhaps this issue is in the wrong repo.

I'm talking about how we capture these ports in the .fbp DSL

Those links only appear to talk about what automatic ports do.

[chadrik]

This repo is responsible for parsing .fbp files into json data. It doesn't care about implementation-specific details such as auto-ports and their naming conventions. What is relevant to this repo is the regex used for port names. To support this we need to make the regex less strict, though we can't make it too lax or the tokenizer will break.

[dancrumb]

I feel like I'm not articulating the purpose of this ticket clearly.

My understanding is that this repo is responsible (in part) for defining what constitutes a valid .fbp file, since it defines an .fbp parser.

I agree that the implementation of automatic ports is implementation specific. However, the concept of automatic ports is not. They are a feature of a generic FBP network.

Thus, it makes sense to me that the DSL that describes FBP networks should be able to describe automatic ports.

Also, automatic ports do not have naming conventions. They are, by definition, nameless.

However, they do require notation conventions in .fbp files... hence this issue.

The regex does not need to be less strict. All this would need is some logic to recognize when the port name is a single asterisk (or whatever notation is settled on) and to understand that that represents a nameless automatic port.

Or am I missing something here?

[chadrik]

Can you explain what you think the json output should be in the case that one uses an automatic port?

The sub-document for a port produced by this project looks like this:

{
   "process": "Count",
   "port": "IN"
}

In my mind, the proper result for your case would be:

{
   "process": "Count",
   "port": "*"
}

This project does not need to know about the existence of automatic ports in order to achieve this result, it merely needs to modify the regex for allowable port names. It would then be up to a runtime to interpret the above document as an automatic port. This is not just semantics. I would argue that using * to denote an automatic port is a convention. Why require this project to form an opinion on the naming convention for automatic ports when it is not required to produce acceptable output?

[dancrumb]

Surely the goal is to have a notation that is identically understood across
all implementations?

Do you look to another source to determine how the parser should interpret
elements in this language? If so, I understand that I should bring this
request to them.

If there is no other source then there becomes a de facto standard or else
we end up with .fbp files that only work with certain parsers. This feels
like a disservice to those working with FBP.

I agree that using asterisks is just a convention, but every element in the
FBP notation is "just a convention". Surely a specification is little more
than a codification of convention to ensure that newcomers know where top
start and maverick don't unilaterally break things for others.

On Wed, Jun 8, 2016, 17:12 Chad Dombrova notifications@github.com wrote:

Can you explain what you think the json output should be in the case that
one uses an automatic port?

The sub-document for a port produced by this project looks like this:

{
"process": "Count",
"port": "IN"
}

In my mind, the proper result for your case would be:

{
"process": "Count",
"port": "*"
}

This project does not need to know about the existence of automatic ports
in order to achieve this result, it merely needs to modify the regex for
allowable port names. It would then be up to a runtime to interpret the
above document as an automatic port. This is not just semantics. I would
argue that using * to denote an automatic port is a convention. Why
require this project to form an opinion on the naming convention for
automatic ports when it is not required to produce acceptable output?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#57 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AANhT23qFJKErc8kFiW50jQn9BzjTOGDks5qJz47gaJpZM4IxCPv
.

[chadrik]

Do you look to another source to determine how the parser should interpret elements in this language? If so, I understand that I should bring this request to them.

The parser doesn't interpret the elements of the language, it parses them into a data structure that is interpreted by a runtime. I understand and appreciate what you are looking for, but I don't think this is the project that defines what you're after. Perhaps others will disagree.

I agree that using asterisks is just a convention, but every element in the FBP notation is "just a convention". Surely a specification is little more than a codification of convention to ensure that newcomers know where top start and maverick don't unilaterally break things for others.

The practical difference is that the parser does not need to know what an auto-port is to do its job, because the existence of auto-ports are not part of the .fbp syntax. For example, in python, using a leading underscore in a variable name (e.g. _foo) indicates that the variable is private. This affects the interpretation of python code (private variables are not imported when using from x import *), but private variables are not part of the python grammar / syntax in any way other than the fact that the regex for valid variable names includes underscores. Syntax vs interpretation. In this analogy, your runtime is the python interpreter.

From the perspective of an fbp parser (which this project is), adding support for auto-ports is a matter of adding another character in a regex. I don't know what other action can or should be taken other than extending the port regex. So can you be more explicit about what you think the json output should be in the case that one uses a port named "*"?

[jpaulm]

In so far as I understand this discussion, I don't see a problem with adding * to the regex as an additional option... Since the JSON does not put any further constraints on how the automatic port is coded, it seems to me that we can just carry the asterisk across unchanged...? @dancrumb, over to you...

Parenthetically, I am not sure what the current standard is for (non-*) port names: in a discussion with @bergie a few years ago, I thought he argued for simple alphameric ports, because of the potential for a Chinese network to use an English-language component, or v.v. More recently, I understood him to be arguing for a looser spec for port names - but maybe I misunderstood. Where do we stand now? Perhaps an agreed-upon regex should be (is?) part of the spec...