Re: Syntax of using Perl5 modules?

2005-05-25 Thread Darren Duncan

At 12:06 PM +0800 5/25/05, Autrijus Tang wrote:

So, this now works in Pugs with (with a env PUGS_EMBED=perl5 build):
use Digest--perl5;
my $cxt = Digest.SHA1;
$cxt.add('Pugs!');
# This prints: 66db83c4c3953949a30563141f08a848c4202f7f
say $cxt.hexdigest;
This includes the Digest.pm from Perl 5.  DBI.pm, CGI.pm etc will
also work.
Now my question is, is my choice of using the perl5 namespace indicator a
sane way to handle this?  Is it okay for Perl 6 to fallback to using Perl 5
automatically?  Or should I use something else than use entirely?
Thanks,
/Autrijus/


I would say that one should always have to specify the Perl 5 
namespace in some way, so that there are no surprises as to whether 
something you invoke is implemented in Perl 6 or Perl 5, and so that 
it is possible to be actively using a Perl 5 and Perl 6 module with 
the same short name at the same time.


Do not fallback to it automatically.

Rather, if someone wanted to not fill their Perl 6 code with 
--perl5, they should use the Perl 6 feature that lets you create 
lexical aliases to things; they can explicitly declare a Perl 6 name 
for what they want to use, which just so happens to be an alias for 
the Perl 5 implementation.


I won't suggest exact syntax here, though yours looks fine for now.

Separately, since this together with the earlier 'inline' feature for 
Perl 5 sort of completes a circle of Pugs-Perl5-Pugs or 
Perl5-Pugs-Perl5, I see a further improvement that could possibly 
be made, if it isn't already.


That is, when you have three-somes like that, let the two endmost 
Pugs, or endmost Perl5, be the exact same interpreter in memory.  So 
that, eg, if you set a global var in the caller-most Perl5, it will 
be visible in the called-most Perl5, or vice-versa.


On the other hand, I don't know whether or not that would be better 
in practice than keeping separate interpreters for calling and called.


-- Darren Duncan


Re: (1,(2,3),4)[2]

2005-05-25 Thread TSa (Thomas Sandlaß)

Juerd wrote:

An array in scalar context evaluates to a reference to itself.

A hash in scalar context evaluates to a reference to itself.

An array in list context evaluates to a list of its elements.

A hash in list context evaluates to a list of its elements (as pairs).

Array context is a scalar context.


I have understand what you mean and how you---and other p6l'er---
derive [EMAIL PROTECTED] == 1 from @a = [1,2,3]. But allow me to regard this
as slightly inconsistent, asymmetric or some such.

Isn't hash context missing in the list above? How does

%a = ( a = 1, b = 2, c = 3 )  # @a = (1,2,3)

compare with

%b = { a = 1, b = 2, c = 3 }  # @b = [1,2,3]

Does that mean

3 == +%a == +%b
  == +{ a = 1, b = 2, c = c }
  == +( a = 1, b = 2, c = c )

holds and the access of the hash works as expected:

%aa == 1 == %ba  # and @a[0] == 1, but @b[0][0] == 1

What would actually be the equivalent syntax to @b?
Is it %ba or %%ba or even (*%b)a?
It will hardly be %b{undef}a, though.
--
TSa (Thomas Sandlaß)



Re: (1,(2,3),4)[2]

2005-05-25 Thread Juerd
TSa (Thomas Sandlaß) skribis 2005-05-25 10:47 (+0200):
 I have understand what you mean and how you---and other p6l'er---
 derive [EMAIL PROTECTED] == 1 from @a = [1,2,3]. But allow me to regard this
 as slightly inconsistent, asymmetric or some such.

If you STILL don't understand that it has nothing to do with
inconsistency or asymmetry, then please allow me to at this point give
up and stop trying to explain.

() do not construct lists, inside () is an expression, () does not
provide context. [] constructs arrays, inside [] is an expression that
is a list, [] does provide list context.

() and [] are as alike as [] and {} or  and (), or ** and ++.

Your expectation, not the language, is wrong.

 Isn't hash context missing in the list above? How does
 %a = ( a = 1, b = 2, c = 3 )  # @a = (1,2,3)

HASH = THREE PAIRS

 compare with
 %b = { a = 1, b = 2, c = 3 }  # @b = [1,2,3]

HASH = ONE SCALAR

That probably does roughly the same as:

%b;
%b{ { a = 1, b = 2, c = 3 } } = undef;

Hopefully with a warning complaining about the odd number of elements in
the list.

 3 == +%a == +%b

No.

 %aa == 1 == %ba

No, there is no %b{'a'}, only a $b{ $a_certain_hashref }.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: Perl6 and support for Refactoring IDE's

2005-05-25 Thread Piers Cawley
Luke Palmer [EMAIL PROTECTED] writes:

 On 5/6/05, J Matisse Enzer [EMAIL PROTECTED] wrote:
 I've become scared that if Perl is to continue to be viable for large,
 complex, multi-developer projects that the tools need to serious
 catch-up with what is available for Java, for example. Things like:
 
