[OT][SPAM] Re: Pair notation for number radix

[Paul Hodges]

This is another great example of why I love this list. :o]

I live in GA, so far out in the boonies that I can't get cable or
broadband at *all* except for by satellite. I've stopped trying to
explain what I do, because I start saying things like this, and they
glaze and visibly regret it, lol

Now I just tell them my official job title is computer monkey.
That works pretty well. :)

But so that this post isn't (hopefully) entirely hot air, 
 How does this sort of adverbial typecasting relate back to compile
time typing? The old my Dog $spot thing?

There seems to be a significant relationship, but I can't wrap my head
around where the underlying mechanics might be usefully applied.

goes off to reread the synopses/exegeses et alii

--- Ryan Richter [EMAIL PROTECTED] wrote:

 On Tue, Dec 04, 2007 at 07:39:16AM -0800, Larry Wall wrote:
  On Sun, Oct 07, 2007 at 03:01:06PM -0600, David Green wrote:
   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.
 
 I don't know if I ever mentioned it on the mailing list, but a while
 back I did some work on a units module that uses units.dat
 (examples/rules/unitsdat-grammar.pm in the pugs repo).  I think
 that a simple postfix syntax (e.g.) doesn't give you the ability to
 specify the kind of composite units that are common in scientific
 applications where units are heavily used (e.g. Gauss per square root
 Hertz).  Those kind of units also rule out simple type-based units,
 e.g.
 having roles for length, mass, etc. - you can't do a role to the -7/3
 power.  I settled on a syntax that allows a mini-language similar to
 units(1):
 
 9.8.:asm / s ** 2
 $field_noise.:asgauss / sqrt(Hz)
 
 But someone may be able to come up with something better.  My
 implementation does unit type-checking at runtime, but compile-time
 checking would be much nicer where possible.  It would also be cool
 to
 be able to define roles that can represent themselves in several
 different units:
 
 role Photon does NumUnit { ??? }
 my Photon $p .=new( energy = 42.:aseV );
 say energy is $p.:aszJ zeptojoules;
 say wavelength is $p.:asangstrom Å;
 say frequency is $p.:asTHz THz;
 
 -ryan
 



  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: Pair notation for number radix

[brian d foy]

In article [EMAIL PROTECTED], Smylers
[EMAIL PROTECTED] wrote:

 brian d foy writes:
 
  In article [EMAIL PROTECTED], Larry Wall
  [EMAIL PROTECTED] wrote:
  
   On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
   
   : In article [EMAIL PROTECTED], Larry Wall
   : [EMAIL PROTECTED] wrote:
   : 
   :  : Later in the Literals section of S02, there's a chart of the
   :  : corresponding forms for fat arrow, pair, and paren notation. It has
   :  : 
   :  :a = 'foo'  :afoo  :a(foo)

   You're confusing various levels here when you say same thing.
   They're the same in some ways and different in others.


 The colon can _also_ be used for forming adverbs (similarly to how the
 slash can be used for both regexes and division, in different places),
 but that doesn't effect the equivalence of the above.

The section where that table is talks about adverbs. This isn't just
the same characters being used for different things. Some pairs also
act like adverbs. See my earlier message on file test operators.

Re: Pair notation for number radix

[brian d foy]

In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:

 On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
 : In article [EMAIL PROTECTED], Larry Wall
 : [EMAIL PROTECTED] wrote:
 : 
 :  : Later in the Literals section of S02, there's a chart of the
 :  : corresponding forms for fat arrow, pair, and paren notation. It has
 :  : 
 :  :a = 'foo'  :afoo  :a(foo)


 You're confusing various levels here when you say same thing.
 They're the same in some ways and different in others.

Well, I think the documentation is confusing it. If these notations are
not the same thing, should there be a table that shows the
correspondence of these forms? If the pair notation shouldn't be used
for adverbs, perhaps the documentation shouldn't note a generalized
adverbial form of Pair notation.

I guess I'll just leave it at that, though, and not bring it up again.

Re: Pair notation for number radix

[Larry Wall]

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:8377: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 :10377?

 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.

