Re: Ruminating RFC 93- alphabet-blind pattern matching
Luke Palmer wrote:
On Thu, Apr 03, 2003 at 07:29:37AM -0800, Austin Hastings wrote:
This has been alluded to before.
What would /A*B*/ produce?
Because if you were just processing the rex, I think you'd have to
finish generating all possibilities of A* before you began iterating
over B*...
The proper way would be to first produce all possibilities of length n
before giving any possibility of length n+1.
''
'A'
'B'
'AA'
'AB'
'BB'
'AAA'
'AAB'
...
I haven't spent a milisecond of working out whether that's feasible to
implement, but from a theoretical POV it seems like the solution.
Well, I'm not certain there is really a proper way. But sure, your
way is doable.
use Permutations permutations compositions;
# Generate all strings of length $n
method Rule::Group::generate(Int $n) { # Type sprinkles :)
compositions($n, [EMAIL PROTECTED]) == map {
my @rets = map {
$^atom.generate($^n)
} zip(@.atoms, $_);
*permutations([EMAIL PROTECTED])
}
}
How's that for A4 and A6 in a nutshell, implementing an A5 conept? :)
I hope I got it right
Provided each other kind of rx element implemented generate, that
returned all generated strings of length $n, which might be zero.
This would be trivial for most other atoms and ops (I think).
Oh, compositions($a,$b) is a function that returns all lists of length
$b whose elements sum to $a. Yes, it exists.
I have a couple syntax questions about this if anyone knows the answers:
$^atom.generate($^n)
I want @rets to be an array of array refs. Do I have to explicitly
take the reference of that, or does that work by itself?
zip(@.atoms, $_)
I want the array ref in $_ to be zipped up with @.atoms as if $_ were
a real array. If this Iis correct, am I allowed to say:
zip(@.atoms, @$_)
for documentation?
Also, related to the first question:
*permutations([EMAIL PROTECTED])
Does that interpolate the returned list from permutations right into
the map's return, a la Perl5? Do I need the * ?
As far all of these questions, I think the answer is related. I think
the general question is Is implicit flattening needed for perl6
builtins? I think that the answer is no, or at least should be no,
because it won't be hard to get the builtins to DWIM because of
multimethods.
For instance, an implementation of map might be:
sub *map (code, Array @array) {
return @array.map(code);
}
sub *map (code, [EMAIL PROTECTED]) {
my @ret;
for @rest {
@ret.push( code.($_) );
}
return @ret;
}
So, given an Array/Array Subclass/Reference to one of the two as the
2nd argument to map, map would call the method version of map;
otherwise, the arguments after the code block are flattened and
looped over.
This behaivor should be consistant across all of the perl6 builtins.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Joseph F. Ryan wrote:
Luke Palmer wrote:
On Thu, Apr 03, 2003 at 07:29:37AM -0800, Austin Hastings wrote:
This has been alluded to before.
What would /A*B*/ produce?
Because if you were just processing the rex, I think you'd have to
finish generating all possibilities of A* before you began iterating
over B*...
The proper way would be to first produce all possibilities of
length n before giving any possibility of length n+1.
''
'A'
'B'
'AA'
'AB'
'BB'
'AAA'
'AAB'
...
I haven't spent a milisecond of working out whether that's feasible
to implement, but from a theoretical POV it seems like the solution.
Well, I'm not certain there is really a proper way. But sure, your
way is doable.
use Permutations permutations compositions;
# Generate all strings of length $n
method Rule::Group::generate(Int $n) { # Type sprinkles :)
compositions($n, [EMAIL PROTECTED]) == map {
my @rets = map {$^atom.generate($^n)
} zip(@.atoms, $_);
*permutations([EMAIL PROTECTED])
}
}
How's that for A4 and A6 in a nutshell, implementing an A5 conept? :)
I hope I got it right
Provided each other kind of rx element implemented generate, that
returned all generated strings of length $n, which might be zero.
This would be trivial for most other atoms and ops (I think).
Oh, compositions($a,$b) is a function that returns all lists of length
$b whose elements sum to $a. Yes, it exists.
I have a couple syntax questions about this if anyone knows the answers:
$^atom.generate($^n)
I want @rets to be an array of array refs. Do I have to explicitly
take the reference of that, or does that work by itself?
zip(@.atoms, $_)
I want the array ref in $_ to be zipped up with @.atoms as if $_ were
a real array. If this Iis correct, am I allowed to say:
zip(@.atoms, @$_)
for documentation?
Also, related to the first question:
*permutations([EMAIL PROTECTED])
Does that interpolate the returned list from permutations right into
the map's return, a la Perl5? Do I need the * ?
As far all of these questions, I think the answer is related. I think
the general question is Is implicit flattening needed for perl6
builtins? I think that the answer is no, or at least should be no,
because it won't be hard to get the builtins to DWIM because of
multimethods.
For instance, an implementation of map might be:
sub *map (code, Array @array) {
return @array.map(code);
}
sub *map (code, [EMAIL PROTECTED]) {
my @ret;
for @rest {
@ret.push( code.($_) );
}
return @ret;
}
Except that it should be:
multi *map (code, Array @array) {
return @array.map(code);
}
multi *map (code, [EMAIL PROTECTED]) {
my @ret;
for @rest {
@ret.push( code.($_) );
}
return @ret;
}
I swear, my brain must hate me; I always overlook the most obvious
mistakes. (-:
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Yary Hluchan wrote:
making *productions* of strings/sounds/whatever that could possibly
match the regular expression?
Correct me if I am wrong, but isn't this the :any switch of apoc 5?
http://www.perl.com/pub/a/2002/06/26/synopsis5.html
Not really, unless the input string is infinite!
Well, thats just in the general purpose case, right? That's because
a regex like /a*/ matches:
'w'
'qsdf'
'i bet you didn't wnt this to mtch'
So, you're going to need some sort of controlled input to a regex match
with the :any for it to work right.
Here's my approach to the problem: generate a possible string that
could match every atom in the regex individually, and then generate
matches for the whole regex off of that. I liked Luke's approach
of stapling methods onto the Rx classes, so I used an approach that
made use of that idea. I completed each of the needed rules, since
the methods in my example are pretty simple (they probably would be
in Luke's example too, but I just wanted to be sure I wasn't missing
anything).
use List::Permutations permutations; # Perl 5's name.
sub generate (rx $spec, Int $limit) {
my $string = $spec.generate_match (propagate, $limit);
$string =~ m:any/ ($spec) { yield $1 } /;
my sub propagate ($atom) {
given ($atom) {
when Perl::sv_literal {
$string ~= $_.literal()
}
when Perl::Rx {
$string ~= .generate_match (propagate, $limit)
if .isa(generate_match)
}
}
}
}
Perl::Rx::Atom::generate_match (p, $limit) {
return p.($.atom)
}
Perl::Rx::Zerowidth::generate_match (p, $limit) {
return p.($.atom)
}
Perl::Rx::Meta::generate_match (p, $limit) {
return join '', $.possible
}
Perl::Rx::Oneof::generate_match (p, $limit) {
return join '', $.possible
}
Perl::Rx::Charclass::generate_match (p, $limit) {
return join '', $.possible
}
Perl::Rx::Sequence::generate_match (p, $limit) {
my $string;
$string ~= p.($_) for $.atoms;
return $string;
}
Perl::Rx::Alternation::generate_match (p, $limit) {
my $string;
$string ~= p.($_) for $.branches;
return $string;
}
Perl::Rx::Modifier::generate_match (p, $limit) {
my $string;
$string ~= p.($_) for $.atoms;
# is $self ($.) still the topic here? or is the last
# member of $.atoms?
return $self.mod.transform($string);
}
Perl::Rx::Modifier::repeat (p, $limit) {
$string := join '', map { join '', $_ }
permutations (split //, p.($.atom)) xx ($.max // $limit);
return $string;
}
So, given a call like:
generate (/(A*B*(C*|Z+))/, 4);
The C$string variable in the 2nd line of Cgenerate would become:
And the :any switch takes care of the rest. (-:
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Edward Peschko wrote: What I think you're looking for is the fact that they're not regexes any more. They are rexen, but in horrifying-secret-reality, what has happened is that Larry's decided to move Fortran out of core, and replace it with yacc. just an aside, and a bit off-topic, but has anybody considered hijacking the regular expression engine in perl6 and turning it into its opposite, namely making *productions* of strings/sounds/whatever that could possibly match the regular expression? ie: a* producing '' a aa aaa etc. Correct me if I am wrong, but isn't this the :any switch of apoc 5? http://www.perl.com/pub/a/2002/06/26/synopsis5.html Joseph F. Ryan [EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
Austin Hastings wrote:
Another example. Let's say there's a class that deals with colors.
It has an operator that returns true if two colors look about the
same. Given a list of color objects, is there a regexp to find a
rainbow? Even if the color class doesn't support stringification?
Yes.
grammar Rainbow;
rule color {...}; # this one's on you.
rule same_color($color is Colorific)
{
color ::: { fail unless $1.looks_like($color); }
}
rule band($color is Colorific)
{
same_color($color)+
}
rule Rainbow
{
band(new Color(red))
band(new Color(orange))
band(new Color(yellow))
band(new Color(green))
band(new Color(blue))
band(new Color(indigo))
band(new Color(violet))
pot_o_gold?
}
I'm a bit confused by the Csame_color rule; specifically, this line:
$1.looks_like($color)
Shouldn't this be: C $color.looks_like($1) ? Otherwise, it
suggests that you're redefining the match object class, which
probably isn't a good idea.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Embedded foreign syntax (was Re: P6ML?)
Miko O'Sullivan wrote: Andy Wardley wrote: For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; We already have the ability to embed foreign languages (XML, HTML, whatever) using here docs: $myml = MyXmlParser-new( '(MARKUP)'); thingy blahblah blah/blah /thingy (MARKUP) Well, P6C has the new ability of inlining code from another parrot- based language. All someone needs to do is write an XML processor that spits out pasm/imcc, and then: use inline 'XML', q[ thingy blahblah blah/blah /thingy processing XSLT stuff or whatever here / ]; or even: use inline 'XML', XML_IS_FUN; thingy blahblah blah/blah /thingy processing XSLT stuff or whatever here / XML_IS_FUN See how easy that is? Who needs a stinking P6ML now? (-: Joseph F. Ryan [EMAIL PROTECTED] -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Re: Embedded foreign syntax (was Re: P6ML?)
Miko O'Sullivan wrote: Andy Wardley wrote: For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; We already have the ability to embed foreign languages (XML, HTML, whatever) using here docs: $myml = MyXmlParser-new( '(MARKUP)'); thingy blahblah blah/blah /thingy (MARKUP) As a side note, P6C now has the ability to inline code of a different language, so something like this will work: use inline 'XML', q[ thingy blahblah blah/blah /thingy ... XSLT PROCESSING STUFF ]; Provided, of course, that there is an parrot/imcc targetted XML processor. Who needs a P6ML now? (-: Joseph F. Ryan [EMAIL PROTECTED] -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Re: Embedded foreign syntax (was Re: P6ML?)
Joseph F. Ryan wrote: Miko O'Sullivan wrote: Andy Wardley wrote: For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; We already have the ability to embed foreign languages (XML, HTML, whatever) using here docs: $myml = MyXmlParser-new( '(MARKUP)'); thingy blahblah blah/blah /thingy (MARKUP) As a side note, P6C now has the ability to inline code of a different language, so something like this will work: use inline 'XML', q[ thingy blahblah blah/blah /thingy ... XSLT PROCESSING STUFF ]; Provided, of course, that there is an parrot/imcc targetted XML processor. Who needs a P6ML now? (-: Joseph F. Ryan [EMAIL PROTECTED] Woops; my mail client crashed when I sent this the first time; I had thought it hadn't sent, so I re-wrote it and sent it again. Sorry for the double post! Joseph F. Ryan [EMAIL PROTECTED] -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote: -- On Wed, 12 Feb 2003 18:29:29 Joseph F. Ryan wrote: As near as I can tell, the only problem with the nice flow of: A Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray is a variable that holds a list. is the Rvalue-assign list, which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); I don't see a problem here. The list on the right is still just value, unmodifiable. It is a list of rvalues. When you use a variable on the right hand side it is a rvalue. Similarly, a list of variables doesn't flatten to it's values - it is the list itself that it is immutable. It's individual members still retain asignibility in rvalue context. -Erik Ah, I'm a compete fool. I meant Lvalue, not Rvalue. If you could do a mental s:e/Rvalue/Lvalue on that last message, I would appreciate it. Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray is a variable that holds a list.
is the Rvalue-assign list, which takes the form of:
($r1, $r2, $r3) = (1, 2, 3);
I don't see a problem here. The list on the right is still just
value, unmodifiable. It is a list of rvalues. When you use a variable
on the right hand side it is a rvalue. Similarly, a list of variables
doesn't flatten to it's values - it is the list itself that it is
immutable. It's individual members still retain asignibility in
rvalue context.
Okay, pardon me for replying to myself, but that was _really_ badly
worded. An example
foreach ($foo, $bar, $baz) {
.zoomdingle;
}
The objects in the list retain full status qua objects even though
they are in a list, which is why we can call methods on them.
Similarly, the fact that a scalar variable acts as a value on the
lefthand side and a rvalue on the right hand side is retained even
though it is in a list. It is the list itself which is immutable.
Python programmers will grasp this real fast - it's just a tuple.
You're completely right. See my last message :-)
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs. Lists
Mark J. Reed wrote:
On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote:
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Except that the Perl5 equivalent, ugly as the syntax may be, works fine:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
I don't see any reason to change this behavior for Perl6.
Apologies; when I meant same as above, I meant same answer that I gave
for:
[1..10].map {...
I think this *should* work, although I'm not sure *how*.
Meaning that I think this should be possible, but I'm not
sure if that syntax is correct, because it would mean that
the arrayrefs would need to be their own class to allow
a method to be called on it, and this class would need to be
a wrapper around the real array class.
Re-reading my original message, I can see the reason for
the confusion. In fact, I don't even know what I was thinking
when I thought people would make that connection that I wanted,
as it doesn't even make sense to me now :-)
Hmm... now that I think more about it, making array references
their own class and wrapping it around the real array
class would make it pretty easy to cause all of the auto
dereferencing when necessary behaivor that is causing
so many problems, since auto-dereferencing wouldn't have to
happen, it would only seem that way.
Does this sound feasible?
Joseph F. Ryan
[EMAIL PROTECTED]
Arrays vs lists; A possible solution?
As near as I can tell, the only problem with the nice flow of: A Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray is a variable that holds a list. is the Rvalue-assign list, which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); Well, what if an Rvalue-assign list is simply decoupled from a normal data list. The confusion would end. The concepts themselves are separate, so why shouldn't the names be? data lists become The One True List Type, and Rvalue-assign lists become something like Rvalue sequences (or a catchier name). Peace would reign on earth, or at least p6-lang and p6-doc. (I hope I'm not missing something obvious here, at any rate :) Joseph F. Ryan ryan.311@osu
Re: Arrays vs. Lists
Michael Lazzaro wrote:
On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
Indeed, this supports the distinction, which I will reiterate:
- Arrays are variables.
- Lists are values.
My hesitation about the 'arrays are variables' part is that Damian
corrected me on a similar thing when I was writing about scalars. A
variable is more like a name of a container for a value, e.g.
there's three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
They're definately variables. The container is a PerlArray,
which is a distinctly different object compared to a
PerlUndef.
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
I'd say it is an array reference.
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous container
There should be a variable attached, but just no name
attached to the variable.
So I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
Maybe :-)
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
But is it OK for a list to be silently promoted to an array when used
as an array
But this would mean that an implicit anonymous array would need
to be created, which isn't always possible in the middle of a
statement. So, that would mean the compiler would need to be
smart enough to figure out when this will happen, and then
create the anonymous array beforehand, and then somehow
alias the list contents to the array. Thats a heck of a lot
of magic going on there.
So that all of the following would work, and not just 50% of them?
(1..10).map {...}
I think this should be an error. What object is the method
getting called on?
Is forcing the functional syntax on lists really that horrible?
[1..10].map {...
I think this *should* work, although I'm not sure *how*.
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs. Lists
Deborah Ariel Pickett wrote: While I like the glib Arrays are variables that hold lists explanation that worked so well in Perl5, I think that Perl6 is introducing some changes to this that make this less true. Like what? Well, like the builtin switch statement, which was what I was trying to show in my bad example below. What I meant was: In Perl5, pretty much anywhere you have a list, you can write an array variable instead, and get much the same behaviour: @a = (1, 2, 3); func(@a); func(1,2,3); The exceptions appear to be builtin operators like Cpush, functions that have Perl5-prototypes, and using lists/arrays as lvalues. But all of those are caught by the Perl5 parser, and treated specially. Everywhere else, naming an array automatically expands to a list containing the array's contents. It's pretty much a universal, and something which Perl programmers hold dear. In Perl6, where there seems to be even more of a blur between compile-time and runtime, Actually, I think they'll be more separated. In fact, the compiler will just be an extension to the runtime-engine. I don't think it's always going to be possible (i.e., easy) to know where naming an array or providing an actual list would produce the same effect. The switch statement was my example. Apocalypse 4 has a table (page 2 of the perl.com version) which bears this out. Lists have their own entries on this table, separate from arrays. So it's conceivable that a switch statement that switches on a list and a switch statement that switches on an array containing the same list produces different results. I see what you mean now; Cgiven topic-alizes what it is, well, given. This would cause it to work differently for variables and other. Perhaps this just adds the switch statement to the set of Perl constructs that require special compiler attention, like lvalues and builtin operators. I think you might be right; however, it would be nice if this wasn't the case, as then user-defined functions could act similarly. (kinda like how perl5-prototypes allow user-defined functions to act like perl5- bultins, without the yeehh of perl5-prototypes.) (This suggests to me that it won't be possible to implement the switch statement as a pure Perl6 function - as people were trying to do with Cif - without greater-than-usual assistance from the Perl6 compiler.) It also appears that we'll now be able to pass multiple arrays to functions without the taking-references shenanigans that you have to go through in Perl5. So there's another example where lists and arrays appear to be going their separate ways, with lists almost being their own data type, in a manner of speaking. I dare say that we'll have to wait till Apocalypse 6 for the full story here. (Just going off on a tangent: Is it true that an array slice such as @array[4..8] is syntactically equivalent to this list (@array[4], @array[5], @array[6], @array[7], @array[8]) ? Are array slices always lists in Perl6?) I think so, unless its possible to do crazy things like reference part of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5], \@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps that behaivor, then @array[4..8] is always a list. Would there be any truth in this distinction: - lists are ordered sets/bags/etc seen by the Perl parser - arrays are ordered sets/bags/etc seen by the Perl interpreter ? Where s/parser/compiler/, and s/interpretter/runtime engine/? I do believe that's accurate. What joy I'll have explaining that one to my students . . . Better you than me. :-) Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs. Lists
Deborah Ariel Pickett wrote:
I'm trying, and failing, to accurately and definitively answer the
question what's the difference between an array and a list in Perl6?
If someone can come up with a simple but accurate definition, it would
be helpful.
While I like the glib Arrays are variables that hold lists explanation
that worked so well in Perl5, I think that Perl6 is introducing some
changes to this that make this less true.
Like what?
For instance, the switch
statement has different rules for lists and arrays. So these don't
necessarily do exactly the same thing in Perl6:
# Please excuse syntax errors here, but you know what I mean
given (1,2,3)
{
when $x:
and
@a = (1, 2, 3);
given @a
{
when $x: ...
I don't understand the difference here. Could you elaborate?
Would there be any truth in this distinction:
- lists are ordered sets/bags/etc seen by the Perl parser
- arrays are ordered sets/bags/etc seen by the Perl interpreter
?
Where s/parser/compiler/, and s/interpretter/runtime engine/? I
do believe that's accurate.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Shortcut: ?=
Miko O'Sullivan wrote: SUMMARY C$var ?= $x : $y as a shortcut for C$var = $var ? $x : $y. DETAILS We have ||=, +=, -=, etc. These shortcuts (I'm sure there's some fancy linguistic term for them) save us a few keystrokes and clean up the code. So, concerning C? :, I find myself doing this type of thing a lot: $var = $var ? 1 : 0; How 'bout a shortcut for that, something like this: $var ?= 1 : 0; -miko Doesn't the perl6 //= operator already do what you suggest? Joseph F. Ryan [EMAIL PROTECTED]
Re: Ordering is not what distinguish array from associative tables
Stéphane Payrard wrote:
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
Yes, I would expect that. In my opinion there is no difference between
an array and a hash other than the underlying storage and the
type-management of the key. I'm increasingly of the opinion that a)
there should be no @ vs %, there should be no {} vs [], there should be
a keys, values, defined, delete, exists, push, pop, shift, unshift for
every container and foreach shouldn't give a damn.
I think that arrays and associative tables are very different entities
for two reasons:
-type of keys. array keys are integers
-cost of insertion and deletion operations: O(n) and
lower for associative table ( O(1) if you don't care for key ordering,
O(log(n)) if you care for ordering).
This is enough to warrant different syntaxes for arrays and hash.
I'm sure I'll get shot for saying this, but no it doesn't. PHP arrays
are simply associative arrays with a integer as the key value.
Of course, this doesn't mean I like the idea, but I just wanted to
point out that there are some languages that do it this way. However,
I hope that we are not going to be one of those.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays: Default Values
attriel wrote: So ... with the discussion of what if i really wanted to put an undef in there b/c it's not just that i haven't defined it but rather that it really isn't defined. I KNOW it's not defined, and i'm now explicitly saying it's undefined as opposed to before when i was implicitly suggesting that i didn't know what it was and used a default 'unknown' discussion ... What we really need is: @a[2] = undef but undef; or, possibly (more tongue-in-cheek-y) @a[2] = undef but seriously; so the ... property? would say you have a default, maybe, but i don't care. this is REALLY undef is that possible? aside from it being disturbing to write undef but undef :o --attriel (the first suggestion is serious, but the syntax is flawed; the second suggestion has better syntax but is tongue-in-cheek suggested ... ) What about: undef @a[2]; or possibly even (although I would argue that undef should remain a unary operator only): @a[2].undef(); Joseph F. Ryan [EMAIL PROTECTED]
Re: A proposal on if and else
Rafael Garcia-Suarez wrote: Brent Dax wrote in perl.perl6.language : Yes, I know this means that we have 'else if' instead of 'elsif', but it's only two more characters and it makes the grammar cleaner. The tokeniser could send two tokens else and if whenever it recognizes the keyword elsif -- so this isn't a problem. I think the point of having Cif as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Joseph F. Ryan [EMAIL PROTECTED]
Re: A proposal on if and else
Rafael Garcia-Suarez wrote: Joseph F. Ryan wrote in perl.perl6.language : I think the point of having Cif as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Simplify the compiler, yes; but (with my limited knowledge of Perl 6) I don't expect the tokenizer to be simple. And the hack I just proposed to the tokenizer is mostly stateless. If the final design stays the way it is now, there really won't be a lexer. Instead, a perl6 grammar parses the data, and builds up a huge match-object as it, well, matches. This match object is then munged into the optree. This means the grammar probably won't be anything resembling simple, since it has to act as both a lexer and a parser at the same time. However, that's not to say your hack couldn't work; in fact, it would be easy to implement during the match-object-munging phase. However, it still treats Cif as special syntax, which is the real issue at hand.. I question whether treating Cif as a function rather than as built-in syntax will make the parser any simpler if special block rules keep getting added to simply make it work. I'm in favor of keeping a few special blocks if it makes things easier to implement/design in the long run. Joseph F. Ryan [EMAIL PROTECTED]
Re: Civility, please.
Michael Lazzaro wrote:
Joseph F. Ryan wrote:
Perhaps in the grand scheme of things; however, anyone that is
redesigning a system should not be ignorant of how the old system
worked (even in the slightest degree), in order to know of what to
keep and what to throw away.
Oy. One more time. My objection is this: I said Cmap {...} @a and
friends are special compared to normal subroutine syntax, because there
isn't a comma after the {...}. It was then stated that Cmap itself is
not special, because the '' in the prototype allows the special case to
exist not only in map, but in anything else prototyped in the same
way. True.
My error, therefore, was to not properly define what I meant by normal
subroutine syntax, because I thought it was clear from the context what
normal meant... it meant compared to having a comma there. But it
wasn't clear.
This, however, is a Computer Science discussion. Computer Science is
one of those fields populated almost exclusively by people who consider
any statement devoid of at least three explanatory footnotes to be an
act of aggression, and who measure their own genius in large part by
their practiced lack of ability to infer meaning from any string of
words not emanating from their own head.
Thus, a possible response like I don't agree with your use of the word
'special' to describe this case, because these other cases are
identically 'special' too is transformed without any apparent irony to
since you did not use the precise wording I myself would have used in
your two-sentence explanation, that provides conclusive evidence that
you therefore don't know Perl5.
Yes, in hindsight, I should have responded I know *why* the specialness
exists, you thundering blowhards, I'm just noting that it *is* special
compared to how *most* subroutine argument lists look. Quit assuming
that every last syntactic nuance will tunnel untouched to Perl6 by the
grace of your own unassailable wisdom, and tell me *why* this particular
one should. [1] Those sorts of communications can sometimes cross the
semantic barrier.
Yes, perhaps we should all have our mail proofread by a peer jury before
we post, thus attempting universal semantic clarity... or perhaps we can
all just practice those human social skills that some of us might have
seen on television or in the movies, and Get Over Ourselves. [2]
(Note that Damian was the *only* person who, at any point in the
discussion, was able to identify the notion that not having the comma
there was different from having the comma there, and was able to
respond with an argument more structured than because Perl5 does it.
_This_ is why his ideas get implemented. Duh.) [3]
Any programmer who doesn't know that they are ignorant are almost
certainly instead arrogant.
Ignorant of what? Surely we shouldn't assume that we're all ignorant
of Perl?
What I'm trying to avoid is the apparent need for programmers to degrade
every conversation into an I'm-smarter-than-you semantic duel. In the
entire history of the Perl6 process, there has been noone here to emerge
as God's Perfect Gift to Language Design -- I think the design has been
improved repeatedly by the collective thoughts of the group. But
nobody, individually, has a very good batting average, so I think nobody
is in a position to throw stones.
MikeL [4]
[1] OK, that's definitely not civil. Which is why I didn't originally
say it.
[2] Er, that's not great either, but probably in the range of acceptable.
[3] Note to self -- remove the 'Duh', and it will be fine.
[4] And yes, the irony of needing N paragraphs to try to convince
programmers of such a profoundly simple concept is not lost on me. Nor
is the fact that it will inevitably fail...
Sorry, I hope I didn't offend you. In that last remark I was in no way
fingering you; I was simply speaking broadly.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Civility, please. (was Re: L2R/R2L syntax)
Sam Vilain wrote: On Sat, 18 Jan 2003 15:10, you wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. In the very young field of programming, aren't we all ignorant amateurs? Perhaps in the grand scheme of things; however, anyone that is redesigning a system should not be ignorant of how the old system worked (even in the slightest degree), in order to know of what to keep and what to throw away. Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. Ignorant of what? Surely we shouldn't assume that we're all ignorant of Perl? Joseph F. Ryan [EMAIL PROTECTED]
Re: L2R/R2L syntax
Mark J. Reed wrote:
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
This is plainly untrue. See the perlsub documentation, which talks about
creating your own syntax with the prototype. You can do all this in
Perl 5, and it saddens me that some of the people redesigning Perl don't
know what Perl can do.
Well, if even some of the people redesigning the language are
ignorant of some of its capabilities, that is an argument for making
those capabilities easier to discover, and maybe even more intuitive
to use, in the new design.
I see it more as the people who are ignorant of the features of Perl5
should go RTFM (Research The Features that they are Making?)
The fact that a in a prototype obviates
the following comma is a pretty obscure detail; it's not the sort
of consistent behavior I'd want to build around going forward.
Why not? Its a syntax that everyone (or at least, most people)
seem to like.
But as I see it, the real problem being solved by the new syntax
is that grep and map can exist solely as methods on some class
in the inheritance tree of @arrays, no global functions required.
That is a Good Thing.
In your opinion. I'll still want to be able to write 1-liners and
short scripts. I'm sure perl6 will still be used for things other
than large applications. Is it such a sin to want the old syntax?
Even if the definition for grep lives in a method, why couldn't
there also exist a global function that looks like:
sub grep(code,@array) {
@array.grep(code);
}
Or even if this function does not exist, there's nothing stopping
the compiler from simply aliasing:
grep {} @array;
to:
@array.grep({});
Joseph F. Ryan
[EMAIL PROTECTED]
Re: my int( 1..31 ) $var ?
Luke Palmer wrote: From: Joe Gottman [EMAIL PROTECTED] Date: Fri, 3 Jan 2003 22:25:16 -0500 JG == Joe Gottman [EMAIL PROTECTED] writes: JG Speaking of which, is there a run-time test to check if a variable JG is of JG integral type? Something like JG print date if ($var is int) (1 = $var = 31); the old standby is: int( $var ) == $var I'm not sure if this works. my $var = 0; # Notice the quotation marks print is integer if (int($var) == $var); In the above case int($var) == $var returns true when I would want it to return false. Why? It returns true in perl5; 0 certainly is an integer value. print date if $var.isa(int); print date if isa $var: int; print date if $var ~~ int; Those should all work. IMO the first reads the best. That will also work for CInts, as CInt is a subclass of Cint (I think). These only determine if $var is of type int or Int. However: my $var = 0; # or my $var = 0; # or my int $var = 0; # or my num $var = 0; # all 4 cases should print is integer print is integer if int $var == $var; This should work as a more generic method to test Integer *value*, rather than type, which IMHO is more useful (and more commonly wanted). This message was sent using the Webmail System hosted by OARDC Computing Services -- http://webmail.oardc.ohio-state.edu:8080
Re: AW: nag Exegesis 2
Luke Palmer wrote:
In Perl 5,
my int ($one = 0, $two = 1, $three = 2);
is a fatal error. I could argue for this to change, as to support
better readability (and it would). It's obvious WIM, so why doesn't
it DWIM (disclaimer: cannot be used as an argument for arbitrary
features. Is not a slogan. I repeat, is not a slogan. :) ?
The problem is that this couldn't work given the current semantics of
the assignment operator. The return-value of an assignment is the
lhs of the assignment, so
my int ($one = 0, $two = 1, $three = 2);
ends up becoming:
my int (0,1,2);
Which, of course, is a fatal error (partly because it doesn't make any
sense). This is why stuff like:
if (defined ($child = fork)) {
}
Works as expected.
The point that I am trying to get at is: just because it is obvious
WIM to a human reader doesn't mean that it will be easy for a compiler
to figure out, especially when the rest of the language works a
different way. List assignment is much easier to read anyways.
Joseph F. Ryan
[EMAIL PROTECTED]
This message was sent using the Webmail System hosted by OARDC Computing Services --
http://webmail.oardc.ohio-state.edu:8080
Re: Usage of \[oxdb]
Luke Palmer wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Mon, 9 Dec 2002 23:43:44 +
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Disposition: inline
From: Nicholas Clark [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On Sun, Dec 08, 2002 at 03:41:22PM +1100, Damian Conway wrote:
Nicholas Clark wrote:
Well, I was wondering if my function returned CR, then
\c[$(call_a_func())] would mean that the CR gets run thought the
\c[...] conversion and a single byte (\r) is what ends up in the string.
I seriously doubt it. %-)
So what will perl6's parser do if it is presented with what appears to
be a $() interpolation sequence inside some other double quoting
construction?
1: Proceed silently (so treating \c[$(call_a_func())] as a request for
the character literally named '$(call_a_func())'), potentially returning
whatever warnings fall out of that second stage
2: Issue a nesting warning when it finds something that seems to be an
interpolative construction occurring within another construction, but
otherwise carry on
3: Treat it as a syntax error
I suspect that the answer is yes - ie all of the above, with a warning on
nesting interpolative constructions, which can be made fatal, and can be made
silent.
You must remember that the Perl 6 parser is one-pass now. An
interpolating string has a rule set of its own, whose simplified
version might look like this:
grammar interpolating_string {
rule string { string_thing* }
rule string_thing { \$\( Perl::expression \)
| \\c \[ .*? \]
| character }
rule character { \\ \\ | \\ | . }
}
A fuller version might look like this:
(Note that this is with only allowing [] for internal brackets and
without accounting for the balanced-brackets are ok rule (out of
curiousity, is that still allowed?))
grammar Interpolating_String {
rule string {
$delim := head
{ $delim = %matching{$delim} || $delim }
(body($delim)+)
$delim
}
rule head {
() | qq (special_delim) (
}
rule special_delim {
-[\w\s]
}
rule body(Str $delim) {
\\ backslashed_expr
| interpolated_value
| interpolated_variable
| -[ \\\$\@\%\$delim ]*
}
rule interpolated_variable {
Perl::Expression::variable
str_subscript*
!before [ \[\{\( ]
}
rule backslashed_expr {
\\Q !before \[
| before \\[qQ]\[
Perl::Literal::Non_Interpolating_String::body(']')
| c \[ string_set \]
| \: \[ string_set \]
| x \[ set Perl::Literal::Hex::number+ \]
| x Perl::Literal::Hex::number
| [UL] \[ Perl::Literal::Non_Interpolating_String::body(']')
| 0 Perl::Literal::number
| 0 \[ Perl::Literal::number \]
| [ule] .
| .
}
rule string_set {
[
!before [:\]]+ \]
Perl::Literal::Non_Interpolating_String::body(';')
]*
Perl::Literal::Non_Interpolating_String::body(']')
}
rule set($item) {
$item [ before ;$item | \] ]
}
rule str_subscript {
!before \s|\Q
Perl::Expression::subscript
}
rule interpolated_value {
Perl::Expression::Variable::sigil
\( Perl::Expression::comma \)
}
}
Re: Usage of \[oxdb]
Dan Sugalski wrote: At 5:11 PM -0700 12/9/02, Luke Palmer wrote: You must remember that the Perl 6 parser is one-pass now. It is? Are you sure? It should be; the raw parsed data might be treated with regular expressions in the parse-tree processing stage, but that shouldn't count as a second pass.
Re: Usage of \[oxdb]
Dan Sugalski wrote: At 10:16 PM -0500 12/9/02, Joseph F. Ryan wrote: Dan Sugalski wrote: At 5:11 PM -0700 12/9/02, Luke Palmer wrote: You must remember that the Perl 6 parser is one-pass now. It is? Are you sure? It should be; Doesn't mean it will be. And should is an awfully strong word... This is true; however, I don't see where anything would need more than 1 pass, except to reduce complexity in some places. After all, since the parser is to be constructed with regular expressions, then a second pass would only be another use of regular expressions, which means the second pass could have been included in the parser in the first place. Of course, the parser isn't close to finish yet; as such, its anyone's guess as to what the final product will be. :) Joseph F. Ryan [EMAIL PROTECTED]
Re: Stringification of references and objects.
Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members?
Stringification of references and objects.
A big issue that still remains with literals is the stringification of
objects and references. In an effort to get the behaviors hammered
down, here are a few ideas:
First off, references:
By default, references should not stringify to anything pretty, they
should stringifiy to something useful for debugging. Heck, even perl5
style should be fine. Not only is this handy, but also prevents
problems with circular referencing data structures, huge data
structures, etc. However, all built-in types should have a .repr()
method, which should provide primitive Data::Dumper-ish output
So:
$var = [1,2,3];
print $var;
print \n;
print $($var.repr);
Might print something like:
[REF_TO_ARRAY_AT: '0x1245AB']
[
'1',
'2',
'3'
]
Next, objects:
Objects should have an AS_STRING method inherited from UNIVERSAL
defined as follows:
method AS_STRING() {
return [CLASS_INSTANCE_OF: ' ~ $self.CLASS() ~ '];
}
The AS_STRING method is implicitly called when an object is
interpolated within a string. The AS_STRING method can be
overloaded within the class if the class's author wants nicer
(classier;) output.
so:
class Normal {}
class Special {
method AS_STRING() {
return qq['one','two',three']
}
}
my Normal $obj1;
my Special $obj2;
print $obj1;
print \n;
print $obj2;
Should print:
[CLASS_INSTANCE_OF: 'Normal']
'one','two',three'
Re: Stringification of references and objects.
Brent Dax wrote:
Joseph F. Ryan:
# By default, references should not stringify to anything
# pretty, they should stringifiy to something useful for
# debugging. Heck, even perl5 style should be fine. Not only
Why? Isn't the pretty form more generally useful?
I don't think so; I'd think it to be annoying to have type more code
in order to specify a more cocise form; if I need to dump a structure,
I'd prefer to do it manually.
# is this handy, but also prevents problems with circular
# referencing data structures, huge data structures, etc.
# However, all built-in types should have a .repr() method,
# which should provide primitive Data::Dumper-ish output
#
# So:
#
#$var = [1,2,3];
# print $var;
# print \n;
# print $($var.repr);
#
# Might print something like:
#
# [REF_TO_ARRAY_AT: '0x1245AB']
What's wrong with a Perl 5-esque format for the debugging version?
Array(0x1245AB)
Personally, I like this format. It's succinct, informative, and tells
you enough to do identity testing.
I like it too, but I thought everyone else hated it :)
# Next, objects:
#
# Objects should have an AS_STRING method inherited from
# UNIVERSAL defined as follows:
I'd prefer if we drop the capitals. str() ought to work fine, IMHO.
# method AS_STRING() {
# return [CLASS_INSTANCE_OF: ' ~ $self.CLASS() ~ '];
# }
Once again, what's wrong with:
method str() {
#Unnamed invocant means you need $_, right?
return $_.class() ~ ($_.id());
}
(where id() returns a uniquely identifying integer, usually the
address).
Objects aren't references anymore, are they? So I don't think it is
apporpriate for an object to stringify with its id.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: p6d gatewayed by nntp.perl.org?
Simon Cozens wrote: [EMAIL PROTECTED] (Tim Conrow) writes: I'm not seeing it. My problem, or is it not being mirrored yet? I'm reading it via NNTP. Interestingly, p6d doesn't seem to be listed on lists.perl.org
Re: TERN-discuss mailing list finally available
david wrote: The brazen heresy continues... http://mail.nongnu.org/mailman/listinfo/TERN-discuss Are these people serious? What on earth is the point?
Re: perl6 operator precedence table
Damian Conway wrote: Adam D. Lopresto wrote: Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. I would hope/expect that that's what the subroutine form of Cs would do. That is, it takes a string, a pattern, and a replacement string, and returns a new string with substitution performed (without affecting the original string): print 'He said $( s($statement,/\.$/,) ), but we didn't believe him.'; That seems a bit obfuscated; is there any chance the subroutine form could be called Csubst or Csubstitute?