- Refactoring Support (see http://www.refactoring.com/)
- CVS and/or Subversion integration
- Support for integrating regression tests and auto-building
- Automated syntax and dependency checking
 
 I've been using Eclipse, with the EPIC plugin
 (http://e-p-i-c.sourceforge.net/) and so far I like it. It uses
 Devel::Refactor to support extract subroutine, but a lot more is
 needed to match what you can do with Java these days.
 
 What are others' thoughts on this?

 I think you're absolutely right.  Perl should have an IDE with
 Eclipse-like context-sensitivity and refactoring support.  However,
 it's hardly in Perl's philosophy or interest to bless one.

 One thing is for sure.  Perl 6 is providing enough introspection and
 parsing capabilities to make it possible to write a context-sensitive
 IDE, unlike Perl 5 (well, Perl 5 made it *possible*, I suppose, but
 Perl 6 will make it obvious).  Perl 6 is exposing its whole grammar at
 the language level, so you can say give me a syntax tree for this
 chunk of code and it will.  Even if there are modules that change the
 syntax with macros (though your editor might have trouble
 understanding what the macros mean).

One of the 'mental apps' that's been pushing some of the things I've been
asking for in Perl 6's introspection system is a combined
refactoring/debugging/editing environment for the language. One of the
annoyances of the 'only perl can parse Perl' thing is not so much the truth of
the statement, but that perl 5 doesn't allow you to ask about the parsed code
in ways that would be useful for an IDE. Perl 6 promises to change that -- it
should be possible to either write a fantastic Perl 6 IDE in perl itself, or to
write a codegrokker object that can be used by some pre existing IDE. 

 In other words, Perl 6 is open to the possibility of such an IDE, and
 is going to provide the machinery necessary to build a really good
 one, but I doubt it will become a development milestone.

What about the debugger?


Re: Perl6 and support for Refactoring IDE's

2005-05-25 Thread Deborah Pickett

Piers Cawley wrote:

One of the 'mental apps' that's been pushing some of the things I've been
asking for in Perl 6's introspection system is a combined
refactoring/debugging/editing environment for the language. One of the
annoyances of the 'only perl can parse Perl' thing is not so much the truth of
the statement, but that perl 5 doesn't allow you to ask about the parsed code
in ways that would be useful for an IDE. Perl 6 promises to change that -- it
should be possible to either write a fantastic Perl 6 IDE in perl itself, or to
write a codegrokker object that can be used by some pre existing IDE. 


While I agree with this wholeheartedly, I am afraid to say that I 
haven't seen a lot of evidence that introspection has been given much 
thought in the Perl 6 design process.  There was a flurry at one point 
about the execution of BEGIN blocks, but then silence again.


One thing is for sure: although B::Deparse is a wonder to behold, it 
isn't something that we should try to be repeating.  It doesn't give you 
control over how much of the code to parse, whether you trust the code 
your're parsing, or in the case of BEGIN blocks even whether you have 
the choice to execute them or not.  It doesn't give you the ability to 
load parts of another program into the running program's namespace, and 
it doesn't give you enough hooks and callbacks to be able to transform 
syntax trees.  At least, if it does do any of those things, then I 
haven't seen ways of doing them in the documentation for B and O.


I'm afraid that because of the dynamic parse/execute nature of Perl, it 
may be a theoretically intractable problem to parse Perl safely.  Don't 
run the BEGIN blocks and you change the way future source is parsed 
compared with true runtime.  Do run them and you risk someone inserting 
dangerous code into one.  It isn't good if turning on syntax 
highlighting on some found-in-the-wild code in your Perl-aware editor 
could wipe your hard disk.


Oh, and I don't have a lot of faith in the Safe module, either, which is 
a marvel of kludge engineering and broken, both at the same time. 
What's the plan for that module's moral equivalent in Perl 6?


I'd love it if someone could set my mind at ease here.  I have to 
process syntax trees of Perl code quite often in my line of work and I'd 
love something less finicky than a Safe/B::* combination.


Re: (1,(2,3),4)[2]

2005-05-25 Thread TSa (Thomas Sandlaß)

Juerd wrote:

If you STILL don't understand that it has nothing to do with
inconsistency or asymmetry, then please allow me to at this point give
up and stop trying to explain.


I would bewail that, because your explainations are very clear.
And it might appear different but I'm just trying to understand
things. Obviously I'm quite bad at it. So keep on helping a pity
old man.



() and [] are as alike as [] and {} or  and (), or ** and ++.


Ohh, that is interessting. I look at them beeing all basically
the same thing: syntax draped around operations that are lexically 
dispatched according to the types of the values involved. In other

words my primary interest is in the type system of Perl6 in particular
and all languages running on Parrot in general.



Your expectation, not the language, is wrong.


I have no expectations, and I'm not judging right or wrong.
But passive observation isn't enough either. So I'm asking
questions as well. I hope this is usefull to this list or
at least not considered as pestering.



%a = ( a = 1, b = 2, c = 3 )  # @a = (1,2,3)


HASH = THREE PAIRS


I look at it as infix:{'='}:( Hash, List of Pair : -- Ref of Hash )
and then try to understand how it behaves. BTW, I'm neither sure
of the type of the second invocant parameter nor of the return type.
Even the position of the : is contestable.



%b = { a = 1, b = 2, c = 3 }  # @b = [1,2,3]



HASH = ONE SCALAR


infix:{'='}:( Hash, Scalar : -- Ref of Hash )


That probably does roughly the same as:

%b;
%b{ { a = 1, b = 2, c = 3 } } = undef;


Here I ask myself: is infix:{'='} dispatching to postfix:{ }?
What then ultimately defines hashiness: the type, the indexing
operator or the sigil? The other two are then derived concepts.

And +[1,2,3] seems to mean prefix:+:(Ref of Array: -- Num)
while +(1,2,3) is prefix:+:(List: -- Num). More interesting
are the infix:, inside. Is that infix:,:(:*Num -- Eager of Num)?

BTW, another mystery to me is which operators are pure code types,
which ones are macro assisted---and to what extent---and which are
pure macros aka syntactic sugar/necessity without a specific
implementation backend.

So, to summarize we could interpret our points of view as
syntax-down and type-up if the upward direction is from
implementation to type to syntax.
--
TSa (Thomas Sandlaß)



Re: (1,(2,3),4)[2]

2005-05-25 Thread Juerd
TSa (Thomas Sandlaß) skribis 2005-05-25 13:53 (+0200):
 %a = ( a = 1, b = 2, c = 3 )  # @a = (1,2,3)
 HASH = THREE PAIRS
 I look at it as infix:{'='}:( Hash, List of Pair : -- Ref of Hash )
 and then try to understand how it behaves. BTW, I'm neither sure
 of the type of the second invocant parameter nor of the return type.
 Even the position of the : is contestable.

If assigning a ref to a hash uses the hashref's elements, then the same
is to be expected for an array. Because this behaviour is unwanted for
arrays (because you then can't assign a single arrayref anymore without
doubling the square brackets, communicating an entirely wrong thing),
hashes have to concede as well, even though %a = $href may not make
sense.

 And +[1,2,3] seems to mean prefix:+:(Ref of Array: -- Num)
 while +(1,2,3) is prefix:+:(List: -- Num). More interesting

The + forces scalar Num context. So it can probably be written as
something resembling

sub prefix:+ (Num $foo) { $foo }

Prefix + doesn't take a list. If you use comma in scalar context, an
array reference is created. This makes +[] and +() practically equal,
but that doesn't mean [] and () are always exchangeable, or even that
they have anything to do with eachother. In +[], the [] make the
arrayref, while in +(), the comma does that. If you have +() without
comma, you don't have an arrayref, because () only groups.

 are the infix:, inside

I recall having read something about , being listfix, not infix. The
same would be true for Y and | and  and ^.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: Virtual methods

2005-05-25 Thread Piers Cawley
Aaron Sherman [EMAIL PROTECTED] writes:

 On Wed, 2005-05-18 at 10:51, Luke Palmer wrote:

 Except that mixins like this always treat things as virtual. 
 Whenever you mixin a role at runtime, Perl creates an empty, anonymous
 subclass of the current class and mixes the role in that class.  Since
 roles beat superclasses, you'll always override your own methods.

 Ok, good point (I've even pointed that out to others before, and I
 missed it)...

 I know that's the way it works, but now it's really bothering me.

 There are many gotchas that fall out of that. For example, you might
 have a special role that overrides .print to handle structured data, so
 your code says:

   my Foo $obj;
   given $obj {
   when StructuredPrintRole {
   # Someone's already taken care of it, possibly
   # adding a more specialized role, so leave it
   # alone.
   }
   default {
   # Add in a boring default handler
   $obj does StructuredPrintRole
   }
   }
   $obj.print($structured_data);

 Woefully, you lose is Foo happens to be DECLARED with
 StructuredPrintRole, and it overrode print. But, if it just inherited a
 print(), then it works. In other words, this code will mysteriously fail
 the second someone innocently adds a print method to Foo!

 Action at a distance... my head hurts.

Aaron, you do realise that that's quite obscene code don't you? I mean, you're
doing a case statement based on the type of its topic, and to compound the
evils, you're changing how your topic's print method works *everywhere* simply
to get your 'special' print behaviour. If you must do something like this (and
call it print), then write it as a multimethod or something.



Re: (1,(2,3),4)[2]

2005-05-25 Thread TSa (Thomas Sandlaß)

Juerd wrote:

If assigning a ref to a hash uses the hashref's elements, then the same
is to be expected for an array.


Same feeling here. But I would let the array concede.



Because this behaviour is unwanted for
arrays (because you then can't assign a single arrayref anymore without
doubling the square brackets, communicating an entirely wrong thing),


You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.



hashes have to concede as well, even though %a = $href may not make
sense.


I would treat it just the same as a literal hashref build with
{ = } because this should be what the dispatch system sees anyway.
E.g.

%h;
sub assign { my $href = { a = 1, b = 2}; %h = $href }
assign;

should be the same as

%h = { a = 1, b = 2 };



I recall having read something about , being listfix, not infix. The
same would be true for Y and | and  and ^.


I can't find that in the archives. But it is a nice abbreviation for
infix:, ( ... ) is assoc(list). Could/should the same be done
as chainfix, leftfix and rightfix? Or asterfix, idfix, truebafix, ... :))
This last joke might work for Germans only.
--
TSa (Thomas Sandlaß)



