childsplayosu / bogl Goto Github PK

Need to add a run endpoint to submit code to a running instance of spiel on the backend (at the least).

WRONG TYPE is unfriendly to users, we need really good type errors

The typechecker only checks the regular types, not any of the special board game types

The program in examples/notWorking/BadConnectFour crashes due to what appears to be a tuple order error. I think the offending line is play(a,b) = outcome(loop(a,b))

The function outcome expects type (Board, Player) but loop returns type (Player, Board).

The crash occurs due to a non-exhaustive pattern in the inARow lambda since Vboard arr cannot match a player.

This error is strange because I have tried to isolate this case of swapped parameter order in an intentionally ill-typed program but it did not typecheck, as expected. For some reason this does, so maybe the issue is something else.

Optional addition to add a saveAndRunCmds endpoint, which just performs the action of saving and then runningCommands in 1 request instead of 2.

Existing test cases need to be updated so CI can actually inform if we are making breaking changes.

We need to figure out what our templates look like. We could have like a progression from heavily templated to not-very-templated code. We also might want to write some sort of DSL for scripting user documentation lessons?

Martin indicated to use the & operation in extended types now. This would allow us to represent such things like Maybe Int as:

type Int & {Nothing}

in addition Player & {Empty} should be a type we can use for board defs (mostly sure about this one).

This should be considered completed when the:

• syntax change has been integrated
• tests have been updated to verify this syntax can be parsed to generate a valid AST

Need to output JSON so that the frontend can know what's going on

Maybe look into https://hackage.haskell.org/package/aeson?

Need to display the board with a REPL

We need user documentation, for both teachers using the language to teach students and for students to work through.

An equation like myBoard!(x,x) = X should be a parse error

Tangled up with this is also the fact that (Int,Int) cannot currently be used to access the board. Once Position is removed, this will be working.

We should setup some CI via travis or the like to perform at least basic tests on PRs. This would be done both to ensure continuity with existing tests, and just to double check that haven't broken the build.

We should reorganize all Spiel examples under a common folder, examples would probably work just fine. From that point we should keep all our bgl code we write in there, and potentially organizing it to serve as descriptions for us, and also as a location for practice files (for lessons).

As martin noted we need to switch to using set notation for enumeration types, eg:

type Player = {A,B}

In addition the abstract type Positions has been removed from the given syntax.

This should be considered completed when the:

• syntax change has been integrated
• tests have been updated to verify this syntax can be parsed to generate a valid AST

Developer documentation can be improved. There can be guides on the usage of Haskell features too (or at least links to papers/tutorials), in order to get future developers up to speed

• X::"Empty"|"O"|"X" Type Holes: should reflect the new syntax with {} and &.
• don't display the type holes bit if there are no holes

Extended types should be treated as a union. I'll probably use Data.Set for this.

This ended up being more involved than I anticipated it being. I had to implement case expressions in the language in order to get extended types to safely typecheck. There are other solutions that can be discussed at the meeting, the case addition I've completed as a prototype is 8d9d1ea

Need to add another endpoint that allows creating new files from text that the frontend sends back.

Need to add additional game examples, such that we can create a sort of build-up into more advanced material. Might be worthwhile organizing these things under a lesson folder in examples, with lesson_n and such for the recommended progression of files to work on.

Martin requested that we have an ability to show/hide builtins in the prelude. In #85 I introduced a quick fix that allows redefining builtins, which can indirectly do this, but it doesn't provide a mechanism by which to hide all builtins by default.

I dug into Typechecker.hs to find environment, which utilizes builtinT. Removing a builtin defined in this list will effectively remove it from access in the program. Digging further I saw that builtinT is also used in Monad.hs, but this in turn is used back in the Typechecker all over the place. It seems that the builtins are tightly integrated into the current implementation, and that a means to separate them would probably take a bit of time (or a clever fix).

I'm leaving this issue outstanding so that there is a documented note of the issue, and that this leaves some idea of where to start with fixing it. Ideally, the result of parsing the prelude should include what builtins are hidden/shown (whichever is decided) and this changed list of available builtins is used instead of the hardcoded one.

Sometimes the parser spits out some awful parse errors

A comment on the first line of the prelude results in a parse error

Need a nice editor

b : Board
b!(x,y) = 0

b2 : Board
b2!(x,y) = 0 
b2!(1,1) = 1

