Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]

5 views
Skip to first unread message

Aaron Sherman

unread,
Mar 26, 2005, 9:59:10 AM3/26/05
to Perl6 Language List
On Sat, 2005-03-26 at 00:27 -0800, Larry Wall wrote:

> $$ is now $*PID. ($$foo is now unambuous.)
>
> $0 is gone in favor of $*PROGRAM_NAME or some such.

You know, Java did one thing in this respect that I liked, and managed
to do it in a way that I couldn't stand. The idea of program as object
was nice, but they made the programmer manage it, which was really kind
of silly.

If you think of the OS-level shell around a Perl interpreter as an
object, and make perl manage that for you, then this falls out rather
nicely:

$*PID := $*PROC.pid;
$*PPID := $*PROC.ppid;
$*PROGRAM_NAME := ~$*PROC;

Perhaps even some often-used data could be shoved in there:

$life = time() - $*PROC.start_time;

In fact, it seems like a good place for any OS-level globals:

$*IN := $*PROC.pio_in // $*PROC.stdin;

If we consider $*PROC to be the invocant of the implicit "main", then:

say "I am number {.pid}, who is number 1?";

works just fine in global context. This also gives you a nice simple way
to drill down into your interpreter / runtime / VM / whatever state:

say "I'm {.name} running under {.interp.name}";


Rod Adams

unread,
Mar 26, 2005, 3:37:24 PM3/26/05
to perl6-l...@perl.org
Larry Wall wrote:

>%+ and %- are gone. $0, $1, $2, etc. are all objects that know
>where they .start and .end. (Mind you, those methods return magical
>positions that are Unicode level independent.)
>
How can you have a level independent position?
The matching itself happens at a specified level. (Note that which level
the match happens at can change what is matched.) So it makes sense that
all the positions that come out of it are in terms of that level.

Now, that position can be translated to a lower level, but not to an
upper level, since you can happily land in the middle of a char.

This is part of what I'm having trouble with your concept of a Str being
at several levels at once: There's no reliable way to have a notion of
"position", expect to have it as attached to the highest possible level,
and the second someone does something at lower level, you void the
position, and possibly the ability to remain at that high level.

I still see my notion of a Str having only one level and encoding at a
time as being preferable. Having the ability to recast a string to other
levels/encoding should be easy, and many builtins should do that
recasting for you.

I do _not_ see $/ & friends getting ported across a recasting. .pos can
be translated if new level <= old level, otherwise gets set to undef.

Please convince me your view works in practice. I'm not seeing it work
well when I attempt to define the relevent parts of S29. But I might
just be dense on this.

-- Rod Adams

Larry Wall

unread,
Mar 26, 2005, 3:48:12 PM3/26/05
to Perl6 Language List
On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote:

: On Sat, 2005-03-26 at 00:27 -0800, Larry Wall wrote:
:
: > $$ is now $*PID. ($$foo is now unambuous.)
: >
: > $0 is gone in favor of $*PROGRAM_NAME or some such.
:
: You know, Java did one thing in this respect that I liked, and managed
: to do it in a way that I couldn't stand. The idea of program as object
: was nice, but they made the programmer manage it, which was really kind
: of silly.

Well, there is a process object, but it actually exists inside the
operating system. It's a little silly to force people to name their
own process all the time. I think we can assume that global variables
belong to the current process, sort of on the "you're soaking in it"
principle.

: If you think of the OS-level shell around a Perl interpreter as an


: object, and make perl manage that for you, then this falls out rather
: nicely:
:
: $*PID := $*PROC.pid;
: $*PPID := $*PROC.ppid;
: $*PROGRAM_NAME := ~$*PROC;
:
: Perhaps even some often-used data could be shoved in there:
:
: $life = time() - $*PROC.start_time;
:
: In fact, it seems like a good place for any OS-level globals:
:
: $*IN := $*PROC.pio_in // $*PROC.stdin;

We can certainly have various objects proxying for various contexts.
It's not clear how those should be broken out though. To me, an OS
isn't a process, and there's not necessarily going to be a one-to-one
correspondence.

: If we consider $*PROC to be the invocant of the implicit "main", then:


:
: say "I am number {.pid}, who is number 1?";
:
: works just fine in global context. This also gives you a nice simple way
: to drill down into your interpreter / runtime / VM / whatever state:
:
: say "I'm {.name} running under {.interp.name}";

That's an interesting idea, the more so now that we're leaning away
from .foo ever assuming the current topic unless it also happens to
be the invocant. But it probably wouldn't do to have one common name for
the .pid outside of methods and force people to use a different name
inside methods. Here's where $*PID works much better, because it can
be the same everywhere.

Larry

Aaron Sherman

unread,
Mar 26, 2005, 5:50:31 PM3/26/05
to Larry Wall, Perl6 Language List
On Sat, 2005-03-26 at 12:48 -0800, Larry Wall wrote:
> On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote:

> Well, there is a process object, but it actually exists inside the
> operating system. It's a little silly to force people to name their
> own process all the time. I think we can assume that global variables
> belong to the current process, sort of on the "you're soaking in it"
> principle.

That seems to be a self-limiting position. It leads (as it did in Perl
5) to a desire to reduce the number of times you add access to new OS
features (as it requires global namespace suckage, though not as bad as
in Perl 5), and you'll still split out an object, module or data
structure to contain all of the information that's not in Perl proper
because it's platform specific (e.g. current drive letter context under
DOS).

I agree that $*PID is a useful alias for $*PROC.pid (though the extra *
still bothers me), but providing a unified API for interacting with
myself as an OS-level construct seems to make sense.