Re: comprehensive list of perl6 rule tokens

2005-05-25 Thread Mark A. Biggar

Jonathan Scott Duff wrote:

On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:

I wish !prop X was allowed.  I don't see why !... has to be confined 
to zero-width assertions.



I don't either actually. One thing that occurred to me while responding
to your original email was that !foo might have slightly wrong
huffmanization.  Is zero-width the common case?  If not, we could use
character doubling for emphasis:  !foo consumes, while !!foo is
zero-width.  


But that's just a random rambling on my part. I trust @Larry has put
wee more thought into it than I.  :-)


But what would a consuming !... mean?  As it can have no internal
backtracking points (it only has them if it fails), it would match (and
consume) the whole rest of the string, then if there were any more to
the pattern, would immediately backtrack back out left of itself.  Thus
it would be semantically identical to the zero-width version.  So 
zero-width is really the only possibility for !


Now prop X is a character class just like +digit and so
under the new character class syntax, would probably be written
+prop X or if the white space is a problem, then maybe +prop:X
(or +prop(X) as Larry gets the colon :-), but that is a pretty
adverbial case so ':' maybe okay) with the complemented case being
-prop:X.  Actually the 'prop' may be unnecessary at all, as we know
we're in the character class sub-language because we saw the '+', '-'
or '[', so we could just define the various Unicode character property
codes (I.e., Lu, Ll, Zs, etc) as pre-defined character class names just
like 'digit' or 'letter'.

BTW, as a matter of terminology, -digit should probably be called the
complement of +digit instead of the negation so as not to confuse it 
with the !... negative zero-width assertion case.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]


Re: Syntax of using Perl5 modules?

2005-05-25 Thread Terrence Brannon
Autrijus Tang [EMAIL PROTECTED] writes:

 So, this now works in Pugs with (with a env PUGS_EMBED=perl5 build):

 use Digest--perl5;

 my $cxt = Digest.SHA1;
 $cxt.add('Pugs!');

 # This prints: 66db83c4c3953949a30563141f08a848c4202f7f
 say $cxt.hexdigest;

 This includes the Digest.pm from Perl 5.  DBI.pm, CGI.pm etc will
 also work.

 Now my question is, is my choice of using the perl5 namespace indicator a 
 sane way to handle this? 

