headers
herbert breunung | 1 Jan 2008 04:27
Picon
Gravatar

Re: Perl6::Doc # Hail to the new pharao

hello c

i have now permisson from you, mjd, phil crow and jonathan and perl.com 
is also
mentioned in the head as you see here:

http://search.cpan.org/dist/Perl6-Doc/lib/Perl6/Doc/Magazine/perl.com/EverydayPerl6.pod

its all moving along.

and special thanks to allison and patrick for helping me with the 
interviews. there will be new
content in the tables soon.

http://www.perlfoundation.org/perl6/index.cgi?perl_table

cheers and happy new year

> On Friday 28 December 2007 17:04:40 herbert breunung wrote:
>
>   
>> I have also plans to add my perl article (once they transelated) for $foo
>> perl magazine and maybe some perl.com articles, if chomatic allowes.
>>     
>
> It's fine with O'Reilly, as long as the authors of the articles agree (they 
> hold the copyright).  Where I'm the author, you have my permission.
>
> O'Reilly generally asks that you include a link to the original article as 
> published on our site, but that's a request and not a requirement.
(Continue reading)

Permalink | Reply | 0 comments |
headers
larry | 1 Jan 2008 09:22
Picon

[svn:perl6-synopsis] r14476 - doc/trunk/design/syn

Author: larry
Date: Tue Jan  1 00:22:25 2008
New Revision: 14476

Modified:
   doc/trunk/design/syn/S02.pod

Log:
Infelicities noticed by Limbic_Region++

Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod	(original)
+++ doc/trunk/design/syn/S02.pod	Tue Jan  1 00:22:25 2008
 <at>  <at>  -12,9 +12,9  <at>  <at> 

   Maintainer: Larry Wall <larry <at> wall.org>
   Date: 10 Aug 2004
-  Last Modified: 5 Dec 2007
+  Last Modified: 1 Jan 2008
   Number: 2
-  Version: 121
+  Version: 122

 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
 <at>  <at>  -198,7 +198,7  <at>  <at> 
 =item *

 For all quoting constructs that use user-selected brackets, you can open
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Worthington | 1 Jan 2008 10:18

Re: calling parrot from perl6

Richard Hainsworth wrote:
> Given a function implemented in parrot, how can it be called from a 
> perl6 program?
To use functions from a class or module in a different language, you 
will be able to use "use" to include the module, but with the language 
name out the front. So:

use parrot:SomeModule;

There'll be some way to import symbols too, I imagine.

I'm sure someone with a more encycopedic knowledge of the synopses will 
be able to tell you whether/where that is mentioned in those, but I 
think this is fairly settled on. :-)

Jonathan
Permalink | Reply | 0 comments |
headers
Patrick R. Michaud | 1 Jan 2008 20:19
Picon
Favicon
Gravatar

Re: calling parrot from perl6

On Mon, Dec 31, 2007 at 11:17:53PM +0300, Richard Hainsworth wrote:
> Not sure whether this should be p6-lan or p6-users. Posted to p6l only.

Since the question is specific to perl6 and Parrot, it probably
belongs on perl6-compiler.  But I'll answer it here for now,
as it may spark a language related discussion.

> Given a function implemented in parrot, how can it be called from a 
> perl6 program?
> 
> Suppose I have a file (in current path) 'myfun.pir' which contains
> 
> .sub myfun
>    .param pmc passed_variable
>    .local int an_int
>    an_int = passed_variable[1]
>    .local string string_var
> #code
>    .return (string_var)
>   end                            # is this necessary?
> .end
> 
> how do I create a mymodule.pm so that I can in a perl6 program do
> 
> use mymodule;
> 
> my $parameter = 30;
> my $string_var = myfun($parameter);
> 
> ???
(Continue reading)

Permalink | Reply | 0 comments |
headers
larry | 2 Jan 2008 02:01
Picon

[svn:perl6-synopsis] r14477 - doc/trunk/design/syn

Author: larry
Date: Tue Jan  1 17:01:32 2008
New Revision: 14477

Modified:
   doc/trunk/design/syn/S02.pod

Log:
Clarification of off-the-end semantics of KeySet and KeyBag requested by Limbic~Region++.

Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod	(original)
+++ doc/trunk/design/syn/S02.pod	Tue Jan  1 17:01:32 2008
 <at>  <at>  -14,7 +14,7  <at>  <at> 
   Date: 10 Aug 2004
   Last Modified: 1 Jan 2008
   Number: 2
-  Version: 122
+  Version: 123

 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
 <at>  <at>  -896,7 +896,9  <at>  <at> 
 If you use the C<Hash> interface and increment an element of a
 C<KeySet> its value becomes true (creating the element if it doesn't
 exist already).  If you decrement the element it becomes false and
-is automatically deleted.  When not used as a C<Hash> (that is,
+is automatically deleted.  Decrementing a non-existing value results
+in a C<False> value.  Incrementing an existing value results in C<True>.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hodges | 1 Jan 2008 19:27
Favicon

Re: Multiline comments in Perl6


I love this list. I wish I had more of value to contribute. =o]
But for those of you who don't want to read a long blather, this is
mostly opinion, hopefully sans soapbox. Feel free to skip to the end.

> <asnide>What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years?  It's not
> like  <at> Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.</asnide>

I agree 100%. In fact, I've been guilty of this myself, but the point
is valid...and I think the <asnide> was a nice touch. Still, we do want
to keep polling the user base, if hopefully with a minimum of spam. As
long as we don't lose the forum under a deluge of whining and
me-too-isms, I think it's good to get the occasional, abbreviated
re-airing of old issues. For example, I missed this one the first dozen
times through....

