[<<][meta][>>][..]
Sat Apr 27 11:37:43 EDT 2013

Input types

I'm trying to add the input type annotation using a special form,
which copies the annotation to a symbolic form in the ai-function
object, and a parameter conversion routine.

However, the latter can be multi-valued.  I have 1->2 but n->m is
probably also a possibility.

In general it seems not possible to separate these.  Maybe it needs to
be tagged in the type system?



The thing is that this is really type information in a generalized
sense.  Meaning, it is not something the program uses, but it is
something that a program "meta-thing" uses.

Can it be stored somewhere else?  I.e. it should not be used in
unification, since the difference between a float and a float in [0,1]
goes away after it's been "blessed".  Also, it's possible to add a log
float and a lin float (i.e. a polynomial approximating "exp" bridges
the linear/exponential "type").

Maybe this is more something of a "unit".  I'm thinking Haskell
"phantom types".  It seems that going that way is a bit overkill for
the Scheme thing..

I really just need units and scales.  Some kind of annotation that is
only used outside of the whole code generation thing.  Sure, it would
be useful to apply more general "theorems" about values, but it might
be hard to express things like "linearity".  Basically, there is no
"logarithmic" scale: it is only an artifact of the curvature of some
polynomial approximation.



So what is the real problem?

- scales
- bounds
- units

Maybe this should be considered as a 2nd level type system.  The
problem of scales is the same as that of units.  I.e. Hz or logHz.

The important distinction with the "machine" type system is that this
2nd level type system cannot be applied to the primitives.  It only
makes sense at a level that glosses over certain details.

This requires a big change: a dataflow network has 2 parts:
- A highlevel semantics that can be typed in the "units" sense.
- A lowlevel implementation


What about this:

- The current float/int array type system is part of a specific
  interpretation.

- The unit-correct type system is a *different language* that expands
  into the flat number-crunching stream language.


The current I/O specification problem is exactly this: the processor
is the number-crunching part, which is abstracted as a higer level
program that can be typed in terms of higher level units.

Note that there is a possibility to add higher level semantics, since
there is already a function object as part of the representation.

This corresponds very well to the idea of approximation.  It could
even be used to encode exact and approximate functions and
(automatically) find approximation errors etc..

Some nice beef is hidden here.  But I need to move on.

Let's stick to the plan: store the annotation in the ai-function-args
field, or add an extra "types" tag to the function object.

Yeah, this is not good.  It needs to use a typing approach.

The idea is not ready.
Time to put the annotation in there manually, then connect it up later.




[Reply][About]
[<<][meta][>>][..]