I was getting used to : as an adverbial and adjective modifier. So I
would think the above would be:

use Digest:perl5

but that would be confusing given that two colons separate parts of a
package namespace.

-- 
Carter's Compass: I know I'm on the right track when,
   by deleting something, I'm adding functionality.



Re: (1,(2,3),4)[2]

2005-05-25 Thread Mark Reed
[1,2,3] is not an array or a list.  It is a reference to an anonymous array.
It is not 3 values; it¹s 1 value, which happens to point to a list of size
3.  If you assign that to an array via something like @a = [1,2,3], I would
expect at least a warning and possibly a compile-time error.

 If it does work, it probably gets translated into @a = ([1,2,3]), which
creates an array of size 1 whose first (and only) element is a reference to
an array of size 3.  That would give this result:

[EMAIL PROTECTED] == 1;

@a[0] == [1,2,3]; 
@a[1] == undef; 
@a[0][0] == 1;
@a[0][1] == 2; 
@a[0][2] == 3;

I¹m not sure about +(@a[0]), but I¹m guessing it would == 3.





On 2005-05-25 04:47, TSa (Thomas Sandlaß) [EMAIL PROTECTED]
wrote:

 Juerd wrote: 
  An array in scalar context evaluates to a reference to itself.
  
  A hash in scalar context evaluates to a reference to itself.
  
  An array in list context evaluates to a list of its elements.
  
  A hash in list context evaluates to a list of its elements (as pairs).
  
  Array context is a scalar context.
 
 I have understand what you mean and how you---and other p6l'er---
 derive [EMAIL PROTECTED] == 1 from @a = [1,2,3]. But allow me to regard this
 as slightly inconsistent, asymmetric or some such.
 
 Isn't hash context missing in the list above? How does
 
 %a = ( a = 1, b = 2, c = 3 )  # @a = (1,2,3)
 
 compare with 
 
 %b = { a = 1, b = 2, c = 3 }  # @b = [1,2,3]
 
 Does that mean 
 
 3 == +%a == +%b 
== +{ a = 1, b = 2, c = c }
== +( a = 1, b = 2, c = c )
 
 holds and the access of the hash works as expected:
 
 %aa == 1 == %ba  # and @a[0] == 1, but @b[0][0] == 1
 
 What would actually be the equivalent syntax to @b?
 Is it %ba or %%ba or even (*%b)a?
 It will hardly be %b{undef}a, though.




Re: comprehensive list of perl6 rule tokens

2005-05-25 Thread Jeff 'japhy' Pinyan

On May 25, Jonathan Scott Duff said:


On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:

I wish !prop X was allowed.  I don't see why !... has to be confined
to zero-width assertions.


I don't either actually. One thing that occurred to me while responding
to your original email was that !foo might have slightly wrong
huffmanization.  Is zero-width the common case?  If not, we could use
character doubling for emphasis:  !foo consumes, while !!foo is
zero-width.


But that's not even the point.  The ! in !after ... is not what makes 
!after ... a zero-width assertion, it's the 'after' that does that.  All 
the ! does is negate the boolean sense of the assertion, which seems like 
a useful thing to have.


Hrm, but I think I see the problem.  How does one define negation for an 
arbitrary assertion?  Is !foo saying if foo matches, fail?  Because 
then !prop X doesn't make mean the same as -prop X.  We don't want 
negation, we want complement.


I guess '!' is only well-defined for zero-width assertions.  When you want 
to say !foo, I guess !before foo or !after foo is the proper way 
to go.


--
Jeff japhy Pinyan %  How can we ever be the sold short or
RPI Acacia Brother #734 %  the cheated, we who for every service
http://japhy.perlmonk.org/  %  have long ago been overpaid?
http://www.perlmonks.org/   %-- Meister Eckhart


Re: Perl6 and support for Refactoring IDE's

2005-05-25 Thread Stevan Little

On May 25, 2005, at 5:39 AM, Piers Cawley wrote:
One of the 'mental apps' that's been pushing some of the things I've 
been

asking for in Perl 6's introspection system is a combined
refactoring/debugging/editing environment for the language.


Maybe I have been reading too much about Smalltalk meta-classes lately, 
but in doing some draft ideas of the Perl6 meta-model for Pugs, I 
realized that given a really solid class/metaclass introspection system 
and access to the interpreter level meta-meta-classes, it would be 
possible to easily write a class browser much like Smalltalk.


And to extend that to also be a refactoring browser would require the 
meta-meta-class system to be able to generate and emit code, which, if 
we properly model the meta-meta-classes should also be fairly simple as 
well.


And of course all this is even simpler if the interpreter is written in 
Perl6 (although the cyclical nature of that can be dizzying at times).


However adding debugging support to this is another matter all 
together, and it is only partially useful to the non-OO programmer.


Anyway, just wanted to add my 2 cents. Back to $work for me :)

Stevan



Re: comprehensive list of perl6 rule tokens

2005-05-25 Thread Jeff 'japhy' Pinyan

On May 25, Mark A. Biggar said:


Jonathan Scott Duff wrote:

On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:

I wish !prop X was allowed.  I don't see why !... has to be confined to 
zero-width assertions.


I don't either actually. One thing that occurred to me while responding
to your original email was that !foo might have slightly wrong
huffmanization.  Is zero-width the common case?  If not, we could use
character doubling for emphasis:  !foo consumes, while !!foo is
zero-width. 


Now prop X is a character class just like +digit and so
under the new character class syntax, would probably be written
+prop X or if the white space is a problem, then maybe +prop:X
(or +prop(X) as Larry gets the colon :-), but that is a pretty
adverbial case so ':' maybe okay) with the complemented case being
-prop:X.  Actually the 'prop' may be unnecessary at all, as we know
we're in the character class sub-language because we saw the '+', '-'
or '[', so we could just define the various Unicode character property
codes (I.e., Lu, Ll, Zs, etc) as pre-defined character class names just
like 'digit' or 'letter'.