Larry

Re: Pair notation for number radix

[Andy Armstrong]

On 4 Dec 2007, at 15:39, Larry Wall wrote:

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.)



I've missed prior discussions about this - apologies.

Is there any thought of doing dimensional analysis?

2m/s * 3s = 6m

Is there any thought of using units to denote, e.g. string encoding?

my $amp  = ''; # No unit, plain text
my $body = body$amp/bodyhtml; # gets bodyamp;/body

In other words interpolating plain text into a string that has the  
unit 'html' would force a (user defined) html upgrade on the  
interpolated text.


On the other hand

my $amp  = 'amp;'html; 
my $body = body$amp/bodyhtml; # gets bodyamp;/body

--
Andy Armstrong, Hexten

Re: Pair notation for number radix

[Andy Armstrong]

On 4 Dec 2007, at 16:19, Andy Armstrong wrote:

my $amp  = ''; # No unit, plain text
my $body = body$amp/bodyhtml; # gets bodyamp;/body



Per http://search.cpan.org/~andya/String-Smart/ I should say.
--
Andy Armstrong, Hexten

Re: Pair notation for number radix

[brian d foy]

In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:

 : Later in the Literals section of S02, there's a chart of the
 : corresponding forms for fat arrow, pair, and paren notation. It has
 : 
 :a = 'foo'  :afoo  :a(foo)
 : 
 : That looks like it might mean that these are corresponding forms:
 : 
 :8 = 377:8377:8(377)
 
 The first is just a pair of 8 and 377, and has no special numeric
 significance.  The adverbial syntax is special in that, for ordinary
 pairs, what follows the colon must be an identifier, so :8377
 would ordinarily be illegal. 

Did I miss this in the spec somewhere? I've basically assked the same
question in regards to file tests. I wouldn't be asking the question if
the spec didn't keep talking about pairs and adverbs being the same
thing. If the Pair and adverbs aren't different syntax for the same
thing, how should that affect that chart in S02?

 The :8(377) above is a bit wrong, by the way, and works only because
 decimal 377 happens to stringify to something that looks like an
 octal number.  You couldn't, for instance, say :16(deadbeef) unless
 deadbeef() was a 0-ary (or listop with no args) function returning
 a hex string.

Could you have :16('deadbeef')? Should the :8(377) still work (so, does
'wrong' mean it won't do what I'm thinking it will do, or that it does
mean that Perl 6 won't compile it, or some other sort of wrong)?

Re: Pair notation for number radix

[Larry Wall]

On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
: In article [EMAIL PROTECTED], Larry Wall
: [EMAIL PROTECTED] wrote:
: 
:  : Later in the Literals section of S02, there's a chart of the
:  : corresponding forms for fat arrow, pair, and paren notation. It has
:  : 
:  :a = 'foo'  :afoo  :a(foo)
:  : 
:  : That looks like it might mean that these are corresponding forms:
:  : 
:  :8 = 377:8377:8(377)
:  
:  The first is just a pair of 8 and 377, and has no special numeric
:  significance.  The adverbial syntax is special in that, for ordinary
:  pairs, what follows the colon must be an identifier, so :8377
:  would ordinarily be illegal. 
: 
: Did I miss this in the spec somewhere? I've basically assked the same
: question in regards to file tests. I wouldn't be asking the question if
: the spec didn't keep talking about pairs and adverbs being the same
: thing. If the Pair and adverbs aren't different syntax for the same
: thing, how should that affect that chart in S02?

You're confusing various levels here when you say same thing.
They're the same in some ways and different in others.

Syntactically, only the :foo forms can be considered literals.  =
is just a Pair composer operator and takes two scalar expressions of
arbitrary complexity.  = always creates a Pair object in the abstract
(which may be interpreted as a named argument when used in an argument
list).  The = syntax may only ever be used where a term is expected.

The :foo forms, when used where a term is expected, behave like =
but are restricted to an identifier for the key.  (The value can be any
subscriptlike expression.)  But unlike =, the :foo forms can also be
used as adverbs where an *operator* is expected, as in

1..20 :by(3)

The = form cannot be used in this syntactic slot because it would end
up looking like two terms in a row to the parser:

1..20 'by' = 3

or alternately would look like an attempt to use infix:by:

1..20 by = 3

Basically, = shouldn't be used for adverbials.  It's only for real Pair
programming.  (Or in a pinch, named args, but maybe we should just force
people to use :foo for that.)

:  The :8(377) above is a bit wrong, by the way, and works only because
:  decimal 377 happens to stringify to something that looks like an
:  octal number.  You couldn't, for instance, say :16(deadbeef) unless
:  deadbeef() was a 0-ary (or listop with no args) function returning
:  a hex string.
: 
: Could you have :16('deadbeef')?

Certainly, why not?  It's a hex string passed as a normal arg.  But usually
you'd reserve that parenthesized form for when you don't know the arg:

:16($randomvar)

and instead write the above as

:16deadbeef

since in that case you want a complete literal.  :16($x) is really
kind of a pseudoliteral, like this is a $randomvar string is a
pseudoliteral that really is one or more operators in disguise.
:[EMAIL PROTECTED] would also be a pseudo-literal, but :16[1,2,3,4] could
be construed as a real literal only via constant folding of a
real expression, just as :16('deadbeef') could be constant folded.
But we don't yet spec what must be constant folded and what isn't.
This could be construed as a weakness in the spec, since it could
result in non-portabilities.  On the other hand, maybe we should
just claim that every operation known to be pure at compile time
is constant folded.  That would be simpler to learn and to teach,
except for the part about teaching what pure means.  :)

