On Sun, Oct 07, 2007 at 03:01:06PM -0600, David Green wrote:
> On 10/6/07, brian d foy wrote:
>> That looks like it might mean that these are corresponding forms:
>>    8 => 377    :8<377>    :8(377)
>> Now, if I can do that, what happens to the pair form in a hash composer
>> when I want the key of '8' and the value of :10<377>?
> What happened to the suggestion of using ` to designate units?

It's kinda caught between two other notions.  On the one hand,
we're trying to reserve ` for user definition, in part because it's
so difficult to tell from ' in many fonts so we're avoiding it for
standard usage.  On the other hand, it's not clear that units aren't
generally just simple multiplication by a scaling factor: 1*in, where
1*in == 2.54*cm, for instance.  Units could also be viewed as type
conversion, which would give us kg(1) and 1.kg as conversion forms
in current Perl 6.  Since 1.kg is essentially using the units as a
postfix, presumably the 1kg form could also work on literals, just as
we currently allow 1i to convert 1 to i via the postfix:<i> operator.
(And I suppose there's a sense in which 10e-2 is specifying the
scaling factor of the left side explicitly.)

In any case, though, if we treated them as type names rather than
just methods, we'd probably want to require predeclaration of unit
names since a type name like "kg" or "in" or "fortnight" could easily
collide with a user-defined routine.  Or maybe they still want some
special sigil-ish mark to stay in their own namespace.  Dunno.  I don't
think we have to solve that for 6.0.0 in any case, especially if we
require predeclaration of which unit names are wanted, in which case
there might just be a units pragma that can pull in selections of
the predefined units:

    use units :cgs, :nasa, <╬╝fortnight gibibyte>;
    my newton $thrust = 42.lbf;

But with a sigilish mark we could just pull in all the units from
/usr/share/units.dat, I suppose.

> Bases are a 
> kind of unit (sort of -- counting the number of 10's or 2's or 16's), so if 
> the colon-form is ambiguous, perhaps it could be 20`16==32`10?

Hmm, well, kinda...

I think that would be a bit of an end-weight mistake, like the /x
modifiers in Perl 5, where you when you get to the end of the regex
you mentally have to backtrack and reparse.  Though numeric literals
are rarely that long, so the end-weight argument doesn't carry a lot
of weight when you take in the construct as a single visual unit.

I think the killer is that the two ends are visually ambiguous: 10`8
would be misread as 8 in base 10 half the time.  2.54`cm doesn't have
that problem so much.  And in any case, I like the current prefix form
more better.


Reply via email to