Yeah, that was going to be my next step, except that the unknowing person 
might make a sub-rule of their own called, say, Zs, and then which would 
take precedence?  Perhaps prop:X is a good way of writing it.



BTW, as a matter of terminology, -digit should probably be called the
complement of +digit instead of the negation so as not to confuse it with 
the !... negative zero-width assertion case.


Yeah, I just wrote that in my recent reply to Scott.  I realized the 
nomenclature would be a point of confusion.


--
Jeff japhy Pinyan %  How can we ever be the sold short or
RPI Acacia Brother #734 %  the cheated, we who for every service
http://japhy.perlmonk.org/  %  have long ago been overpaid?
http://www.perlmonks.org/   %-- Meister Eckhart


Re: comprehensive list of perl6 rule tokens

2005-05-25 Thread Mark A. Biggar

Jeff 'japhy' Pinyan wrote:

On May 25, Mark A. Biggar said:


Jonathan Scott Duff wrote:


On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:

I wish !prop X was allowed.  I don't see why !... has to be 
confined to zero-width assertions.



I don't either actually. One thing that occurred to me while responding
to your original email was that !foo might have slightly wrong
huffmanization.  Is zero-width the common case?  If not, we could use
character doubling for emphasis:  !foo consumes, while !!foo is
zero-width. 



Now prop X is a character class just like +digit and so
under the new character class syntax, would probably be written
+prop X or if the white space is a problem, then maybe +prop:X
(or +prop(X) as Larry gets the colon :-), but that is a pretty
adverbial case so ':' maybe okay) with the complemented case being
-prop:X.  Actually the 'prop' may be unnecessary at all, as we know
we're in the character class sub-language because we saw the '+', '-'
or '[', so we could just define the various Unicode character property
codes (I.e., Lu, Ll, Zs, etc) as pre-defined character class names just
like 'digit' or 'letter'.



Yeah, that was going to be my next step, except that the unknowing 
person might make a sub-rule of their own called, say, Zs, and then 
which would take precedence?  Perhaps prop:X is a good way of writing it.


Well we have the same problem with someone redefining 'digit'.  But 
character classes are their own sub-language and we may need to
distinguish between Rule::digit and CharClass::digit in the syntax.  Of 
course we could hack it and say that a rule that consists of nothing but 
a single character class item is usable in other character classes by
its name, but that could lead to subtle bugs where someone modifies that 
special rule to add stuff to it and breaks all usage of it as a 
character class everywhere else.  Now a grammar is just a special kind 
of class that contains special kinds of methods called rules, maybe we 
need another special kind of method in a grammar that just define a 
named character class for later use?  In any case as usual with methods 
a user define character class should override a predefined one of the 
same name.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]


hash slice from array items

2005-05-25 Thread Carl Franks
Is [EMAIL PROTECTED] the correct way to get a hash slice using elements of an 
array?

(it's giving me a compilation error with pugs)

Cheers,
Carl


Re: hash slice from array items

2005-05-25 Thread Jonathan Scott Duff
On Wed, May 25, 2005 at 05:00:39PM +0100, Carl Franks wrote:
 Is [EMAIL PROTECTED] the correct way to get a hash slice using elements of
 an array?

Yep.

 (it's giving me a compilation error with pugs)

Works just fine for me.  What version of pugs are you using?  Perhaps
you need to upgrade.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]


Re: Syntax of using Perl5 modules?

2005-05-25 Thread Dave Whipp

Autrijus Tang wrote:

So, this now works in Pugs with (with a env PUGS_EMBED=perl5 build):

use Digest--perl5;

my $cxt = Digest.SHA1;
$cxt.add('Pugs!');

# This prints: 66db83c4c3953949a30563141f08a848c4202f7f
say $cxt.hexdigest;

This includes the Digest.pm from Perl 5.  DBI.pm, CGI.pm etc will
also work.

Now my question is, is my choice of using the perl5 namespace indicator a 
sane way to handle this?  Is it okay for Perl 6 to fallback to using Perl 5

automatically?  Or should I use something else than use entirely?



To my mind, the coupling seems wrong. If the use statement needs to 
state the language of the included module, then it would be difficult to 
later re-implement that module in p6.


My understanding is that there are clear rules (see S11) to distinguish 
p5 modules from p6: if the first keyword in the file is module or 
class, then it's p6; otherwise assume p5.


Your use of hyphens puts your perl5 indicator in the URI field 
(again, see S11), which is expected to refer to the author. perl5 
doesn't seem correct in this context. Even if you got rid of one of the 
hypthens (so that perl5 is the version), then it still feels wrong. 
Each version of a module should be free to choose its language, but that 
should be encapsulated within the module.


If you do want to impose the language from the useer, the I'd expect 
an adverbial syntax: use:p5 Digest;.



Dave.


Re: hash slice from array items

2005-05-25 Thread Carl Franks
On 5/25/05, Jonathan Scott Duff [EMAIL PROTECTED] wrote:
 Works just fine for me.  What version of pugs are you using?  Perhaps
 you need to upgrade.

Ok, I've just realised I had missed a '-' to '.' in my perl5 to perl6
conversion,
I was trying to do
[EMAIL PROTECTED] = $obj-list;

I wasn't sure if slicing from an array was implemented, as I couldn't
find any pugs tests for it.

Thanks for your help,
Carl


Re: Perl6 and support for Refactoring IDE's

2005-05-25 Thread Luke Palmer
On 5/25/05, Deborah Pickett [EMAIL PROTECTED] wrote:
 I'm afraid that because of the dynamic parse/execute nature of Perl, it
 may be a theoretically intractable problem to parse Perl safely. 

Yep.  It's not really possible for the parser to distinguish between:

BEGIN {
%main::{'foo'} = sub { print Hello! };
}

And:

BEGIN { for 1... {} }

Or even:

BEGIN { system 'rm -rf /' }

So, like most things in Perl, we can trust the author of the code not
to do such things, or we can not trust them and lose something while
we're at it (the choice is given to the IDE user, not to us
designers).  BEGIN blocks should never do INITialization, opening
filehandles, etc., precisely for this reason.  This becomes even more
important in Perl 6 where bytecode will be more prevelant.

