TODO

In this file, "*" indicates finished items, and "o" unfinished items.

* a = b = c;

* param variables

* proper handling of inconsistent equations

o multiplied types

o more tests

* declaration to pause and load a linogram library file

* declaration to require a Perl file

  * not needed; just "require 'blah'" in the __END__ section

*  type name = EXPR
   equivalent to
        type name;
        constraints { name = EXPR; }

* Builtin functions - sin(), cos(), sqrt()

  o "builtin foo;"

o Compilation of types into data-dumper code

o Reorganize modules.  Put Value classes into Value.pm, etc.

  o Do this just after you get to 2.0

o Fix TODO and XXX items

* string constants

o require "foo", "bar", "baz";

o object declarations or "extends" constructions that involve unknown
  types might try to require a .lino file of the same name, and fail
  only if none can be found

o Comments

o Test suite should check error output instead of throwing it away

o A bunch of the environment handling would be simplified if an
  environment had a pointer to the next environment to be searched.
  You wouldn't have to explicitly pass around multiple environments or
  to merge new environments into old ones.

o There's an inconsistency in the code in how environments are
  handled.  In some environments, the values are expressions, and in
  others they're value objects, and in others they're ordinary Perl
  scalars.  This is confusing.  Maybe three separate subclasses of a
  single abstract base class?

o Test string concatenation

o Error production(s) in grammar

o Better error messages!  Modify lexer to include character and line
  in each token.  Then error messages can refer to the position in the
  linogram source file.

o Should compound names be allowed on the LHS of a param-spec?

o Remove unused code

  o Build a trivial coverage analyzer

o Arithmetic on two chunks should abort with an error message unless
  the two chunks have a common supertype.

o Refactor more Chunk methods using new HO "over" call

o With the implementation of the new system for parameter variables,
  all your old tests that check for failure in case of 
  improper parameter specifications are passing instead of failing.
  That's great, but it now means you need some new tests for the
  failure cases.

o Add cis() builtin function; mechanism for functions that return
  non-constants generally.

  o Done 20051231.

o Test suite should round off numbers to 8 places or so

o Why have "contstraints { ... } "?  It should be unambiguous if
  constraints just appear in the definition without any such tagging.
  Similarly it should be possible to abbreviate  "draw { X }" to just
  "draw X;" when there's only one X.

o Some bug: In your etch-a-sketch pictures (~/blog/etc/...) you tried
  to have a line of slope 2/3.  This appears in eas2-12-3.lino.  You
  put:

  line L1(start=the_eas.screen.ne);
  constraints { 
     ...
     L1.end.y = the_eas.screen.s.y;
     L1.end.y - L1.start.y = (2/3) * L1.end.x - L1.start.x;
  }

  and this worked fine.  But when you moved the first of the L1
  constraints into the L1 declaration, the line was too long:

  line L1(start=the_eas.screen.ne, end.y = the_eas.screen.s.y);
  constraints { 
     ...
     L1.end.y - L1.start.y = (2/3) * L1.end.x - L1.start.x;
  }


  What went wrong?

* This sloped line thing is useful.  Maybe put this in the standard library:

        define sline extends line {
          param number slope;
          constraints {
            end.y - start.y = slope * (end.x - start.x);
          }
        }

  o Add tests for this

o Tests for square.lino and circle.lino.


o Maybe support this new syntax:

        define hline extends sline(slope=0) {
          ...
        }

  I'm not suggesting that we replace the definition of hline with
  this, just showing an example.  That main point is the specification
  of parameters in the extends clause.

o What about arcs?  We might like to specify: start and end
  points, center, radius/diameter, angle.    Problem: nonlinear
  relationships.  Several different sorts?  (arc_se { point start,
  end; }; arc_c { point center; number r, d=2*r, angle; } etc?)
  Probably the arc_se thing is most useful.  

o Add in support for line thickness and dottedness.  

o Make default fill -1, to indicate none, since filling with white and
  black are both different from this.  Potential problem:  Consider
  two white-filled circles, which intersect.  The appearance of the
  diragram will depend on which is drawn first.  Linogram has no
  method for specifying this.  Maybe guarantee that (A) items will be
  drawn in the order specified in the draw {} block, and (B) in the
  default case, items will be drawn in the order they are declared?
  It should be possible to arrange this.  Will it get us everything
  that is needed?

o Should variables in outer scopes be inherited by variables in inner
  scopes?  For example, this doesn't work:

        number a;
        define foo {
          number b;
          constraints { b = a; }
        }

  Because the constraint is looking for foo.a, and there is no such
  thing.   This raises all sorts of issues, like that type definitions
  should maybe take place in a hierarchical rather than a flat
  namespace.  (that is, ROOT.foo, not jut plain foo.)

  This was motivated by:

        number a, b, c;

        define quadratic {
          param number x;
          param number y;
          constraints {
            a * x * x + b * x + c = y;
          }
        }

        quadratic q1(x=1, y=7), q2(x=0, y=2), q3(x=-1, y=0);

o SVG output.