imp1/blossom

The graph-based programming language (and its first interpreter)

blossom's Issues

Should default label matching allow for any other label items?

Currently in the spec, it says the following:

Both nodes and edges can have labels, which are lists. These lists can contain integers (no signifier), strings (wrapped in quotation marks), colours (prefixed with a hash sign). A label may also contain the keyword 'empty', meaning the list must have no value in. To only match the first item in the label list, you can specify that it can be followed by other values you don't care about with the . (5, ) will match a list beginning with 5. The * also can match nothing, so the list might also possibly just contain 5. Likewise, (, 5) will match a list ending with a 5, and (, 5, *) will match a list that contains a 5 at any point.

Should it be changed so that the contect of the label is unimportant, and so all labels are (*, whatever, *)?

Rule Applications

A rule's initial graph needs to comparable with a host graph to see if it matches, and if so, which nodes match with which.

Add tests

Add more tests to test the more intricate stuff I'm doing now.

• Test for a rule rule r1 [ 1, 2 | 1->2, 1->2 ] => [] against graph [ 1, 2 | 1->2 ]. Should this match? Make a test for it either way.
• Tests with variables just in edge labels.
• Tests for adding nodes.
• Tests for adding edges.
• Tests for changing an edge's label.
• Tests for changing an node's label.
• Tests for other features examples/split_string.blsm use.
• Tests for rational literals
• Tests for converting between rationals / reals / ints

Variable reuse in match graph

Should a variable be allowed to be reused in a rule's match graph?
If so, they should all be the same value (and if not, then not a match). And this needs explaining.
If not, then this needs documenting somewhere.

Outputting options

have an option for keeping rationals in the outputted graph's labels

edges do not persist

Edges are removed and added again. As such their labels are not 'unchanged', and only contain what is in the resultant graph. So the below table, which is nice and consistent, needs rethinking.

	Graph	Rule Match Graph	Rule Result Graph (New)	Rule Result Graph (Existing)	(How to achieve)
empty label	empty	any	empty	unchanged	empty
empty label value	void	any	empty	unchanged	void
empty label markset	unmarked	any	empty	unchanged	unmarked / ¬

Edges in the rule's result graph are never 'existing' edges. They're always new, and so empty labels for them will always be empty.

Is this a problem? That their markset cannot be maintained (because their value can).

rename uedge to adjacent

This says that two nodes connected by a single edge are adjacent.
It also says that a node connected to an edge is incident to that edge.

Rule Application Choices

should the non-deterministic rule application choice ({r1, r2}) choose one that can succeed over ones that will fail?
{a, b}! could loop 0 times because b can't be applied, whereas a can be applied. This feels odd.
The Check_Forest example on the York Plasma GP wiki page seems to suggest that a rule that can succeed would take priority over those that cannot.

This needs clarifying I think.

Success vs Valid

Currently the only check that a rule application has been successful is whether the resultant graph is valid.

Is it a good idea to allow rules to explicitly result in the invalid graph? If so, is that successful? If so, then some other measure of success is needed.

Type checking

Perhaps all the places where parameters are passed and declared in the parser/interpreter is a bit much.
Reduce this as much as possible.

And then, check types and raise errors when there are errors, as early as possibly.

Try It Online!

Have a look at what server hosting options there are that would allow for my own ruby web server.
And then clone the interpreter there and hook it up to a simple web page that runs blossom code.

Stricter Language Enforcement

• No ¬markname marks in any label's markset in a normal graph (not a rule's graph).
• No duplicate node ids in a graph.
• No duplicate variable names in a rule's parameter list.

Documentation

Write up the documentation a bit nicer, like.
Take inspiration from Rust, Hexagony, even Jelly.
And maybe some other other languages, and the York Uni's GP wiki page.

Decide on a license as well.

Graphical editor

GP had a graphical editor (albeit a terrible one).
Think about some designs for a graphical editor for blossom programmes.

Graph-conversion mode of blossom

Have a flag which just converts the supplied graph to the desired output.
Essentially this just performs a single noop as the programme.

Rework printer to be for specific formats

The current printer converts a graph to a string in some more-or-less ad-hoc way.
Rename it to BlossomFormatter (or something), and have it output a graph string in the blossom format.
Then add another DotFormatter which outputs a graph string in the dot format.

Matching on INVALID

Should it be possible for a rule to match on the invalid graph?
It would mean that rules can 'rescue' a programme back into a sensible state.
The downside would be that were this not the case, a programme could return immediately upon hitting an invalid graph.

Blossom Usage

Print usage of blossom command-line on help command, and maybe a more brief one for a specific command on incorrect usage of it.

Keywords for true/false

Maybe there should be an invalid keyword (if there isn't already) that is the equivilent of FALSE, and can be used in if/with statements. Or as a exit(1). There could also be a noop keyword which returns the current graph (so if it's a valid graph, this will return "true") that could also be used in if/with statements. There's already a NOOP instruction, so the keyword could just reference that. And it would be a simple matter of making an INVALID instruction that always returns the invalid graph, and having the invalid keyword referencing that.

Rational type

Are rational literals parsed? Are integer division results returning a rational or an integer? If a rational (which I think is preferable), is there an integer division operator? Or a floor function?

Edge variable matching

Variables' values can't be calculated if they only exist in an edge's label.

rule r1
    <int x>
    [1, 2 | 1->2 (x), 2->1 (x)]
 => [];

If there are two edges from node A to node B with values 3 and 4, and one from node B to node A with value 4, then the edges with value 4 should be matched, right? But this currently isn't possible.

---

Also, there's a step where a possible matching is only kept if all the mappings it has have valid (read: equal) variable values. Edges can't be checked in the same way. Maybe check that the count of edges between two rule nodes with variable labels is equal to (or less than) the count of edges between two graph nodes with the same value of the right type. But this condition should be checked for all possible variable values, which may be more than one per matching (see above)

Label Restructuring

Marksets on an edge's label are not maintainable. At all. This seems bad to me, as the label's value is maintainable, using a variable. Should there be a convenient way to reference a markset? This seems like a lot of additional complexity (is a markset its own type? is it an array of marks, which are their own type?).

Perhaps marksets should be gotten rid of. Is a single label value enough? Another type (colour or style or something) could be added.

Maybe it needs to be a list of values. But then the same problem arises, there's no way to keep the rest-of-the-list of an edge's label. Only whichever variable you've matched on.

What's the use case for multiple values?
I think I can see a use-case for having both a value, and some styling/debugging information, or some marker of a 'head' node or edge. And maybe the current markset is fine for that goal.

Implement the Blossom Algorithm

Write a programme that implements the blossom algorithm. Just because of the name.

Marks only internal?

Should marks be deleted when creating a final output graph? And if so, should they not be expected in a host graph?

This would mean that they would be only internal to blossom programmes, which seems fine.