You may certainly parse Perl syntax trees without executing BEGIN
blocks, but you have to bite the bullet if the BEGIN changes the
syntax in a way that you can no longer parse it if you don't execute
it.  And if you can't accept that, I see only one option:  give up
BEGIN blocks.  And we're not going to do that  (but you're free to
place that restriction on whoever's code you're parsing).

Luke


Re: Syntax of using Perl5 modules?

2005-05-25 Thread Rod Adams

Autrijus Tang wrote:


So, this now works in Pugs with (with a env PUGS_EMBED=perl5 build):

   use Digest--perl5;

   my $cxt = Digest.SHA1;
   $cxt.add('Pugs!');

   # This prints: 66db83c4c3953949a30563141f08a848c4202f7f
   say $cxt.hexdigest;

This includes the Digest.pm from Perl 5.  DBI.pm, CGI.pm etc will
also work.

Now my question is, is my choice of using the perl5 namespace indicator a 
sane way to handle this?  Is it okay for Perl 6 to fallback to using Perl 5

automatically?  Or should I use something else than use entirely?

Thanks,
/Autrijus/
 

Personally, I question the need for any flag saying it's perl5, and 
actually would prefer there be no such thing.


Consider S01: Migration is important. The perl interpreter will assume 
that it is being fed Perl 5 code unless the code starts with a class 
or module keyword, or you specifically tell it you're running Perl 6 
code in some other way,, which sounds to me like a yes to your 
fallback question.


On the migration front, when someone ports Digest.pm to Perl6, I get a 
free upgrade, assuming the module author was kind enough to up the 
version number.



Glancing at S11, I see where you're coming from. There is some logic in 
giving all the p5 modules an author of perl5, since they will not have 
one on their own. However, I think the calling syntax would have to be 
use Digest-(Any)-perl5; to force the usage of a perl5 version.


-- Rod Adams







Re: (1,(2,3),4)[2]

2005-05-25 Thread Rod Adams

TSa (Thomas Sandlaß) wrote:



You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.



@m[0,1] is an array slice of two elements, in this case two arrayrefs 
[1,2], and [3,4].

@m[0;1] is a multidim deref, referencing the 4.

@m[0..3] is valid, returning arrayref x 2, undef x 2.


Personally, I strongly believe that assigning an arrayref to an array 
should dereference the arrayref, and send that to the array. Otherwise, 
you get silly things like:


   $a = [1,2,3];
   @a = $a;
   say [EMAIL PROTECTED]; # 1

I would prefer to not have people be forced to write that as @a = $a[];.

I don't see the big problem with having to double up the brackets to 
assign an arrayref to an array element.


-- Rod Adams





Re: (1,(2,3),4)[2]

2005-05-25 Thread Austin Hastings

--- Rod Adams [EMAIL PROTECTED] wrote:
 TSa (Thomas Sandlaß) wrote:
 
 
  You mean @a = [[1,2,3]]? Which is quite what you need for multi
  dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
  of course @m[0][1] to pull out the 2. I'm not sure if this
 automatically
  makes the array multi-dimensional to the type system though. That
 is
  if @m[0,1] returns 2 as well or if it returns the list (1,2) or
 whatever.
  Is @m[0..3] valid and what does it return? And what's the type of
 that
  return value(s)? I can imagine many things ranging from a two
 element
  array of refs to two element arrays up to a flattened list of 4
 values.
 
 
 @m[0,1] is an array slice of two elements, in this case two arrayrefs
 
 [1,2], and [3,4].
 @m[0;1] is a multidim deref, referencing the 4.
 

Referencing the 2, I hope?


 -- Rod Adams

=Austin



Re: (1,(2,3),4)[2]

2005-05-25 Thread Rod Adams

Austin Hastings wrote:


--- Rod Adams [EMAIL PROTECTED] wrote:
 


TSa (Thomas Sandlaß) wrote:

   


You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this
 


automatically
   


makes the array multi-dimensional to the type system though. That
 


is
   


if @m[0,1] returns 2 as well or if it returns the list (1,2) or
 


whatever.
   


Is @m[0..3] valid and what does it return? And what's the type of
 


that
   


return value(s)? I can imagine many things ranging from a two
 


element
   


array of refs to two element arrays up to a flattened list of 4
 


values.
   


@m[0,1] is an array slice of two elements, in this case two arrayrefs

[1,2], and [3,4].
@m[0;1] is a multidim deref, referencing the 4.

   



Referencing the 2, I hope?
 


Doh!

Yes, the 2.

-- Rod Adams



This week's Perl 6 Summary

2005-05-25 Thread The Perl 6 Summarizer
The Perl 6 Summary for the week ending 2005-05-24
Note to self: It's generally not a good idea to go installing Tiger on
the day you return from holiday. It's especially not a good idea to fail
to check that it didn't completely and utterly radish your Postfix
configuration. And your emacs. And the backing store for your website.
And a bunch of other stuff. It's an especially bad idea not to have
backups of things like your aliases file...

Nor is it a good idea to get preoccupied with all these joys and
completely forget that you're supposed to be writ ting the Perl 6
summary.

Ahem.

I'm very, very sorry.

So, on with the show.

This week in perl6-compiler
  Inline::Pugs
Autrijus announced the availability of Inline::Pugs. If you've ever been
moved to mix up Perls 5 and 6 in one program, your prayers have been
answered. Just grab Pugs and Inline and you're set. Brian Ingerson made
things even more delightfully evil:

 #!perl
 use pugs;
 sub postfix:! { [*] 1..$_ }
 sub sum_factorial { [+] 0..$_! }
 no pugs;
 print sum_factorial(3); # 21

