#$Header: /usr/export/home/projects/ltg2/Pleuk/Distribution/Pleuk/RCS/things_to_do,v 1.1 1993/05/04 17:15:56 pleuk Exp $
#$Log: things_to_do,v $
# Revision 1.1  1993/05/04  17:15:56  pleuk
# tiny change from Jo
#
# Revision 1.0  1993/04/27  09:01:35  pleuk
# Version 1.00beta from Jo
#
#
This file contains a list of desirable changes to Pleuk.  It was last
updated on Fri Apr  2 14:31:22 1993.  If you would like to offer help
with any of the tasks mentioned below, we'd be really pleased to hear
from you.  

** = urgent

This list should be read in conjunction with Pleuk/Doc/Info/overview,
topic Known Problems and Bugs.  

Graphics
========

PostScript-fix drawing of relation parens [still dodgy Tue Feb 16
13:10:54 1993] 
Improve drawing of sets and relations, both in terms of left-right
spacing and of a more accurate drawing of braces and parens.  There
are problems in both DC and PostScript in this respect.  

Improve PostScript output by prolog so that it caches common
substructures. (Currently things which are identical are measured many
times, e.g. atomic values). 

Fix PS/epsmetrics.ps so that it takes account of scaling and
landscaping.  


(Longer term) Allow GM (and/or other graphics systems) to replace
PostScript options and window.  Make the two standard windows (output
and file) mouse sensitive (this may have major implications for control).

Allow font selection by user under GM, including, if possible, menus,
DC, output, ...

Have Prolog dump the values of appropriate graphics variables to
PostScript on sending each thing to be printed.  Currently, if one
wishes to change a dimension used by PostScript, one must insert an
appropriate command in one's ~/.ghostscript file.  This should work
for both on-line and printed output.  

There should be some low-level translation mechanism for mapping
things like atomic(-) to symbol(minus), as the former looks too small
relative to the size of atomic(+).  

(Longer term) Following Suresh Manandhar's suggestion, the graphics
parts of the code should be better modularized.  In particular, all
graphics handling including the standard windows, menu system, DC,
etc, should be brought under a single discipline.  There also appears
to be some motivation for ad-hoc windowing capability, with supporting for
click detection, etc, to support AVM browsers and editors.  

System
======

(Longer term) Introduce a set of ``environment'' statements along the
lines of RAO'K's postings.  

(Longer term) Investigate portability with respect to Quintus and
forthcoming ISO standard, and with respect to other window systems.  

There should be a write canonical option that ensures character output
is readable by the specialization.  

Make menus more context sensitive (e.g. don't offer ``delete all
defns'' or ``list files'' when none are loaded ...).  Likewise for
`next parse' if the user is currently looking at the last parse for
some input.  Review and perhaps come up with a better way of allowing
specs to add items to or delete items from menus.

There should be a select subset menu analogous to select1 (see
Code/Xsicstus.pl.gm).  This should allow the presentation of some
collection of information (say attributes to ignore in printing, or
files defining the current system), some of which are checked.  The
user can then change which elements are checked.  There should be a
way of calling some command to use the resulting information
appropriately,  (i.e. in the case of shadowing attributes, to set a
new value for the variable 'shadowed attributes').  

(longer term) Find out from somewhere which sets of builtins in the
various prologs are ISO-compliant.  Implement an iso-010100.pl file
which defines the eccs_sys_... version for the intersection of those
sets.  This will limit the amount of work to be done and duplication
when porting to other Prologs.  

(longer term) There should be a generic way for a specialization to
inquire what operation is currently taking place.  In particular, when
loading, the name and source file of the definition currently being
compiled should be available.  (This would allow us to simplify a
number of compilers, which would then not be required to pass around
object names, etc, for the purposes of error reporting.)  Some of this
may already be in place, but not properly exploited (cf
current_file/6).

Write a prolog tokenizer for dialog box input.  

There should be a generic way of allowing a specialization to ask
whether it's running under Pleuk or not, to allow reasonable
development of systems which exist both as standalones and as Pleuk
specializations.

Variables  (longer term) 
---------

I) It's often inconvenient to have always to supply a value for a
variable.  And, there are a number of cases where a variable doesn't
have a eccs_new_variable/5 definition. 

We should rework Chris's eccs_ensure_variable/5, so that one can
describe a variable while leaving its value unset.  

- new predicates
	eccs_define_variable(Name, Value, Class, Access, DocString)
	eccs_define_variable(Name, Class, Access, DocString)

Always succeeds.  Issues a warning if values for Class, Access, and
DocString differ from any record in the database.  

Results in the addition to the database of a clause recording this
information, and (in the case of eccs_define_variable/5) a two place
relation recording Name and Value for the variable.  

- new predicate
	eccs_unset_variable(Name)

any value for variable is removed.  

II) Introduce type checking routines.  Ultimately we want to be able
to set non-atomic values for variables through dboxes, (e.g. the
equivalent of set(shadowed_attributes, [f1, f2, g])).  

- new predicate 
	eccs_variable_type(VarName, Type, CoercionRoutine)

where VarName is the name of an existing variable, Type is an atom 
used to inform the user of the expected type of some variable, and
CoercionRoutine is some 2-place pred which 
i) identifies its args in case its first arg is of the expected type
or failing that
ii) attempts to map the supplied value to the expected type.

This predicate should be checked everytime a variable is given a
value.  

III) Alter variable names that we expect the user to manipulate, so
that they have spaces rather than underscores.  Ditto for types in
specializations?



Specs and Grammars
==================

SLE
---

Add other schemata to phpsg2 

Check out problem with context variables and implications in SLE
(This shows up with grammar phpsg2, "loves").

(longer term) Rewrite constraint satisfaction engine of SLE. Its
current data structures are way to complex and should be replaced by a
uniform:

[Node-Constraint, Node1-Constraint1 ...]

structure.   This will allow a number of things.  First, we can do
checking against atomic values first (big speed improvement).  Second,
we will have to pass around less complex structures and so individual
routines can determine whether a particular constraint should be
evaluated sooner rather than later.   At the same time, we should
improve the engine by keeping a record of template expansions.
(O'Keefe's book has some useful ideas.)

Ale
---

Incorporate into Pleuk.

DCG
---

Would be very useful for instructional purposes.  

All specializations
-------------------

Write lots of grammars.  


DC
==

Fix menu options:  there are currently potentially too many options
(especially given the small size of fonts).  These should be
rationalized, maybe to a maximum of: 

	-Grammar Ops 
	-Print	
	-Copy
	-Reset
	-Help
	-Return to Pleuk

where most of these menus lead to regular Pleuk menus.  

Provide labels for full forms of DC objects:  this is really an issue
for specializations and contains a theoretical problem, viz. given
some arbitrary object implied by a grammar, what is a good name for
it? ... 

Doc and help
============

[Wed Feb  3 12:03:15 1993 JC The menu structure is in place for the
following]. 
** Add a section ``What to do when things go wrong'' including a
discussion of

Prolog errors
Backbone errors

Grammar Errors -- syntax errors
	       -- compilation errors
               -- parsing/generation errors


Add an appendix ``References'' to the end of overview.texinfo, and
pointers to this from each of the spec's doc.

(Longer term) Major rationalization of documentation.  
