Unit values

[Brian Rice]

On Apr 27, 2005, at 2:02 PM, Adde wrote:

> Brian Rice wrote:
>> I think the attention you two have given this library has reached a 
>> threshhold. If you read the source, you'll see that I just ported it 
>> from Smalltalk-80 and didn't care too much about it.
>>
>> Right now, you two care more about it than I do. So put your fingers 
>> where your mouth is, and code up these changes yourself and use darcs 
>> send so I can apply them.
>>
>> Patches speak louder than words! :)
>>
>> On Apr 27, 2005, at 7:41 AM, David Hopwood wrote:
>>> Suggestion: merge the UnitValue and Unit types, by having a unit 
>>> behave
>>> as 1 of that unit, i.e. px = 1*px.
>>>
>>> Then only multiplication is needed to form a UnitValue, e.g. 42*px.
>>> Similarly examples like "(72*px) / in" would work automatically. This
>>> design also allows derived units and conversion factors to be 
>>> expressed
>>> more simply.
> I'm fine with implementing the changes myself if and when I feel I 
> understand the problem well enough.
> One thing I'm wondering that has nothing to do with the Units library 
> is if there is any way to dispatch on a slot of an object.
> Something like this maybe:
>
> uv unit@(Pixel traits) printOn: p@(SVG Printer traits) [
>  uv value printOn: p.
>  uv unit printOn: p.
> ].
>
> And if that isn't possible, do you think it'd be a good idea to add a 
> slot to BaseUnit that contains the base for it's values so that you 
> can dispatch on that instead? It wouldn't mean any changes to the code 
> using the library since BaseUnit could init the slot itself. Then you 
> cold do things like this:
>
> uv@(Pixel baseValue traits) printOn: p@(SVG Printer traits) [
>  uv value printOn: p.
>  uv unit printOn: p.
> ].

Dispatching on slot-values is basically dynamic pattern-matching. This 
is problematic mostly for performance reasons, but also your syntax and 
methodology for this definition is unsound. Slate is one step away from 
this level of semantics for a good reason...

What you're failing to grasp is that what follows the @ is just another 
Slate expression which happens to annotate the argument name you've 
specified, so "Pixel baseValue traits" will get you the traits object 
of whatever is returned by sending baseValue to Pixel, not by sending 
baseValue to uv. Furthermore, uv is the argument of the message, not 
its baseValue. The fact that Slate has no special syntax here is a hard 
limit to what we can do this way. You just can't dispatch on something 
that's not an argument in Slate. As far as I can tell, you have to 
choose between simple, flexible syntax (Slate) and being able to do 
pattern-match-y things (Cecil, Haskell, etc.) by using a baroque 
syntax.

Maybe Lee has some ideas on how to admit pattern-matching-like 
semantics to Slate, since he's given it a little thought, but don't 
count on this any time soon (i.e. before we bootstrap into a much less 
concrete syntax, and even then don't expect us to go the route of 
languages "with declarations" like Haskell or Java).

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/