http://xrl.us/f73s

  Experimental Coroutine support
Autrijus announced that Pugs now has an experimental implementation of
coroutines. It's almost certainly not final, but it's good enough for
exploration and feedback purposes.

http://xrl.us/f73t

  Graphing tool for PerlGuts Illustrated
Yuval Kogman asked what tool was used to generate the 'pretty diagrams'
in PerlGuts Illustrated because he wanted to use it for diagrams in a
forthcoming PugsGuts Illustrated. Ingy said that Gisle had hand hacked
postscript based on initial diagrams drawn on graph paper. After some
discussion, the plan seems to be that Yuval will just draw diagrams,
scan them and bung them into the pugs repository. He'll rely on the
LazyWeb to turn them into beautiful scalable graphics.

http://www.lazyweb.org/

http://xrl.us/f73u

  Perl Development Server
Okay everyone, repeat after me: Juerd is a star!

You may ask me why, and I shall tell you.

Juerd and his cosponsors, Twistspace will making a Perl 6 development
server available over the internet to any Perl 6 developers who are
working on 'everything that improves Perl 6 development'. So, if you've
been put off working on Pugs by the hassles of getting Haskell working
on your machine, or if you have the kind of bandwidth that makes svn
updates a painful prospect, worry no longer. Just sign up for a
development account.

There was much rejoicing and suggesting of hostnames. Rather bizarrely,
there was also discussion of the etymology of 'sipuli' (Finnish for
'onion' in case you were wondering).

http://xrl.us/f73v

  Two releases in one day
Autrijus announced the release of Pugs 6.2.4. About half an hour later
he announced the release of Pugs 6.2.5.

http://xrl.us/f73w

  Undef issues
Adrian Taylor thought he'd found some issues with Perl 6's understanding
of undef. It turned out that he'd found some issues with his own
understanding of same.

http://xrl.us/f73x

  Method/attribute chaining
Alex Gutteridge found some weirdness with the chaining of autogenerated
attribute methods (I wonder if the same weirdness occurs with hand
rolled attribute methods). So far it remains unfixed, but given the
speed of Pugs development I doubt it'll stay that way for long.

http://xrl.us/f73y

Meanwhile, in perl6-internals
  Parrot as an extension language
Colin Adams continued to have problems using Parrot as an extension
language for Eiffel. It turns out that interfacing between statically
strongly typed languages and Parrot isn't easy.

http://xrl.us/f73z

  Fixing t/src/manifest.t
Dino Morelli reported problems with t/src/manifest.t and wondered how
some of the failures came about. Jürgen Bömmels thought that the problem
was an overzealous test -- the original version of which simply ensured
that version control and the MANIFEST were in sync. He provided his
suggested version of a less eager, but still svn compatible test.
Further discussion thrashed out the various difference use cases for
manifest checking.

http://xrl.us/f733

  More t/p6rules tests
Dino Morelli posted a bunch of tests for the Perl 6 rules. Well, he did
once he'd done battling his mailer's somewhat bizarre choice of MIME
type for his test files. Remember, if you're about to attach a .t file
to a message you send to the list, make sure your mailer doesn't declare
it to be an application/x-troff file -- text/plain is your fiend.

Patches were applied.

http://xrl.us/f734

  Stressing the hash
Leo asked for some stress and bench mark tests for hashes because he was
in the process of redoing src/hash.c. Bob Rogers provided one.


Reductions, junctions, hashslices, and cribbage scoring

2005-05-25 Thread Rob Kinyon
(This post references the discussion at
http://www.perlmonks.org/?node_id=458728, particularly dragonchild's
response at the bottom.)

For those who don't know, cribbage is a game where each player has
access to 4 cards, plus a community card. Various card combinations
score points. The one in question is when cards add up to 15. If you
have a group of cards that add up to 15, you receive 2 points. This is
for every group, so if you have a ten and 2 fives, you get 4 points.
Two tens and two fives is 8 points. Face cards are worth 10 and aces
are 1, for these purposes.

I proposed the following:

# Fifteens
$score += 2 * all( 15 == [EMAIL PROTECTED] any( 0 .. 4 ) } );

* Is this syntax legal?
* Does it do what I want it to do?
* Is there another way?

Thanks,
Rob


Re: (1,(2,3),4)[2]

2005-05-25 Thread Juerd
Mark Reed skribis 2005-05-25 10:49 (-0400):
 [1,2,3] is not an array or a list.  It is a reference to an anonymous array.
 It is not 3 values; it¹s 1 value, which happens to point to a list of size

Just for accuracy: it points to an array, which is still not a list in
our jargon.

 3.  If you assign that to an array via something like @a = [1,2,3], I would
 expect at least a warning and possibly a compile-time error.
 
  If it does work, it probably gets translated into @a = ([1,2,3]), which

That's not a translation. Parens, when not postfix, serve only one
purpose: group to defeat precedence. $foo and ($foo) are always the same
thing, regardless of the $foo.

 I¹m not sure about +(@a[0]), but I¹m guessing it would == 3.

Because parens only group, and [0] here has tighter precedence than the
prefix + anyway, +(@a[0]) and [EMAIL PROTECTED] are exactly the same. 

Because @a[0] is a reference to an array, that array is @{ @a[0] }. [EMAIL 
PROTECTED]
@a[0] } is also the same as [EMAIL PROTECTED] 

The numeric value of an array reference is the same as that of its
array.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: (1,(2,3),4)[2]

2005-05-25 Thread Mark Reed



On 2005-05-25 13:54, Juerd [EMAIL PROTECTED] wrote:

 3.  If you assign that to an array via something like @a = [1,2,3], I would
 expect at least a warning and possibly a compile-time error.
 
  If it does work, it probably gets translated into @a = ([1,2,3]), which
 
 That's not a translation. Parens, when not postfix, serve only one
 purpose: group to defeat precedence. $foo and ($foo) are always the same
 thing, regardless of the $foo.

So, you could then do this to make an array of size 3 in Perl6?