: Should the :8(377) still work (so, does
: 'wrong' mean it won't do what I'm thinking it will do, or that it does
: mean that Perl 6 won't compile it, or some other sort of wrong)?

Er, should?  In one sense of should, it shouldn't.  But as I
said, it does work, but not the way it appears to work, because 377
is parsed as a decimal number, not an octal string.  It's just a
mathematical accident that octal can be encoded in decimal that way,
and it misleads people to think that the () are functioning as quotes
rather than real expression delimiters.  Then they'll cargocult it
to write :16(deadbeef) as well and it Simply Won't Work.

Larry

Re: Pair notation for number radix

[Ryan Richter]

On Tue, Dec 04, 2007 at 07:39:16AM -0800, Larry Wall wrote:
 On Sun, Oct 07, 2007 at 03:01:06PM -0600, David Green wrote:
  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.

I don't know if I ever mentioned it on the mailing list, but a while
back I did some work on a units module that uses units.dat
(examples/rules/unitsdat-grammar.pm in the pugs repo).  I think
that a simple postfix syntax (e.g.) doesn't give you the ability to
specify the kind of composite units that are common in scientific
applications where units are heavily used (e.g. Gauss per square root
Hertz).  Those kind of units also rule out simple type-based units, e.g.
having roles for length, mass, etc. - you can't do a role to the -7/3
power.  I settled on a syntax that allows a mini-language similar to
units(1):

9.8.:asm / s ** 2
$field_noise.:asgauss / sqrt(Hz)

But someone may be able to come up with something better.  My
implementation does unit type-checking at runtime, but compile-time
checking would be much nicer where possible.  It would also be cool to
be able to define roles that can represent themselves in several
different units:

role Photon does NumUnit { ??? }
my Photon $p .=new( energy = 42.:aseV );
say energy is $p.:aszJ zeptojoules;
say wavelength is $p.:asangstrom Å;
say frequency is $p.:asTHz THz;

-ryan

Re: Pair notation for number radix

[Larry Wall]

On Sat, Oct 06, 2007 at 04:00:18PM -0500, brian d foy wrote:
: This is basically the same question I had about file test operators
: earlier
: (http://www.nntp.perl.org/group/perl.perl6.language/2007/04/msg27415.htm
: l). I never got an answer on my syntax question and the discussion went
: off to talk about file tests instead of pair notation. 

Sorry, keep meaning to answer things and then get distracted.  It's only
been, what, two months since you sent this message...  :)

