nomeata / incredible Goto Github PK

Currently, the order depends on the random UUIDs assigned by JointJS. It would be much more predictable if the order was fixed: Either traverse the list by age (oldest connection first) or least recently changed connection first.

I see no obvious way to remove an arrow. Currently I find this the hardest part of the quest.

Simple to implement, but it needs some thoughs about where the button should be etc.

The parser should convert ascii abbreviations into their unicode versions, so that the formulas look better.

Plus this avoids confusion because e.g. normally one would think that you cannot deconstruct A&B with a rule which has A∧B as input, but in fact you can...

It would make experimenting and debugging a lot easier if I could save and load a proof.

JointJS seems to provide a useful method in http://www.jointjs.com/api#joint.dia.Graph:toJSON

It would already help to store the graph in a text area, and load it from there.

The paper needs a small toolbar in the corner, similar to the toolbar of the main page, with functionality for

• zooming out (and back in)
• zooming and panning the proof to fit.

This is a feature that is a prerequisite for a few things, such as creating new blocks while editing a proof, or moving multiple blocks at once.

This proof has neither red sockets nor is the goal highlighted green.

Maybe make custom blocks deletable. Sometimes you just want to try out a rule and later come to the conclusion that it's useless - then it would be cool delete it to "clean up"

When the logic reports cycles (in the cycles field of the analysis), these need to be visualized appropriately.

Requires #1 (or a logic stub).

I'm not a big fan of Coq and such languages, because these have quite heavy syntax and the learning curve is not very good (i.e. I'm just not smart enough). Though there's a lot of interesting logic systems that I would love to play with, apart of BHK:

• There're (iso)recursive types that require just two operations to implement, though I'm not sure if these are OK for a proof system.

  pack : forall p. (mu x. p x) -> p (mu x. p x)
  unpack : forall p. p (mu x. p x) -> (mu x. p x)

• Dependent types that are, as I can guess, not that easy to implement.

• Notions of equality.

Do you have any plans on extending the system? Would it be possible to allow users define their own blocks to model such systems? Something like "propositions" in Agda, which are essentially fake proofs for any given fact, would fit into this role.

How about

• a lesson where the student is supposed to prove False with a given consistent set of blocks? Maybe the students will then ask themselves why they fail...
• a lesson where the student is supposed to prove False with a given inconsistent set of rules? The inconsistency could be fairly subtle so you don't see it on first sight. Maybe the students could discuss then why such a set of blocks is a bad idea...

The current printing code for propositions in the logic core is too simle, and should avoid unnecessary parentheses.

With the new Schieblehre blocks, it is possible to lay out proofs so that all edges go from left to right. With this in mind, is it realistic to automatically layout a proof? Doesn’t have to be perfect, but would be useful to clean up completely messy proofs, or to be able to load proofs into the UI.

So the task here would be to turn a proof object into a graph, assigning position to the cells, and for those Schieblehre blocks, the width. I guess the code would be realtively hackish, as it would have to “know” what proof elements can be shown as a Schieblehre etc..

If the block area would be resizable horizontally, it would be possible to see all the blocks.

and it confused the logic. I now made the logic complain about it, but it would be nice if the UI automatically oriented the links the right way.

It might be possible to detect a wrongly-oriented link in graph.on('change:source change:target') and reverse it there.

@olydis, since you already worked on the UI code, do you think this is easily possible?

After dragging a helper block onto the board, it can not be deleted and a weird second copy shows up in the topleft corner. After clicking "switch task", the undeletable helper block also shows up there, and it isn't possible to go back to the previous task.

Occurs both in latest firefox as chrome on Ubuntu.

For example, if I hover my cursor over the output port of a block on my canvas, grey out all available blocks (both to the left, and elsewhere on the canvas) which cannot be connected to from that port.

@nomeata This is an amazing idea! I'm always excited to see creative thinking in the arena of better UI and tooling for proof environments.