@a = 1,2,3;




Re: (1,(2,3),4)[2]

2005-05-25 Thread Juerd
Mark Reed skribis 2005-05-25 14:09 (-0400):
  That's not a translation. Parens, when not postfix, serve only one
  purpose: group to defeat precedence. $foo and ($foo) are always the same
  thing, regardless of the $foo.
 So, you could then do this to make an array of size 3 in Perl6?
 @a = 1,2,3;

You could, if you changed the precedence of , to be tighter than =.

However, by default, = has higher precedence than ,, so that you need
parens to override this decision: @a = (1,2,3);


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: (1,(2,3),4)[2]

2005-05-25 Thread Rod Adams

Juerd wrote:


Mark Reed skribis 2005-05-25 14:09 (-0400):
 


That's not a translation. Parens, when not postfix, serve only one
purpose: group to defeat precedence. $foo and ($foo) are always the same
thing, regardless of the $foo.
 


So, you could then do this to make an array of size 3 in Perl6?
   @a = 1,2,3;
   



You could, if you changed the precedence of , to be tighter than =.

However, by default, = has higher precedence than ,, so that you need
parens to override this decision: @a = (1,2,3);
 



Or use

   @a == 1,2,3;

-- Rod Adams



Re: (1,(2,3),4)[2]

2005-05-25 Thread wolverian
On Wed, May 25, 2005 at 01:38:27PM -0500, Rod Adams wrote:
 Or use
 
@a == 1,2,3;

I would just like to say that I like this idiom immensely.

my @foo == 1, 2, 3;

reads extremely well to me, especially since I've always disliked the
usage of '=' as an operator with side effects. (I'm strange like that.)

-- 
wolverian


signature.asc
Description: Digital signature


Re: (1,(2,3),4)[2]

2005-05-25 Thread Uri Guttman
 w == wolverian  [EMAIL PROTECTED] writes:

  w On Wed, May 25, 2005 at 01:38:27PM -0500, Rod Adams wrote:
   Or use
   
   @a == 1,2,3;

  w I would just like to say that I like this idiom immensely.

  w my @foo == 1, 2, 3;

  w reads extremely well to me, especially since I've always disliked the
  w usage of '=' as an operator with side effects. (I'm strange like that.)

please don't use == for simple assignments as it will confuse too many
newbies and auch. it (and its sister ==) are for pipelining ops like
map/grep and for forcing assignment to the slurpy array arg of funcs
(hey, i think i said that correctly! :). = is still fine for basic
assignment and everyone will understand it immediately.

the only advantage in the above case is the different prececences of =
and == which allows dropping of parens with the latter. i don't
consider that so important a win as to be used often. and they are at
equal huffman levels as the =() is matched in length by ==.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org


Re: (1,(2,3),4)[2]

2005-05-25 Thread wolverian
On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote:
 please don't use == for simple assignments as it will confuse too many
 newbies and auch. it (and its sister ==) are for pipelining ops like
 map/grep and for forcing assignment to the slurpy array arg of funcs
 (hey, i think i said that correctly! :). = is still fine for basic
 assignment and everyone will understand it immediately.

I thought the op is visually so obvious it wouldn't need any
explanation, even for newbies.

Too bad what I _think_ is often not what actually _is_.

-- 
wolverian


signature.asc
Description: Digital signature


Re: (1,(2,3),4)[2]

2005-05-25 Thread Uri Guttman
 w == wolverian  [EMAIL PROTECTED] writes:

  w On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote:
   please don't use == for simple assignments as it will confuse too many
   newbies and auch. it (and its sister ==) are for pipelining ops like
   map/grep and for forcing assignment to the slurpy array arg of funcs
   (hey, i think i said that correctly! :). = is still fine for basic
   assignment and everyone will understand it immediately.

  w I thought the op is visually so obvious it wouldn't need any
  w explanation, even for newbies.

  w Too bad what I _think_ is often not what actually _is_.

well, = has massive history on its side and almost all commonly used
languages use it for assignment (pascal is NOT common anymore,
thankfully and lisp isn't common enough :). so there is zero learning
curve for that. you do need to learn about perl's precedences which need
() for assigning a list. but == may seem obvious to you and for sure to
anyone here but imagining what newbies would make of it boggles me. if
there is a way to misunderstand it and abuse it, it will happen. :) so
consider it just a style rule that i would encourage. damian should add
it to his P6BP book when it comes out next christmas. :)

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org


Re: (1,(2,3),4)[2]

2005-05-25 Thread Stuart Cook
On 5/26/05, Juerd [EMAIL PROTECTED] wrote:
 You could, if you changed the precedence of , to be tighter than =.
 
 However, by default, = has higher precedence than ,, so that you need
 parens to override this decision: @a = (1,2,3);

Is giving = a higher precedence than , still considered A Good Thing?

I'm not familiar with the reasoning behind the current situation, but
I'm struggling to come up with any good reasons for keeping it.

Consider the alternative:

my $a, $b = 1, 2; # $b should contain 2, not 1
my @foo = 3, 4, 5; # @foo should contain (3, 4, 5), not (list 3)

What justification for the status quo could be so compelling that we
feel the need to prevent both of these from doing the 'natural' thing?


Stuart


Re: (1,(2,3),4)[2]

2005-05-25 Thread Stuart Cook
On 5/26/05, Stuart Cook [EMAIL PROTECTED] wrote:
 my $a, $b = 1, 2; # $b should contain 2, not 1
 my @foo = 3, 4, 5; # @foo should contain (3, 4, 5), not (list 3)
 
 What justification for the status quo could be so compelling that we
 feel the need to prevent both of these from doing the 'natural' thing?

(Scanning through the the history of this thread, I noticed the link
to Larry's comment about the precedence of = and ,. I personally
would still prefer them to be changed, but I guess it's not a big
deal, as long as we have warnings to catch obvious-but-wrong code like
my suggestions. When in doubt, use parens...)