That's perhaps just my preference. I'm a hybrid OO/procedural guy, so I
tend to reach into the OO toolbox whenever I think it will make my life
easier.

> : If you think of the OS-level shell around a Perl interpreter as an

> : object[...]


> We can certainly have various objects proxying for various contexts.
> It's not clear how those should be broken out though. To me, an OS
> isn't a process, and there's not necessarily going to be a one-to-one
> correspondence.

True enough, and you would certainly NOT:

my $sock = $*PROC.socket;

That makes no sense at all. However, things like "what IO layer am I
using" or "am I a thread" are perfectly valid questions to pose of a
process abstraction.

> : If we consider $*PROC to be the invocant of the implicit "main", then:
> :
> : say "I am number {.pid}, who is number 1?";

> That's an interesting idea, the more so now that we're leaning away


> from .foo ever assuming the current topic unless it also happens to
> be the invocant. But it probably wouldn't do to have one common name for
> the .pid outside of methods and force people to use a different name
> inside methods. Here's where $*PID works much better, because it can
> be the same everywhere.

Well, it's always:

$*PROC.pid

The invocant goodness is just handy in a certain circumstance (what *is*
main's invocant, out of curiosity? I guess it could be the interpreter
context, but that should probably have some relationship to your process
info anyway (either is or does ... probably does.) If I were writing
Learning Perl 6, I would teach "$*PID" and/or "$*PROC.pid", but not
".pid".


Larry Wall

unread,
Mar 26, 2005, 10:29:06 PM3/26/05
to perl6-l...@perl.org
On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: Larry Wall wrote:
:
: >%+ and %- are gone. $0, $1, $2, etc. are all objects that know
: >where they .start and .end. (Mind you, those methods return magical
: >positions that are Unicode level independent.)
: >
: How can you have a level independent position?

By not confusing positions with numbers. They're just pointers into
a particular string.

: The matching itself happens at a specified level. (Note that which level

: the match happens at can change what is matched.) So it makes sense that
: all the positions that come out of it are in terms of that level.

When we're dealing with mostly variable length encodings, it makes
more sense that the positions come out as string pointers that only
convert to numbers grudgingly under duress. If you're just going to
feed a position back into a substr() or as the start position of the
next index(), there's no reason to translate it to a number and back
to a pointer. It's a lot more efficient if you don't.

: Now, that position can be translated to a lower level, but not to an

: upper level, since you can happily land in the middle of a char.

I talked about this problem in one of the As. I think the fail soft
approach is to round to the next "ceiling" boundary and issue a warning.

: This is part of what I'm having trouble with your concept of a Str being

: at several levels at once: There's no reliable way to have a notion of
: "position", expect to have it as attached to the highest possible level,
: and the second someone does something at lower level, you void the
: position, and possibly the ability to remain at that high level.

A position that is a pointer can be true for all levels simultaneously.
It has the additional benefit of a type that is subtype constrained
to operate with other values from the same string, so if you subtract
two pointers from different strings, you can actually detect the error.

: I still see my notion of a Str having only one level and encoding at a

: time as being preferable. Having the ability to recast a string to other
: levels/encoding should be easy, and many builtins should do that
: recasting for you.

And I still see that you can have your view if you install a pragma
that forces all incoming strings to a single level. But I think we
can do that lazily, or not at all, in many cases.

The basic underlying problem is that there is no simple mapping from
math to Unicode. The language that lets people express their solution
in terms of Unicode instead of in terms of math is going to have a leg
up on the future, at least in the Unicode problem space. Strings were
never arrays in Perl, and they're only getting further apart as the
world makes greater demands on strings to represent human language.

So I'd much rather introduce an abstraction like "string position"
now that is not a number. It's a dimensional value, where the scaling
of the dimensionality is bound to a particular string. You can have
a pragma that says, "Untyped numbers are assumed to be meters, kilograms,
and seconds", and a different lexical scope might have a pragma that
says "Untyped numbers are assumed to be centimeters, grams, and seconds."
These scopes can get along as long as they don't try to exchange untyped
integers. Or if they do, they have some way of ascertaining what an
untyped integer meant when it was generated.

: I do _not_ see $/ & friends getting ported across a recasting. .pos can

: be translated if new level <= old level, otherwise gets set to undef.

The interesting thing about a pointer is that you can pass it through
a higher level transparently as long as you don't actually try to
use it. But if you do try to use it, I think undef is overkill.
Just as a float stuffed into an int truncates, we should just pick
a direction to find the next boundary and go from there, maybe with
a loss of precision warning. The right way to suppress the warning
would be to install an explicit function that rounds up or down.

: Please convince me your view works in practice. I'm not seeing it work

: well when I attempt to define the relevent parts of S29. But I might
: just be dense on this.

Well, let's work through an example.

multi method substr(Str $s: Ptr $start, PtrDiff ?$len, Str ?$repl)

Depending on the typology of Ptr and PtrDiff, we can either coerce
various dimensionalities into an appropriate Ptr and PtrDiff type
within those classes, or we could rely on MMD to dispatch to a suite
of substr implementations with more explicit classes. Interestingly,
since Ptrs aren't integers, we might also allow

multi method substr(Str $s: Ptr $start, Ptr ?$end, Str ?$repl)

which might be a more natural way to deal with variable length encodings,
and we just leave the "lengthy" version in there for old times sake.

We could go as far as to allow a range as the second argument:

$x = substr($a, $start..^$end);

or its evil twin:

$x = $a[$start..^$end];

Of course, with the evil twin notation you lose the "repl" facility.

But in fact, we probably can't actually allow both of

multi method substr(Str $s: Ptr $start, PtrDiff ?$len, Str ?$repl)
multi method substr(Str $s: Ptr $start, Ptr ?$end, Str ?$repl)

since MMD might well tie on who to dispatch

substr($a, 5, 10)

to, unless we forced it to Perl 5 interpretation in case of tie. So I'm
guessing we put in

$x = $a[$start..^$end];

for the non-destructive slicing of a string, and leave substr() with
Perl 5 semantics, in which case it's just a SMOP to coerce the user's

substr($a, 5, 10);

to something the effectively means

substr($a, Ptr.new($a, 5, $?UNI_LEVEL), PtrDiff.new(10, $?UNI_LEVEL));

Actually, in this case, I expect we're actually calling into

multi method substr(Str $s: PtrDiff $start, PtrDiff ?$len, Str ?$repl)

where $start will be counted from the begining of the string, so the
call is effectively

substr($a, PtrDiff.new(5, $?UNI_LEVEL), PtrDiff.new(10, $?UNI_LEVEL));

Okay, that looks scary, but if as in my previous message we define
"chars" as the highest Unicode level allowed by the context and the
string, then we can just write that in some notation resembling:

substr($a, 5`Chars, 10`Chars);

or whatever notation we end up with for labeling units on numbers.
Even if we don't define "chars" that way, they just end up labeled with
the current level (here assuming "Codes"):

substr($a, 5`Codes, 10`Codes);

or whatever.

But this is all implicit, which is why you can just write

substr($a, 5, 10);

and have it DWYM.

Now, I admit that I've handwaved the tricksy bit, which is, "How do
you know, Larry, that substr() wants 5`Codes rather than 5`Meters?
It's all very well if you have a single predeclared subroutine and
can look at the signature at compile time, but you wrote those as multi
methods up above, so we don't know the signature at compile time."

Well, that's correct, we don't know it at compile time. But what
*do* we know? We know we have a number, and that it was generated
in a context where, if you use it like a string position, it should
turn into a number of code points, and if you use it like a weight,
it should turn into a number of kilograms (or pounds, if you're NASA).

In other words, the effective type of that literal 5 is not "Int",
but "Int|Codes|Meters|Kilograms|Seconds|Bogomips" or some such.
And if MMD can handle that in an argument type and match up Codes as
a subtype of Ptr, and if we write our method signature only in the
abstract types like Ptr, we're pretty much home free. That certainly
simplifies how you write S29, though I don't know if the MMD folks
will be terribly happy with the notion of dispatching arguments with
junctional types. But it does fall out of the design rather naturally.

I know that offhand this seems like a lot of needless complication,
and it's is a little bit hard to explain, but I believe it's very close
to how we actually use context in real language, so I think people
will find it intuitively obvious once they start using it. More to
the point, it will produce very *clean* code, uncluttered with most of
the crufty conversions and coercions you find in singly typed languages
that compiler writers tend to love, and programmers tend to hate.

And you can still put in all that cruft if you want to. You can even
force yourself to have to do it. But to me, it feels a bit like slavery,
so I'm still looking for a land flowing with milk and honey, even if
there are a few giants in it.

Er, sorry for waxing poetic.

Larry

Markus Laire

unread,
Mar 28, 2005, 8:47:24 AM3/28/05
to perl6-l...@perl.org
Larry Wall wrote:

> ... SKIP ...

> ...

So do you actually envision perl6 to allow a junction of units on
numbers? This would have huge implications, depending on what exactly is
possible with these units...


Would/could some of these DWIM in perl6?

# import proper MMD-subs for + - * etc...
use MyUnitConversions;

my $length = 1.3`Meters + 4.6`Yards;
my $weight = 4`Pounds - 1'Kilograms;
my $money = 12`€ + 5.78`£ + 12`US$;

Then, how would I specify the unit of the result?

my $unit = 1`Minutes|Kilograms|Meters;

my $time_mins`Minutes = $unit * 5.45; # 5.45 Minutes
my $time_secs`Seconds = $unit * 5.45; # 327 Seconds

my $weight`Weight = $unit * 2.34;
my $length`Length = $unit * 12.56;

But these would need MMD based on return-type which is out IIRC?
So perhaps just simple:

my $time_mins = unit_conversion($unit * 5.45, Minutes);
my $time_secs = unit_conversion($unit * 5.45, Seconds);

Or using some infix-op:

my $time_mins = ($unit * 5.45) ` Minutes;
my $time_secs = ($unit * 5.45) ` Seconds;


And what about hex/dec/oct/bin? Could these be included in this system?

my $number`Dec = 12`Oct + 010101`Bin + 0cab`Hex;

And then we of course definitely need

my $length = 12`Oct&Miles + 0c`Hex&Kilometers; :)


Not sure if I'm on right track at all - but Units on numbers with MMD
gives some really nice ideas to a mathematically minded person...

my $speed_a = 78`Kilometers / 2`Hour;
my $speed_b = 50`(Miles/Hour); # or 50`Miles_per_Hour
my $delta = $speed_a - $speed_b;


--
Markus Laire
<Jam. 1:5-6>

Rod Adams

unread,
Mar 28, 2005, 3:07:18 PM3/28/05
to perl6-l...@perl.org
Markus Laire wrote:

The real "fun" in determining what should happen with units comes to
when you do operations that _change_ the units.

my $Current = 5`Amps;
my $Resistance = 10`Ohms;
my $Power = $Current * $Resistance; # Do I get 50`Watts here?


my $theta = 45`Degrees;
my $x = cos($theta); # no units on $x
my $theta2 = acos($x); # in radians? or does $x carry a
# "used to be Degrees" property?


my $distance1 = 100`Meters;
my $distance2 = 0.25`Kilometers;
my $timeinterval = 5'Seconds;
my $velocity1 = $distance1 / $timeinterval;
my $velocity2 = $distance2 / $timeinterval;
my $acceleration = ($velocity2-$velocity1)/$timeinterval;
# is $acceleration something like 30`Meters/Second/Second ?

Don't forget fun operations like C<$x**2> and others, which should be
nicely reversible, or used as is. (Think cubic meters for volume). And
there will likely always be corner cases like C<exp(2*log(5`Feet)) !=
5`Feet**2> which I would be very surprised about it Perl caught them.

Another fun thing is dealing with ambiguous unit names. "Pound" can
refer to Force, Mass, or Money. "1`Gallon" can be either "4`Quarts" or
"5`Quarts" depending on which side of the Atlantic you're on. "Ounce"
can be either Mass or Liquid Volume, _and_ has US/UK issues. Having to
specify "5`FluidUSOunces" can get tedious, though hopefully short
aliases can be made. Then there's the fun of currency, where the
exchange rates are time dependent. (Do we start say "5'US$.at($time)"?)


All that being said, I think it would be great if we could come up with
a way of integrating units into Perl 6. But I'd want the following features:
- It's more than just a "toy" for solving a few minor problems like
specifying characters.
- It's fairly comprehensive in that it should be easy to write
functions which mutate the units intelligently, and know when to flag a
type mismatch.
- It all goes away by default for the user who doesn't want to bother
with it.


-- Rod Adams

Aaron Sherman

unread,
Mar 28, 2005, 3:40:14 PM3/28/05
to Rod Adams, Perl6 Language List
On Mon, 2005-03-28 at 15:07, Rod Adams wrote:
> Markus Laire wrote:

> > So do you actually envision perl6 to allow a junction of units on
> > numbers? This would have huge implications, depending on what exactly
> > is possible with these units...

> > # import proper MMD-subs for + - * etc...


> > use MyUnitConversions;
> >
> > my $length = 1.3`Meters + 4.6`Yards;
> > my $weight = 4`Pounds - 1'Kilograms;
> > my $money = 12`€ + 5.78`£ + 12`US$;
> >
> > Then, how would I specify the unit of the result?

You ask for the unit you want. I'm not sure I like or dislike this
syntax, but it's easy enough to see that:

12`€

is just

12 but €

where € is probably an alias for the class (role?) Units::Money::Euro.
Addition would be defined in a base class in such a way that conversion
to an appropriate intermediate unit would be done and then addition
performed. The derived classes would provide addition only for the
special case where both operands were in the derived unit (for
performance).

Now you can ask for whatever you like:

say "We have {€.new $money}€"

Though you might have some snazzy way of saying that.

> The real "fun" in determining what should happen with units comes to
> when you do operations that _change_ the units.
>
> my $Current = 5`Amps;
> my $Resistance = 10`Ohms;
> my $Power = $Current * $Resistance; # Do I get 50`Watts here?

Again, if Amps and Ohms know that they can do that, then you're all set.
Otherwise, you just construct a new value like so:

my Watts $Power = $Current * $Resistance;

Which again are probably all aliases for Units::Physics::*

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback


Craig DeForest

unread,
Mar 28, 2005, 3:30:14 PM3/28/05
to perl6-l...@perl.org
Yow -- units would be extra cool for perl6: I know of no other language that
has units support built in. It would go a long way toward making perl6 the
language of choice for students in the physical sciences...

The perl5 CPAN modules already have a pretty good unit system that could be
ported to the junctive strategy. The problem of resolving ambiguous units is
subject to DWIMming based on context; my own units engines always include a
context field that lets you choose what context should be used for further
unit string parsing (e.g. "SI", "currency", etc.). If not specified, any
unambiguous units in a compound statement can be used to guess an appropriate
context for the ambiguous ones. It's not clear how that would fit into the
junction scheme, but that might bear some thinking about...

Another point: one should probably worry more about making the unit parser
extensible, than about making it complete. The main symptom of an incomplete
or confused parser is a bunch of units-junk that is usually parsable by a
human but not in "simplest form" (e.g. "barn megaparsec tsp^-1" or some such
[0.63]); that's generally not a fatal problem, especially if the user has
access to the units database and can add another simplifying resolution.

Yet another point: there are plenty of non-obvious reductions that people
worry about, such as "N m" -> "J" (energy) but "m N" -> "m N" (torque); but
it's probably not worth worrying about such things: if the coder knows that
s/he wants a torque, s/he should be able to ask for reduction to a particular
form [e.g. 'units( $val, $template )' should exist and return $val in whatever
units $template has, if possible.]

Quoth Rod Adams on Monday 28 March 2005 01:07 pm,

Larry Wall

unread,
Mar 28, 2005, 4:06:31 PM3/28/05
to perl6-l...@perl.org
On Mon, Mar 28, 2005 at 01:30:14PM -0700, Craig DeForest wrote:
: Yow -- units would be extra cool for perl6: I know of no other language that
: has units support built in. It would go a long way toward making perl6 the
: language of choice for students in the physical sciences...

Well, yes. I certainly would have liked it back when I was taking
physics, but I had to make do with BASIC/PLUS. One of the reasons I
eventually got hired on at the college's computer center was that the
director was impressed by the fact that my physics program to calculate
the gravitational constant from my experimental data was named "G".
He said, "Everyone else always names their programs with the full six
available characters." So he knew I was a Lazy Critter from the start.

Larry

Larry Wall

unread,
Mar 28, 2005, 4:00:15 PM3/28/05
to Perl6 Language List
On Mon, Mar 28, 2005 at 03:40:14PM -0500, Aaron Sherman wrote:
: Now you can ask for whatever you like:

:
: say "We have {€.new $money}€"
:
: Though you might have some snazzy way of saying that.

Just by the by, that's illegal syntax. Methods with arguments
require parens. You could, however, say

say "We have {new €: $money}€"

: > The real "fun" in determining what should happen with units comes to

: > when you do operations that _change_ the units.

Doing the proper dimensionalysis, that's really just a specialized form of type
inferencing, I expect.

: > my $Current = 5`Amps;


: > my $Resistance = 10`Ohms;
: > my $Power = $Current * $Resistance; # Do I get 50`Watts here?
:
: Again, if Amps and Ohms know that they can do that, then you're all set.
: Otherwise, you just construct a new value like so:
:
: my Watts $Power = $Current * $Resistance;
:
: Which again are probably all aliases for Units::Physics::*

I've always thought that we should make use of the database of the
"units" program for standardized names of units. The units database
has a pretty good list of which units are just differently scaled
units of the actual underlying fundamental dimensions, and a lot
of encoded experience in distinguishing ambiguous units names. It'd
be a shame to reinvent all that.

But the basic underlying principle here is just the same as with
characters. Define your formal parameters in terms of the fundamental
dimensions like Length and Time, and let the computer worry about
the scaling issues. I consider types like Velocity and Acceleration
to also be fundamental in that sense, even though composed of other
fundamental dimensions, so it's not necessary to write Length/Time
or Length/Time**2 (however you care to spell those types).

It is this sense in which Position or Ptr is fundamental, even though
it is a location in a particular string at a particular time.

Larry

Aaron Sherman

unread,
Mar 28, 2005, 5:40:33 PM3/28/05
to Larry Wall, Perl6 Language List
On Mon, 2005-03-28 at 16:00, Larry Wall wrote:

> I've always thought that we should make use of the database of the
> "units" program for standardized names of units. The units database
> has a pretty good list of which units are just differently scaled
> units of the actual underlying fundamental dimensions, and a lot
> of encoded experience in distinguishing ambiguous units names. It'd
> be a shame to reinvent all that.

That makes fine sense, and I think it would be fairly trivial to
generate a set of roles from the Units database at run-time,
pre-compiled with the source or both (selectable in some way).

Of course, there are going to be people who have to re-define chunks of
that namespace because they have special needs (e.g. money -- this is
such a huge bear of a problem that it can only be solved for the
domain-specific cases), but that's fine, and does not preclude your
suggestion.

here's a start:

perl -nle 'while(<>) {print("# $_"),next if /^\s*($|\#)/;$c="";s/\s+\#.*// && ($c=$&);($unit,$def)=split /\s+/, $_, 2;if ($def eq "!") {$base{$unit}=1;print "class units::$unit does unit { ... }$c"} elsif ($unit =~ /-$/){print "# No handling for prefixes yet ($unit=$def)$c"}elsif($base{$def}){print "class units::$unit is units::$def;$c"}else{print "# No handling for derived units yet ($unit=$def)$c"}}' < /usr/share/units.dat

Craig DeForest

unread,
Mar 28, 2005, 5:48:23 PM3/28/05
to perl6-l...@perl.org
The problem with using the units(1) database is that it only deals with
multiplicative relations -- so, e.g., it won't handle temperature.

Units resolvers are not so hard to come by -- the strategy is to try to break
each compound unit out into a collection of fundamental quantities that
are interconvertible (e.g. all lengths get converted to "meters"), while
keeping track of the conversion constant. I haven't looked at units(1) in
a while, but it used to do this to both the original units and the destination
units, then take the ratio of the accumulated constants. That's why the
"conformability" error messages are sometimes a little weird: they always
refer to the fully expanded SI representation of each unit.


Quoth Aaron Sherman on Monday 28 March 2005 03:40 pm,

Aaron Sherman

unread,
Mar 28, 2005, 5:56:55 PM3/28/05
to Craig DeForest, Perl6 Language List
On Mon, 2005-03-28 at 17:48, Craig DeForest wrote:
> The problem with using the units(1) database is that it only deals with
> multiplicative relations -- so, e.g., it won't handle temperature.

Well, that's fine. You don't have to get everything from one source.
Larry is right though, units is a fine starting point.

I'm still of the basic opinion that all of the logic can be handled
through roles (classes?) and MMD, rather than trying to code up a units
converter in parallel to the type system.

Andrew Rodland

unread,
Mar 28, 2005, 6:03:42 PM3/28/05
to perl6-l...@perl.org
On Monday 28 March 2005 05:48 pm, Craig DeForest wrote:
> The problem with using the units(1) database is that it only deals with
> multiplicative relations -- so, e.g., it won't handle temperature.

andrew@twisted:~$ units
2084 units, 71 prefixes, 32 nonlinear units

Among those "nonlinear units" are such units as tempF and tempC, defined as
functions of a base unit tempK; units(1) seems to be at least decently
capable with such things.

--Andrew

Rod Adams

unread,
Mar 29, 2005, 2:07:20 AM3/29/05
to perl6-l...@perl.org
Larry Wall wrote:

>On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
>
>: Please convince me your view works in practice. I'm not seeing it work
>: well when I attempt to define the relevent parts of S29. But I might
>: just be dense on this.
>
>Well, let's work through an example.
>
> multi method substr(Str $s: Ptr $start, PtrDiff ?$len, Str ?$repl)
>
>Depending on the typology of Ptr and PtrDiff, we can either coerce
>various dimensionalities into an appropriate Ptr and PtrDiff type
>within those classes, or we could rely on MMD to dispatch to a suite
>of substr implementations with more explicit classes. Interestingly,
>since Ptrs aren't integers, we might also allow
>
> multi method substr(Str $s: Ptr $start, Ptr ?$end, Str ?$repl)
>
>which might be a more natural way to deal with variable length encodings,
>and we just leave the "lengthy" version in there for old times sake.

>...snip...


>for the non-destructive slicing of a string, and leave substr() with
>Perl 5 semantics, in which case it's just a SMOP to coerce the user's
>
> substr($a, 5, 10);
>
>to something the effectively means
>
> substr($a, Ptr.new($a, 5, $?UNI_LEVEL), PtrDiff.new(10, $?UNI_LEVEL));
>
>Actually, in this case, I expect we're actually calling into
>
> multi method substr(Str $s: PtrDiff $start, PtrDiff ?$len, Str ?$repl)
>
>where $start will be counted from the begining of the string, so the
>call is effectively
>
> substr($a, PtrDiff.new(5, $?UNI_LEVEL), PtrDiff.new(10, $?UNI_LEVEL));
>
>Okay, that looks scary, but if as in my previous message we define
>"chars" as the highest Unicode level allowed by the context and the
>string, then we can just write that in some notation resembling:
>
> substr($a, 5`Chars, 10`Chars);
>
>or whatever notation we end up with for labeling units on numbers.
>Even if we don't define "chars" that way, they just end up labeled with
>the current level (here assuming "Codes"):
>
> substr($a, 5`Codes, 10`Codes);
>
>or whatever.
>
>But this is all implicit, which is why you can just write
>
> substr($a, 5, 10);
>
>and have it DWYM.
>
>

I see some danger here. In particular, there is a huge difference
between a Ptr (position), and a PtrDiff (length). I'm going to rename
these classes StrPos and StrLen for the time being.

A StrPos can have multiple char units associated with it, and has the
ability morph between them. However, it is also strictly bound to a
given string.

A StrLen can only have one char unit associated with it, since there is
no binding string and anchors with which to reliably map how many cpts
there are to so many lchars.

I see the following operations being possible at a logical level:

StrPos = StrPos + StrLen
StrLen = StrPos - StrPos # must specify units (else implied), and
must be same base Str
StrLen = StrLen + StrLen # if same units.
StrLen = StrLen + Int

So I see the following cases of Substr happening:

multi sub substr(Str $s, StrPos $start : StrPos ?$end, ?$replace)

Where $start and $end must be anchored to $s

multi sub substr(Str $s, StrPos $start, StrLen $length : ?$replace)

Same restriction on $start,

multi sub substr(Str $s, StrLen $offset : StrLen ?$length, ?$replace)

Where $offset gets used as C<$s.start + $offset> and kicked over to case #2.

Hmm. Okay, that's not dangerous, just a lot to look at.


What gets dangerous is letting users think of a StrPos as a number,
since it's not. Only StrLen's get to pretend to be numbers. StrPos
should have some nifty methods to return StrLen's relative to it's base
Str's .start, and those StrLens can look like a number, but the StrPos
never gets to ever look like a number.

Make it where StrLen "does Int", and there's a
C«coerce:<as>(Int,StrLen)» with default units of your "Chars as highest
supported by string applied to", and I think we're getting somewhere.

We need to define what happens to a StrPos when it's base Str goes away.
Having it assume some nifty flavor of undef would do the trick. This
implies that a Str knows all the StrPos's hanging off it, so the
destructor can undef them. But that shouldn't pose a problem for p6c.

>Now, I admit that I've handwaved the tricksy bit, which is, "How do
>you know, Larry, that substr() wants 5`Codes rather than 5`Meters?
>It's all very well if you have a single predeclared subroutine and
>can look at the signature at compile time, but you wrote those as multi
>methods up above, so we don't know the signature at compile time."
>
>Well, that's correct, we don't know it at compile time. But what
>*do* we know? We know we have a number, and that it was generated
>in a context where, if you use it like a string position, it should
>turn into a number of code points, and if you use it like a weight,
>it should turn into a number of kilograms (or pounds, if you're NASA).
>
>

I don't see the need for all this. Make a C«coerce:<as>(Int,StrLen)» as
mentioned above, and the MMD should be able to figure out that it can
take the Int peg and hammer it into the StrLen hole. Then leave it up to
the coerce sub to complain if the Int happens to have units that make
the peg not fit.

>I know that offhand this seems like a lot of needless complication,
>and it's is a little bit hard to explain, but I believe it's very close
>to how we actually use context in real language, so I think people
>will find it intuitively obvious once they start using it.
>

As one who is seriously thinking about diving head first into the world
of Natural Language Processing (aka getting a PhD in it), I can tell you
that determining how we humans actually infer context out of language is
a mind boggling complex task, and that there are no simple rules to it.
It is still very much the case that it's easier to teach humans to talk
like a computer than have a computer understand the human language
(easier here is defined as simply being possible). We can make the
computer language look and feel a lot more like a "regular" language,
but in the end you're still training the human, not the computer.
(Fixing this problem is what appeals me to the NLP arena.)

That said, I think that most any solution we pick that let's us easily
dance up and down the Unicode tree with something significantly less
onerous than Java will become near intuitive once people start using it.
Consider that anyone on this list has what amounts to an intuitive
understanding of what

next if /^\s*$/;

means, even though it looks little like the pure English equivalent:
"Skip blank lines." (Though we did put the verb first in each case).

What counts is how much translation has to be done from what's in the
programmer's head into something the computer can grok unambiguously.
This is not necessarily the same thing as matching how we use language,
but I will agree there are often corollaries. The Perl programmer
thinking something like "Skip blank lines" will translate that to C<next
if /^\s*$/;>, whereas the one thinking "When I get a blank line, skip
it" will generate C<if /^\s*$/ {next}>.

Where I'm going with this: your statement of "it's very close to how we
actually use context in real language" is better said "it's very close
to one of the common ways we actually use context in real language".
The OO method is another common way, where the Direct Object of the
sentence is everything. OOP also happens to be a useful way of mapping
certain tasks into a computer language. There are many other context
models that we use, none significantly better than the rest in general,
but each can stomp any other way in specific.

Therefore, TMTOWTDI is a Good Thing.

Since strings are so fundamental to what Perl is, we should be able to
support several context models and WTDI at once, without prejudice or
having to declare what we're doing too much. Now all that's left is
figuring out which contexts are meaningful, and figure out how to get
them all at once.


-- Rod Adams

PS - I don't think we're that far away from each other on this stuff.
We're just looking at it from different sides.

Mark Reed

unread,
Mar 28, 2005, 5:59:16 PM3/28/05
to defo...@boulder.swri.edu, perl6-l...@perl.org
>From: defo...@boulder.swri.edu

>The problem with using the >units(1) database is that it only >deals with

>multiplicative relations -- so, e.g., >It won't handle temperature.

So the temperature functions available in units(1) aren't defined in the database? They're hard-coded? I find that unlikely.

In case you haven't seen them, I'm talking about TempF(x) and TempC(x), which represent absolute points on the scale and convert happily to each other including the offset, not degF and degC which represent temperature differences.

James Mastros

unread,
Mar 29, 2005, 2:56:56 AM3/29/05
to perl6-l...@perl.org
Craig DeForest wrote:
> Yet another point: there are plenty of non-obvious reductions that people
> worry about, such as "N m" -> "J" (energy) but "m N" -> "m N" (torque); but
> it's probably not worth worrying about such things: if the coder knows that
> s/he wants a torque, s/he should be able to ask for reduction to a particular
> form [e.g. 'units( $val, $template )' should exist and return $val in whatever
> units $template has, if possible.]

Oh, and don't underestimate the usefulness of doing things in
non-base-ten mixed units, and useful fractions: my height is
5`ft+(6+1/4)`in, not 66.25`in, thank you.

In any case, I'd love something like this, and I suspect many other
people would as well... but remember, again, extensibility is key.

C< $d=22`AWG; $a=pi*($d/2)**2; print $a`mm**2." qm"; # buying wire in
Germany> doesn't work very well if there is no way to specify insane
units like AWG.

25`USD*1.06+5`EUR can't be computed at all without extensibility,
because the conversion rate from USD to EUR doesn't stay static over
time. For that matter, monetary conversions are going to take some
effort to get right, though they will be very useful if they are gotten
right, because going through a common intermediary isn't correct. You
won't get the same results converting USD to EUR to JPY as you will from
converting USD to JPY. (OTOH, if you want to convert from DEM to FRF,
you /must/ convert to EUR in the middle, or you will get the wrong
result. Of course, neither the DEM nor the FRF have existed in several
years, so it probably isn't that important...)

-=- James Mastros,
Who certainly looks forward to this.

Thomas Sandlaß

unread,
Mar 29, 2005, 10:49:07 AM3/29/05
to perl6-l...@perl.org
Craig DeForest wrote:
> Yow -- units would be extra cool for perl6: I know of no other language that
> has units support built in. It would go a long way toward making perl6 the
> language of choice for students in the physical sciences...

Well, my HP48 pocket calculator used to have it :)
--
TSa (Thomas Sandlaß)

Osfameron

unread,
Mar 29, 2005, 11:24:20 AM3/29/05
to perl6-l...@perl.org
Craig DeForest wrote:
> Yow -- units would be extra cool for perl6: I know of no other language that
> has units support built in. It would go a long way toward making perl6 the
> language of choice for students in the physical sciences...

Frink is built around this idea: http://c2.com/cgi/wiki?FrinkLanguage

-
osfameron

Thomas Sandlaß

unread,
Mar 31, 2005, 8:03:09 AM3/31/05
to perl6-l...@perl.org
Larry Wall wrote:
> On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
> : How can you have a level independent position?
>
> By not confusing positions with numbers. They're just pointers into
> a particular string.

I'm not the Unicode guru but my understanding is that all composition
sequences are finite and stateless with respect to everything before
and after them in the string. Which brings me to the question if these
positions are defined like positions in Emacs as lying *between* the
chars? Then the set of positions of a higher level is a subset of the
positions of lower levels.

With defining position as between chars many operations on strings are
downwards compatible between levels, e.g. splitting. If one determines
e.g. an insert position on a higher level there's no problem in letting
the actual insertion beeing handled by a lower level. With fractional
positions on higher levels some degree of upward or tunneling
compatibility can be achieved.

BTW, will bidirectionality be supported? Does it make sense to reflect
it in the StrPos type such that $pos_start < $pos_end means a non-empty
left to right string, $pos_start > $pos_end is a non-empty right to left
string and $pos_start == $pos_end delimit an empty (sub)string? As a
natural consequence the sign indicates direction with negative length
beeing right to left. And that leads to two times two types of iterators:
left to right, right to left, start to end and end to start.

All the above leads me to rant about an array like type. Please forgive
me if the following is not proper Perl6. My point is to illustrate how
I imagine the future communication between implementor and user of such
a class. Actually some POD support for extracting the type information
into the documentation would be great, too!

And yes, the :analyse should be made lazy. The distinction between the
first and second index method could be even more specific by using
type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
information that indexing with a list of one element doesn't result
in a List of Str but a plain Str. OTOH this will incur a performance
penalty and violate the intuitive notion "list in, list out".

class StrPosArray does Array where { ::Index does StrPos }
{
has Str $:data;
has StrPos @:pos;

multi method postcircumfix:<[ ]>
(: Index $i ) returns Str {...}
multi method postcircumfix:<[ ]>
(: List of Index $i ) returns List of Str {...}
multi method postcircumfix:<[ ]>
(: Range of Index $i ) returns List of Str {...}
multi method postcircumfix:<[ ]>
(: Int $i ) returns Str {...}

# more stuff here for push, pop, shift etc.

method infix:<=> (: Str $rhs ) returns ::?CLASS
{
$:data = $rhs;
:analyse;
}

method :analyse ()
{
# scan $:data for all between char positions
# and store them into @:pos
}
}

Question:
does the compiler go over this source in multiple passes
such that the declaration of :analyse is known before its
usage in infix:<=>?
--
TSa (Thomas Sandlaß)


Larry Wall

unread,
Apr 2, 2005, 2:40:17 PM4/2/05
to perl6-l...@perl.org
On Thu, Mar 31, 2005 at 03:03:09PM +0200, Thomas Sandlaß wrote:
: Larry Wall wrote:
: >On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: >: How can you have a level independent position?
: >
: >By not confusing positions with numbers. They're just pointers into
: >a particular string.
:
: I'm not the Unicode guru but my understanding is that all composition
: sequences are finite and stateless with respect to everything before
: and after them in the string. Which brings me to the question if these
: positions are defined like positions in Emacs as lying *between* the
: chars? Then the set of positions of a higher level is a subset of the
: positions of lower levels.

Yes, that's how I've been thinking of them. Thanks for making that explicit.

: With defining position as between chars many operations on strings are


: downwards compatible between levels, e.g. splitting. If one determines
: e.g. an insert position on a higher level there's no problem in letting
: the actual insertion beeing handled by a lower level. With fractional
: positions on higher levels some degree of upward or tunneling
: compatibility can be achieved.

That's my feeling.

: BTW, will bidirectionality be supported? Does it make sense to reflect


: it in the StrPos type such that $pos_start < $pos_end means a non-empty
: left to right string, $pos_start > $pos_end is a non-empty right to left
: string and $pos_start == $pos_end delimit an empty (sub)string? As a
: natural consequence the sign indicates direction with negative length
: beeing right to left. And that leads to two times two types of iterators:
: left to right, right to left, start to end and end to start.

Offhand I'd rather have end < start be undefined, I think, but I
suppose we could give it a meaning if it turns out not to be an
easily generated degenerate case like 0..-1. On the other hand,
I think right-to-left might deserve more Huffman visibility than an
itty-bitty sign that might be hidden down in a varible.

But then, we've played games with signs in substr and splice before.
It's not clear that people would want substr($x, -3) to return the
characters in reversed order, though.

: All the above leads me to rant about an array like type. Please forgive


: me if the following is not proper Perl6. My point is to illustrate how
: I imagine the future communication between implementor and user of such
: a class. Actually some POD support for extracting the type information
: into the documentation would be great, too!
:
: And yes, the :analyse should be made lazy. The distinction between the
: first and second index method could be even more specific by using
: type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
: information that indexing with a list of one element doesn't result
: in a List of Str but a plain Str. OTOH this will incur a performance
: penalty and violate the intuitive notion "list in, list out".

MEGO.

: class StrPosArray does Array where { ::Index does StrPos }


: {
: has Str $:data;
: has StrPos @:pos;
:
: multi method postcircumfix:<[ ]>
: (: Index $i ) returns Str {...}
: multi method postcircumfix:<[ ]>
: (: List of Index $i ) returns List of Str {...}
: multi method postcircumfix:<[ ]>
: (: Range of Index $i ) returns List of Str {...}
: multi method postcircumfix:<[ ]>
: (: Int $i ) returns Str {...}
:
: # more stuff here for push, pop, shift etc.
:
: method infix:<=> (: Str $rhs ) returns ::?CLASS
: {
: $:data = $rhs;
: :analyse;
: }
:
: method :analyse ()
: {
: # scan $:data for all between char positions
: # and store them into @:pos
: }
: }
:
: Question:
: does the compiler go over this source in multiple passes
: such that the declaration of :analyse is known before its
: usage in infix:<=>?

No, you just throw in a forward declaration with {...} in that case.

Larry

Rod Adams

unread,
Apr 3, 2005, 5:03:40 AM4/3/05
to perl6-l...@perl.org
Larry Wall wrote:

>On Thu, Mar 31, 2005 at 03:03:09PM +0200, Thomas Sandlaß wrote:
>
>: BTW, will bidirectionality be supported? Does it make sense to reflect
>: it in the StrPos type such that $pos_start < $pos_end means a non-empty
>: left to right string, $pos_start > $pos_end is a non-empty right to left
>: string and $pos_start == $pos_end delimit an empty (sub)string? As a
>: natural consequence the sign indicates direction with negative length
>: beeing right to left. And that leads to two times two types of iterators:
>: left to right, right to left, start to end and end to start.
>
>Offhand I'd rather have end < start be undefined, I think, but I
>suppose we could give it a meaning if it turns out not to be an
>easily generated degenerate case like 0..-1. On the other hand,
>I think right-to-left might deserve more Huffman visibility than an
>itty-bitty sign that might be hidden down in a varible.
>
>But then, we've played games with signs in substr and splice before.
>It's not clear that people would want substr($x, -3) to return the
>characters in reversed order, though.
>

I don't see how rtl vs ltr changes how we process strings. It's purely a
display problem. I seriously doubt the someone working with a rtl
language would ever wish to count the characters ltr. And note that we
are calling the positions "start" and "end", not "left" and "right".

If I'm missing something basic here, let me know.

-- Rod Adams

Reply all
Reply to author
Forward
0 new messages