After I have exported a rule, the building blocks stay there. In most cases, I guess, I just need the rule and do not care about the proof, so how about making the proof disappear with a cool animation (e.g. blinking like in tetris)? ;)
For cases in which the proof is still needed, one could just undo that.

So have followed the instructions in the README in an attempt to get it building locally. The current version of GHCJS requires a newer version of GHC than the version mentioned in the repo. So I am using the following

'$ ghcjs --version
The Glorious Glasgow Haskell Compilation System for JavaScript, version 0.2.0 (GHC 7.10.2)`

I am trying to build the master branch, commit 1eac53c
The compilation error I get (when running make logic.js) is as follows,

[1 of 2] Compiling ConvertJS ( js/ConvertJS.hs, dist-ghcjs/build/js-interface/js-interface- >tmp/ConvertJS.js_o )

js/ConvertJS.hs:14:25: Not in scope: ‘castRef’

js/ConvertJS.hs:21:25: Not in scope: ‘castRef’

js/ConvertJS.hs:28:25: Not in scope: ‘castRef’

js/ConvertJS.hs:37:14: Not in scope: ‘castRef’
make: *** [logic/dist-ghcjs/build/js-interface/js-interface.jsexe/all.js] Error 1

Have I made a mistake somewhere or is this a real compilation error? (This is on a clean Ubuntu install so there should not be anything else causing problems)

Cheers,
Gene Taylor

This could make the hard tasks (grandfather, drinker) more easy (provided that some of the earlier tasks really help).

As per the attached image, as soon as the mouse moves near the connection port at the top right the big red X comes up, obscuring it

The structures shown when I click "details" lack fields, which I have to add manually.

• For graphs, I have to add the logic (otherwise loading the graph fails with an exception on the javascript console)
• For proofs, I have to add the task (otherwise "make" fails and complains about a missing task field).

Is this intended / unaviodable or should we fix this?

possible outputs that would be nice are:

• human readable text (in the style of EasyProve)
• proof trees (using LaTeX and inference rules)
• Isabelle theories
• Coq theories

We really should provide undo/redo functionality. It should be relatively easy: Maintain a list of serialized graphs (graph.toJSON()) that is appended upon major changes, and cleared when a new task is loaded, and popped upon undo.

I’m at a loss with the UI design here. How should I present the switch task button? What symbol should I put on it, to avoid text? Maybe one of these? http://getbootstrap.com/components/#glyphicons

We have some form of higher order unification, but it does not work well: It does not find the required solutions, and it does not treat locally free resp. locally fixed variables correctly, it seems.

Maybe http://www-users.cs.umn.edu/~gopalan/papers/pattern-unif.pdf is a good read on that, but not today.

The parser is really picky...

Selecting an example task from the developer tools, saves the selected task as the current session task. Without erasing all user data, it is therefore impossible to get back to the originally selected session task.

Steps to reproduce:
1.) Select a task (1) in the task selection menu ("Was möchtest Du gerne beweisen").
2.) Select an example task in the developers tools section
3.) Click "Switch task" and select another task from the task selection menu
4.) Click "Switch task" again and select the task from step 1.)

I.e. the proposition that would be there if one had a connection with nothing else there.

Could use the same display style as for the prototypes.

We currently have some English and some German strings in the project. While there is not much text, we cannot do completely without text, so some form of localization is needed.

These need the usual pacman style, and should potentially expand to fit their content.

Several js files are not found. Is there something I am supposed to to so that this works again?

The two logics blocks introduced in Session 6 that have "P(c)" do not work as labeled. The first should take P(c) and produce ∀x.P(x) but instead produces ∀x.P(c). The second should take ∃x.P(x) and create an assumption P(c) but instead creates an assumption P(c_k) that conflicts with P(c).

I believe this makes Session 6 impossible, as well as the custom task "∃x.P(x)→⊥ / ∃x.P(x)→Q" (which is similar to the simple proof for "A→⊥ / A→B"):

(Funny enough, if I change box 11 to P(x), then box 14 produces ∀x.P(x) which still disagrees with the label ∀x.P(x) from box 15.)

Clicking on switch task... opens a task selection with a scroll bar, but the frame is not focused, i.e. it's impossible to scroll down to advanced lessons with the arrow keys (without clicking it first). It should be possible to give it focus upon opening.

@lohner pointed me to a bug today, and I tracked it down to a insufficiency in the scope calculation.

This is the failure:

It should say A(c₄)∨B(c₄), but it dropped the dependency on c. The problem was not the unification, but the scope calculation in the presence of open ports.

Here is what it does now: Every block that has no successor gets an implicit edge to a fake exit note. If we’d remove the left edge, then the ∃-elim block would have no such edge, so it would get one, then the ∨ block would be post-dominated by ∃’s local input, and A and C would be allowed to depend on c₄, as observed by Denis.

With this connection, now both blocks do have a successor (the other block), so no edge to the exit is added, and thus no post dominators are found at all!

This points to the work-around: Add a block after ∃ that has no successors, as in

Now the scope algorithm works as intended and unification does as well!

Drawing a line to the fake exit from all open ports would also be too harsh.

So we need a better idea about how to define scopes in the presence of open ports.

See https://groups.google.com/forum/#!topic/jointjs/RHoBMvrReaM for some ideas on how to do it.

We need a block like this:

   ___________
 P |          |    P
---|  [edit]  |--------
   |__________|

where the user can specify a proposition manually (e.g. using window.prompt() if we want to be lazy). This can help in cases where the tools does not figure out all unifications.

For the "Nand" problem set, it would be nice to have a way to input the "nand arrow" instead of copying the unicode symbol. I don't have any good suggestion for it, though.

The logic core should detect cycles in the proof, and report them in the analysis.

Resizing the browser window can lead to parts of the proof being hidden in an invisible part of the pane because proof blocks have absolute positions (this also applies to loading proofs for e.g. grandfather from the Dev Tools in a different sized browser window). A further annoyance is that the pane isn't scrollable. Either relative positions or scroll bars will fix this -- or of course automatic (re-)layouting as in #21.

For pedagogical purposes, I'd like to suggest an option to fully parenthesize expressions, because newcomers to logic (I'm considering showing this cool app to kids!) may get distracted by matters of precedence of the operators.

Some users might not get that actually the whole thing just runs in their browser (for example, if they don't know what github.io is, and what it can and can't do). If they then use incredible in e.g. private mode, nothing is saved.

So wouldn't it be a good idea to tell them that, e.g. with a popup or something like that?

Of course, this only applies until there actually is a server.

Behaviour was observed in Google Chrome 45.0.2454.85 (64-bit)
on commit 475a265
When I do the usual thing to delete a block, it seems like everything is selected (see screenshot). Sometimes, the block is gone, sometimes not.

Without having much of a clue about formal systems: is it intended that you can't type in "bottom" in the fill-in fields? Or is that just an oversight?

It should be possible to

• Chose to start without a task
• Have the logic core return to the UI the rule that the current graph would prove to be valid, if the graph has no errors.
• Have a button to save the current graph as a rule, which is then added to the logic.

This would allow the user to define his own block for “(¬P ⇒ ⊥) ⇒ P".

This would be cool because then I don't have to look into the blocks area or draw dummy connections if I just want to see how this block worked again...

On http://incredible.nomeata.de, there seems to be neither documentation nor examples how to use lambdas.

Currently we have

A list of paths, where every path is a list of connection keys that
form a path from a local hypothesis to a conclusion of
the proposition.

We could have

A list of paths, where every path is a list of connection keys that form a path from a local hypothesis to a conclusion of the proposition, or to a block that is also dependent on a conclusion of the block of the local hypothesis.