Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for automatic ports #57

Open
dancrumb opened this issue Jun 8, 2016 · 9 comments
Open

Add support for automatic ports #57

dancrumb opened this issue Jun 8, 2016 · 9 comments

Comments

@dancrumb
Copy link

dancrumb commented Jun 8, 2016

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

jpaulm commented Jun 8, 2016

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

@dancrumb
Copy link
Author

dancrumb commented Jun 8, 2016

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
Copy link
Contributor

chadrik commented Jun 8, 2016

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
Copy link
Author

dancrumb commented Jun 8, 2016

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
Copy link
Contributor

chadrik commented Jun 8, 2016

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
Copy link
Author

dancrumb commented Jun 9, 2016

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 [email protected] 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
Copy link
Contributor

chadrik commented Jun 9, 2016

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

jpaulm commented Jun 9, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants