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

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][>>][..]