Fun with unified collections [was: Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types]
A little blue-sky, here...
> > And strictly
> > speaking, its an ordered associative array right? It doesn't really
need
> > the full range of expression offered by $0{...} and $0[...]. All it
> > needs is $0[1] for ordered lookups and $0["1"] for named lookups.
>
> Nope. The array aspect returns $1, $2, $3, etc.
> The hash aspect returns the named captures.
Seems to me this dual-aspectedness could be useful in representing the
sort of tree nodes one would get from parsing XML. The hash aspect
allows access to the (unordered) attributes and the array aspect allows
access to the (ordered) child nodes. With such a collection type built-in,
perhaps embedded XML could be treated as a quote-like construct, yielding
tree values instead of string or regexp values like the other quote-like
constructs...
my $doc =
Howdy!
Hello, strange new world!
;
Not only is this handy for XML, but it may be handy also for parsers
written in Perl.
Some cleverness could be applied to come up with a set of tree-operators.
Roughly,
$doc = tgrep { ref $_ or not $_ =~ m/^\s*$/s } $doc;
would kill the whitespace-only leaf nodes in the above tree.
Perl already does great stuff with scalars and lists, but it would be nice
to see it do some new things with trees (natively).
One crude example would be an 'at' tree-path op (think XPath, I guess) --
although I expect there are superior formulations of this idea:
my $msg = $doc at "/html/body/p"; # Returns first node.
print "$msg\n"; # Prints "Hello, strange new world!\n"
Or, imagining some big HTML document already in $html, this:
my @h = $html at "h1|h2|h3"; # Returns a list of nodes.
foreach my $h (@h) {
my ($level) = $h =~ /^h(\d)$/; # Stringizes to element name
my $title = join " ", tgrep { not ref $_ } $h; # Flatten to list of
strings
print(" " x $level, $title, "\n");
}
would print a heading summary with indentation.
Perl can already do some pretty LISPy things, so why not some TREPpy
things, too?
Regards,
-- Gregor
Re: Arrays: is computed
Shouldn't access to 'is computed' arrays be read-only?
If you want to be able to consume the elements by shifting,
you can always create a tied object that kees a cursor and
a reference to the underlying array and gives you that
access (and it could die for splicing, etc.)...
Regards,
-- Gregor
Michael Lazzaro <[EMAIL PROTECTED]>
01/30/2003 02:25 PM
To: [EMAIL PROTECTED]
cc:
Subject:Arrays: is computed
For C arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2]; # 4 (doesn't exist, is computed)
@a[3]; # 9 (doesn't exist, is computed)
@a[4]; # 16 (doesn't exist, is computed)
Now setting an element:
@a[4] = 0;# (setting an element autofills previous elements)
# @a now contains (0,1,4,9,0)
@a[2];# 4
@a[3];# 9
@a[4];# 0
@a[5];# 25 (still doesn't exist, is computed)
@a[1000] = 0 # (calls the computed sub 1000 times, hope ya meant
it)
Again, note the dubious behavior of doing a C or other
manipulation on any C array. The autofilled portion would
shift, but the computed portion would not:
my int @a is computed { $^index ** 2 }
# at first, @a is entirely computed,
(0,1,4,9,16,25,...)
@a[4] = 0; # @a now contains (0,1,4,9,0);
# now (real) + (computed)
shift @a;# (1,4,9,0) + (16,25,...)
shift @a;# (4,9,0) + (9,16,25,...)
shift @a;# (9,0) + (4,9,16,25,...)
shift @a;# (0) + (1,4,9,16,25,...)
shift @a;# () + (0,1,4,9,16,25,...)
Not saying that's wrong. Just very, very wacky. And yes, it's fixable
if every array has an "offset" number that's always updated to mark how
far the array has been shifted/unshifted from it's starting point. But
I'm not suggesting that. Really.
MikeL
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
AAron --
I think the point is that C<$x{$foo}> says "Hey C<$x>, y'know that
unordered
mess of stuff you've been keeping track of? Get me the one tagged $foo,
woudja?" while C<$x[$n]> says "yo C<$x>! Grab me the C<$n>-th thingee
in line over there, hey!". And, nothing prevents you wanting to use a
number for a tag in the first instance (so type doesn't disambiguate).
And,
nothing prevents you having a single object that allows both types of
abuse (like the tree stuff I posted about earlier). Thus, we retain two
different
(but related) notations: one for unordered access, one for ordered access.
Any given object may support none, one or both.
Regards,
-- Gregor
Aaron Sherman <[EMAIL PROTECTED]>
01/30/2003 03:15 PM
To: Damian Conway <[EMAIL PROTECTED]>
cc: Perl6 Language List <[EMAIL PROTECTED]>
Subject:Re: arrays, hashes unified indexing syntax impact on future
varia tion s
on other collection types
On Thu, 2003-01-30 at 14:21, Damian Conway wrote:
> People, the whole argument that $a[key] should be a homonym for both
> array-like and hash-like look-ups is
... a really bad argument to have, and I would not presume. When Perl
has tried to unify syntax in that way, it has ultimately failed (as you
note) to be coherent.
My question was, are these two different semantic operations, or are
they one operation with some type-sensitivity? Do curlies actually
resolve some fundamental ambiguity? I think we've demonstrated that they
don't, other than that ambiguity which exists already in the language,
outside of indexing operations.
What was the semantic tie between select and select? Even the tie
between the various gotos was pretty tenuous, and that caused problems.
This is a case where the indexing operator on one container class is
different from the indexing operator on another. Why? Because we had so
much spare syntax lying around? No. It was because a) AWK introduced the
idea and b) Perl1..5 had a "sigle denotes access, not type" model.
Those things are not terribly relevant to Perl 6, and as such, I'm not
sure why you feel that there's an imperative to use the Perl 5 notation.
Please enlighten me, Damian. I respect your deep understanding of this
language, and I'm willing to accept that you're intuitively grasping
something that I don't. All I see now is:
namevalue
namevalue
Which would seem to be easier written as:
value
value
value
Perhaps casting it in non-Perl syntax will free us from the bonds of our
preconceptions
--
Aaron Sherman <[EMAIL PROTECTED]>
This message (c) 2003 by Aaron Sherman,
and granted to the Public Domain in 2023.
Fight the DMCA and copyright extension!
Re: Language Discussion Summaries
Sounds like a job for a bot! (couldn't resist) -- Gregor Jonathan Scott Duff <[EMAIL PROTECTED]> 02/04/2003 11:38 AM Please respond to duff To: Buddha Buck <[EMAIL PROTECTED]> cc: "Miko O'Sullivan" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject:Re: Language Discussion Summaries On Tue, Feb 04, 2003 at 10:56:34AM -0500, Buddha Buck wrote: > Miko O'Sullivan wrote: > >>And how do these differ in concept to the RFC process Perl 6 has already > >>gone through? Wouldn't it make sense, assuming that clean, final > >>presentations of proposed ideas or features in Perl are useful, to > >>re-open the RFC process? > > > > > > RFC's are proposals before the comments. The summaries are, well, > > summaries of the comments. My main concern is that Larry, Damian, et al, > > are likely to have a hard time reading through all the comments in the > > language list (Damian isn't even in the list right now), so the summaries > > are a way of letting them cut to the chase on the discussion of each idea. > > You are aware the that RFCs went through a revision process, and the > "finalized" RFCs that the Design Team are looking at are supposed to > include the final form of the idea after discussion, and a summary of > what was thought of it? Many of the RFCs weren't written until after > the idea had been discussed. Buddha Buck's comments aside, I think thread-summaries would be a useful thing. But probably only if we continue to have these long seemingly endless threads. Better might be someone who's there to shout "LET'S WRAP IT UP PEOPLE!" every now and then. And maybe that someone is Miko :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Object spec
> Are you speaking in terms of limitation, or requirement?
> It would be nice to have a syntax solution. I've seen p5 interfaces
> with stubs that die so that you have to override them in a subclass. It
> works, but seems a little kludgy.
Back in 1988 programming Objective-C under NeXTSTEP you could have a
class that does these things (based on methods inherited from Object):
- iJustCantSeemToGetAnythingDone
{
[self notImplemented:_cmd]; // TODO: We'd better write this soon!
}
- imFeelingAbstract
{
[self subclassResponsibility:_cmd];
}
- bogus
{
[self error:"Bogon flux exceeds limit %d\n", BOGON_LIMIT];
}
Also, there was a doesNotRecognize: method that was called by the runtime
system when method lookup failed. I presume you could override it to do
nasty things, but I never did that myself.
Regards,
-- Gregor
Re: Associations between classes [was: Re: Object spec]
Seems like you are thinking along the lines of making Parrot support
Prevayler-style
http://www-106.ibm.com/developerworks/web/library/wa-objprev/index.html
stuff naturally and with less coding at the top layer. Is that where you
are headed with
this?
Regards,
-- Gregor Purdy
Sam Vilain <[EMAIL PROTECTED]>
Sent by: Sam Vilain <[EMAIL PROTECTED]>
03/05/2003 11:11 AM
To: [EMAIL PROTECTED], Paul <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc:
Subject:Associations between classes [was: Re: Object spec]
On Thu, 06 Mar 2003 04:19, Paul wrote:
> > Leave them out to carry on with the status quo of a myriad of subtly
> > different, non-interchangable approaches to associating classes.
> TMTOWTDI?
> Still, though your point is valid if I understand it, it will always be
> possible to create "non-interchangable approaches", and we don't want
> to dictate methods if we can help it.
> I think I need an exampleunfortunately I'm at work and haven't the
> time to properly peruse the one you offered. Thus I must apologize, and
> wait for more input.
Consider this excerpt from the test script:
my $joe = new Person(name => "Joe Average");
my $car = new Object(description => "Red Car");
$car->set_owner($joe);
ok($joe->posessions->includes($car), "Joe owns car");
The `Object' class has an association which it calls `owner', to class
`Person' (note: not all associations will be restricted to a particular
class). This is a collection that can only have one element so it is
implemented with a reference.
The `Person' class has an association which it calls `posessions' to class
`Object'. This is an unordered collection that can hold many elements so
it is implemented with a Set::Object.
They are the same relationship, and so setting the relationship from one
direction affects the other direction.
So, it makes sense to allow the same methods to access and update the
collections.
is($joe->get_posessions(0), $car, "Joe's first posession is his car");
ok($joe->posessions->includes($car), "Joe's posessions are a set");
ok($joe->posessions_includes($car), "Joe's set of posessions is
encapsulated");
These tests perhaps illustrate the level to which I've made them similar;
is($car->get_owner(0), $joe, "Refs can look like arrays");
ok($car->owner_includes($joe), "Refs can look like encapsulated sets");
eval { $car->owner->includes($joe) };
ok($@, "Refs cannot behave like real Sets");
To make the last test work would need associations in the object core, I
think.
--
Sam Vilain, [EMAIL PROTECTED]
Whatever you do will be insignificant, but it is very important that
you do it.
-- Mahatma Gandhi
Re: A6: Complex Parameter Types
Nick --
I've been thinking of it like this:
class int isa intlike; # and isa value or whatever
class Int isa intlike; # and isa Object or whatever
class num isa numlike; # and isa value or whatever
class Num isa numlike; # and isa Object or whatever
...
class Scalar isa intlike, numlike, ...; # and isa Object or whatever
The *like classes are placeholder (interface) classes that capture
the ability to *treat as* (as opposed to *really is*). And (importantly
IMO) the *like classes capture the aspects of foo and Foo that
are the same, leaving the foo and Foo classes to capture the
differences.
- - - - - - - - - - - - - - - - - - - - - -
A different way to handle Scalar would be to have Perl 6 allow
mutating objects (type changes). Scalar could be a superclass
of Int and Num, but it could be abstract (no instances allowed).
Values would be only of concrete types (e.g. Int, Num, Str). That
isn't very tricky, until you try to do
my $x = "5";
$x += 37;
Is $x the same object as it was before, but with a different internal
state, or is it now a completely different object (since its type
presumably changed to Int from Str)?
I'm not as comfortable with this, I have to admit. I like a single Scalar
class that has magical internal state and presents various "facets"
to the outside world (Int, Num, Str, ...). The magical internal state
can do things like maintain Int and Str values in parallel if it wishes
(which would be a strange thing for Int to do by itself, IMO).
- - - - - - - - - - - - - - - - - - - - - - - -
FWIW, I think Circle is a predicate on the set of Ellipses, so I'd say
Circle isa Ellipse. If I were using Eiffel, I'd use renaming and
overriding so that you could query the semimajor and semiminor
axes and radius, and get the same number in all three cases.
And, if you are working with a value that isa Circle, you may not
*set* the semimajor and semiminor axes (you have to set the
radius). Of course, this makes things ugly when you have a Circle
in an Ellipse variable. You'd like to take the fact that something
is an Ellipse to mean that you *can* set the axes separately,
since that is an Ellipse kind of thing to do. This smacks of an
argument for Ellipse and Circle being peers -- subclasses of
some other abstract helper class.
Or, to truly simplify, don't have a Circle class at all. Have an isCircle
predicate on Ellipse, which matches the mathematical case nicely.
Being able to do C and get back an
appropriate ellipse would still be nice, though.
I think the trouble comes from the fact that there are two kinds of
Circle that come up: Ellipse-in-general-but-Circle-right-now (loose,
or behavioral) and Circle-we-want-to-treat-as-Ellipse-sometimes
(strict, classical). You could definitely make an Ellipse class that
had an isCircle method, a radius-based constructor, and
getRadius and setRadius methods, and the only time it would let
you down is if you didn't check isCircle before calling getRadius,
because it would throw an exception (since there is no single
radius for a not isCircle Ellipse). It means your class is really
EllipseOrCircle, I guess.
For the strict case above, you would have to have though
ahead enough to have the Ellipse-like 'get' methods in one
place and teh Ellipse-like 'set' methods elsewhere. Circle
could inherit from the EllipseGettable but not EllipseSettable
(since you can ask for, but not set the semi axes).
Regards,
-- Gregor Purdy
Nicholas Clark <[EMAIL PROTECTED]>
03/15/2003 06:48 PM
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
cc:
Subject:Re: A6: Complex Parameter Types
There seems to be some confusion about which way up the world is.
On Tue, Mar 11, 2003 at 01:25:41PM +1100, Damian Conway wrote:
> Which in turn is because:
>
>not Scalar.isa(int)
On Thu, Mar 13, 2003 at 11:55:06AM -0800, Larry Wall wrote:
> On Thu, Mar 13, 2003 at 11:31:30AM -0800, Austin Hastings wrote:
> : "Everyone Knows" that an Int is a Scalar, and therefore a sub that has
> : a Scalar parameter can safely be passed an Int. This is normal.
> I don't see a problem. Scalar == Int|Num|Str|Ref, so Scalar.isa("Int").
>
> Larry
On Thu, Mar 13, 2003 at 12:00:54PM -0800, Paul wrote:
> > I don't see a problem. Scalar == Int|Num|Str|Ref, so
> > Scalar.isa("Int").
>
> Scalar.isa("Int") && Int.isa("Scalar")
This term "subtyping" I didn't know:
On Fri, Mar 14, 2003 at 10:46:31AM -0800, Larry Wall wrote:
> Well, I'm using the terms type and class pretty much interchangeably
> there, so don't put too much weight on that. But Perl 6 may well
> distinguish classes from types. Classical classes can only add
> capabilities when you derive (yes, you can rede
Re: Perl and *ML
Dan -- Dan++ (Dan -- this is going to look familiar to you from prior IRC conversions IIRC, but I thought it could stand repeating in public). A good set of tree/graph primitives/utilities would be a wonderful addition IMO. And since XML is so common, I'd like to see it treated as a quotelike construct for producing trees (we already have qq for strings and qw for lists, etc.): my $foo = Hi there! would be one way to point $foo at one of these magical graph representations. If we had such a thing, plus an eval variant that only accepted plain old data (safe to use on untrusted sources because nothing active will be respected), we could pull info in from XML (and other) files easily, too. The construct in the example above could be parsed at compile time. In memory you've got the tree. If you are compiling to bytecode, the constant section could contain the list of SAX events (or equivalent) required to reproduce it (allowing some lazy possibilities BTW). Regards, -- Gregor Purdy Dan Sugalski <[EMAIL PROTECTED]> 03/26/2003 10:25 AM To: [EMAIL PROTECTED] cc: Subject:Perl and *ML I think that the issue here isn't so much good perl support for XML as it is good support for attributed DAGs, something which would be of general good use for perl, since the ASTs the parser feeds to the compiler will ultimately be DAGs of a sort. So, rather than jumping on the "XML [insert verb here]!" bandwagon, perhaps we'd be better served figuring out what would be useful operations and support for/on DAGs and suchlike things? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The C Comma
Luke --
I guess it might be nice to just do that with a block...
my $n;
while { $n++; @accum } < $total {
...;
}
since we already have a nice do-this-then-do-this syntax.
Sure, it looks a little weird in a for loop:
for ($i = 0; $i < $X; { $i++; some_func() }) {
...;
}
but they are already weird anyway.
FWIW, In the (hypothetical) future Jako (see parrot's
languages/jako/docs/future.pod), I've toyed with a few different ways of
looking at these sorts of constructs, one of which is this (I've made it
look a *little* more Perlish than in future.pod):
You can still write for() like this:
for ($i = 0; $i < l;$ i++) { print $x[$i], "\n" }
but it is really shorthand for this (there's a nit here wrt mapping
"for (my $i ...)" to something reasonable):
for { $i = 0 } { $i < l } { $i++ } { print $x[$i], "\n" }
or, more verbosely:
for {
$i = 0;
} while {
$i < l
} continue {
$i++
} do {
print $x[$i], "\n"
}
That is, the construct:
( ...; ...; ...; )
is another way of saying
{ ... } { ... } { ... }
which, in the case of for(), is interpreted as
{ ... } while { ... } continue { ... }
when each of the "..." is a single statement. For any case where you
want to use more than one statement for one of the "...", you just use
the more verbose syntax.
Now, that won't map directly to Perl 6, since it will handle continue
differently inside the "do" part (right?), but it fits my mental model
nicely (this idea came from looking at looping constructs from Eiffel
as well as elsewhere and looking for the unifying stuff).
Regards,
-- Gregor
On Mon, 2003-11-24 at 16:00, Luke Palmer wrote:
> Honestly you guys, I'm not trolling. I'm just getting a lot of ideas
> recently. :-)
>
> The C comma has always bugged me, but its function is indeed useful
> (many times I use C in its place, if I know the left side will
> always be true). I don't know whether it's staying or not (I've heard
> rumors of both), but I'd suggest that it leave and allow itself to be
> replaced by a word, alongside C, C, and C.
>
> This word: C.
>
> So, from a recent script of mine:
>
> my $n;
> while $n++ then @accum < $total {
> ...
> }
>
> (Where I got in trouble for using C and never executing anything :-)
>
> To me, it's very clear what's going on, and eliminates the mystery of
> the comma in scalar context for a syntax error.
>
> Luke
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: The Sort Problem
Luke --
Hmmm... I haven't been practicing my Perl 6, and its been a while
since the last Apocalyptic refresher, but here goes (I'll don a paper
bag preemptively)...
Thinking of that as the equivalent to:
sort {
my ($ta, $tb) = map { $_.foo('bar').compute } ($^a, $^b);
$ta <=> $tb
} @unsorted;
so if you had a unary <=> that took a two element array (old style
syntax here, sorry):
sub cmp_num { my ($a, $b) = @_; $a <=> $b; }
you could write that as:
sort {
cmp_num map { $_.foo('bar').compute } ($^a, $^b);
} @unsorted;
I'd be a bit afraid of allowing <=> itself to be prefix, although I
admit it would be handy not to need the separate sub definition:
sort {
<=> map { $_.foo('bar').compute } ($^a, $^b);
} @unsorted;
The Schwartzian is the usual way, of course:
map { $_->[1] }
sort { $^a[0] <=> $^b[0] }
map { [ $_.foo('bar').compute, $_ ] }
@unsorted;
But we really aren't being concise here.
(Aside) I wonder if there will be a new Perl 6 idiom to replace this
using properties, something like this:
map { $_.really }
sort : numerically
map { $_.foo('bar').compute but really($_) }
@unsorted;
or:
@unsorted
==> map { $_.foo('bar').compute but really($_) }
==> sort : numerically
==> map { $_.really };
But we *still* aren't concise.
Maybe we should have a two-block sort? The second block gives the
transform to apply to the elements before applying the comparison
block:
sort { $^a <=> $^b } { $_.foo('bar').compute } @unsorted;
Or maybe even something like this:
sort :numerically :as { $^a.foo('bar').compute } @unsorted;
Regards,
-- Gregor
On Wed, 2004-02-11 at 19:11, Luke Palmer wrote:
> I've been thinking about this problem which comes up in my code a lot:
>
> @sorted = sort { $^a.foo('bar').compute <=> $^b.foo('bar').compute }
> @unsorted;
>
> Often the expressions on each side are even longer than that. But one
> thing remains: both sides are exactly the same, substitute a $^b for a
> $^a.
>
> I can see a couple less-than-desirable ways around this redundancy:
>
> @sorted = sort { infix:<=>( *($^a, $^b)».foo('bar').compute ) }
> @unsorted;
>
> Which doesn't work if .compute returns a list... not to mention its
> horrible ugliness. Another is to define a variant of sort (haven't had
> much practice with A6 material recently; here we go!):
>
> multi sub sort (&block($) = { $_ } : [EMAIL PROTECTED]) {
> sort { block($^a) cmp block($^b) } @data;
> }
>
> @sorted = sort { .foo('bar').compute } @unsorted;
>
> Which has the disadvantage of forcing you to use C and forcing an
> ascending sort.
>
> Any other ideas? Is a more general solution necessary?
>
> Luke
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Some other tyops
First, thanks Damian for doing this, and good show!
Smylers already pointed out a few errors in the document, but
here are a few others I noticed:
* In "Why, how now, ho! From whence ariseth this?"
We have this near the top:
type FormArgs ::= Str|Array|Pair;
and this below:
type FormArgs ::= Str|Num|Array|Pair
which is it? (The former -- :) -- appears later in the document
too,
in "Therefore, put you in your best array...")
* In "What a block art thou..."
We have a format like this:
"...{<<<<<<<<<<<<<<<<<}...{>>>>>>>}...
printing something like this:
...By the pricking of ... A horse!...
That should be
...By the pricking of ...A horse!...
* In "Therefore, put you in your best array..."
"form doesn't losing track" should be "form doesn't lose track"
* In "Or else be impudently negative..."
"we simple put an" should be "we simply put an"
* In "Thou shalt have my best gown to make thee a pair..."
"that the string that contains a valid identifier" should be "that
the string contains a valid identifier"
* In "What you will command me will I do..."
"there's not reason" should be "there's no reason".
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Dynamic Headers
In "From the crown of his head to the sole of his foot..." (clearly
a reference to a Gilligan's Island episode where Lovey said something
similar :), we have:
:header{ ..., odd => "Act, $act, Scene $scene...", ... }
and below, text indicating that it will
"prepend the act and scene information to the start of any odd page
(except, of course, the first or the last), ..."
I don't see how that can be. The string will be evaluated and
interpolated at the time the option pair is constructed, most likely
with C<$act> and C<$scene> undef. After that, the same static text
will appear in the header.
I suppose
... odd => sub { "Act, $act, Scene $scene ..." }, ...
would work, though.
Regards,
-- Gregor
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Fill Justification
In the section "He doth fill fields..." we see an example of Fill Justification where two spaces fit between every word. This doesn't give us an idea of how spaces are distributed if the number of spaces needed does not divide evenly into the number of interstices. In the section "More particulars must justify my knowledge...", indicates the approach is to "...distribute any padding as evenly as possible into the existing whitespace gaps...", but still doesn't tell us what the rule really is. In the example, there are two spaces to be distributed and three interstices. The last two each get one space. That could be the "add one pad to each insterstice from right to left, repeat until exhausted" rule, which isn't really about even distribution. One other note about this example: The text says C will "...extract a maximal substring...", but in the example that string would be "A fellow of infinite j". The example output shows that the extracted string isn't quite maximal. It tries to keep words together (this rule is detailed elsewhere, but this example doesn't refer to that extraction rule). -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Option Key Validity
In "Thou shalt have my best gown to make thee a pair...", we are given a reason to use the option syntax vs. the pair constructing fat comma C<< => >>: "...we're guaranteed that the key of the resulting pair is a string, that the string [...] contains a valid identifier, and that the compiler can check the validity before the program starts." (Do we need both "...a valid..." and "...check the validity..."?) We aren't told what validity checking the compiler is doing. I figure its looking for some in-scope declaration of that identifier, but what would such a declaration look like? Where exactly does the set of valid option identifiers *for C* come from, and are they tied *to C*, or floating in a global space, free to collide with other (option key) identifier declarations? It seems like there's more to this story... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Overflow Fields
In "And now at length they overflow their banks." its not clear how an overflow field gets tied to its initial non-overflow field. In the recipe example given, how does it know to go with the $method field instead of the $prep_time field? Is it basing off of matching the horizontal extent of the initial field? If so, are error messages generated if there is overlap? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Exegesis 7: Perl6::Slurp
The Exegesis mentions the Perl6::Slurp module, but I don't see it on CPAN. Is it just a race condition? Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Option Key Validity
Smylers -- I think the claim in E7 is stronger, that not only does the string match the identifier pattern, but that it is a 'valid' (known, declared) identifier. Else, what would be the point of saying both: * "contains a valid identifier", and * "check the validity before the program starts" But, since E7 doesn't come right out and say it, I'm asking for clarification. Still could be that you are right and there is nothing to see here, though... Regards, -- Gregor On Sat, 2004-02-28 at 07:46, Smylers wrote: > Gregor N. Purdy writes: > > > "...we're guaranteed that the key of the resulting pair is a string, > > that the string [...] contains a valid identifier, and that the > > compiler can check the validity before the program starts." > > > > We aren't told what validity checking the compiler is doing. I figure > > its looking for some in-scope declaration of that identifier, but what > > would such a declaration look like? > > I take "valid identifier" to mean something which is syntactically valid > as an identifier, rather than something that is in the finite set of > identifiers which C actually uses. > > Using the C<< => >> it's possible to construct pairs in which the key is > not a valid identifier: > > 'Hello there' => 'contains a space', > '2b' => 'starts with a digit', > '%^&@";' => 'only punctuation characters', > > None of those keys could result from using the C<:> option constructor. > > Smylers -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Overflow Fields
Smylers -- So, what I'm looking for is more explicit phrasing around "immediately above". In the example, the column range for the overflow field is exactly the same as that of the $method field in the prior "picture". But, what does it do if it doesn't match *exactly*? Is it an error, does it have some heuristics to guess? What are the edge cases? Regards, -- Gregor On Sat, 2004-02-28 at 07:39, Smylers wrote: > Gregor N. Purdy writes: > > > In "And now at length they overflow their banks." its not clear > > how an overflow field gets tied to its initial non-overflow field. > > In the recipe example given, how does it know to go with the > > $method field instead of the $prep_time field? > > The definition given is: > > An overflow field automagically duplicates the field specification > immediately above it. > > The method field is immediately above the overflow field; the > preparation time field isn't. > > Smylers -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Fill Justification
Damian -- Good. I don't remember where I first heard about doing it that way vs. from the left, but the results going from the right to left are typically better looking than from left to right, and I use that way exclusively now. Regards, -- Gregor On Sat, 2004-02-28 at 15:54, Damian Conway wrote: > Gregor N. Purdy wrote: > > > In the section "He doth fill fields..." we see an example of Fill > > Justification where two spaces fit between every word. This doesn't > > give us an idea of how spaces are distributed if the number of > > spaces needed does not divide evenly into the number of interstices. > > Currently extra spaces are fitted into the rightmost gaps (as this seems -- to > me at leats- to produce the least weird results). I've tried all sorts of > other schemes but none seem as satisfactory to me. > > Damian -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Mutating methods
Larry --
So, will "mutatingness" be a context we'll be able to inquire on
in the implementation of a called routine? Or, could we provide
a specialized distinct implementation for mutating that would get
called if .=X() is used? If we are performing some operation on
large data, and we know the end result is going to clobber the
current object, we could avoid making an extra copy.
I suppose there is some danger here. What if I write a class
that I intend to have value semantics. That is, once an instance's
value is set at construction time, it never changes, although you
can get new instances by invoking its methods. BigInt would
work this way. I can imagine a Point class working this way - you
don't (necessarily) want two objects hanging on to a point, and one
of them to mutate it into a different value out from under the other
one. You wouldn't expect that behavior from other value objects such
as built-in strings.
This points at mutatingness being aimed at the reference (variable)
not the referrent (value), unless it can be different in the case
of value-objects and container-objects...
So, if we had a BigDataContainer class for which it *was* reasonable
to mutate it in place, and we wanted that behavior to trigger on .=
to do an in-place modification:
$bigData .=applyBlockCipher($cipher, $key);
would there be a way to do that without the extra copy implied in:
$bigData = $bigData.applyBlockCipher($cipher, $key);
while leaving
$foo .=someOtherMethod();
equivalent to
$foo = $foo.someOtherMethod();
when $foo's class or someOtherMethod() implementation doesn't do
anything special?
Regards,
-- Gregor
On Wed, 2004-03-10 at 21:29, Larry Wall wrote:
> On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
> : I was thinking along the lines of...
> :
> : String $foo = "hello";
> : $foo.scramble!
>
> That would be $foo.=scramble in the current scheme of things.
>
> : print "$foo\n";
> : $foo = "hello"
> : print $foo.scramble ~ "\n";
> : print $foo;
> :
> : OUTPUT (or close):
> : elhlo
> : hloel
> : hello
> :
> : Also, along these same things.. is there a way to apply a method to all
> : variables/objects of a certain type (e.g. String, Num, etc)? Taking the
> : above example.. being able to write a method called "Scramble" that can be
> : called as a method from any String type.
>
> Two ways, actually. You can 'reopen" the String class and add the method:
>
> class String is extended {
> method scramble () returns String {...}
> }
>
> or if you consider that underhanded, you can define a multi-sub:
>
> multi sub *scramble (String $s) returns String {...}
>
> If you call that as a method, and there is no ordinary scramble method,
> it will "fail soft" to looking for a scramble multimethod, and end up
> calling your definition. Or you can just call it directly as a function:
>
> scramble("hello")
>
> Larry
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Funky «vector» operator
For me, (vim 6.2), that is < < to get « > > to get » after doing :set digraph (list of available digraphs can be seen by :digraph) But, I find the above a bit unnerving because I've deleted the character, and then if I type a certain character next I haven't. Vim also allows < < to get « > > to get » Regards, -- Gregor On Fri, 2004-03-19 at 05:39, Rafael Garcia-Suarez wrote: > Andy Wardley wrote in perl.perl6.language : > > I'm so happy! I just found out, totally by accident, that I can type > > the « and » characters by pressing AltGr + Z and AltGr + X, > > respectively. > > Of course this information is almost completely unusable without knowing > your OS, your locale, and your keyboard flavour. But thanks anyway, and > I'll share mine : with vim, and with the 'digraph' option set, just type > < < to get « > > > to get » > This is probably common knowledge as well. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Funky «vector» operator
Oh, and the form doesn't require you to do the :set digraph thing. Its always available. Regards, -- Gregor On Fri, 2004-03-19 at 06:16, Gregor N. Purdy wrote: > For me, (vim 6.2), that is > > < < to get « > > > to get » > > after doing > > :set digraph > > (list of available digraphs can be seen by :digraph) > > But, I find the above a bit unnerving because I've deleted > the character, and then if I type a certain character next > I haven't. > > Vim also allows > >< < to get « >> > to get » > > > Regards, > > -- Gregor > > On Fri, 2004-03-19 at 05:39, Rafael Garcia-Suarez wrote: > > Andy Wardley wrote in perl.perl6.language : > > > I'm so happy! I just found out, totally by accident, that I can type > > > the « and » characters by pressing AltGr + Z and AltGr + X, > > > respectively. > > > > Of course this information is almost completely unusable without knowing > > your OS, your locale, and your keyboard flavour. But thanks anyway, and > > I'll share mine : with vim, and with the 'digraph' option set, just type > > < <to get « > > > >to get » > > This is probably common knowledge as well. -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
So, we are moving in a more verbose direction, which is a bummer for people who like to write one-liners and other tiny programs. Assuming only Perl 6 is installed on your system, if your script started with: #!/usr/bin/perl all the stuff about trying to figure out what version you are using would have to apply I suppose. But, if you used this, are we saying you still have to do something else to ensure its treated as Perl 6? #!/usr/bin/perl6 And, if you did this, you might have to do something else to ensure it is treated as Perl 5? #!/usr/bin/perl5 that seems wrong. Regards, -- Gregor On Tue, 2004-04-13 at 08:12, Luke Palmer wrote: > David Cantrell writes: > > A few days ago I briefly discussed with Nicholas Clark (current perl 5.8 > > pumpking) about making perl5 code forward-compatible with perl6. A > > quick look through the mailing list archives didn't turn up anything > > obvious, and I don't recall any mechanism being presented in any of the > > Apocalypses, so ... > > Well, there is one, as far as I understand it. Your "use perl5;" is > spelled "package". That is, perl will assume Perl 6 unless it sees > "package SomethingOrOther;" (since Perl 6 calls them "module"s). So, to > force Perl 5 interpretation, use: > > package main; > > Luke -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
Lets try that again, since I think you parsed my email in a way I
didn't intend (and its at least 50% my fault)
--
In my opinion, starting a script with "#!/usr/bin/perl6" should force
the interpreter to treat it like Perl 6, and if it does anything else
that's just ugly. Similarly, starting a script with "#!/usr/bin/perl5"
should force the interpreter to treat it like Perl 5, and if it does
anything else that's just ugly, too. The only opportunity for
ambiguity is if the script starts with "#!/usr/bin/perl" or no shebang
line.
In that case, maximal backward compatibility dictates that the
interpreter expect Perl 5, although 20 years from now we may wish
Perl 6 was assumed (and maybe by Perl 7 we will assume Perl 6 unless
told otherwise... :)
Personally, I view Perl 6 as such a completely new language (although
still Perlish in spirit, it is very different in other respects), that
I would be perfectly happy to be required to start all my Perl 6
programs with "#!/usr/bin/perl6" instead of "#!/usr/bin/perl", just
the same as I'd start a Python program with "#!/usr/bin/python".
If it turns out that the /usr/bin/perl program is actually just a link
to the same executable as /usr/bin/perl6 but operating with a different
personality, I'm fine with that. Heck, I'd be fine with /usr/bin/python
being a symlink to the same executable, too, and I'd expect it to behave
like a Python interpreter.
I don't see any need to have a program start out as a potentially Perl 5
program and then determine that it should really be thought of as Perl 6
and switch personalities. That is, I don't see a need for this:
#!/usr/bin/perl
use 6;
Since there is no version 6 of the Perl (5) language. Inline::Perl6
aside, there ain't no Perl 6 in the Perl 5 world, even though there are
a few Perl6:: isms.
Now, I do think it would be perfectly fine for a program to start off
as a Perl 6 program and have an embedded chunk that is interpreted as
Perl 5, since that is a feature of Perl 6.
#!/usr/bin/perl6
... # Perl 6 stuff here
use 5; # or, whatever
# Perl 5 stuff here
no 5; # or, whatever
# More Perl 6 stuff here
use python; # you get the idea
...
Regards,
-- Gregor
On Wed, 2004-04-14 at 12:59, Aaron Sherman wrote:
> On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> > So, we are moving in a more verbose direction, which is a bummer for
> > people who like to write one-liners and other tiny programs.
>
> perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> s:g/\b\.\.\.\b/IP ADDR/;' *
>
> No biggie.
>
> > Assuming only Perl 6 is installed on your system, if your script
> > started with:
> >
> > #!/usr/bin/perl
> >
> > all the stuff about trying to figure out what version you are using
> > would have to apply I suppose. But, if you used this, are we saying
> > you still have to do something else to ensure its treated as Perl 6?
>
> Yes, because Perl 6 *is* Perl 5, when it wants to be.
>
> > #!/usr/bin/perl6
> >
> > And, if you did this, you might have to do something else to ensure
> > it is treated as Perl 5?
>
> Correct. If you *say* "perl6" and then want to *be* Perl 5, I'm not sure
> if a) you could not or b) you would have to throw in something like "use
> 5".
>
> > #!/usr/bin/perl5
> >
> > that seems wrong.
>
> Not sure why. That is just short-hand for:
>
> #!/usr/bin/perl
> use 5;
>
> I'm not sure, once again, what would happen if you said:
>
> use 5;
> use 6;
>
> Either it would give you an error (you really deserve it) or it would
> just switch back to Perl 6 mode... the problem arises when you ask,
> "what about anything that got parsed in between the two?" Yech.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
Brent --
Clever points are relatively high here, but I find the idea of
doing the notionally simultaneous parse uncomfortable. I really
don't want my programs subject to a hidden double parse cost.
Regards,
-- Gregor
On Wed, 2004-04-14 at 15:30, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman wrote:
> > On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> >
> >>So, we are moving in a more verbose direction, which is a bummer for
> >>people who like to write one-liners and other tiny programs.
> >
> >
> > perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> > s:g/\b\.\.\.\b/IP ADDR/;' *
> >
> > No biggie.
>
> Curlies aren't used for that anymore. I'd also suggest using an
> assertion for a much shorter C rule:
>
> perl6 -i.bak -ple 'rule octet {(\d<1,3>)<($1<256)>}
> s:g/\b\.\.\.\b/IP ADDR/' *
>
> TMTOWTDI, though, and I'm being rather nitpicky.
>
> Personally, I would implement Perl 5 vs. Perl 6 switching as:
>
> 1. If argv[0] includes either '5' or '6', use the appropriate version.
> 2. Parse the program as *both* Perl 5 and Perl 6.
> 3. Figure out which parses succeeded:
> a. If Perl 5 succeeded...
>i. If Perl 6 succeeded, emit an ambiguity warning. (I think this
> warning should be on by default, but that's open to
> negotiation.)
> ii. Execute the Perl 6 parse.
> b. Else if Perl 6 succeeded, execute the Perl 6 parse.
> c. Else...
>i. If exactly one of the parses died on an error that
> disambiguates between the Perls (e.g. a package statement, a
> 'use 6'), emit the other's error message.
> ii. Otherwise, emit an ambiguity warning and both error messages.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
Brent --
I think I missed your point. I'll refer to your two code chunks as
(a) and (b). Maybe you are getting at a finer point, though...
What you've said in (a) is pretty much what I hinted about Inline::Perl6
in my message. If you pass it to a Perl 6 interpreter, then it will
probably use that hint to shift into Perl 5 mode (which, fortunately,
is a perfectly respectable thing for a Perl 6 interpreter to do) kind
of as if what you had sent it was really:
#!/usr/bin/perl6
use syntax 'perl5';
...
Any Perl 5 code above your 'use 5' statement that isn't also legal
Perl 6 code, though, would cause the compiler to complain.
I don't see how what you've said in (b) is different from what I've
said, outside the "use 6" which I think shouldn't exist, since
it means nothing to Perl 5 (there is no Perl 5, version 6) and
means nothing to Perl 6 (which has as its lowest version number...
6). So, the code you wrote is Perl 6 with a redundant "use 6"
in it, otherwise in the same vein as what I wrote. If you pass it
to a Perl 5 interpreter, it will choke. If you pass it to a Perl 6
interpreter, life is peachy keen. If you pass it to a Python
interpreter, you get what you deserve :) You have used "use syntax"
which falls under the category of "# or whatever" in my message.
Regards,
-- Gregor
On Wed, 2004-04-14 at 18:51, Brent 'Dax' Royal-Gordon wrote:
> Gregor N. Purdy wrote:
>
> > #!/usr/bin/perl6
> >
> > ... # Perl 6 stuff here
> >
> > use 5; # or, whatever
> >
> > # Perl 5 stuff here
> >
> > no 5; # or, whatever
> >
> > # More Perl 6 stuff here
> >
> > use python; # you get the idea
>
> Why conflate the two at all? Perl 5 has two separate syntaxes for
> forcing a version and embedding code in a different language:
>
> use 5;# forces Perl < 6
> perl_five_code();
> use Inline::Perl6 q{ # Ah, the wonders of ponie...
> perl_six_code();
> };
> use Inline::Python q{
> python_code()
> };
>
> So why not do the same (albeit in a much slicker way) for Perl 6?
>
> use 6;# forces Perl 6+
> perl_six_code();
>
> {
> use syntax 'perl5'; # switches to Perl 5 syntax
> perl_five_code();
> }
>
> {
> use syntax 'python';
> python_code()
> }#With the indentation, I think this closes both the Perl and
> # the Python block...
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