I don't like having to think about whitespace so much, but I'll get
used to that. Virtually every language uses significant whitespace, and
though P6 seems to be more saturated with *relevant* whitespace issues,
as a rule of thumb I have been bluntly impressed with what the  <at> Larry
have been accomplishing. I'll learn, I'll deal, and I'll be happy for
the toys they let me buy with those quirks, lol....

But for my meager $.02 in the matter....

http://perl6.org/doc/design/syn/S02.html still says:
 "Intra-line comments will not be supported in standard Perl"
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jonathan Lang | 2 Jan 2008 20:28
Picon

Re: Multiline comments in Perl6

Paul Hodges wrote:
> http://perl6.org/doc/design/syn/S02.html still says:
>  "Intra-line comments will not be supported in standard Perl"

This is wrong, since S02 also defines intra-line comments, under
"Whitespace and Comments".  It calls them 'embedded comments'.  You
don't need a 'use' statement.

> Is there any restriction of the whitespace *inside* the comment?

Not from my reading of it, no.

> And is / a valid bracketer?

No.  The valid bracketers are defined under "Lexical Conventions" - in
layman's terms, bracketing characters are matching pairs of
characters: so '(' and ')' are bracketing characters, but '/' is not.
Likewise, the matches are based on individual characters, so if you
use "<--" at the start of a bracketed segment, only the "<" counts as
a bracketing character.

> or should I stick to things like
>
>    $x = #<-- comment  --> 1;
>    $x = #{   comment   #} 1;
>    $x = #(   comment   +) 1;
>    $x = #[   comment  =o] 1;
>
> Or will any of these not work?
(Continue reading)

Permalink | Reply | 6 comments |
headers
larry | 2 Jan 2008 20:30
Picon

[svn:perl6-synopsis] r14478 - doc/trunk/design/syn

Author: larry
Date: Wed Jan  2 11:30:16 2008
New Revision: 14478

Modified:
   doc/trunk/design/syn/S03.pod
   doc/trunk/design/syn/S06.pod

Log:
Rationalize migration strategy from Perl 5 to Perl 6 using transitional p5=> operator

Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod	(original)
+++ doc/trunk/design/syn/S03.pod	Wed Jan  2 11:30:16 2008
 <at>  <at>  -12,9 +12,9  <at>  <at> 

   Maintainer: Larry Wall <larry <at> wall.org>
   Date: 8 Mar 2004
-  Last Modified: 31 Dec 2007
+  Last Modified: 2 Jan 2008
   Number: 3
-  Version: 125
+  Version: 126

 =head1 Overview

 <at>  <at>  -48,7 +48,7  <at>  <at> 
     Conditional         ?? !! ff fff
     Item assignment     = := ::= => += -= **= xx= .=
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Lang | 3 Jan 2008 02:58
Picon

Re: Multiline comments in Perl6

I've been putting a fair amount of thought into this.  Here's what
I've come up with:

Perl 6 has several instances where whitespace is required or forbidden
in order to better facilitate "Do What I Mean" programming: for
instance, by having the presence or absence of whitespace before curly
braces affect their meaning, you're allowed to omit the parentheses
around the parameters of the various control structures: e.g., 'if $x
{ ... }' is now valid, whereas in Perl 5 you would have had to say 'if
($x) { ... }'.  Likewise, the same technique lets you provide an
unambiguous distinction between an infix operator and a postfix
operator (IIRC).  So it isn't much of a stretch to require the use of
whitespace in order to distinguish between a standard "line comment"
and an embedded comment.

Except that that isn't what Perl 6 is doing.  All that it does is to
say "there's this one case where there's some ambiguity between line
comments and embedded comments; it's up to the programmer to remove
the ambiguity, through whatever means he sees fit."  In many ways,
this is the opposite of the above cases, and is more akin to how role
composition must be explicitly disambiguated by the programmer,
instead of having the compiler take a best guess.

I must admit: as nice as it is to be able to create an embedded
comment by wrapping the actual comment in brackets, the existence of
that one point of ambiguity is troubling.

--

What I like about the current embedded comments:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Lang | 3 Jan 2008 05:09
Picon

Re: Multiline comments in Perl6

Jonathan Lang wrote:
> How about '~#', meaning something along the lines of "string-like
> comment"?  The idea is that the syntax that follows this would conform
> closely to that of string literals (i.e., quotes).  We might even
> consider loosening the restrictions on delimiter characters, allowing
> the full versatility of quoting delimiters, since there'd no longer be
> any danger of confusing this with a line comment.  So:

For the record: if this gets implemented as I'm describing above, I
will personally restrict myself to using bracketing characters as the
delimiters.  Non-bracketing delimiters have issues that, as a
programmer, I don't want to have to deal with: e.g., if I were to use
'~#/ ... /' to comment out a block of code, I'd have to be very sure
that said code doesn't do any division.  This is still a problem with
brackets, but less so - especially with the ability to double up (or
more) on the brackets.  E.g., '~#[[ ... ]]' pretty much guarantees
that I'll comment out exactly what I want to comment out on the first
try.

Oh, and I just realized: '~#( ... )' looks a bit like an
ascii-graphics thought bubble, as used in old text-based MUXs.  If
'~#' gets nixed, perhaps 'oO' would be a viable alternative?

  $x = oO(here's a comment) 5;

--

-- 
Jonathan "Dataweaver" Lang
Permalink | Reply | 0 comments |

Gmane