Find file
Fetching contributors…
Cannot retrieve contributors at this time
190 lines (129 sloc) 5.5 KB
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, 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
line L1(;
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(, 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,, 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.