geraldpenn / trale-sld Goto Github PK

It might be useful to come back to one idea about the chart display we once
had: it may be not desired that the chart display always reflects the chart
state at the currently selected step. I think it is often desirable to
always see the entire chart constructed so far and somehow graphically mark
the parts of the chart that were not known at the inspected step with some
kind of "fog of war". Changing this would also alleviate issue 11.

...should be added, similarly to Variable Watching.

The unification of whole mothers or daughters with a variable currently
doesn't serve as an entry point to substructure highlighting but it should.

Clicking on a lexical edge on the chart display will not select the
corresponding node in the control flow tree, but the mother node. As a
result, and highly unintuitively, the clicked edge will vanish (along with
the entire chart, because the mother node has an emoty chart associated
with it). In a sense, this behaviour is linked to issue 12.

With some path descriptions, small substructures are inserted too high in
the FS at exit port. Example: test_gram/4a, step 94 (in application of
semantics principle, DTR2)

Frank:

Ich frag mich auch zunehmend, ob es nicht noch ein 'Expertenpanel' geben 
sollte, in dem man sich die präzisen Portangaben des ursprünglichen 
Debuggers mitansehen kann, so dass man also Sachen zu sehen 
bekommt wie:

Call:close chart edge under rule application?
Call:apply rule, subject_head_rule?
Fail:enforce description on category value of value at synsem? Skipping to 
next occurrence of stepID 382
Redo:resolve goal, append/3?

Ich stelle mehr und mehr fest, dass ich das Emacsfenster hinzuziehe, um 
diese explizitere Info auch noch zu haben. Klar, dass man das nicht 
zwingend braucht, und wahrscheinlich wollen es eher intuitiv arbeitende 
Benutzer nicht sehen. Daher wäre es vielleicht günstig, wenn dieses Panel 
nicht defaultmäßig sichtbar ist, sondern man es sich je nach Wunsch in den 
Vordergrund konfigurieren kann. Vielleicht als ein ein paar Zeillen großes 
Panel unter das Source-Panel?

This describes what the new variable watching component, to be implemented
within the new architecture, should look like.

Basic view:
A small table that shows just tags, variable names, and FS types. By
double-clicking, on a row, one can open a

Variable window:
Shows the full feature structure currently held by a variable. Need to keep
the windows in sync with the currently selected step.

build_fragment_subtrees(860,701,1,3,2,_31111,_31112) is misbehaving and
causing an insufficient memory error in parsing [she,gives,her,milk] with
the test_gram.

In constraint applications, variables from outside the scope of the current
constraint are not yet correctly excluded from the view.

The best way to fix this seems to be to restructure constraint-handling in
the ALE debugger such that each constraint application has its own debugger
step.

...should be added.

After a step exits, variables and local trees currently are currently shown
at their exit port state. A more informative variant would be a diff view
of their call (resp. redo) vs. exit state.

Alas, TRALE's diff functionality doesn't seem to be functional at this time.

Reasons for specific steps failing should generally be more visible in the
GUI. Possible approaches discussed so far include pseudo-steps, but this
needs more thought.

...by using the portray_cat/5 hook instead of the current solution found
hacks. Depends on portray_cat/4 being upgraded to portray_cat/5 in
interp.pl first.

Sometimes it's hard to place the current substructure because the debugger
hasn't seen the parent structure yet - that is, not in a sufficiently
instantiated form to find the corresponding feature value. As a stopgap,
the current substructure is just invisible in such cases; the lowest
ancestor already seen is highlighted. To solve this problem, the debugger
would have to get the required structures from deep in ALE's intestines
(difficult), or invent suitable structures by itself (difficult AND ugly,
for it would then be hard to guarantee that what the user sees is what is
really going on inside ALE - even more difficult than it is already, that is).

...I should keep the following things in mind:
1. Generate mothers and daughters together in order to be able to
2. replace the replaced parts in all FSs in order to preserve cross-FS
re-entrancies
tbc.

