Interface for input

[gsvgit]

Create an interface for input data.

• Generalization of linear and graph-structured data
• Should be as general as possible
  Seems, that next functions are required.
• Get outgoing tokens by position
• Convert edg label to token
• Convert vrt label to token

[darthorimar]

It is already done but in kinda other way, take a look at https://github.com/YaccConstructor/Meerkat/blob/master/core/src/main/scala/org/meerkat/input/Input.scala
PS, Three last methods are for compatibility purposes and will be removed soon

[gsvgit]

@darthorimar Some comments:

• Edge label type is type parameter, but node is not. Node label should not be fixed as int.
• filterEdges, checkNode looks like some pieces of knowledge about parsing algorithm internal structure. It is a bad idea. Out edges and tokenizer function looks more intuitive for external users and may be internally composed as required function.
• I'm not sure that start position should be a part of Input. For string it is required, but not for a graph. Moreover, it should not be fixed to 0 for a graph.
• What is "length" for agraph? May be "edgesCount"?
• I'm not sure that last methods should be removed. It may be useful for semantic calculation.

[darthorimar]

@gsvgit

• Edge and node label have the same type parameter L, it can be Int, String or anything else
• filterEdges, checkNode are just for optimization purposes. First one just returns all edges with given label and checkNode checks if label of node with specific id equals to a given one. IMHO, nothing about internal structure is shown. Or do you want to unify it with YC approach? :-)
• Start position is for compatibility purposes too :)
• Yeah
• Substring may be useful, yeah, but it is not obvious how to implement it for graphs. Maybe there will be no need in it, have not looked deep in implementation of semantics yet

[gsvgit]

@darthorimar (@ilya-nozhkin @kajigor) Well. Seems that interface should be discussed in more details. And redesigned.

Let suppose that we should not support linear-input specific features.

Firs idea. As far as token is just a function for shecking some properties of element at specified position in input (when I specify tok("a") in grammar, I meens that it should be checked wheter w.[i] = "a" for appropriate i), I want to generalize "tokens" to functions for properties checking. Smthg like this:

// Suppose that we have the input graph of type Graph<Vrt, Edg>
val isOne (v:Vrt) = v.f1 = 1
val isB (e:Edg) = e.f2 = "B"
val S = V(isOne) ~ S ~ E(isB) <|> V(isOne) ~ E(isB)

Looks like generalization of "filterEdges"

Next. The return type of each combinator should be a LazyCollection<Path<Vrt, Edg>>, where path is a sequence of vertices and edges. A partial path can eds with edge or vertex, vertices and edges should be in a right order, and combinators for some vertices can be omitted: V(isOne) ~ V(isOne) is incorrect, but E(isB) ~ E(isB) is correct. These constraints should be fixed in types.

[darthorimar]

Makes sense, see #34