Commit Graph

5 Commits

Author SHA1 Message Date
Brian Picciano
9c48232ac1 Allow Graph edge and vertex values to be different types
Lots of type aliases in use with `gg` to make this not be a verbose
clusterfuck.
2021-12-30 09:56:20 -07:00
Brian Picciano
c4dd673bf4 Refactor Graph internals to deduplicate OpenEdges
This change required OpenEdges to be passed around as pointers, which in
turn required me to audit how value copying is being done everywhere and
simplify it in a few places. I think I covered all the bases.

The new internals of Graph allow the graph's actual structure to be
reflected within the graph itself. For example, if the OpenEdges of two
ValueIns are equivalent then the same OpenEdge pointer is shared for the
two internally. This applies recursively, so if two OpenEdge tuples
share an inner OpenEdge, they will share the same pointer.

This change is a preliminary requirement for creating a graph mapping
operation. Without OpenEdge deduplication the map operation would end up
operating on the same OpenEdge multiple times, which would be incorrect.
2021-12-29 13:57:14 -07:00
Brian Picciano
e7991adfaa Make graph generic
The base graph implementation has been moved into its own package,
`graph`, and been made fully generic, ie the value on each vertex/edge
is a parameterized type. This will allow us to use the graph for both
syntax parsing (gg) and runtime evaluation (vm), with each use-case
being able to use slightly different Value types.
2021-12-29 12:32:53 -07:00
Brian Picciano
c5aa582226 Improve semantics of tokens and values obtained from them.
Now gg.Values can carry the token used to parse them, which will be
useful later when generating errors.
2021-12-28 09:49:02 -07:00
Brian Picciano
33e59a3836 Implement Decoder
The decoder basically works, though there's some quirks in the design
I'll need to marinate one. For example, you can't have a tuple as an
edge value. This is probably fine?

Stringification of Graphs was added to aid in debugging the decoder, the
format it outputs is not the final one. Most likely the (future) encoder
will be used for that purpose.

The decoder is not implemented in the nicest way; it fully reads in the
LexerTokens first, and then processes. This made trying to wrap my head
around the problem a lot easier because it left fewer failure cases, but
it's not the most efficient thing to do.

Now that v0 is done it's pretty plain to see that the decoder could work
by only reading in the next N tokens that it needs at a time. But that
will be left for a future version.
2021-12-27 15:45:18 -07:00