: From S02 The general radix form of a number involves prefixing with
: the radix in adverbial form.
: 
: This seems to say that there are non-general radix forms, and that
: those might involve a different radix form that's not adverbial.

Nope, anything else is just a function/method call.

: Later in the Literals section of S02, there's a chart of the
: corresponding forms for fat arrow, pair, and paren notation. It has
: 
:a = 'foo'  :afoo  :a(foo)
: 
: That looks like it might mean that these are corresponding forms:
: 
:8 = 377:8377:8(377)

The first is just a pair of 8 and 377, and has no special numeric
significance.  The adverbial syntax is special in that, for ordinary
pairs, what follows the colon must be an identifier, so :8377
would ordinarily be illegal.  And because it would be illegal, we
can just reuse that syntax for an easy way to write radix literals.

It happens to fall out from this that the parenthetical form (which
allows an arbitrary expression returning a string instead of a literal
string) gives us a way to get rid of the badly named hex and oct
functions, which are bass-ackwards from the usual conversion functions
in that they name the input rather than the output.

The :8(377) above is a bit wrong, by the way, and works only because
decimal 377 happens to stringify to something that looks like an
octal number.  You couldn't, for instance, say :16(deadbeef) unless
deadbeef() was a 0-ary (or listop with no args) function returning
a hex string.

: 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 :10377?

The situation doesn't arise, since you can't create a pair starting
with :8 anyway.

: Also, going a bit further, the table lists
: 
:a = foo bar  :afoo bar  :a(foo bar)
: 
: So can I do things like
: 
:255 = 10 1 0 6;  # hey, that looks like an IP address

That's just a pair equivalent to 255 = (10,1,0,6), which promotes
to 255 = [10,1,0,6] because = is scalar context on both sides.
The construct has no numeric significance in terms of radix.

::25510 1 0 6; # is that the same as :255[ 10,1,0,6 ] ?

Unspecced, but yes, that would probably be allowable if we force
:255{10,1,0,6} to mean the same as :255[10,1,0,6].

Except, if you were really trying to generate an IPv4 address, I'd
suggest using :256 instead.  :)

: And, if that works, what might this do? 
: 
:q:w:25510 1 0 6

That would almost certainly be illegal syntactically on the face of it,
since the quote syntax doesn't know :255, and the quote syntax must
understand its options at compile time because that may influence how
the quoted string will be parsed.

If passed to an ordinary function where a term is expected, it's just
a literal number term.  If passed adverbially where an operator is
expected, it's likely to fail at compile time as two terms in a row,
and if somehow it got past that, it'd attempt to bind to an optional
parameter named 255, which you can't declare, so it fails.  Anyway,
it's gonna blow up one way or another.  I guarantee it.  :)

Larry

Re: Pair notation for number radix

[David Green]

On 10/6/07, brian d foy wrote:

That looks like it might mean that these are corresponding forms:
   8 = 377:8377: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 :10377?


What happened to the suggestion of using ` to designate units?  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?




-David

Pair notation for number radix

[brian d foy]

This is basically the same question I had about file test operators
earlier
(http://www.nntp.perl.org/group/perl.perl6.language/2007/04/msg27415.htm
l). I never got an answer on my syntax question and the discussion went
off to talk about file tests instead of pair notation. 

From S02 The general radix form of a number involves prefixing with
the radix in adverbial form.

This seems to say that there are non-general radix forms, and that
those might involve a different radix form that's not adverbial.

Later in the Literals section of S02, there's a chart of the
corresponding forms for fat arrow, pair, and paren notation. It has

   a = 'foo'  :afoo  :a(foo)

That looks like it might mean that these are corresponding forms:

   8 = 377:8377: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 :10377?

Also, going a bit further, the table lists

   a = foo bar  :afoo bar  :a(foo bar)

So can I do things like

   255 = 10 1 0 6;  # hey, that looks like an IP address

   :25510 1 0 6; # is that the same as :255[ 10,1,0,6 ] ?

And, if that works, what might this do? 

   q:w:25510 1 0 6