{"action":"opened","issue":{"url":"https://api.github.com/repos/JeroenBos/ASDE/issues/23","repository_url":"https://api.github.com/repos/JeroenBos/ASDE","labels_url":"https://api.github.com/repos/JeroenBos/ASDE/issues/23/labels{/name}","comments_url":"https://api.github.com/repos/JeroenBos/ASDE/issues/23/comments","events_url":"https://api.github.com/repos/JeroenBos/ASDE/issues/23/events","html_url":"https://github.com/JeroenBos/ASDE/issues/23","id":187686103,"number":23,"title":"Design: Name","user":{"login":"JeroenBos","id":15310631,"avatar_url":"https://avatars.githubusercontent.com/u/15310631?v=3","gravatar_id":"","url":"https://api.github.com/users/JeroenBos","html_url":"https://github.com/JeroenBos","followers_url":"https://api.github.com/users/JeroenBos/followers","following_url":"https://api.github.com/users/JeroenBos/following{/other_user}","gists_url":"https://api.github.com/users/JeroenBos/gists{/gist_id}","starred_url":"https://api.github.com/users/JeroenBos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JeroenBos/subscriptions","organizations_url":"https://api.github.com/users/JeroenBos/orgs","repos_url":"https://api.github.com/users/JeroenBos/repos","events_url":"https://api.github.com/users/JeroenBos/events{/privacy}","received_events_url":"https://api.github.com/users/JeroenBos/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-11-07T11:19:18Z","updated_at":"2016-11-07T11:19:18Z","closed_at":null,"body":"Questions I have regarding `Name`:\r\n\r\n- Should `INameInstance` derive from `INotation`, or should `Name`? And how does this relate to `IFixedNotation`?\r\n- What is a `Name`?\r\n- Does `Name` need a tree structure?\r\n- Does `Name` have the responsibility of distinguishing wrapped vs unwrapped notations?\r\n- Does `AtomicName` need to be a notation? It only implemented `INotationForm`. \r\n\r\n#### Option 1:\r\n\r\nMake `Name` a fixed notation with a property `Form` of type `INameInstance`.\r\nIn that case `INameInstance` must implement `INotation`. Ugly. \r\n\r\n\r\n#### Option 2:\r\n\r\nLet `Name` be a type of the form `FixedNotation`, such that it contains the `INameInstance` but implements the members of `INotation` itself. But the `ResultingDomain` is known, so then it should derive from `IFixedNotation`. In that case a Name is a wrapper around a name instance making it suitable for consumption by the `ASTBuilder`, and a tree structure is not required (because that resides in the `INameInstance`). \r\n\r\n\r\n\r\n\r\n#### AtomicName is not really a notation:\r\nBecause it doesn't implement the method INotation.SelectElements. Does the NameInferrer have that responsibility?\r\n\r\n\r\n#### Is the ASTBuilder used at all for inferring names? No. So INameInstance nor INameInstance needs to derive from INotation. \r\n\r\nNames and Notations are similar in that they both represent a mathematical shape. The name is restricted to constant shapes with characters explicitly appearing, whereas a Notation is more general than that. Their overlap is represented in the type `INameInstance`, which are the parts in a shape that constitute it (by specifying their positions). \r\n\r\nCurrently, it's implemented that the `NameInferrer` infers names and _afterwards_ the results are thrown in an `ASTBuilder`. I guess I had originally thought that this was more involved. I wanted the `ASTBuilder` to be responsible for inferring names out of its constituents. That explains why the ASTBuilder had functionality of selecting notions for each node. That would have been used if a parse attempt failed, so that another possible meaning of characters was attempted. Unfortunately, that doesn't go well with the idea that the notion of a node can be determined solely from its constituents. I like that independency. If the notion of a series of characters depends on its context (i.e. whether the outer parts of the AST node can be built depending on which notion is chosen), that's not very statically-typed like. Now there's a phase that preselects some names and then tries to build and AST assuming that. Later, other preselections may be tried. This may result in the same effect (that the notion is chosen depending on how whether the AST is constructible).....\r\n\r\nThe ASTBuilder couldn't do what the NameInferrer does because the ASTBuilder succeeds when the input is reduced to a single node, whereas the NameInferrer merely needs to understand each input, and can have a multi-node output. On the other hand, this could have been achieved by having a notation that takes the input only if all parts are understood (collapsing them), but this is ugly and not really relevant because it's not implemented like that. \r\n\r\n"}}
{"actor":{"display_login":"JeroenBos"}}