The parser still thinks b2 is part of b.

This does work, however:

b : Board
b!(x,y) = 0

x : Int 
x = 3

b2 : Board
b2!(x,y) = 0 
b2!(1,1) = 1

The part in between breaks it out of the first parser and succeeds.

This also works:

b : Board
b!(x,y) = 0

d : Board
d!(x,y) = 0 
d!(1,1) = 1

I think right now it is hardcoded to produce a pair of integers/Position but, as in ConnectFour, it should produce a single int for the column.

The parser assumes any foo : Board is a board equation, so it rejects a value such as

foo : Board
foo = place(1,board,(1,1))

If I give the parser 100aaaa, it will accept that as the integer 100. This is due to how parsec handles things, it doesn't care about what comes after the input, all it cares about is accepting as much as possible. I think there's a way to tell parsec that any extra input left is an error.
Reproduction:
parse the expression 100aaaa
Desired Behavior:
Should get back a parse error
Actual behavior:
Vi 100

if a student makes their OS crash with a bogl program, that would be bad. almost all of the programs they could write will have either very short loops, or nonterminating loops that nevertheless ask for input once per loop. if they can write an unbounded loop like

while True do const True

it should error out relatively quickly, instead of stalling their computer.

Currently order in-dependent.

Currently it only takes an xtype

Just leaving an issue so that we are aware this is an ongoing process. Roughly 10 rules, with about 7 done so far, rules are listed in an openleaf doc.

change semantics :(

This is best explained with a visual. Here is a short video.

input : Board -> input => input : Input
Place should take care of printing boards

If the user wishes to see the board that they initialized, they may do so by entering its name in the REPL which will return its pretty-printed value.

I don't have much detail yet, but an expression like play(X, tryMove(X, initialBoard)) crashes the interpreter due to non-exhaustive patterns in a lambda in Builtins:34. One of us can look into it more soon.

There are some nice builtins that need to be implemented (besides input, which is #5 ):

• positions : Positions
• free : Board -> Positions
• place : (Symbol, Board, Position) -> Board
• remove : (Board, Position) -> Board
• next : Player -> Player
• isFull : Board -> Bool
• inARow : (Int, Symbol, Board) -> Bool
• countBoard : (Symbol, Board) -> Int
• countColumn : (Symbol, Board, Int) -> Int

b ! p == Empty parses as b ! (p == Empty) but it should be (b ! p) == Empty

I am not quite sure why it fails, but the typechecking with nested tuples is unfinished. I created the file examples/notWorking/NestedTupleError in the remove-Position branch with some examples of how they fail.

this would require a change to the parser, where each parsed element is marked with the line where it was defined.

The current setup binds the environment in any BoGL file in reverse. This was done in commit 25e4dcc, which seems to have been done to resolve an issue with Connect 4 not working otherwise with some of the builtins. All examples work with this in place, but it prevents declaring Variable equations that use pre-existing var equations or functions, like this:

-- this would work
f1 : Int
f1 = 2

-- but this will fail, since it is bound first
f2 : Int
f2 = f1

and this will fail as well

f1 : Int -> Int
f1(x) = x

f2 : Int
f2 = f1(2)

The line in question is in Eval.hs:31, where the reverse is inverting the array of ValDefs to be bound. Again, this doesn't cause problems for function equations, and I'm not entirely sure why. Two fixes are likely:

1. Fix the parsing such that builtins can be used correctly with a top-down binding.
2. Enable Variable equations to have to the seen benefits as Function equations, such that they can resolve unbound references or functions .

There may be other approaches to this as well, but I'd like to emphasize that all games should be checked (particularly Connect 4) to verify a patch does not introduce a subtle issue with running other files. Any fix will need to introduce tests will need to at least verify that:

• the examples above can run correctly
• connect 4 can parse and evaluate correctly without issues

Additionally, the associated branch pm-fixes was my last attempt at fixing this. This includes a large number of changes for debugging and traces purposes, and will need building and running like so:

# producing a debuggable build 
# (note, if you haven't done this before, it can take 30+ mins...)
stack build --profile
# running a debuggable build
stack exec --profile spielserver 5174 -RTS --rts-options -xc

The rule was updated to be boarddef* (presumably actually boarddef boarddef*)

• Board as array
• New boardEqu
• Pos data type
• ! binary operation

Doesn't type check expressions from the repl, but does typecheck the program.