We need some detail display for the execution of lexical rules.

To make it visible when edges are added and retrieved.

Should find a way to keep re-entrancy numbers in FS display as consistent
as possible across steps. Currently, they often change wildly, which is
confusing for the user. Possible strategy: per rule application, assign
numbers used to specific paths of specific FSs (the mother or a specific
daughter).

The "no variables at this step" message is not reliably shown, at least if
the variable watch panel is docked out.

There's currently no detail view for FS unification in lexical lookup. Need
to equib tralesld_hooks.pl with an entry point for that.

...should be added.

Currently, structure sharing between mother and daughters is not visible in
any way in the FS display.

Color is used to signalize whether a step was completed and through which
port it was completed (white: not completed yet, green: exit, red: fail,
blue: finished). Also, the "current node" is marked with yellow. Those two
usages of color are in conflict the moment the current node completes,
causing a slight irritation as the respective creeping does not trigger any
visible change in the decision tree. The "current node" could be marked
without using color, e.g. by a thicker border.

Due to the static nature of the call stack it maintains, trale-sld
currently treats the execution of a blocked goal just like a child of the
node where the goal gets unblocked. We have yet to determine what the
desired behavior is, and to implement it.

Some possibilities:
1. leave it as it is, but connect execution to corresponding when-node
using a spaghetto
2. move the execution nodes to the corresponding when-node but introduce a
pseudo-node labeled "unblocked" at the appropriate place and connect it to
the corresponding when-node using a spaghetto

Thinking about it, I strongly prefer 1 because 2 might be tricky
call-stack-management-wise, and, more importantly, unblocking goals can be
subject to backtracking.

[deleted issue]

To be investigated and fixed.

trale-sld currently assumes that featval/3 steps *always* drill exactly 1
level deeper into the FS. However, there are cases where there is no change
in level:

Sometimes a featval/3 step ("enforce description on ... value of ...") is
"repeated" as its own child, where the FS has a more specific type. This
happens when the feature being referred to is appropriate only for the more
specific type.

Problem: how to recognize such cases?

Test case (from Frank):

Man nehme die Grammatik im Attachment (die Grammatik aus dem Grammar 
Formalisms - Lehrbuch, die ihr am Anfang verwendet habt, um den SLD zu 
testen).

Testfall mit angeschaltetem Lexical Lookup:
drec[she].

In dieser Grammatik werden einige Prinzipien auf Wörter und auch
Lexcial Rules angewendet, die hier also ins Spiel kommen.

Bei Schritt 66 bricht der SLD ab (noch im Versuch, das Wort 'Peter'
für den Lexical Lookup zu verwenden).

Der reine SLD leitet dagegen letzten Endes korrekt ab, dass 'Peter' nicht
als Kandidat für 'she' infrage kommt.

In the long run, we want to make the GUI the primary interface for the
user, where she can start parsing processes, recompile the grammar, and so on.

On the Prolog side, there will be an infinite loop always waiting for
commands from the GUI (that are now given by the user in the form of
queries to the Prolog top-level). A simple protocol will have to be devised
for that.

There's currently no debugger step for "constraint application", although
conceptually that would make a lot of sense. This should be fixed either by
introducing pseudo-steps, or by changing interp.pl to make each constraint
application an actual step. The latter might also be the solution to issue 25.

Dissecting and reassembling FSs for the GUI still breaks re-entrancies
sometimes - not when a the replaced structure is itself shared, but when it
contains shared structures. Will probably have to look for all paths of all
shared structures explicitly and fix them every time.

In FS trees, mothers and daughters don't currently have re-entrancy tags.

The problem is in ghooks.pl, and perhaps also in Gralej.

should be something like <width of leftmost edge> + (<number of daughters
in rule> - 1) * <estimated width of each future edge = 1> and be updated
dynamically as more edges are retrieved (and abandoned again)

Steps that are Redone currently keep their status (failed vs. exited) and
possibly node data from the last invocation; previous statuses and data are
lost. We should think about what we can do to improve this.