Re: STDOUT = WWW

[Matthew Walton]

On 8 July 2011 12:28, Rajeev Prasad  wrote:
> will apps made for one distribution of Rakudo work with another?

Yes, provided that the versions of Rakudo used are sufficiently
compatible (one might have newer features that you used that another
one hasn't updated to include yet, for example), and that the required
modules are available. I don't imagine that we'll get into a situation
where you install one particular distribution and then can't install
the modules bundled with a different one.

> the time for web targeted distro is approaching fast. as soon as we know the 
> most secure/stable and extendable WEB services 
> model(mashups/REST/XML/WSDL...) is identified/spec-ed, there will be a need 
> (requirement) for perl compiler(or any other SSLanguage) to support it out of 
> the box.
> - i think so.

Web programming is one of the big applications for Perl historically.
It would be silly to neglect that for Perl 6, and there are people
looking at writing the necessary modules to provide the support. I
wouldn't be at all surprised to see at least a basic CGI module in
Rakudo Star. I wouldn't expect something like Catalyst though - that's
a bit big to bundle in, but would instead be installed separately. I
would also not expect to find this functionality put into the core
language at any point - Perl 6 is deliberately intended to be powerful
and flexible so that you can write good modules to do anything you
need to do without having to have core language support for
everything. That way, everybody gets what they need, whether they're
doing CGI programming or writing a compiler or using image recognition
to count the number of sweets in a jar.

You mention too many choices of modules confusing new users - yes,
that is a problem, but I personally prefer to have the ability to
choose the most suitable module for my task, rather than being stuck
with something that somebody has declared is the right way to do it,
but actually fits my use case quite badly and causes me a lot of
frustration as a result.

What is needed is a way to make the appropriate modules easy to find,
easy to get and easy to use, in a way that can make system
administrators happy (because I know CPAN drives them nuts).

> rgds,
> Rajeev
>
>
>
> 
> From: Carl Mäsak 
> To: "perl6-langu...@perl.org" 
> Sent: Friday, July 8, 2011 6:05 AM
> Subject: Re: STDOUT = WWW
>
> Rakudo (the compiler) will be packaged in various distributions. The
> one distribution we have so far is Rakudo Star.
>
> There's sometimes been talk on conferences and on IRC about putting
> together a Net/Web-targeted distribution of Rakudo, one with all the
> appropriate modules pre-packaged. The idea is sound; its time may or
> may not have arrived.
>
> // Carl
>
> On Fri, Jul 8, 2011 at 12:59 PM, Rajeev Prasad  wrote:
>>> perl generates the WWW page and dynamic form for WWW user, using data 
>>> stored in RDBMS.
>>
>>> WWW user fills form on browser
>>
>>  >form runs a perl script on server
>>
>>    > perl script saves input data in RDBMS
>>
>>    > perl script logs into many other heterogeneous systems using advertised 
>> web-services, ssh, telnet etc..
>>
>>    > perl script fetches data, operate on it. and saves it in RDBMS
>>
>>       > output it back to WWW user with proper presentation
>>
>> this is going to be the most used scenario (of perl6) in future[in other 
>> words STDOUT=WWW, and STDIN = WWW/RDBMS/remote sys(RPC)], therefore my
>> request is to have some basic (tested fast/secure) functionality built
>> into the base language(interpreter itself), so that i do not have to use any 
>> modules for
>> such activity.
>>
>> Of-course, there can be choice of modules of all of above and much
>> more, but for 80% population, basic setup is enough, which means high
>> popularity, and user-base. Too many choices in modules to do the same thing 
>> over and over again confuses new developers and slows down development. Also 
>> multiple modules doing the same thing, will overlap activities with other 
>> unrelated modules too. (But), you can not control how many modules will be 
>> written for a particular task (say for e.g. generating HTML templates). 
>> Therefore old timers and exceptional knowers of language should clearly rate 
>> modules and incorporate minimal functionality (as much as possible) into the 
>> base interpreter itself.
>>
>> Another wish is, base interpreter should have no diff whether used to serve 
>> documents via console/non HTTP protocol or HTTP protocol.
>>
>> all the best to perl6 community.
>>
>>
>> thank you.
>>
>>
>> rajeev
>>

Re: threads?

[Matthew Walton]

Damian, I use threads in C++ a lot in my day to day job. We use an
in-house library which isn't much more than a thread class which you
inherit from and give a Run method to, and a load of locks of various
(sometimes ill-defined) kinds.

Let me say: it's not good. Threads with semaphores and mutexes and all
that are just horrible, horrible things. It's probably not helped at
all by how C++ itself has no awareness at all of the threading, so
there are no hints in the code that something runs in a particular
thread, you can't put lock preconditions on functions or data
structures or anything like that...

I'm not sure what a better model is, but what I'd like to see is
something which:

- can enforce that certain bits of data are only accessed if you have
certain locks, at compile time
- can enforce that certain bits of code can only be run when you have
certain locks, at compile time
- can know that you shouldn't take lock B before lock A if you want to
avoid a deadlock
- uses a completely different model that nobody's probably thought of
yet where none of this matters because all those three things are
utterly foul

I always liked Software Transactional Memory, which works very nicely
in Haskell - but not for all solutions. Whatever concurrency model
Perl 6 might support, it's probably going to need more than one of
them. Since the language is so extensible, it may be that the core
should only implement the very basic primitives, and then there are
libraries which provide the rest - some of which might ship alongside
the compiler. I don't know, but I do not want people to end up having
to count semaphores and verify locking integrity by eye because it's
really, truly horrible.

I did read a bit about Go's mechanism, and it did look interesting.
Some systems are very well-modelled as completely independent
processes (which might be threads) throwing messages at each other...

Actually something that's very nice as a mental model for server-type
systems is a core routine which responds to a trigger (say, a new
connection) by spawning a new thread to handle it, which is the only
thing which handles it, and maybe uses something like channels to
interact with any global data store that's required. For that though
you need cheap thread creation or easy thread pool stuff, and you need
to have a global data model which isn't going to completely bottleneck
your performance.

I'm totally rambling now, but I do get the distinct impression from
all my experience that safe concurrency is very difficult to do
quickly in the general case. Of course, the safest concurrency boils
down to sequencing everything and running it all on one core...

On 12 October 2010 16:25,   wrote:
> Although anecdotal, I've heard good things about Go's "channel" mechanism as 
> a simple lightweight concurrency model and a good alternative to typical 
> threading. Channels are first-class in the language and leverage simple 
> "goroutine" semantics to invoke concurrency.
>
>
> --- Phil
>
>
>
> -Original Message-
> From: thoughtstr...@gmail.com [mailto:thoughtstr...@gmail.com] On Behalf Of 
> Damian Conway
> Sent: October 12, 2010 10:23 AM
> To: perl6-langu...@perl.org
> Subject: Re: threads?
>
> Leon Timmermans wrote:
>
>> For the love of $DEITY, let's please not repeat ithreads!
>
> $AMEN!
>
> Backwards compatibility is not the major design criterion for Perl 6,
> so there's no need to recapitulate our own phylogeny here.
>
> The problem is: while most people can agree on what have proved to be
> unsatisfactory threading models, not many people can seem to agree on
> what would constititute a satisfactory threading model (or, possibly, models).
>
> What we really need is some anecdotal evidence from folks who are actually
> using threading in real-world situations (in *any* languages). What has worked
> in practice? What has worked well? What was painful? What was error-prone?
> And for which kinds of tasks?
>
> And we also need to stand back a little further and ask: is "threading"
> the right approach at all? Do threads work in *any* language? Are there
> better metaphors?
>
> Perhaps we need to think more Perlishly and reframe the entire question.
> Not: "What threading model do we need?", but: "What kinds of non-sequential
> programming tasks do we want to make easy...and how would we like to be
> able to specify those tasks?"
>
> As someone who doesn't (need to) use threading to solve the kinds of
> problems I work on, I'm well aware that I'm not the right person to help
> in this design work. We need those poor souls who already suffer under
> threads to share their tales of constant misery (and their occasional
> moments of triumph) so we can identify successful patterns of use
> and steal^Wborg^Wborrow the very best available solutions.
>
> Damian
>



On 12 October 2010 16:25,   wrote:
> Although anecdotal, I've heard good things about Go's "channel" mechanism as 
> a simple lightweight concurrency model and a good alternativ

[announce] Rakudo Perl 6 release #32 "Pisa"

[Matthew Walton]

On behalf of the Rakudo development team, I'm happy to announce the
August 2010 release of Rakudo Perl #32 "Pisa".  Rakudo is an
implementation of Perl 6 on the Parrot Virtual Machine (see
). The tarball for the August 2010 release
is available from .

Please note: This announcement is not for the Rakudo Star distribution --
it's announcing a new release of the compiler only.  For the latest
Rakudo Star release, see .

The Rakudo Perl compiler follows a monthly release cycle, with each release
named after a Perl Mongers group. The August 2010 release is code named
"Pisa" in recognition of its excellent work in organizing
YAPC::EU 2010, "The Renaissance of Perl" [1,2].  Many Rakudo
developers presented at the conference, and it was an excellent
location for a hackathon and planning the next phases of Rakudo
development.

Some of the specific changes and improvements occurring with this
release include:

* Due to a specification change, Nil is now undefined, and no longer
  simply an empty Parcel.

* Many modifiers are now recognized on the outside of regexes and
  substitutions, for example s:g:samecase/abc/defg/

* Improvements to the performance of integer operations

* Initial implementations of .pack and .unpack methods for the Buf class

* Smartmatching against True or False is now an error. Most people who did
  this really wanted to look at the return value of .so instead.

For a more detailed list of changes see "docs/ChangeLog".

The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible, as well as those people who worked on
Parrot, the Perl 6 test suite and the specification.

The following people contributed to this release:
Moritz Lenz, Patrick R. Michaud, Solomon Foster, Will "Coke" Coleda,
Carl Mäsak, Jonathan Worthington, Bruce Gray, Patrick Abi Salloum,
tylercurtis, Kyle Hasselbacher, Tadeusz Sośnierz, Jonathan Scott Duff,
Christopher J. Madsen, Kodi Arfer, Reini Urban, TimToady, felliott,
Matt Kraai, Jan Ingvoldstad, szabgab, madsen, Andy Lester, cosimo,
Fitz Elliott

If you would like to contribute, see , ask on
the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#33) is scheduled for September 23, 2010.
A list of the other planned release dates and code names for 2010 is
available in the "docs/release_guide.pod" file.  In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release.  Parrot releases the third Tuesday of each month.

Have fun!

[1] http://www.perl.it/
[2] http://conferences.yapceurope.org/ye2010/

Re: Documentaion Details (was: underscores vs hyphens)

[Matthew Walton]

On Mon, Apr 12, 2010 at 8:04 PM, Shawn H Corey  wrote:
> Matthew Walton wrote:
>>
>> On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey 
>> wrote:
>>>
>>> So, I'll ask again:  Where in the official documentation does it state
>>> that
>>> Perl 6 names are case sensitive?
>>
>> I think it's more important to ask where it says that they aren't.
>>
>> 1) Perl 5 is case sensitive, and the original Apocalypses ran on the
>> basis of 'if it's not mentioned it's the same as Perl 5'
>> 2) The spec assigns no meaning to identifier characters, it just
>> allows you to use a certain set of them. They mean nothing to the
>> language, therefore it has no concept of case to be insensitive about
>> 3) Most popular programming languages are also case-sensitive
>>
>> Maybe it should be explicitly mentioned somewhere, but I think it's a
>> reasonable default assumption. Programmers know that
>> case-insensitivity is a special form of string comparison which
>> involves lots of extra work, so tend to assume (at least in my
>> experience) that it's not going to happen unless they actually ask for
>> it.
>>
>
> You're looking at it from the point of view of experienced programmers.
>  What if the person is a high-school student learning Perl 6 as their first
> programming language?  (And yes, I take the point of view that any computer
> language that a high-school student can not learn is useless.)

If a high-school student assumes case-insensitive identifiers and
codes accordingly, the compiler's soon going to tell them they're
doing something wrong. Besides, their book will probably mention it
(see below).

> It's fine to assume that anyone who reads the Apocalypses is a very
> experienced programmer but when it comes to the official documentation, such
> things should be explicitly stated.  By now, the documentation should be
> reaching its final stages.  Yes, it's a finicky little detail but
> programming is all about getting the finicky little details right.

The spec, in parts, is in its final stages (in other parts, it very
much isn't). The spec is not user documentation. Most of that hasn't
been written yet.

Re: underscores vs hyphens (was Re: A new era for Temporal)

[Matthew Walton]

On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey  wrote:
> Darren Duncan wrote:
>>
>> See http://perlcabal.org/syn/S02.html#Names for your answers.
>
> Thanks for the link but nowhere in it does it state tha Perl 6 names are
> case sensitive.  The best the do is this, which implies it is but doesn't
> state it.
>
> "Other all-caps names are semi-reserved. We may add more of them in the
> future, so you can protect yourself from future collisions by using mixed
> case on your top-level packages. (We promise not to break any existing
> top-level CPAN package, of course. Except maybe ACME, and then only for
> coyotes.)"
>
> So, I'll ask again:  Where in the official documentation does it state that
> Perl 6 names are case sensitive?

I think it's more important to ask where it says that they aren't.

1) Perl 5 is case sensitive, and the original Apocalypses ran on the
basis of 'if it's not mentioned it's the same as Perl 5'
2) The spec assigns no meaning to identifier characters, it just
allows you to use a certain set of them. They mean nothing to the
language, therefore it has no concept of case to be insensitive about
3) Most popular programming languages are also case-sensitive

Maybe it should be explicitly mentioned somewhere, but I think it's a
reasonable default assumption. Programmers know that
case-insensitivity is a special form of string comparison which
involves lots of extra work, so tend to assume (at least in my
experience) that it's not going to happen unless they actually ask for
it.

Re: perl6 compiler

[Matthew Walton]

Rakudo in its normal operation will compile the program, then run it
immediately. You can, however, get it to save the compiled code for
later use i fyou wish.

On Sun, Mar 14, 2010 at 4:09 PM, dell  wrote:
> Hello,
>
>            I had just began looking at the perl6 raduko compiler and have a
> question. Is perl6 actually compiled then ran similar to java or is the
> script ran and then compiled at run time?
>
>
> -Wendell
>

Re: Functional-style pattern matching

[Matthew Walton]

I think the closest things we've got to pattern matching come from a
combination of multiple dispatch, where clauses and signature
unpacking. I don't know much about the latter, but a where clause can
discriminate multiple dispatch variants based on parameter values
rather than just the type, so you can say:

multi doSomething(@a where { .elems == 0 }) {
  # empty arrays only
}

multi doSomething(@a where { .elems >= 3 && .[2] == 4 }) {
  # arrays with a third element numerically equal to 4
}

multi doSomething(@a) {
  # anything else
}

Which is pretty powerful, really.

> This is a contrived example of what I'm referring to:
>
> sub traverse([Leaf $a]) {
>  # do something
> }
>
> sub traverse([Tree $left, Tree $right]) {
>  traverse($left);
>  traverse($right);
> }
>
> my $t = Tree(...);
> traverse($t);

You could do most of this with multidispatch and where clauses. It
doesn't quite work because of the unpacking which pattern matching
does, and also because Perl 6 data structures don't get built in the
same way that Haskell ones do, and you've used a Haskell-like syntax
for Leaf and Tree and so forth.

Now, while it might be nice to say let me write a signature which
accepts a Tree object which has a left and right subtree, and binds
them to $left and $right respectively, arguably a where clause can
check that the subtrees exist, and your tree class should have good
accessors for the subtrees which make unpacking them a little
pointless. This is where Perl 6 is not the same as functional
languages, since it's got an imperative OO element as well.

multi traverse(Tree $t where { all(.left, .right).defined }) { ... }

Perhaps.

Re: Counting characters

[Matthew Walton]

On Wed, Jan 27, 2010 at 1:19 PM, Carl Mäsak  wrote:
> Mark (>), Carl (>>):
>>> S05 describes tr/// in terms of the .trans function, a handsome but
>>> very different beast. Specifically, it doesn't seem to have a "scalar
>>> context", with which one could count things.
>>
>> What does trans return in numeric (+) context?
>
> As spec'd, it returns the numification of the string resulting from
> the substitution, I guess.
>
> // Carl
>

$str.comb(/C|G/).join('').chars might do it. It's maybe not quite as elegant...

Matt

Re: error installing Perl6

[Matthew Walton]

On Thu, Nov 12, 2009 at 2:30 PM, Richard Hainsworth
 wrote:

> Can't exec "svn": No such file or directory at build/gen_parrot.pl line 47.

You need to install Subversion in order to allow the build script to
obtain Parrot.

Re: unusual invocants

[Matthew Walton]

On Tue, Oct 20, 2009 at 5:35 PM, David Green  wrote:
> I would expect "$foo where {$_ ~~ X}" and "X $foo" simply to be different
> ways of writing the same thing, but whatever works!

Yes, but the where clause lets you test against multiple types at
once. They don't participate in multiple dispatch in the same way
though. Whether it should be possible to attach a where clause to an
invocant appears to be unresolved.

Re: unusual invocants

[Matthew Walton]

On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed  wrote:
> On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang  wrote:
>> Because a method is part of a role, and ought to abide by the same
>> terms by which the role abides.  If Logging doesn't do Numeric, it
>> shouldn't have any methods in it that won't work unless it does.
>
> 100% agreed.
>
> So what the OP wants to do is declare a method that is available on
> all those invocants - and only those invocatnts - which do all of
> roles X, Y, and Z.  Granted, you can declare a new role XandYandZ that
> does X, Y, and Z, and define the method there, but that won't work on
> $foo unless you declare explicitly  '$foo does XandYandZ' .  The goal
> is to have the method show up no matter how $foo comes to do all three
> roles.
>
> This is an interesting idea.  Currently, it doesn't work because
> there's no place for such a method to live, so perhaps there could be
> a way to declare a "method space" for arbitrary combinations of roles,
> a sort of meta-role.  It's an odd duck, but it does sort of fall out
> of the multiple-dispatch semantics, which already let you base
> implementation chioce on arbitrary combinations of roles...

Well, if you could put a where clause on your invocant you could do that...

method m($invocant where { $_ ~~ X and $_ ~~ Y and $_ ~~ Z }: Int $a,
Int $b) { ... }

The STD.pm bot in #perl6 thinks where clauses on invocants are
allowed, but Rakudo currently seems to completely ignore them. I'm not
sure what the proper behaviour should be.

Matthew

Re: Freezing role methods

[Matthew Walton]

On Thu, Oct 15, 2009 at 10:07 AM, Ovid
 wrote:
> Reading the paper I linked to could help to clarify the issue.  In short, 
> there are times under my current understanding of roles where you *can't* 
> resolve the conflicts.  Two roles, each providing and dependent upon a method 
> x(), such that if either tries to use the other's "x()", the code will fail. 
> Thus, you cannot choose one x() over the other.
>
> "frozen" traits suggests that the composing class determine which x() it 
> wants and statically binding the other x() to its role, thus guaranteeing 
> that no role can get the wrong x(), but still allowing classes full control 
> over their composition.
>
> I need to read the other responses more closely to understand their 
> reasoning.  So far, they seem wrong to me, but that's probably because I'm 
> not reading them closely enough.

What if there are genuinely situations when you cannot combine two
roles into the same class? Do all combinations have to be possible? As
TSa said, a role depending on one of its own public methods is asking
for trouble when it gets combined with something else with a
conflicting method, so perhaps what we should really be thinking about
is how to write well-behaved roles.

Re: Cobra & Ioke Programming Languages

[Matthew Walton]

On Thu, Sep 17, 2009 at 6:58 PM, yary  wrote:
> Matthew Walton wrote
>>Yes, Perl 6 does - it is not backwards compatible with Perl 5.
>
> That so? I thought Perl6 was supposed to recognize and execute perl5
> code. That statement itself implies that perl6 and perl5 are different
> languages, and I'm not too interested in arguing over semantics. I am
> curious about P6 executing P5 modules/libraries- that was in the
> original plans and I think it's still included in the specs- though
> not sure.

That's not Perl 6, so much as there being plans for a Perl 6
implementation to also be able to load Perl 5 libraries and code.
Rakudo (and all other Parrot languages) is currently gaining this
ability through the Blizkost project, which embeds the Perl 5
interpreter to do the heavy work. A system which understands Perl 6
the language is not going to be happy with most Perl 5 programmes you
might choose to feed it - it would have to detect that and feed it to
a Perl 5 interpreter instead. There will be such systems, but I tend
to think of them as multilingual.

> On Thu, Sep 17, 2009 at 6:06 AM, Juan Madrigal  wrote:
>> Hopefully Catalyst will be re-written for Perl6.
> I think that's a ways away. Right now there is a built-from-scratch
> wiki in perl6, November, that is pushing perl6's web code-base. P6
> will either get Catalyst, or something better.
>
>>Web development with Perl
>> needs to be easier PHP and Ruby make it easy. I would prefer to just use
>> Perl without having to hunt down CPAN modules for features that are built in
>> to other languages. Mail, Sessions/Authentication, Database Connectivity
>> etc... are native. Maybe the best modules should be included or a standard
>> set developed for the web including Catalyst? EmbPerl is another option.
>
> Some people are already writing web apps in Perl6 and discussing their
> experience, all getting incorporated into the discussion and P6
> language / library design. If you have the time to install Rakudo, and
> join the November effort, then you'll have a direct influence on the
> future of web development in Perl as well!

You're never going to get web features built into the language itself
- they will be modules, because Perl 6 is not a language specifically
intended for web development (although it's likely to be rather good
at it once the libraries are in place). Ruby doesn't do much web in
the core language either - Ruby on Rails is all extra (very clever)
libraries, rather like Catalyst, although Catalyst tends to expose a
bit more of the plumbing.

Carl Mäsak is working on a project called Web.pm which is the core
Perl 6 web programming experience. It's an outgrowth of the November
wiki project, and if you're interested in web programming I recommend
you take a look at it as it may well be the basis of all the fancy web
frameworks we might want to build in the future.

Re: How can i contribute for perl 6 ?

[Matthew Walton]

On Thu, Sep 17, 2009 at 4:13 AM, Saravanan T  wrote:
> Thanks everyone for sharing the links...
>
> Thought of working in porting Data::Dumper functionality in perl 6 .Seems
> like already there is ".perl" function which does the same..
> and a monker "mberends" said there is a bug in circular references ..
>
>
> So i am thinking to get deep into the problem.
>
> Was expecting "perl6 -d" functionality to debug ?
>
> How do you guys normally debug a perl6 program?

Lots of print and say statements, in my case - the old-fashioned way.
We don't have a debugger for Rakudo at this point.

Re: Cobra & Ioke Programming Languages

[Matthew Walton]

On Thu, Sep 17, 2009 at 4:41 AM, yary  wrote:
> Perl is being actively developed for the Parrot VM. LLVM is another
> interesting option and if someone or some group would like to take it
> on, it would be a welcome alternate implementation.
>
> What parts in particular of Cobra and ioke look useful to you? Looking
> at Cobra's intro slide-
>
> * Cobra is a new language (sub 1.0)
> Not sure if Perl6 qualifies as a new language. It's built off of an
> old language, and is backwards compatible with it. And, perl5 is
> adopting pieces of perl6. On the other hand there's enough in Perl6
> that's new it's easy to make the case that it is a new case.

Yes, Perl 6 does - it is not backwards compatible with Perl 5. It's
based very heavily on it, but I think it does qualify as 'new' to most
purposes. New, but at least partially familiar.

I don't see anything in either language's summary that Perl 6 can't
already do or which couldn't be implemented with it. One thing you
have to keep in mind is that when we have the full-blown macro and
introspection systems available in a Perl 6 implementation, a great
deal of power to add new language features is then in our hands. At
that point we could quite probably manage syntax-level support for
unit tests, etc. - although I've never been entirely convinced about
the absolute necessity of such things. We do have pre- and
post-conditions, in PRE and POST blocks - see Synopsis 4 under
'closure traits'. Signature-level where blocks help with DBC-style
programming as well.

Okay so we don't run on JVM or .NET right now, but there are people
who've come to #perl6 and expressed an interest in doing it. Not an
easy project, but maybe some amazing people will do it one day.

Fwd: More flexible POD

[Matthew Walton]

Woops - forgot to reply all (I'm on an irritating mixture of lists
which set reply-to and don't, and I never remember which is which).
Sorry!


-- Forwarded message ------
From: Matthew Walton 
Date: Tue, Aug 11, 2009 at 7:10 AM
Subject: Re: More flexible POD
To: Jon Lang 


I'm not sure what it should be, but I do believe that there should be
a solution which allows elegant mixing of code and Pod. I want to
document my APIs by attaching the documentation to the methods in
question, otherwise the documentation won't get updated when the code
does (and if the code at work is anything to go by, won't get updated
at all anyway, but you can at least make it as easy as possible for
the people who do remember).

Attaching blocks of documentation to bits of code is something that
Javadoc's syntax gets very right.

The trouble is, if we just allow arbitrary whitespace before the start
of a Pod block:

class A {
 =head2 foo()
 Frobnicates the widget.
 =end
 method foo() { ... }
}

(modulo accurate Pod directives - I'm a bit hazy on how it works now,
I keep thinking I should be able to say '=method', but maybe that's a
matter for the Pod extractor).

Do we run the risk of causing problems if somebody does this:

my ($several, $lengthily-named, $variables)
 = something-which-produces-a-list();

and the parser thinks 'hang on a sec, that's Pod'. This is
particularly bad for programmers who don't put spaces around their
binary operators (hah! We could enforce it!) and may cause
confuzzlement.

I don't think footnote-like references in the code would help
programmers keep the documentation up to date or help them in reading
it to comprehend the code when they come to maintain it, which I think
are the two key reasons to put your documentation right there in the
code. If you did do it though, you'd have to use named references
(probably valid Perl 6 identifiers), because numbers are just a
nightmare.

Matthew

Re: Rukudo-Star => Rakudo-lite?

[Matthew Walton]

Then you could be like TeX and have releases numbered with
ever-increasing parts of an irrational number.

On Mon, Aug 10, 2009 at 12:37 PM, Mark J. Reed wrote:
> Wrong reply button...
>
> -- Forwarded message --
> From: "Mark J. Reed" 
> Date: Mon, 10 Aug 2009 07:36:52 -0400
> Subject: Re: Rukudo-Star => Rakudo-lite?
> To: Gabor Szabo 
>
> That has the same problem as lots of other themes - it puts a hard
> limit on the number of releases before the One True Rakudo.
> Maybe you could call it Zeno's Camel (project motto: "halfway done!")
> and have releases numbered 0.5, 0.75, 0.875, 0.9375,... :)
>
> On 8/10/09, Gabor Szabo  wrote:
>> On Mon, Aug 10, 2009 at 2:02 AM, Patrick R. Michaud
>> wrote:
>>> On Sun, Aug 09, 2009 at 04:35:42PM -0600, David Green wrote:
 On 2009-Aug-9, at 3:57 pm, Tim Bunce wrote:
> Perhaps it's worth asking what we might call the release after that
> one.
> "Rakudo not-quite-so-lite"?

 Rakudo ** (aka "Rakudo Exponentiation")?  Though I think Patrick is
 optimistic that development will proceed exponentially enough that a
 single interim release will be enough to hold us over until Christmas.
>>>
>>> I'm not sure I'm quite THAT optimistic.  :-)  We may end up with
>>> multiple interim releases in the Rakudo Star series before we reach
>>> Christmas.  (And yes, they may even be *+1, *+2, etc.)
>>>
>>> In some ways I'm starting to think of "Star" (or whatever designation
>>> we end up using) as a label for a series of interim releases in the
>>> same sense that NASA used "Gemini" as the label for the program
>>> came between "Mercury" and "Apollo".
>>>
>>> In other words, "Star" may really end up being a designation for a
>>> program of planned releases with certain major objectives that
>>> cumulatively lead up to the ultimate goal of a "full Perl 6 release".
>>>
>>> The precise details are still a little ill-formed in my head at the
>>> moment, but as they come together (and are expressed in planning
>>> documents) I'll be blogging or writing about them appropriately.
>>>
>>
>>
>> my bikeshed would go along the lines of
>>
>> @rakudo[*-100]
>> @rakudo[*-99]
>> ...
>>
>> Gabor
>>
>
> --
> Sent from my mobile device
>
> Mark J. Reed 
>
> --
> Sent from my mobile device
>
> Mark J. Reed 
>

Re: [perl #67810] AutoReply: [PATCH] Test.pm planless testing support update

[Matthew Walton]

Updated patch (replaces previous) which does the right thing when you
don't call done_testing in planless mode. Thanks pmurias++ for
spotting that.

On Thu, Jul 23, 2009 at 12:38 PM, perl6 via
RT wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
>        "[PATCH] Test.pm planless testing support update",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [perl #67810].
>
> Please include the string:
>
>         [perl #67810]
>
> in the subject line of all future correspondence about this issue. To do so,
> you may reply to this message.
>
>                        Thank you,
>                        perl6-bugs-follo...@perl.org
>
> -
> Following IRC discussion on 23rd of July 2009, this patch removes the
> need to call 'plan', and adds done_testing.
>
> Should work (and seems to work) seamlessly with numbered test files
> using the usual format (with or without an explicit call to
> done_testing).
>
> May not handle all possible failure cases entirely elegantly.
>
>
From d1b4a9b5dbe57e775bf1fd6c5f3689169eefd989 Mon Sep 17 00:00:00 2001
From: Matthew Walton 
Date: Thu, 23 Jul 2009 12:32:59 +0100
Subject: [PATCH] Updated Test.pm planless testing support.

Omit your call to plan, and call done_testing when all tests have run.
---
 Test.pm |   40 
 1 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/Test.pm b/Test.pm
index 72517d0..237c4ff 100644
--- a/Test.pm
+++ b/Test.pm
@@ -11,13 +11,15 @@ our $num_of_tests_failed = 0;
 our $todo_upto_test_num  = 0;
 our $todo_reason = '';
 our $num_of_tests_planned;
-our $no_plan;
+our $no_plan = 1;
 our $die_on_fail;
 
 our $*WARNINGS = 0;
 
-# for running the test suite multiple times in the same process
-our $testing_started;
+## If done_testing hasn't been run when we hit our END block, we need to know
+## so that it can be run. This allows compatibility with old tests that use
+## plans and don't call done_testing.
+our $done_testing_has_been_run = 0;
 
 
 ## test functions
@@ -28,14 +30,14 @@ sub die_on_fail($fail=1) {
 }
 
 # "plan 'no_plan';" is now "plan *;"
+# It is also the default if nobody calls plan at all
 multi sub plan(Whatever $plan) is export(:DEFAULT) {
 $no_plan = 1;
 }
 
 multi sub plan($number_of_tests) is export(:DEFAULT) {
-$testing_started  = 1;
-
 $num_of_tests_planned = $number_of_tests;
+$no_plan = 0;
 
 say '1..' ~ $number_of_tests;
 }
@@ -212,7 +214,6 @@ sub eval_exception($code) {
 }
 
 sub proclaim($cond, $desc) {
-$testing_started  = 1;
 $num_of_tests_run = $num_of_tests_run + 1;
 
 unless $cond {
@@ -234,26 +235,33 @@ sub proclaim($cond, $desc) {
 return $cond;
 }
 
-END {
-# until END blocks can access compile-time symbol tables of outer scopes,
-#  we need these declarations
-our $testing_started;
-our $num_of_tests_planned;
-our $num_of_tests_run;
-our $num_of_tests_failed;
-our $no_plan;
+sub done_testing() is export(:DEFAULT) {
+our $done_testing_has_been_run;
+
+$done_testing_has_been_run = 1;
 
 if $no_plan {
 $num_of_tests_planned = $num_of_tests_run;
 say "1..$num_of_tests_planned";
 }
 
-if ($testing_started and $num_of_tests_planned != $num_of_tests_run) {  ##Wrong quantity of tests
+if ($num_of_tests_planned != $num_of_tests_run) {  ##Wrong quantity of tests
 diag("Looks like you planned $num_of_tests_planned tests, but ran $num_of_tests_run");
 }
-if ($testing_started and $num_of_tests_failed) {
+if ($num_of_tests_failed) {
 diag("Looks like you failed $num_of_tests_failed tests of $num_of_tests_run");
 }
 }
 
+END {
+our $done_testing_has_been_run;
+our $no_plan;
+
+## In planned mode, people don't necessarily expect to have to call done_testing
+## So call it for them if they didn't
+if !$done_testing_has_been_run && !$no_plan {
+done_testing;
+}
+}
+
 # vim: ft=perl6
-- 
1.6.0.4

Re: [perl #67358] [BUG] less than awesome error message for 1 param expected in Rakudo

[Matthew Walton]

On Thu, Jul 9, 2009 at 1:24 AM, yary wrote:
> On Wed, Jul 8, 2009 at 3:28 PM, Carl Mäsak wrote:
>
>>> It's Parrot behavior.  It's trivial to change to "Too many params passed" or
>>> "Too many results passed".  Would that be clearer?
>>
>> Maybe, but the problem as described in the original ticket was the
>> inconsistency of '1' and 'params' with an 's'.
>
> There's also the inconsistency of "arguments" vs "params"! Drop the
> "params" altogether.
>

There's also also the fact that 'param' is an abbreviation and looks
sloppy, so it should be 'parameter' vs 'argument'. Which is right? I
don't know, but I know that 'param' is wrong. PIR might use it, but
that's not the kind of thing we want to expose in error messages.

Or at least, I don't.

Mixing in to method objects

[Matthew Walton]

As I understand it, in Perl 6 a method of a class, as indeed all
similar things like a sub or a regex, is represented by an object. If
it's an object, I should be able to mix a role into it, right?
Something like:

role Fancy {
  has $.something is rw;
}

sub a {  }

&a does Fancy;
&a.something = 56;
say &a.something;
a();

And so forth. Now, Rakudo's got a whole load of bugs I'm tripping over
trying to do things like this, but I thought I'd check to see if it's
supposed to be possible, and if it isn't, why not.

Also syntactically, is there or should there be a way to do it which
doesn't involve having to haul out the &a afterwards - so can the
'does' or maybe a 'but' be attached to the definition itself?

As for why I want to do this, I've got something in mind which would
be potentially much nicer if some methods can carry a load of extra
data around with them - which seems like an excellent use for a mixin,
especially as I could then smartmatch against it in order to pick out
the relevant methods from the .^methods list.

Matthew

Re: negative index in perl6 array

[Matthew Walton]

On Sat, Jun 20, 2009 at 12:07 PM, Chas. Owens wrote:
> Hmm, I can't get [user-defined array indexes][1] working, and those
> are a prerequisite for mixing subscripts (you can't mix normal and
> user-defined indexes if you can't create user-defined indexes).  I
> took a quick look at the tests and couldn't even find a test for
> user-defined array indexes.
>
> [1] : http://perlcabal.org/syn/S09.html#User-defined_array_indexing

That means it's not implemented yet, unfortunately.

By the way, if you have trouble remembering that negative indexes for
arrays are now *-n, recall that the * is generally called 'whatever',
so it's 'whatever - 1', and the 'whatever' in this case fills in to be
'however many things are in the array, the precise value of which I
really don't care about'.

Re: "Nonexistent file" processing

[Matthew Walton]

The correct place for this is in an email to rakudo...@perl.org, which
will lodge a ticket with the rakudo bug tracker. I've submitted this
one for you, but feel free to do it yourself in the future.

Good luck with Rakudo, and enjoy Perl 6!

On Sun, Jun 21, 2009 at 6:40 PM, Parrot Raiser<1parr...@gmail.com> wrote:
> Following the instructions on the Rakudo how-to-get-rakudo page, I ran
> ./perl hello & hello.pl
> As I had not yet written hello, perl6 objected as follows:
>
> $ ./perl6 hello
> Unable to open filehandle from path 'hello'
> current instr.: 'perl6;PCT;HLLCompiler;evalfiles' pc 1099756 ((unknown 
> file):-1)
> called from Sub 'perl6;PCT;HLLCompiler;evalfiles' pc 1292
> (src/PCT/HLLCompiler.pir:704)
> called from Sub 'perl6;PCT;HLLCompiler;command_line' pc 1513
> (src/PCT/HLLCompiler.pir:813)
> called from Sub 'perl6;Perl6;Compiler;main' pc 271599
> (src/gen_actions.pir:24108)
>
> The error message and its handling could be tidier.
>

Re: Why pass by reference?

[Matthew Walton]

> Complex or not in that sense, it complicates things in allowing the value to
> be changed by another path.  I think that is something we want to avoid
> doing, not present as a feature.  Much of my original post concerns the
> actual meaning, not whether it is considered simple.
>
> Since then, I see that it is useful for plural containers.  We don't want to
> copy them!  But for items, why do we not even _have_ pass by value?  The
> compiler must assume the worst and can't optimize as well.

'is copy' is pass-by-value... remember everything in Perl 6 is a
reference, of sorts. Pass-by-value of the reference is covered by 'is
ref'. A more useful variant of that being 'is rw', which gives you an
extra assurance with its lvalue checking that the user's not giving
you something that's going to explode when you try to modify it.
Pass-by-value of the thing the reference points to is covered by 'is
copy', which is the semantics people would generally expect when they
hear 'pass-by-value'.

Pass-by-reference-but-don't-accidentally-change-what-it-points-to is
covered by the default case or 'is readonly'. This seems to me to be
the ideal - we don't copy huge values around when the user doesn't
need them, but we also don't have hugely dangerous mutable parameters
by default (they should be extremely explicit for the user of an API).

Most of the time, there won't be another path where the value could
change. Under a threaded model allowing shared variables, sure it
could be changed by another thread, but hopefully you're under lock
there. If a user of your API contrives to make it change while you're
running, that's their own foot they've just shot, because they can
look at the signature and know the semantics of the parameter passing
being used and know that if they change the value externally before
you return Bad Things Could Happen.

Matthew

Re: Why pass by reference?

[Matthew Walton]

> Complex or not in that sense, it complicates things in allowing the value to
> be changed by another path.  I think that is something we want to avoid
> doing, not present as a feature.  Much of my original post concerns the
> actual meaning, not whether it is considered simple.
>
> Since then, I see that it is useful for plural containers.  We don't want to
> copy them!  But for items, why do we not even _have_ pass by value?  The
> compiler must assume the worst and can't optimize as well.

'is copy' is pass-by-value... remember everything in Perl 6 is a
reference, of sorts. Pass-by-value of the reference is covered by 'is
ref'. A more useful variant of that being 'is rw', which gives you an
extra assurance with its lvalue checking that the user's not giving
you something that's going to explode when you try to modify it.
Pass-by-value of the thing the reference points to is covered by 'is
copy', which is the semantics people would generally expect when they
hear 'pass-by-value'.

Pass-by-reference-but-don't-accidentally-change-what-it-points-to is
covered by the default case or 'is readonly'. This seems to me to be
the ideal - we don't copy huge values around when the user doesn't
need them, but we also don't have hugely dangerous mutable parameters
by default (they should be extremely explicit for the user of an API).

Most of the time, there won't be another path where the value could
change. Under a threaded model allowing shared variables, sure it
could be changed by another thread, but hopefully you're under lock
there. If a user of your API contrives to make it change while you're
running, that's their own foot they've just shot, because they can
look at the signature and know the semantics of the parameter passing
being used and know that if they change the value externally before
you return Bad Things Could Happen.

Matthew

Re: Multi-d array transforms (was Re: Array rotate)

[Matthew Walton]

On Sat, Jun 13, 2009 at 1:08 AM, Larry Wall wrote:
> Nevertheless, for any major methods borrowed from Perl 6, I'm not
> inclined to change them that drastically.  Much more likely to
> define them as sugar for the more general list operators:
>
>    .push       means   .=append
>    .unshift    means   .=prepend
>    .splice     means   .=impend        :-)
>
> or some such.

That makes sense to me. I'd very much like it if the fundamental
methods on most data types were non-mutating - string manipulation,
list munging etc. Along with having lazy lists, that gives us a good
dose of tricks from the functional world we can do, and with .= and
(hopefully) some clever bits in the compiler which can handle it
effectively (as in performance-wise), it's no hassle to convert any
non-mutator to a mutator. Syntactic sugar for really common mutating
cases, as in other methods which do 'the same thing but mutated' is of
course fine (particularly when they have sensible/familiar names,
which implies to my mind that the operation makes sense).

Although some things may be able to be implemented far more
efficiently if they know that they're being called with infix:<.=> and
not with infix:<.>.

method munge($self is ro:) { } # infix:<.> case
method mung($self is rw:) { } # infix:<.=> case

?

Marginally inspired by C++ const methods. Of course, a potential
problem here is that they might want different return types as well -
but maybe our multis are fine with that, and maybe this is just some
crazy dream caused by waking up too early on a Saturday morning and
thinking about Perl before breakfast.

Matthew

Re: [perl #64094] AutoReply: [BUG] Infinite loop in Rakudo during subst

[Matthew Walton]

Turns out that the loop is actually caused by the +, not the subst,
as I had the same inside an ordinary match. jnthn tells me that the + is
a bit redundant, but it shouldn't cause a loop.

* also succumbs.


signature.asc
Description: This is a digitally signed message part

Re: Rakduo Logo Proposal

[Matthew Walton]

On Wed, 2009-03-18 at 16:43 +0100, Carl Mäsak wrote:
> Stephen (>):
> > Use of the gimel[1] character comes from Justin Simoni's logo design
> > proposal[2] from a while back, and the design is a reference to the
> > anarchist symbol[3].
> 
> It also looks like a reference to another programming language.
> 
>  
> 
> Lambda in a circle. We don't surround our letter with mathematical
> symbols, but the similarity is still there.
> 
> // Carl

Exactly what I was thinking. It looks far too similar to the Haskell
logo, IMO. My first thought was 'that's a lambda'.


signature.asc
Description: This is a digitally signed message part

Re: Announcing Form

[Matthew Walton]

On Mon, 16 Mar 2009 09:51:10 -0400, Guy Hulbert  wrote:
> On Mon, 2009-16-03 at 14:34 +0100, Carl Mäsak wrote:
>> Form is still in its early stages, but is already showing great
>> promise. Consider downloading it and trying it out, or even
>> contributing. 
> 
> Very cool.  This gives me a reason to play with Rakudo.
> 
> What about starting from Build.PL rather than Makefile.PL (even if it
> starts as a make-wrapper) ?

It might make more sense. I think the question of best practice for Perl 6
libraries is still being determined. At the moment the intention is just to
make sure it can be used either directly or using proto, so it's got the
kind of build system that proto expects. I guess this kind of thing is one
of the things that'll come out of talking about how CPAN6 will work.

Constructing objects

[Matthew Walton]

This is probably explained somewhere, but I've been unable to piece it
together in my own investigation. If I have a class:

class Foo {
  has Int $!value;
}

I get the impression that the default constructor would allow me to
say

my Foo $foo .= new(value => 2);

Which seems to me to be a bit odd, since $!value is surely supposed to
be private. In any case, how would I write a custom constructor which
initialises $!value (and possibly many other fields which have to be
initialised based on some constructor parameters)? So far I think it's
something like this:

method new($class: Int $v)
{
  my $self = $class.bless();
  $self!value = $v;
  return $self;
}

Or possibly

method new($class: Int $v)
{
  $class.bless(value => $v);
}

Maybe both are valid. Rakudo didn't seem to understand private
attributes when I tried playing with this, so I have no real idea if
I'm barking in the correct forest.

Re: Sequential bias in S04 (and Perl6 in general)

[Matthew Walton]

On Fri, 2008-01-11 at 10:34 -0800, Dave Whipp wrote:
> Matthew Walton wrote:
> 
> > I wouldn't agree with that at all. I think of arrays as ordered constructs,
> > so I'd want the default iteration over my array to happen in the order of
> > the indices.
> 
> I guess that depends on whether you think of the array as a list or as a 
> ram. I know that a group at microsoft added a ParallelArray datatype 
> (ftp://ftp.research.microsoft.com/pub/tr/TR-2005-184.pdf) to C# as a way 
> to distinguish the intent (they speed up data-parallel code by compiling 
> it down to your GPU/graphics card). Perl6, being an operator-oriented 
> language, associates the distinction with the operators rather than with 
> the datatype. This is probably a better approach, but it does mean that 
> you need an operator whenever you want to treat the array as 
> data-parallel. (BTW, data-parallel arrays differ from bags in that they 
> have an ordered index that is preserved across unordered operations)

Good point, a parallel operation over a list would let you preserve
ordering but still benefit from concurrency with operations where
iterating in order is irrelevant. Which, come to think of it, covers
quite a lot of cases.

> Of course, it's not necessarily true that "you know" that something is 
> safe -- often "you think" it's safe but then you get an intermittent 
> failure at runtime,. I would love to be able to tell the compiler "I 
> think this is safe" and have it tell me "you're wrong" as a compile-time 
> error (this is one of the things that an explicit type system is good 
> for). But perhaps Perl is too dynamic a language for that.

Well, I was thinking with 'knowing' that something was safe that you'd
figured out that it was free of side effects by studying the behaviour
of everything you use within the relevant routines...

...in the real world, you need the compiler to be able to do some of
that for you I guess.

And Perl 6's optionally explicit type system might be able to express
that sort of thing.


signature.asc
Description: This is a digitally signed message part

Re: Sequential bias in S04 (and Perl6 in general)

[Matthew Walton]

Springing out of the ashes (and a job where I have to write Java) for my
first post in years:

On Fri, 04 Jan 2008 13:13:11 -0800, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I agree that adding a parallel "forall" (and similar statements) via a
> pragma will be easy if the appropriate underlying machinery is there, so
> maybe I can live with the bias in S04 -- perhaps rename it to
> "Sequential Blocks and Statements". Anywhere that we guarantee
> sequential behavior, we pretty much rule out concurrency. But if we
> maximize the number of places where we are explicitly "unordered" then
> we also maximize the number of places where implicit concurrency can be
> added later. From that perspective, it's unfortunate a C loop
> always iterates arrays in the order of their indices.

I wouldn't agree with that at all. I think of arrays as ordered constructs,
so I'd want the default iteration over my array to happen in the order of
the indices. I wouldn't have a problem with having the ability for C
to iterate over a bag or some other inherently unordered, unsorted
container in arbitrary possibly-parallel order though. Possibly by default,
if the compiler can be satisfied that the closure's not got any unpleasant
side effects to interfere with parallel execution.

I think you're leaning too far towards concurrency in attempting to address
the perceived bias. A lot of the time, the compiler's not going to be able
to prove that it's safe to autothread a given closure because it might have
side effects. If we were talking about Haskell or some other language which
is ordinarily pure, things would be different. Under these circumstances, I
would much rather have to explicitly say that I want parallel execution -
provided that the ability to do it is there and it's easy to get at and
behaves in a sensible manner (naturally this lets you parallelise things
the compiler isn't sure are safe to parallelise due to possible side
effects. That's fine, since you know which side effects are okay to do that
to in your program).

Matthew

Re: ^method ?

[Matthew Walton]

> On 15/05/05 22:48 +0100, Matthew Walton wrote:
> I don't think that is what Rob is saying at all.

It wasn't aimed entirely at Rob. I have a bad habit on mailing lists of
vaguely replying to the entire thread without remembering who said what
and being too lazy to check.
> My read:
>
>.method($foo);
>
> always means:
>
>$_.method($foo);
>
> and
>
>$self.method($foo);
>
> always means
>
>$?SELF.method($foo);
>
> The former is consistent with the rest of Perl 6, and the latter is
> consistent with most of Perl 5 OO code in the wild.
>
> My only stance is that, given there is no clearly sexy solution, at
> least I can take `$self` home to meet my Mom.

Perhaps. However, I'm uncomfortable with the idea of $self being
automatically assigned, because so far Perl 6 seems to have managed to
avoid automatically providing anything in what I've been thinking of as
the 'normal' or 'user' namespace. $?SELF looks 'special'. Admittedly it
might be nicer if it was $?self, because it still looks 'special'. It's
the same kind of thing that makes me wonder why $a and $b in sort was ever
considered a good idea.
But then perhaps I'm just odd... choosing a name for the invocant yourself
if you don't want $?SELF or $_ to be it (although they will be anyway of
course) seems to me to be the height of programming sexiness. I like being
able to name things myself.
The

./method()

thing proposed in another thread is pretty cool too, by the way, and
largely renders this thread moot. So perhaps I should have replied to
that...

Re: ^method ?

[Matthew Walton]

.
On 15 May 2005, at 16:17, Rob Kinyon wrote:
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method ( Int foo ) {
$self.otherMethod( foo );
}
and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
JS as part of my argument.)
If you have
method ( Int foo ) {
.otherMethod( foo );
}
That would be
method ( Int foo ) {
$_.otherMethod( foo );
}
Just like expected.
My ill-considered and probably not very understandable thoughts:
- As has been said with great eloquence earlier, virtually everywhere  
in Perl 6 so far when you leave something out the default is taken to  
be $_
- As has also been said, elsewhere, internal consistency is a great  
feature of a language people are trying to learn

Given these two points, in my mind anything other than making
.method($foo);
mean
$_.method($foo);
is utterly absurd. If it means $_.method($foo) outside a method  
definition and $?SELF.method($foo) inside one then I think it's a  
reasonable expectation for people learning Perl 6 to throw up their  
hands and start complaining loudly (and possibly going back to their  
previous language of choice).

It also seems to make sense to me that the invocant of a method is  
the default topic for the method body - that is, after all, what that  
code has been invoked in order to do something to/with. Is it really  
a serious hardship to do what you have to do everywhere else in Perl  
6 if you want to preserve the topic, and give it a name of your own  
choosing?

method m($self: $foo) {
  $self.do_something();
}
is hardly difficult to deal with in my opinion. Neither is
method m($foo) {
  my $self := $_;
  $self.do_something();
}
for that matter. Remembering not to clobber the topic when you want  
to keep it will be second-nature to Perl 6 people very shortly after  
they start, I'm sure, as it's always seemed to me that it's going to  
use a lot more things which allow you to do a lot of topic  
manipulation instead of having to think up silly variable names all  
the time (given {} will be particularly handy for my code, thank you  
very much for that!) Thus I don't think that given {} and other such  
things inside the method body are going to be something people will  
particularly find problematic with regard to clobbering their  
invocant, as there is an easy and clear syntactic way to give it an  
alias, and normal variable binding can rescue it at any point up to  
the point where you assign something else to $_ (assuming I've  
understood binding correctly, of course). And indeed afterwards, if  
you use $?SELF. Which, to be honest, I'm not particularly keen on in  
terms of appearance or ease of typing, but I don't think we're going  
to need it except in 'emergencies' - $_ and the invocant naming  
syntax will provide plenty of opportunity for people to refer to $? 
SELF by a saner and more appropriate name for their given situation.

In the long run I can see making sure .method() defaults to $_  
everywhere will save me a fair bit of typing - my methods (in C++ and  
in Perl 5) are usually made up either of coordinating calls to other  
methods of the same object, which will be nice and simple due to  
being able to omit the $_ or $?SELF or other name I might have given  
the invocant; or made up of a bunch of operations largely concerning  
other objects, in which case the whole thing goes out of the window  
because you're barely talking to the invocant at all. In that case,  
changing the topic at various points is probably going to be an  
advantage, depending on the code structure of course.

That may lead to the potential issue of calling the same thing by two  
different names ($_ and $?SELF or $self or $this or $me or whatever)  
in the same method, but that's more a question of style than anything  
else - the careful programmer will make sure it's understandable  
what's going on, while the careless programmer will make a mess no  
matter what the language lets them do.

So that's what I think anyway. Not that anybody should listen to me  
of course, but I really can't see the logic in some of the  
suggestions being thrown about here, so I thought it was prudent to  
try and head them off before my favourite unfinished language gets  
spoiled.

Re: [pugs]weird thing with say ++$

[Matthew Walton]

> On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote:

> It certainly makes more sense to me that the answer would be 2 2.  But
> however it ends up, so long as we know what the answer will be, we can
> utilize it effectively in our programs.

The trick with this construct usually in C is that the C standard doesn't
specify the order of evaluation of function arguments, so you can never be
sure if you'll get the same result if you compile it other than on your
development system (different compilers may evaluate them in a different
order). The Pugs example given in the original post seems to me to be
fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as
far as I can tell, shows left-to-right for the first case and
right-to-left for the second case, which is just odd... please correct me
if I'm wrong, but that seems the only way those answers could have been
arrived at.
So really, what needs to be said is how Perl 6 is supposed to evaluate the
arguments to function calls, then we can know if the current behaviour in
Pugs is correct.

Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?

[Matthew Walton]

> 
> even sillier question:
> if <[a.z]> matches "a", "." and "z"
> and <[a...]> matches all characters from "a" including (for some
> definition of 'all')
>
> how will be range \x21 .. \x2e written?
> <[!..\.]>? (i.e. "." escaped?)
> 

I was assuming from Larry's mail that <[a...]> would parse as either:

  1) a character class containing the range from 'a' to '.' (what that
  means is a bit mind-bending for a friday afternoon)  2) a character class 
containing 'a' then a range from '.' to... oh, an
  error
Which way might be ambiguous, but could of course be defined in the
grammar. It hadn't occurred to me that ... for the range to infinity would
be allowed or useful here. I suppose it could just mean 'up to the end of
the available codepoints'.
I do love the idea of <[a..f]> type ranges though. It's just what the
three dots mean that's got me confused.

Re: Junctive puzzles.

[Matthew Walton]

Matt Fowles wrote:
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside that
junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).

Soemtimes, although frequently I will check for preconditions at the
begining of a function. After I finished checking for them, I expect
to be able to do stuff assuming them without anyworry of exceptions or
anything else.  In these cases I am using conditionals to filter
input, which I imagine is a fairly common case...
Yes, it is fairly common, but I don't think it's common enough to attach 
unexpected side-effects to innocent-seeming functions. If I want to 
modify a junction to contain only values which satisfy a given 
precondition, I'll be wanting to use something which states that explicitly.

Which reminds me that I'm not very aware of anything which can decompose 
a junction once it's been created, which would be fairly necessary for 
doing that sort of thing. If you can turn junctions into lists then 
precondition filtering isn't bad at all. Something like

my $filtered = any($junction.list().grep({ satisfies_precondition }));
Of course, I just invented that out of nothing so I may be way off base. 
I haven't found anything in any Apocalypse or Synopsis which says if you 
can do things like this, but if Perl itself can pick junctions apart, we 
should be able to as well.

My approach to this comes somewhat from my basis in liking Haskell a lot 
and thus wanting to keep unusual side-effects to a minimum. However, if 
junctions collapse and modify themselves as was in your example, what 
happens when you don't want to have them collapse? Do you have to 
explicitly make copies?

Re: Junctive puzzles.

[Matthew Walton]

Matt Fowles wrote:
All~
On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:

Well, we see the same kind of thing with standard interval arithmetic:
  (-1, 1) * (-1, 1) = (-1, 1)
  (-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse.  You'll note the same semantics don't arise in
Quantum::Entanglement (when you set the "try to be true" option).
But you can force a collapse like this:
  my $x = 4 < $j;
  if $j < 2 { say "never executed" }

By which I mean:
  my $x = 4 < $j;
  if $x < 2 { say "never executed" }

Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
is a boolean, unless < returns a magical object... in which case, the
magical part of $x ought to be a reference to the original $j, no?

I'm wonding if we should allow a method that returns a junction that is
allowed to collapse the original:
  if 4 < $j.collapse and $j.collapse < 2 {
  say "never executed";
  }
But that's probably not a good idea, just by looking at the
implementation complexity of Quantum::Entanglement.  People will just
have to learn that junctions don't obey ordering laws.

Well, I suspect that junctions will have to be references and just
collapse every time. Observe:
my $x = any(1, 2, 3, 4, 5);
print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
This only works if $x collapses. Same for matching junctioned strings:
my $a = any ();
print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
(perhaps I meant to use ~~, I don't quite remember :) )
Either way, autocollapsing juntions is a Good Thing IMHO, and the only
remaining confusion (to go back to my initial post) is that the only
case that doesn't work is when you instance a junction twice as a pair
of same literals:
print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
Hope I'm making sense. Been a hard day at work. ;)

What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to find that 
calling is_prime($x) modifies the value of $x despite it being a very 
simple test operation which appears to have no side effects?

As far as I can see it, in the example, it's perfectly logical for 
is_prime($x), is_even($x) and $x > 2 to all be true, because an any() 
junction was used. If an all() junction was used it would be quite a 
different matter of course, but I would see is_prime() called on an 
any() junction as returning true the moment it finds a value inside that 
junction which is prime. It doesn't need to change $x at all.

In a way, you're sort of asking 'has $x got something that has the 
characteristics of a prime number?' and of course, $x has - several of 
them, in fact (but the count is not important).

Re: Pop a Hash?

[Matthew Walton]

Rod Adams wrote:
Does
($k, $v) <== pop %hash;
or
($k, $v) <== %hash.pop;
make sense to anyone except me?
Makes sense to me. Although I would be more inclined to think of pop as 
returning a pair - but does a pair in list context turn into a list of 
key, value? If so then the above makes lots of sense.

Since we now have an explicit concept of pairs, one could consider a 
hash to be nothing but an unordered (but well indexed) list of pairs. 
So, C<< pop %hash >> would be a lot like C<< each >>, except, of course, 
that it deletes the pair at the same time.
The only thing people might not be too pleased about is that the order 
is entirely at the whim of the internal implementation of hashes. I 
suppose you could say %hash.sort.pop(), but that would probably re-sort 
every time and that's clearly not desirable. Working on a sorted copy is 
also not particularly pleasant as memory could be a considerable problem.

If we do that, I'd also want to be able to
push %x, %y;
which would mean something like:
%x{%y.keys} <== %y{%y.keys};
but be much easier to read.
Yes, I'd like that. I find myself wanting to do things like that quite a 
lot in Perl 5.

Re: Perl 6 Summary for 2005-01-31 through 2004-02-8

[Matthew Walton]

Michele Dondi wrote:
On Tue, 8 Feb 2005, Matt Fowles wrote:
  pipe dreams
   Juerd wondered if he could mix = and ==> in a sane way. The answer
   appears to be no. Once you bring in ==> you should stick with it.

Huh?!? It doesn't seem to me that the answer is 'no'. In fact C<< ==> >> 
is supposed to be yet another operator, albeit somewhat a special one. 
If I got it right the answer is actually 'yes': what Larry suggested is 
that it would be _stylistically_ better to stick with it once it is used 
in the first place.
It was also a matter of precedence, as = binds more tightly than ==> so 
extra brackets would be required, leading to ==> being neater if you 
only use it in conjunction with other ==>. Which I rather liked.

Re: CLI signature?

[Matthew Walton]

Juerd wrote:
This probably goes against everything a shell based platform wants, but
would it be possible to give the program a sub-like signature?
I ask this after another painful session of forgetting how things
work, reading Getopt::Long's documentation.
signature (
Rule  $pattern,
bool +$help:short('h'),
Int  +$verbose :short('v'),
Str  [EMAIL PROTECTED] = <->
);
With GNU-like parsing, this'd make

@*ARGS = < foo|bar --verbose 2 first second third >;
@*ARGS = < foo|bar -vv first second third >;

result in the lexical variables
$pattern = rx/foo|bar/;
$help= false;
$verbose = 2;
@files   = < first second third >;
and
@*ARGS = < foo -- -v --verbose --help forth fifth sixth >;
in
$pattern = rx/foo/;
$help= false;
$verbose = undef;
@files   = < -v --verbose --help forth fifth sixth >;
and 

@*ARGS = < pattern >
in

$pattern = rx/pattern/;
$help= false;
$verbose = undef;
@files   = ('-');

Probably a macro can handle this, but does (will) Perl parse a
signature-like argument list and hand the macro something it can use, or
would this require source-filter like trickery?
Would this actually be any better than the interface provided by 
Getopt::Long? I suspect that it's possible, and I also suspect that 
Getopt::Long can be written in a much friendlier manner for Perl 6 (not 
that I have any particular complaints about how it handles things now, 
but it can certainly be better).

I do feel that command-line option parsing should not be built into the 
language though - let modules take care of it, then we'll never have to 
worry about pushing some built-in mechanism aside when we want to do 
something peculiar.

What you want may well be possible with a module though - or something 
similar to it.

Re: Making control variables local in a loop statement

[Matthew Walton]

Austin Hastings wrote:
David Storrs wrote:
On Thu, Jan 13, 2005 at 07:35:19PM -0500, Joe Gottman wrote:
 

  In Perl5,  given code like
   for (my $n = 0; $n < 10; ++$n) {.}
the control variable $n will be local to the for loop.  In the 
equivalent
Perl6 code
  loop my $n = 0; $n < 10; ++$n {.}

$n will not be local to the loop but will instead persist until the 
end of
enclosing block.

Actually, I consider this a good thing.  There are lots of times when
I would LIKE my loop variable to persist and, in order to get that, I
need to do the following:
my $n;
for ($n=0; $n<10; ++$n) {...}
...do stuff with $n...
It's a minor ugliness, but it itches at me.  Under the new Perl6
rules, I can easily have it either way. 
  {for (my $n=0; $n<10; ++$n) {...}}   # Local to loop
   for (my $n=0; $n<10; ++$n) {...}# Persistent

--Dks
 

But there's no clean way to make some of them temporary and some 
persistent.

This seems like a legitimate place for "saying what you intend", viz:
for (my $n is longlasting = 0, $m = 1; ...) {...}
Albeit that's a lame example of how to do it.
What's not clean about
{
  loop my $n = 0; $n < 10; $n++ {
...
  }
}
? Works fine for me, shows the scope boundaries very clearly indeed, 
just the kind of thing a lot of languages are missing, IMO.

Of course, this example's really bad because it's much better written
for 0..9 {
  ...
}
In which case I assume that it only clobbers the topic inside the block, 
not outside it, as it's somewhat like

for 0..9 -> $_ {
  ...
}
To write it explicitly. Or am I barking up the wrong tree completely?

Re: iterators and functions (and lists)

[Matthew Walton]

Michele Dondi wrote:
On Sun, 5 Dec 2004, Matthew Walton wrote:
At least we had the sense to call them subroutines instead of functions.
Of course, that also upset the mathematicians, who wanted to call them
functions anyway.  Go figure.

That might be because the mathematicians haven't heard of a variant of 
a function which is allowed to have side effects yet.

More or less BS for, from the point of view of a mathematitian (i.e. 
from the point of view of Mathematics), you still have "true functions", 
they're either not just the *same* function each time, or the same 
function with some arguments/parameters set to different values (that in 
the implementation are passed implicitly rather than explicitly), which 
are fundamentally the same thing after all (up to an isomorphism, that is).
I wasn't intending to be taken seriously with that comment. I hope 
everyone realised that...

Re: S05 question

[Matthew Walton]

Larry Wall wrote:
I'm still thinking about what «...» might mean, if anything.  Bonus points
for interpolative and/or word-splitty.
I'm perhaps not being entirely serious, but if you want something 
word-splitty and interpolative, how about this (which may cause unwanted 
physiological side effects, I disclaim all responsibility)

«word ws word ws number»
which would mean

but with less typing, depending on how many keystrokes it takes to 
produce « and » on your keyboard, and how much you put in it.

As far as interpolation goes, it would have to treat
«word ws $foo ws number»
As
  <$foo>  
assuming, that is, that <$foo> would take the value of $foo and use it 
as the name of the rule to match against, rather than taking the 
contents of $foo and using it as the rule. Or perhaps that's the better 
way round, if $foo is a regexp/rule object thingy (not quite sure how 
they work for us in Perl 6, can I say my $foo = rule { \d+ }; and expect 
something sane?). Perhaps it treats it as a name if it contains a string 
and a rule if it contains a rule.

Of course, it then begs the question about

if we're thinking of parallels with qw//-like constructs, which I 
certainly am. I'm not quite sure what that would do, as it collides 
slightly with the existing rule match syntax (which I quite like), and 
thus it may already have a meaning.

Perhaps I've gone completely barmy; I throw it open for your decision, 
good p6lers.

Re: iterators and functions (and lists)

[Matthew Walton]

Larry Wall wrote:
On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote:
: I'm sorry, but from a C++ background, overriding postcircumfix:<( )> 
: feels far more natural to me than setting 'is default' on some method. 

That only works for disambiguation if you know which .() to call in
the first place.  It seems likely that that .() maps straight to MMD
and doesn't look for a singly dispatched .() at all.  But maybe I'm
just not understanding this.
No, that makes sense.
What you're talking about
already sounds suspiciously like Aspect Oriented Programming.
I wouldn't know, I've never looked into it. Perhaps I should...
Any foo() can return a list.  That list can be a Lazy list.  So the
ordinary return can say:
return 0...;
to return an infinite list, or even
return 0..., 0...;
to return a surreal list.  Either of those may be bound to an array
as its "generator of missing values".  Assignment sort of implies
copying, but I'm just saying that the copier could also be smart
at least about infinities or indefinities (ohh, a cool new word),
even if it flattens everything else.
That would be good. It would be nice to be able to copy infinite lists 
without having to flatten them first.

An object can play the Undef role.  Or maybe undef can play Ref role.
In any event, since a string is an object, the answer is "Yes, but
an unthrown Exception object that can stringify would be better..."
I'll take either for now. I suspect an unthrown Exception will turn out 
to be the better solution, as it sounds much more useful. Except that 
I'm not quite sure how you'd notice it - I assume unthrown Exceptions 
would be expected to return false in Boolean context?

Next thing you'll be telling me is that all this partially evaluated
code shouldn't have any side effects.  :-)
Well of course it shouldn't. Confining all actions which have side 
effects to the IO monad makes it much easier to reason about programs 
and their behaviour.

Although I suspect anybody who tries to reason about something written 
in idiomatic Perl deserves the headache they're going to get. That 
doesn't mean I don't find Perl to be immensely fun to work with though. 
I believe Perl 6 will be even more immensely fun.

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Matthew Walton]

Austin Hastings wrote:
I'll guess that you're pointing at
 .:send_one($_);
Which supposedly uses "topic" to resolve .:send_one into $this.send_one. 
If that works, then I'm happy -- I like being able to control topic and 
$_ differently. But if C changes topic, then what?

OUTER::.:send_one($_);
Yuck.
I believe it needs to be
method send ($self: [EMAIL PROTECTED]) {
$self.:send_one("BEGIN");
for @data {
$self.:send_one($_);
}
$self.:send_one("END");
}
While that works (I think it works anyway), its debatable if it's nice 
or not. The first and last calls to .:send_one shouldn't need the $self, 
but I put it there because if you use the $self inside the for in a 
method that short, it's nice and clear to have it outside it as well.

I suspect the original example expands the for loop into the equivalent of:
for @data -> $item {
  $item.:send_one($item);
}
And it doesn't take a $larry to figure out that this isn't going to make 
the compiler very happy, as it's most likely a violation of class access 
control, I would have thought.

So Luke, am I right?

Re: while Idiom (Was: Arglist I/O)

[Matthew Walton]

Elyse M. Grasso wrote:
But you need to process the file while you haven't reached the end yet, or 
until you reach the end. And I can't think of an occasion where I knew going 
in what the length of the file I was processing was going to be. I suppose 
foreach might make sense if you sucked in the whole file at once and then 
processed the individual lines, but I've seldom been in situations where I 
could assume it was safe to do that. (Data expands to fill the space 
available, plus 10 %... and the production data file is always bigger than 
they told you it would be.)

The same goes for database queries: you loop while the query is returning data 
or until it stops returning data.

Foreach implies to me that you want to do the same thing, or something very 
similar, to each of the things you are processing. But in handling the lines 
of a file or the records returned by a query you may in fact want to throw 
many of them away, or handle various subgroups of data in different ways.
That doesn't make any difference as far as I'm concerned. foreach (or 
for in Perl 6) implies to me that you have a list of things and you're 
going to look at each of them in turn. Whether you do the same thing to 
them or not is to my mind irrelevant, you're stepping over a list item 
by item. for is, to me, ideally suited for anything where you're looking 
at a sequence of things one at a time - reading lines from a file fits 
that perfectly.

Perhaps the reason the indeterminate length of a file doesn't bother me 
is because I'm a Haskell programmer, where everything is lazy and 
recursing over lists is about the only way to get any kind of looping at 
all. Iterating over something of indeterminate length really doesn't 
bother me :-)

Something like the C++y
while(!in.eof()) {
...
}
Is attractive in its way, but I'd rather have something more convenient, 
and I think doing a for over a conceptual list (as in it's not really a 
list, but it's behaving kind of like one in this context) of lines in 
the file is infinitely better.

One can also view the results of a database query as a list of rows 
returned which you then look at one at a time. In fact, I find that far 
more natural than fetching until there are none left.

Of course, you're still really doing that behind the scenes.

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Matthew Walton]

Luke Palmer wrote:
The remaining problem is what to do about unary dot.  Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (&oper) {
&oper($.left);
&oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (&oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using &oper on the elems anymore.
method perform (&oper) {
  for @.elems {
&oper($_);
  }
}
But I don't think that was the mistake you were talking about. And I 
don't see what it has to do with unary dot either, because you don't 
need to use unary dot to implement that method. Unless each member of 
@.elems is a Duple, in which case the class isn't one I'd call Tuple.

Sorry, nitpicking level seems to be set to 9 at the moment. What did you 
mean?

Re: iterators and functions (and lists)

[Matthew Walton]

Larry Wall wrote:
: of course, that analogy isn't going to work for "true" functions, which  
: returns the same all the time, for some given set of arguments.

Oh, well, we pissed off the mathematicians long ago.  :-)
At least we had the sense to call them subroutines instead of functions.
Of course, that also upset the mathematicians, who wanted to call them
functions anyway.  Go figure.
That might be because the mathematicians haven't heard of a variant of a 
function which is allowed to have side effects yet.

Thank goodness the functional programming people have, otherwise Haskell 
would be pretty useless.

:  $fh(:chomp)
Yes, but in general I think an autochomper layer should be applied
to the handle/iterator at open/construction time, not at evaluation time.
That seems like a sensible approach. I see it as unlikely that I'm going 
to want to read a file in a mixture of chomped and not-chomped modes, so 
I'm going to want to set chomping on the filehandle. However that's done.

And if I *do* ever want to do mixed-chomping on a read, I should just 
open the file in non-chomped mode and chomp manually when I know I want 
to do it, because Perl won't be able to figure it out for me except in 
some really really weird circumstances I don't really want to be 
thinkinga bout.


: # what about making &foo( :bar ) the same as
: #  &foo.assuming( :bar) ? ah, that not gonna work.. but I
: # think that feature definitely wants something more short
: # than .assuming; maybe even some special syntactic honey.
: # because it's  fun(ny|ctional)
We made it long on purpose for readability.  You can always use a macro
to obfuscate it.  What we're *not* going to do is autocurry missing
parameters like Haskell.  That just screws up all the compiler's
expectations on return types.  If I forget to supply an argument, I
want an error, not a function pointer.  I can add in the .assuming
myself when I decide I need it.  All autocurrying does is sweep the
dirt under the carpet for someone else to deal with.
Yes, not really a Perlish thing is it? Haskell programmers cope with it 
because the entire type system explodes if you return a function instead 
of a value somewhere (by leaving out one or more arguments), but Perl's 
unlikely to do that with quite the same level of reliability, I would 
think. While I'm pleased that Perl allows me to pass functions around 
with almost the same ease as I get in Haskell, because Perl isn't a pure 
functional language, the thought of making it behave like that is quite 
scary.

: class Foo {
:   has $.counter;
:   # multi postcircumfix:<( )> makes me sick :(
Not sure it needs to be multi.  Generally a reference tells you exactly
who you're dispatching to.
:   method bar is default {
:  $.counter++;
:   }
: }
: 
: # emulating   10...
: $a = new Foo :counter(10);
: say $a.bar;
: say $a();

Probably want to handle list context as well.
I'm sorry, but from a C++ background, overriding postcircumfix:<( )> 
feels far more natural to me than setting 'is default' on some method. 
What if you do 'is default' on two methods? Compile-time error? What if 
you're opening up someone else's class and want to override the existing 
default (okay, so you shouldn't be doing that in an OOP world, but what 
if you are? What if you're like me and like Perl's delightful mishmash 
of paradigms while simultaneously liking other languages for their 
purity? What if I actually talk about something relevant?)

: # other thingies:
: 
:  sub foo { ... };
:  @array = @&foo # all the results of foo, lazily.

Don't see the need for that when
@array := foo()
does laziness implicitly already.  Maybe even
@array = foo()
maintains laziness if it sees an infinite iterator in the return
value of foo().  Or maybe it blows up and tells you to use ":="
to avoid trying to make a copy.  That's probably cleaner.
This is going to take me a while to get my head round... Does this 
particular foo() return an iterator? Or is it something which is 
iterated? Have I missed a bit of a synopsis or apocalypse which would 
make all this clear to me or are we still in handwaving mode?


Exceptions should not be used for
something so mundane as running out fo values.
Amen to that! One reason I ran screaming from Java was having to catch 
ArrayOutOfBoundsException all the time. And all those exceptions which 
the compiler forces you to catch. They're handy, but there is a limit. I 
prefer return values which can indicate if they're valid or not. undef 
is excellent for that :-)

A string pretending to be undef can be even better. Can we still do 
that? I seem to recall it being in something at some point along the way.

If that's necessary to keep the Lazy from blocking when it runs out
of values.  Just like an ordinary array, a Lazy has to be aware of
when it is out of values, and when it should call into some meta-Lazy
for more iterator values.  And I suppose that meta-Lazy could in
turn have a meta-meta-Lazy, which could have a me

Re: Angle quotes and pointy brackets

[Matthew Walton]

Juerd wrote:
Matthew Walton skribis 2004-12-01  9:55 (+):
Yes, that would be fun... almost worth throwing out a compiler warning 
for that, especially if we've still got use warnings. Something like

	Warning: «{ }» creates empty list

It should generate a warning similar to the warning of interpolating an
undefined value, but with s/undefined variable/empty list/.
Yes, that would make sense.
Because I'm sure it should be wrong to create empty circumfix operators. 

You have to admit that zero width circumfix operators would be VERY NEAT.
Well that depends... are you intending to write programs, or drive the 
world insane?

Re: Angle quotes and pointy brackets

[Matthew Walton]

Larry Wall wrote:
I thought so.
: I don't think I've ever used a hash slice in my life. Is there something 
: wrong with me?

No, a lot of people are naturally monoindexous.
I like that word.
: >* The :w splitting happens after interpolation.  So
: >
: >	« foo $bar @baz »
: >
: >	can end up with lots of words, while
: >
: >	« foo "$bar" "@baz" »
: >
: >	is guaranteed to end up with three "words".
: 
: See the comment about 'fabulouser' above and add another 'and 
: fabulouser' to the end.

I neglected to mention that the smart quoter should also recognize
pair notation and handle it.
I've been trying to get my brain round that, but I can't quite figure 
out what you mean. Pair notation is, as I understand it, when you get

key => value
to construct a pair. Assuming that's me remembering correctly, then 
where does the smart quoter have to deal with pair notation? Are you 
considering allowing something like:

« key1 => flop key2 => floop »
Which would be
hash(key1 => flop, key2 => floop);
or am I completely off my rocker? I hope I am, because that's kind of 
ugly. The only other thing I can think of is if you're just talking 
about *implementing* infix:=>, in which case just ignore the above 
because of course the autoquoter needs to recognise its left-hand-side.

As an aside, is it possible for us to define our own autoquoting 
operators? I assume it will be, but I'm feeling insecure and need 
reassurance.

I neglected to mention that we also naturally get both of:
circumfix:«< >»
circumfix:<« »>
in addition to
circumfix:{'<','>'}
circumfix:{'«','»'}
Have to be careful with
circumfix:«{ }»
though, since {...} interpolates these days.
Yes, that would be fun... almost worth throwing out a compiler warning 
for that, especially if we've still got use warnings. Something like

Warning: «{ }» creates empty list
or even
Warning: circumfix:«{ }» creates empty operator
that one could be an error in fact.
or if you're feeling really nasty
Syntax error
Because I'm sure it should be wrong to create empty circumfix operators. 
Or am I too prescriptive? My inner Haskell programmer is showing through.

Re: Angle quotes and pointy brackets

[Matthew Walton]

James Mastros wrote:
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like  
: qx:noparse 'echo $VAR' ?

I think we need two more adverbs that add the special features of qx 
and qw,
so that you could write that:

q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/

I think I'd like that much better if we consider execution and 
word-splitting to be the primary operations, and interpolation and 
noninterpolation the adverbial modifiers then the other way around, 
making that qx:q/echo $VAR/ or qx:qq/$cmd/.  OTOH, I expect backticks to 
be rare enough that I wouldn't mind writing

use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');
Much more clear, saves ` for other things, and allows for easy 
specification of the many adverbs of spawn (weather it returns the 
return status, the PID/FH set object, or output, if it waits right 
there, or runs in the background (and makes the return value lazy), if 
it replaces the current process (exec)...
I'd quite like that. Although I think spawn should be a builtin rather 
than in a module, if it was in the core, and we were getting rid of 
backticks.

Although I'm masochistic enough that I don't mind the idea of always 
having to do execution with qx//, qx:q// or qx:qq// (running with other 
suggestions, I'd guess that would be non-interpolating execution, then 
the same again more explicitly, then interpolating execution) but I do 
like the idea of spawn.

Kind of removes the idea of pulling in the output of other programs as a 
fundamental part of the language though, for that it's nice to have an 
executing, capturing quote. Perhaps an adverb to qx that makes it behave 
like system() - I don't think it'd be a good idea to provide one that 
makes it behave like exec(), although perhaps other people do.

qx:r/$cmd/
qx:s/$cmd/ # both of these give back return codes? Which one!
But then
qx:r:qq// might be messy.
Or even
qx:exitcode:interpolate//
Ouch.
This isn't very coherent, I'm just thinking out loud based on what other 
people have said that I like.

But there are some things that would be completely ambiguous:
%hash
Bracketing operator.
%hashVery long bracket operator, which quite likely has a syntax error 
directly after it.
But might not have... there's a chance that could slip through, and I 
don't like that for some reason.

: or maybe even we could see consistant to go after +<< +>> and alike, 
and  : make old < and > written as +< and +> (and then lt and gt 
suddenly could  : become ~< and ~> :)

I think people would rise up and slay us if we did that.  We're already
getting sufficiently risen up and slain over Perl 6.
Could be worse.  They could rise from the grave and eat us!
Who says they won't?
Well, yes, but sometimes the weights change over time, so it doesn't
hurt (much) to reevaluate occasionally.  But in this case, I think I
still prefer to attach the "exotic" characters to the exotic behaviors,
and leave the angles with their customary uses.
...of which they have plenty already.  Backtick has exactly one, and not 
an often-used one at that... I'm fine with axing it.  Of course, there 
are a lot more people in the world then just me.
I'm fine with it too. I use it a fair bit but I think it's important to 
have a very clear mark where you're going to an external program

Re: S13: Deep operators

[Matthew Walton]

Luke Palmer wrote:
Also, would things blow up if I specified the return types for operator 
overloads, such as

multi sub *infix:Â+Â (EvilNumber $lhs, EvilNumber $rhs) returns 
EvilNumber is deep { ... }

In that case I don't see why it would blow up.  If you said, say:
multi sub *infix:Â*Â (Vector $lhs, Vector $rhs) 
returns Num is deep
{ ... }

Then you might get into trouble if you did 

$u += $v
Or even
$u *= $v
:-)
Yes, I can see that would be a problem. Care obviously required with the 
types of operator methods as in other languages.

Would that work, would it behave strangely and what would it do to the 
definition of infix:Â+=Â which would be based on it? Is it even 
necessary? Does it give me anything? And can I overload based on return 
types?

I can't be sure, but I don't think that we're doing MMD on return types.
The most compelling reason for that is because you can get yourself into
paradoxes that way.
I didn't think we would be, as it would be hideously difficult to pick 
the right method to dispatch to, but I thought I'd check.

Thanks
Matthew

Re: First public release of grammar engine

[Matthew Walton]

William Coleda wrote:

Patrick R. Michaud wrote:
P6GE assumes that it is part of the parrot distribution in the 
F directory.   Simply type C in this directory
to build the F shared library it needs.  
cc -shared -fpic p6ge_parse.o p6ge_gen.o p6ge_parsep5.o -o p6ge.so
cc: unrecognized option `-shared'
ld: Undefined symbols:
_main
make: *** [p6ge.so] Error 1
$ uname -a
Darwin Althalus.local 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 
12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC  Power 
Macintosh powerpc

$ cc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1666)
That's Mac OS X 10.3.6 'Panther' by the way. I have no idea why GCC's 
not accepting -shared, that came as quite a shock. I'm hoping there's 
someone around who knows more about Apple's GCC on Darwin than I do, 
because my experience is largely limited to using it through XCode for 
Objective-C stuff.

Well done on getting a grammar engine going though. Things are looking 
up :-)

Re: Perl6/Parrot and Backwards Compatability

[Matthew Walton]

I suggest you read more about Parrot... it's designed to allow these 
things. There is a project (Ponie) to make Perl 5 run on Parrot, and 
there will be other languages as well - which will be able to call each 
others libraries. Making the Perl 5 libraries available to Perl 6 being 
a primary motivation. I'm not sure about how well XS will work on Ponie, 
but I assume that it will be made to work if at all possible.

Milscvaer wrote:
 
Hello,
 
 I believe it would be a very good idea and quite
essential, if Perl6 is not simply a superset of Perl5
and thus by default back compatable with Perl5, for
Parrot/Perl6 to also contain complete, 100% backwards
compatability capability with perl5 code, either in a
seperate perl5 parser distributed with perl6 or built
into the perl6 parser. Perl5 code and all of the perl5
language should be able to run on parrot with no
modifications.
 
 Furthermore, on parrot, modules written in perl 6
should be accessible
 from perl5 (forward compatability), and perl5 modules
should be
 accessible from perl6 (backward compatability). The
symbol spaces and so on
 so on for Perl5 libraries should be accessible as
well from Perl6 and
 vice versa, as they are now from one perl5 module to
another. This is
 absolutely essential since there is a very large
library of existing
 Perl5 libraries and it would be completely
unreasonable to expect
 all of these to be converted to Perl6, if such would
be required. There are
 alot of us furthermore who like the Perl5 language as
it is, quirks
 and all, and want to continue to be able to use perl5
yet also have
 access to new libraries written with perl6. perl6
programmers will
 want to have access to modules written with perl5.
Programmers should
 be able to use both perl5 and perl6 in the same
program. Those who
 like Perl5 as it is should have the freedom to be
able to continue to
 use it on Parrot and have a 100% perl5 compatable
language. 
 
 Every quirk and feature of perl5 really needs be
supported in the perl5
 support on parrot, as I code I have written really
does depend on all of them.
 
Furthermore, it is very important as well that
compatabality with the Perl5
internals and XS be maintained on Parrot/Perl6. This
is to allow Perl
modules for Perl5 to be used from Perl6 programs and
on Parrot. If Parrot internals and XS
use a different API from the Perl5 ones, then a
compatability layer must be
provided to allow Perl 5 XS programs to be compiled
and run for Parrot.

This is very important as there is a very large
library of XS modules for
Perl5 and it is totally unreasonable to require that
they all be rewritten for
Parrot to be able to be used. I know the XS interface
and the Perl5
internals can be rather ugly, and its fine if Parrot
wants to provide an
improved API, but its still important to provide a
compatability layer for 
 the old one in order to
allow compatability with existing modules and prevent
unneeded and
unreasonable amounts of work it would require, and
wasted time, to port old
modules to a new API. It would require much less work
and effort to
simply provide a compatability interface and allow
Perl5 XS modules to run
on Parrot and to be accessible from Perl6, than to
attempt to rewrite all of
the modules one would want to have access to on Perl6.
Perl5 and Perl5 XS
compatability will furthermore prevent the
fragmentation of the Perl
community into Perl5 and Perl6 camps, by assuring that
Perl5 modules can be
loaded from Perl6 and vice versa. It also assures that
the rich selection of
modules and packages avialable for Perl5 will be
immediately and instantly
avialable from Perl6, thus continueing the inertia
generated by Perl5 into
Perl6.It allows Perl5 programs to as well benefit from
new Perl6 modules, so both Perl5 and Perl6 can be a
part of the same community rather than being fractured
off into seperate communities.

One reason I use Perl is the vast collection of
modules avialable from CPAN and the choice in modules.
Perl needs to preserve avialability of all of these
modules. Remember that a module, or any feature, that
is useless to one person is essential to another
person. 

Running the old Perl5 interpretor and the Parrot in
the same process is not
a great solution, since this would mean that there
would be two completely
seperate interpretor codebases to support. A big part 
of Parrot is to allow several
languages to use the same interpretor, thus allowing
them all to benefit
from the same solid foundation. It would be quite
ridiculous if Perl did not completely support a past
version of itself on Parrot given we are writing
parsers for numerous other languages for Parrot (a
good idea, indeed, but lets make sure Perl5 has a
Parrot parser too).

I urge complete 100% Perl5 support including XS and
internals to be included
with Parrot.
 This would seem to be a pretty natural feature for
Parrot, which is
 designed to host several language and should also be
extended to other
 languages Parrot supports, why not al

Re: Perl 6 Summary for 2004-10-01 through 2004-10-17

[Matthew Walton]

Larry Wall wrote:
On Tue, Oct 19, 2004 at 09:35:27PM +0100, Matthew Walton wrote:
: Austin Hastings wrote:
: >Does this mean that we're done?   :)
: 
: No, it means Larry's about to stun us with something seemingly bizarre 
: and inexplicable which turns out to be a stroke of genius.

The only bizarre and inexplicable thing that has occurred to me in the
last week is that I fell into a canal in Venice.  It was definitely
somewhat stunning, but I have yet to figure out how to view it as
a stroke of genius.  I suppose if I were Archimedes I'd have climbed
back out and shouted "Eureka", but as far as I know Archimedes never
made it to Italy, so it didn't occur to me...
That's not what I was thinking of.
Also, climbing back out and shouting 'Eureka' would only really be 
appropriate if you actually had experienced a moment of revelation about 
something. I suspect you were too busy with the not drowning part for that.

Youch, anyway.

Re: Perl 6 Summary for 2004-10-01 through 2004-10-17

[Matthew Walton]

Austin Hastings wrote:
Michele Dondi wrote:
On Sun, 17 Oct 2004, Matt Fowles wrote:
Google groups has nothing for Perl6.language between October 2 and 14.
Is this really the case?  (I had not signed up until shortly before

Yes: no traffic at all for quite a while...

Does this mean that we're done?   :)
No, it means Larry's about to stun us with something seemingly bizarre 
and inexplicable which turns out to be a stroke of genius.

At least, I hope that's the case. Life's been so dull lately I've even 
applied to do a PhD.

Re: A..Z alternatives

[Matthew Walton]

Andrew Rodland wrote:
On Tuesday 21 September 2004 07:18 pm, Thomas A. Boyer wrote:
Larry Wall wrote:
Somebody needs to talk me out of using A..Z for the simple cases.
Larry
[ <> for array dimension placeholder ]
That might confuse users of languages that were not
C-syntax-influenced,  who think that '*<>*' means "not equal". But
surely old Modula hacks like me are in a minority in the Perl world (and
Pascal programmers would never do Perl, would they? Algol, anybody?) So
maybe I'm the only one who runs the risk of that particular confusion. :-)

What about BASIC? Aren't all the little kids today raised on BASIC? :)
Only if their parents are evil...
I was raised on BASIC and look what happened - now I'm writing Perl Quiz 
of the Week solutions in Haskell!

Re: Synopsis 9 draft 1

[Matthew Walton]

Michele Dondi wrote:
On Thu, 2 Sep 2004, Larry Wall wrote:

To declare a multidimensional array, you add a shape parameter:
   my num @nums is shape(3);   # one dimension, @nums[0..2]
   my int @ints is shape(4;2); # two dimensions, @ints[0..3; 0..1]

Just a random thought, and probably a minor point: I know that there 
already so many keywords, but if not already taken, could C be 
introduced as a synonim for C to be freely used where it would "fit" 
better? Especially in constructs like

  my num @data is Stuff has shape(4;2);
C is already used to give classes attributes...
class Thing {
  has @.fingers;
  has $.mysteriousness;
}
I wouldn't be surprised if it does run-time attribute addition to 
objects as well, but I can't recall seeing that anywhere and haven't got 
time to look right now. Even if it doesn't, it would, I think, be a 
mistake to overload it in this way.

Re: Return with no expression

[Matthew Walton]

Alexey Trofimenko wrote:
On Fri, 20 Aug 2004 09:21:02 +0100, Matthew Walton  
<[EMAIL PROTECTED]> wrote:

On 19 Aug 2004, at 18:04, Luke Palmer wrote:

[...]
my $num = $param == 0 ?? 0 : rand $param;

my $num = $param == 0 ?? 0 :: rand $param;
surely?
a little off theme.. I wanna ask, could be there in perl6 any 
difficulties  with recognizing C<::> as part of C<... ?? ... :: ...> and 
C<::> as  "module sigil"? Does it involve some DWIM? Would we have 
mandatory space  after C ?
I didn't get perl6 syntax well yet, so if it's true, you can give 
better  examples yourself..
I doubt that's a problem, as C<::> as part of the ternary operator is 
only going to be found where an operator is expected, and C<::> as part 
of a module name is only going to be found where an identifier is 
expected, so it's a matter of looking for different things in different 
places, I suspect.

And if this message comes out with strange and stranger formatting, 
that's because Thunderbird's doing some very odd things in the compose 
window and I'm not entirely sure how it's going to come out.

Re: Instantiation

[Matthew Walton]

Aaron Sherman wrote:
I was thinking about the case where you use a module, only to define a
class that you then instantiate like this:
use Some::Module::That::Defines::A::Class;
our Some::Module::That::Defines::A::Class $foo := new;
and I keep thinking that that's too redundant. It's not so much that I
want to syntax-golf it down, but there's just no reason to throw that
type around twice, when what you really WANT to say is "that module over
there is a class, instantiate me one."
So, I was wondering about a synonym, like:
	uses Some::Module::That::Defines::A::Class $foo;
syntax will be awful and there are a lot of guesses, but:
macro uses($class, $var) is parsed(/() ()/) {
  use $class;
  our $class $var;
}
I suspect. It's probably not quite that simple, but I figured it was 
worth a shot. Hopefully the compiler would run through the result of the 
macro, parse it and compile it as normal so the C would actually work.

Okay okay, I just got a copy of Perl 6 and Parrot Essentials and I'm 
trying to learn stuff. I'm even ripping apart the compiler I wrote for 
my BSc final-year project so it generates working PIR instead of broken C.

Re: A thought for later -- POD tables

[Matthew Walton]

Aaron Sherman wrote:

=table C<$_> | C<$x>  | Type of Match Implied | Matching Code
=row   Any   | CodeC<< <$> >> | scalar sub truth  | match if 
C<$x($_)>
 

That's (the above comments aside) the same thing, and as I said when 
Luke suggested it, it seems fine if that's the way we'd prefer to go. I 
do want to make sure that there's some way to associate a caption, 
though. HTML doesn't have a real caption concept, but many markup 
languages do.
Yes it does. There's a  element for tables in HTML 4.01/XHTML 1:
http://www.w3.org/TR/html4/struct/tables.html#h-11.2.2
Is the general consensus,then, that an C<=>-introduced form would be 
better? I do agree that we don't want the capability to nest tables, as 
that DOES break POD down into a presentation system, which it was never 
meant to be. So perhaps the balanced syntax is too misleading there.
I like the =table =row form. Sufficient syntax for laying out simple 
tables without letting people do silly things.

Re: Return with no expression

[Matthew Walton]

Larry Wall wrote:
On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote:
: It would be nice if rand behaved a bit more sanely in Perl 6. I can 
: understand the reasoning for making rand 0 produce between 0 and 1, but 
: that doesn't mean I have to like it.

What makes you think there was any "reasoning" involved?  As far
as I can recall, it was entirely due to random factors.  :-)
Sush, I'm giving you credit from pure blind faith here ;-)
I suspect there's an argument that [0,0) ought to be considered undef
(which would conveniently numerify to 0 with an optional warning).
In the absence of a paradox value, undef would be fine there I think :-)

Re: Return with no expression

[Matthew Walton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 Aug 2004, at 18:04, Luke Palmer wrote:
The one in Perl 5 that stands out most was the cause for the only patch
I ever sent to p5p: the rand function.  "rand $x" will give you a
uniformly distributed random number in [0, $x) for any $x EXCEPT 0.  If
you say "rand 0", it gives you a random number between 0 and 1, which
was supposed to be What I Meant.  That led to code like this (Perl6ized
as usual):
my $num = $param == 0 ?? 0 : rand $param;
my $num = $param == 0 ?? 0 :: rand $param;
surely?
Repeating the test that it did itself, just to get consistent behavior.
We must be careful not to repeat mistakes like this in the design of
Perl 6 [1].
It would be nice if rand behaved a bit more sanely in Perl 6. I can 
understand the reasoning for making rand 0 produce between 0 and 1, but 
that doesn't mean I have to like it. If that behaviour is required, 
then rand undef; would behave as expected (call with no parameters to 
get [0, 1), with one param to get [0, $param) ), but really if you want 
a random number between 0 and 1 why aren't you calling rand 1?

Feels like a Cism. Ick.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFBJbRx0UvYjCBpIlARAjV2AJ0TSuchOHcVMqg3HUPLJ6G5zhnRYwCfQ/26
C6DCRHq0BjxqX4eH5vUeWwk=
=ctmb
-END PGP SIGNATURE-

Re: Mailing list archives

[Matthew Walton]

Joe Gottman wrote:
   There's something wrong with the mailing list archives at
http://dev.perl.org/perl6/lists/.  I can get to this page OK, but when I
click on a link to the perl6-internals or perl6-language archives, I get a
"This page cannot be displayed" error.
The perl.org list server's been having some fairly serious trouble, 
according to what I read on Planet Perl. That would probably also 
explain why the list has been so quiet lately.

Re: xx and re-running

[Matthew Walton]

Larry Wall wrote:
The rand function may be a bad example, since it's by nature a
generator, and you should maybe have to work harder to get a single
value out of it.  We haven't really said what <$fh> xx 100 should do,
for instance.  I guess the real question is whether xx supplies a
list context to its left argument (and whether rand pays attention
to list context).  These might produce very different results:
@foo = (rand);
@bar = (+rand);
On the other hand, history has rand producing a scalar, so arguably we
should stick with that.
One supposes that it's not entirely unreasonable to have rand in list 
context produce an infinite (lazy) list of random numbers, successively 
drawn from the generator.

The results of
@foo = *(rand);
(if the syntax is right) in that case would of course be in the 'enough 
rope to hang yourself' category. But it might be handy to be able to say

my ($rand1, $rand2, $rand3) = (rand)[4..6];
although I'm sure some would argue that this is needlessly obfuscated, 
and that

my ($rand1, $rand2, $rand3) = (rand, rand, rand);
would be better. Maybe it would.
This random thought was brought to you by the demons of lunchtime idleness.

Re: definitions of truth

[Matthew Walton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Hodges wrote:
| --- Luke Palmer <[EMAIL PROTECTED]> wrote:
|
|>Paul Hodges writes:
|>
|>>So, in P6:
|>>
|>>  if 0 { print "0\n"; } # I assume this won't print.
|>>  if '0'   { print "'0'\n";   } # I assume this won't print.
|>>  if ''{ print "''\n";} # I assume this won't print.
|>>  if undef { print "undef\n"; } # I assume this won't print.
|>>
|>>But my question is, will this:
|>>
|>>  if "\0" { print null\n"; } # Is this going to print, or not?
|>
|>As far as things are currently defined, yes, it will print.  And your
|>syntax is perfect... well, maybe not:
|>
|>if undef { print "undef\n"; }
|>
|>Might be interpreted as:
|>
|>if undef( { print "undef\n"; } ) # syntax error, expecting {
|>
|>But close enough anyway.
|
|
| Maybe I should have been more specific:
|
|   if undef() { whatever(); }
|
| But it's a moot point, since only a moron would test what he knowks the
| answer to -- unless it's one of those wierd cases, and then he could
| just use 0 instead..
|
| So, putting it back into the context of real things.
|
|
|>If you must check for a null byte, it's as simple as:
|>
|>unless $chr { print "0, '', or '0' }
|>unless ord $chr { print "null byte" }
|
|
| So a null byte is still Boolean true.
| Ugh, yarf, ack, etc.
|
| But as long as I know -- easy enough to check explicitly.
|
| But just tell me thisam I the only guy who thinks this *feels*
| wierd? Understanding the reason doesn't make it any more ~comfortable~.
I think it feels fine. The weirdness comes from the difference between
string context and numeric context I think - like with '0' being false
and '0.0' being true in string context, but if you converted them both
to numbers they'd both be false.
This is why Perl 6's explicit typing will be such a Good Thing.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2/4E0UvYjCBpIlARAor4AKCjsHZBmLqnKwDt2kMINwAS0ZMBFQCeIup3
20Jlgv0D/WQt+sRjHhGuAbQ=
=Tl+q
-END PGP SIGNATURE-

Re: user-defined operators?

[Matthew Walton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Larry Wall wrote:
| Same in Perl 6.  For instance, to call the binary addition operator
| C<< $a + $b >> by its "true name", you'd say C<< infix:+($a,$b) >>.
| When you define an operator, you always use the "true name" form.
I immediately start to feel very stupid, because I've definitely read
the Apocalypse about this.
| And here we see a weakness of Haskell's approach: you need to know
| the numeric precedence level.  In Perl 6, all precedence levels
| are defined relative to existing operators.  You don't have to care
| about the numeric level, and in fact, the actual precedence levels are
| probably encoded with strings internally rather than numbers, because
| that makes it trivial to add an arbitrary number of precedence levels
| between any other two precedence levels without having to resequence.
| Precedence levels are a bit like surreal numbers in that respect.
| But the user doesn't have to know that...
Yes, numeric precedence levels aren't really such a great idea. I
suppose one could have floating-point ones, but then you get precendence
levels like 2.56728, and things get even more confusing. The Perl 6 way
sounds a lot better.
| : Wrangling this back to some sort of on-topicness, it would be great if
| : Perl could have user-defined operators that actually work properly. I'm
| : thinking new operator characters (Unicode's got lots left),
|
| Gee, I'm thinking the same thing.  Fancy that.  'Course, the fact
| that I already said as much in the Apocalypses could have something
| to do with it.  :-)
Probably. My small brain isn't capable of remembering everything in the
Apocalypses, they're just too exciting ;-)
| : and also the
| : ability to define short-circuit operators like C's && and || (I can't
| : remember what they've become in Perl 6, did they change? I seem to
| : remember them changing). Not being able to do this is a major weakness
| : in C++'s operator overloading, because it effectively means that && and
| : || are untouchable unless you really want to mess with other people's
| : heads, and demonstrate the only point operator overloading has against
| : it (that is the potential disruption of expected semantics; this is all
| : IMO of course).
|
| Well, any operator or function that knows how to call a closure can
| function as a short-circuit operator.  The built-in short-circuit
| operators are a bit special insofar as they're a kind of macro that
| treats the right side as an implicit closure without you having to
| put braces around it.  No reason in principle you couldn't write your
| own infix macro to do the same thing.
|
| : So can we at least have the ability to define short-circuit operators,
| : even if we can't define new ones?
|
| Already there.  You can even define new short-circuit operators.
| The new ones can even be Unicode operators, if you're willing to go
| into hiding for the next five years or so till most everyone learns
| how to type Unicode.  Alternately, be willing to stare down the
| occasional lynch mob...
|
| On the other hand, we've tried to make it trivially easy to defer
| evaluation of a chunk of code.  All you have to do is slap some
| curlies around it.
Fabulous. That's exactly what I wanted to hear :-) I thought it might be
something to do with passing closures around, as it seems pretty much
the only way to accomplish it anyway without altering things already
laid down which are Good Things.
I'm a very happy man now Larry. Thankyou.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2+ig0UvYjCBpIlARAo5pAKCNNZbWWWBKK+FNNXmntxFmBlq1kACfb+E4
T5cBANE6a2kDZ0QwcAA8aqs=
=pObn
-END PGP SIGNATURE-

Re: user-defined operators?

[Matthew Walton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michele Dondi wrote:
| I don't know if this is already provided by current specifications, but
| since I know of Perl6 that is will support quite a powerful system of
| function prototyping ("signatures"?), I wonder wether it will be possible
| to specify a (finite number of) argument(s) on the left of functions, thus
| allowing to create user-defined operators. I had tried sml (a functional
| language) and despite its being really simple if compared to Perl, it
| provided this functionality...
If SML is anything like Haskell, user-defined operators are really just
syntactic sugar around normal function definitions, with appropriate
allowances in the grammar for arbitrary operators to exist and be parsed
correctly.
Haskell also has an interesting backticks operator, which turns any
two-argument function into an infix operator, and is generally used for
readability purposes. Thus, although you can do modulus with the 'mod'
function like this:
mod 3 4
you can also write
3 `mod` 4
which can be handy when trying to get an arithmetic-type feel to your
programs. I doubt Perl would need something like this though. Haskell of
course also lets you do things like
infixr 3 +++
which defines a right-associative infix operator at precedence level 3,
denoted by the token '+++'
and later you can say something like
(+++) :: Num a => a -> a -> a
x +++ y = x + y
which defines the +++ operator to have exactly the same effect as +
(although probably with different precedence, I have no idea what the
numeric precedence level of + is in Haskell, and indeed if + is right or
left associative, as I always get those two muddled up, so that might be
different too) when applied to numbers. Pretty pointless really, unless
you wanted a tight-binding + or a backwards one, but you get the idea.
Most combinator parsing libraries use user-defined operators to denote
parser combination and choice, and GUI libraries tend to use them to
denote things like signal connection, property setting and so forth.
Wrangling this back to some sort of on-topicness, it would be great if
Perl could have user-defined operators that actually work properly. I'm
thinking new operator characters (Unicode's got lots left), and also the
ability to define short-circuit operators like C's && and || (I can't
remember what they've become in Perl 6, did they change? I seem to
remember them changing). Not being able to do this is a major weakness
in C++'s operator overloading, because it effectively means that && and
|| are untouchable unless you really want to mess with other people's
heads, and demonstrate the only point operator overloading has against
it (that is the potential disruption of expected semantics; this is all
IMO of course).
So can we at least have the ability to define short-circuit operators,
even if we can't define new ones?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2rP20UvYjCBpIlARAsFKAJoCBjgP8+wmbQP3XO1HLD+6AC43DQCfVvj3
kTT9cYnblCADyVCWCrpcpD0=
=G7FE
-END PGP SIGNATURE-

Re: Semantics of vector operations (Damian)

[Matthew Walton]

Mark J. Reed wrote:
On 2004-06-14 at 22:58:58, Matthew Walton wrote:
'it would be better to explicitly just say
(@list.grep value) = undef
although I think that might be supposed to be
(@list.grep value) »= undef;

Those do different things according to my understanding.  The first
removes all matching items from the list; the second replaces the 
matching items with undef.

e.g. (please forgive any Perl6 syntax errors):
[1,2,3,4,5].grep { $_ % 2 } = undef
results in the list
[2,4]
while
[1,2,3,4,5].grep { $_ % 2 } »= undef
results in the list
	[undef, 2, undef, 4, undef]
That's a very good point, and seems rather likely. I wasn't thinking of 
it that way. Quite cunning really.

Re: Semantics of vector operations (Damian)

[Matthew Walton]

Austin Hastings wrote:
Perhaps we could consider the junctive lvalues as a sort of implied 
?= operation:

   junction(@list) = value
means
  
   unless junction(@list) == value
   {
 given junction {
 when 'none' { (@list.grep value) = undef; }
 when 'any'  { for 0 .. random(@list) { @list[random(@list)] =
undef; } }
 when 'one'  { @list[random(@list)] = undef; }
 when 'all'  { @list = $(@list) x undef; }
 }
   }

(which would make for some interesting use cases around 'any', at least
;-)
This is extremely scary. The thought of anybody actually using 'any' in 
their code is... umm... well, let's just say the Haskell programmer me 
is curling up in fright and screaming his head off, because the idea is 
entirely abhorrent to him. Gadget Matthew says it's a substanceless 
'wow' feature. Both are also skeptical about 'one', and my psychiatrist 
is rattling pill bottles.

'none' could be useful, but it would be better to explicitly just say
(@list.grep value) = undef
although I think that might be supposed to be
(@list.grep value) »= undef;
as shouldn't list.grep return a list of matches? Which we assume are 
aliases to the original elements.

I'm with Damian. TMTOWTDI yes, but there's a line between 'nice to have 
the alternative' and 'silly'.

Oh, and the example appears to have forgotten that only 'none' should be 
assigning undef, the rest should be assigning value - shouldn't they? I 
think they should, otherwise it doesn't make any sense at all. Or 
perhaps it does, and I need to go to bed.

Ciao.

Re: Apocalypse 6: IDs of subroutine wrappers should be objects

[Matthew Walton]

Ingo Blechschmidt wrote:
Hello,
quoting Apocalypse 6:
You may ask a subroutine to wrap itself up in another subroutine in
place, so that calls to the original are intercepted and interpreted by
the wrapper, even if access is only through the reference:
   $id = $subref.wrap({
   # preprocessing here
   call;
   # postprocessing here
   }
[...]
The $id is useful for removing a particular wrapper:
  $subref.unwrap($id);

One should be able to unwrap $subref using
 $id.unwrap();
Something tells me that you shouldn't be able to do that. Wrapping is an 
operation on the subref, which implies very strongly to me that 
unwrapping should also be an action on the subref.

Or, given $id, it'd be cool if you could get the original $subref:
 my $origsubref = $id.sub();
Additionally, $id could coerce to an ID number in numeric context, so
 $subref.unwrap($id);
would still be valid code (==> TIMTOWTDI).
At the very least you'd have to be able to do that as well, I get this 
uneasy feeling about having to do $id.unwrap();. unwrap would be the 
wrong method anyway - it implies unwrapping $id itself, which seems 
wrong because $id isn't wrapped, it's wrapped around something else. 
Maybe $id.remove() or $id.tear_off() or $child.give_present($id), which 
would cause unwrapping to happen very, very quickly and messily.

On the other hand, what happens when you call $id.unwrap() (or 
$subref.unwrap($id)) if $id is an object? What happens to $id? Does it 
turn into some kind of limbo object? Does it become undefined? Is it 
right for $subref.unwrap($id) to be able to do that to $id? Is it right 
for $id to be able to do it to itself?

Hmm. Not a very useful email really. Oh well. It's too hot to think 
straight.

Re: Periodic Table of the Operators

[Matthew Walton]

Mark Lentczner wrote:
All -
Awhile back, I saw Larry Wall give a short talk about the current design 
of Perl 6. At some point he put up a list of all the operators - well 
over a hundred of them! I had a sudden inspiration, but it took a few 
months to get around to drawing it...

http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html
Now that is truly a work of art. I look forward to seeing it evolve (and 
the corrections already suggested being made). And I can also see myself 
printing it out and putting it on the wall for use the moment I can get 
my hands on a Perl 6 compiler. Finally a use for the colour laser 
printer in the office...

Well done.

Re: Yadda yadda yadda some more

[Matthew Walton]

[EMAIL PROTECTED] wrote:
Austin Hastings wrote:

  my int $i = ...; # Fails at compile time -- no good conversion.
  my Int $i = ...; # Warns at compile time, fails at runtime.
I don't get the reasoning here. If Yada Yada Yada is to indicate code 
that you haven't written yet, it should never fail at compile time 
unless it's impossible to compile the program without knowing what that 
code is, so

my int $i = ...;
should compile. The problem would arise when you actually tried to run 
that particular bit of code, which may well look to Parrot like 'die 
horribly'.

Or. not so horribly.  If I'm in the perl debugger, I'd want that to be a breakpoint
and give me the option to type in a evaluable string to replace it.  So it should 
throw a properly marked exception that an outer context can do something
with.
Good point.

Re: Yadda yadda yadda some more

[Matthew Walton]

Austin Hastings wrote:
I think of this as very much like the typed-undef we discussed last
month or so: ... should return an unthrown exception wrapped in
undef-ness. 

The type returned by ... should just have a multitude of type-casting
tricks associated:
   my int $i = ...; # Fails at compile time -- no good conversion.
   my Int $i = ...; # Warns at compile time, fails at runtime.
I don't get the reasoning here. If Yada Yada Yada is to indicate code 
that you haven't written yet, it should never fail at compile time 
unless it's impossible to compile the program without knowing what that 
code is, so

my int $i = ...;
should compile. The problem would arise when you actually tried to run 
that particular bit of code, which may well look to Parrot like 'die 
horribly'.

If Yada Yada Yada is not to indicate code that you haven't written yet, 
then what is it really for?

I would guess again that the body of the sub not being actually
executed until the sub is called means that C<...> passes through 
the compile phase without a problem. The compiler would have to
special-case it though, to allow the redefinition.

Perhaps not. If {...} evaluates to C<(Code)(undef but something)>, the
transition from C to C
might not be grounds for a redef warning.
That would make sense... if ... gave you an indefined code block (rather 
than code which returns an undefined value, which we all know and love, 
or at least I love it), it would actually make a LOT of sense.

I'm going to assume that if you tried
my Int $number = ...;
$number = 5;
it would still die at run time on the first C<...>. I really hope it 
would anyway, because if you really want to do something like that
we've already got C.

This is wrong. The purpose of C is "I declare that I've thought
about the issue and at this point in the code $number should have no
value." The purpose of C<...> is "I declare that there should be
something here, but I haven't thought about it yet."
IOW, C<...> is a form of literate programming that's relatively
self-explanatory and highly compatible with Agile development:
class foo {
  has $.x = ...;
  method bar() {...}
  method baz($a)
  {
if ($a) 
{
  .bar();
}

say "Hello";
  }
}

class foo_test
{
  is UnitTestCase;
  has $.foo;
  method test_empty_baz()
  {
 $.foo = new foo;
 $.foo.baz(undef);
  }
}
This code should work okay -- no Yadda ever gets executed.
Then when I add:
  method test_valid_baz()
  {
$.foo = new foo;
$.foo.baz(1);
  }
there should be a failure, because $.foo.baz calls $.foo.bar, which is
defined C<{...}>, which evaluates to an unspecified value exception.
Yes, that's more or less as I would expect it to work.
I thought class closures 'ran' at object creation time. I'm probably 
wrong about that. Object creation time would be a good time for that 
particular yada yada yada to start complaining though. I suspect
C<...> is going to be considerably more sophisticated than a macro
that replaces it with C<{ die }>.

I think the metaclass "class assembler" function will behave like this:
  If only a Yadda is provided, just return a typed Yadda object.
  If anything other than a Yadda:
  If you provide a definition of any name, it goes in.
  If you provide a Yadda, it gets recorded.
  When wrapping up, if any methods are provided, then a special
yadda-on-not-found dispatcher is provided. If no methods are 
provided, a special yadda-on-not-inherited dispatcher is provided.

  A similar data member access is provided.
So that:
  class Foo {
has $.a;
has $.b;
...
  }
Becomes:
  class Foo {
AUTOMETH {
  if inherited($method_name), run it.
  else return sub {...};
}
has $.a;
has $.b;  
AUTOMEMBER {
  if inherited($member_name), return it.
  else return \...;
}
  }
So you can have objects made from class Foo, but if you try and get at a 
method which doesn't exist you get Yada instead of 'that method doesn't 
exist'... that makes sense, I think, because you can use any method 
names you like in your code, and the effect is basically 'this method 
hasn't been written yet'.

I would expect that to run and complain at compile time. That might
be irritating, but I'm not sure how else it could be done, because 
BEGIN blocks are run then, and when they're run you need to know what
values you're going to assign to the variables.

Unless you gather it up inside some sort of lazy evaluation construct
that keeps delaying the evaluation of it until you hit run phase, at 
which point you've probably got the entire BEGIN block ready to go,
with everything that comes after it also hanging around, and... no,
doesn't sound good does it?

Again, I like it. A partially defined object isn't fatal unless you
actually need that part.
If Yada is actually a value with a special type as you've said here, 
then it falls out quite well. You can put it into anything you like, you 
just get a problem the moment you try and take it out again an

Re: Yadda yadda yadda some more

[Matthew Walton]

I actually find myself having somewhat coherent thoughts on this matter. 
Apologies if they seem rather obvious or naive, but I'm still new to all 
this.

Dov Wasserman wrote:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the compile-time type of the term must be assignment-compatible
with any and all lvalues. This will have to be true at least in those
contexts that ask for strict type-checking, even if other scopes don't care.
This reminds me of Java's C literal reference value which can be
validly assigned to any reference type. (Technically, it's not a keyword,
but try giving that answer on an interview at your own peril.)
I don't see any functional problem with this special property as long as it
can be implemented in the core language. Seems like it would have to be a
special rule of type checking. So we'd have generic Scalar as the universal
recipient, and now the Yada literal as the universal donor. (Any association
of strong type-checking with the extraction of blood is purely imaginary.
As far as the compiler's concerned at that point, it might behave 
something like C. For the purposes of the type checker that would 
probably be sufficient. Worrying about the actual value wouldn't be a 
problem until runtime, at which time it's quite safe for C<...> to do 
what it's supposed to do and complain.

[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method, etc.) which
has only been declared with the Yada Yada Yada closure does not generate a
warning. It seems like Perl 6 will have to take some special note, then,
when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
as opposed to:
sub foo($bar, $baz) { die }; # defining sub foo() to throw an exception
(mod throwing syntax)
so that the first case can be redefined without a warning, while the second
case would warn on redefinition.
I would guess again that the body of the sub not being actually executed 
until the sub is called means that C<...> passes through the compile 
phase without a problem. The compiler would have to special-case it 
though, to allow the redefinition.

I'm going to assume that if you tried
my Int $number = ...;
$number = 5;
it would still die at run time on the first C<...>. I really hope it 
would anyway, because if you really want to do something like that we've 
already got C.

[Question #1]
I'd like to understand how Aaron Sherman's initial example would work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it pitch a
fit (or exception)? I'm unsure of the meaning of this idiom, because the
only time the C<...> line gets evaluated is at class compilation time, which
is when we don't want any complaints in this case.
I thought class closures 'ran' at object creation time. I'm probably 
wrong about that. Object creation time would be a good time for that 
particular yada yada yada to start complaining though. I suspect C<...> 
is going to be considerably more sophisticated than a macro that 
replaces it with C<{ die }>.

[Question #2]
Does C<...> know when it's being called during compilation and when it's
being used at run-time? I.e., how would it behave in a compile-time block
such as BEGIN:
BEGIN {  our IO $server = ...; };
The rhs value is evaluated here at compile-time. Is C<...> smart enough to
know that and keep quiet?
I would expect that to run and complain at compile time. That might be 
irritating, but I'm not sure how else it could be done, because BEGIN 
blocks are run then, and when they're run you need to know what values 
you're going to assign to the variables.

Unless you gather it up inside some sort of lazy evaluation construct 
that keeps delaying the evaluation of it until you hit run phase, at 
which point you've probably got the entire BEGIN block ready to go, with 
everything that comes after it also hanging around, and... no, doesn't 
sound good does it?

Re: Yadda yadda yadda some more

[Matthew Walton]

Larry Wall wrote:
On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote:
: Aaron Sherman skribis 2004-05-12 17:30 (-0400):
: > I like C<...> I like it a LOT.  In fact, I'm partial to the idea that
: > it should be usable anywhere
: 
: I agree. It'd make even more of my pseudo code (#perlhelp and
: perlmonks.org) valid syntax :).

Er.  Why are you guys using the subjunctive?
Straining my brain to remember what the subjunctive is (and I only ever 
learned it in German anyway), does that mean that this use of yada yada 
yada is already decided on and allowed?

If so, fantastic.

Re: C style conditional statements

[Matthew Walton]

Juerd wrote:
my $n = IO::Socket::INET.new LocalPort => 20010, Listen => 5;
Or, if I'm remembering correctly:
my IO::Socket::INET $n .= new LocalPort => 20010, Listen => 5;
I really hope I'm remembering correctly. Is this turning into the 'look 
how great Perl 6 is' thread?

Re: C style conditional statements

[Matthew Walton]

Larry Wall wrote:
On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote:
: For some reason, lots of people don't like it when indentation is 
: what's controlling their code structure...

Indentation is a wonderful form of commentary from programmer to
programmer, but its symbology is largely wasted on the computer.
We don't tell poets how to format their poetry.
When you put it like that, I'm almost converted. My favourite language 
that does indentation as syntax is Haskell - where it's optional, so I'm 
not really all that passionate about it. I just don't mind it.

Re: C style conditional statements

[Matthew Walton]

Stéphane Payrard wrote:
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
Hi
Is there any chance that in perl6 there will be the possibility to write
if/else statements without {}s with the condition at the beginning?
Like 

if (condition)
statement;
In order not to break traditional C culture. Is there any technical
reason why it wasn't done in perl5? 

In Perl5, variable declaration are an executable statement. Also the
scope of a variable starts from its declaration and ends at the
end of the immediately enclosing block. Things would get
problematic if the branches of an if/else were not scoped.
What would be the meaning of :
if (condition)
   my $foo = 'bar';
else
   print $foo;
Not entirely sure, but according to the camel book, another reason for 
the braces being compulsory is that Perl makes a distinction between a 
block and a statement, whereas in C a block is actually (sometimes) a 
kind of statement - indeed a compound statement. Of course, it's 
possible that was just an excuse, but it does make a fair bit of sense. 
Especially since Perl's got things like anonymous subroutines and 
closures, which are sort of fancy blocks, and ultimately one has to 
realise that { and } don't mean the same thing in Perl at all. They just 
*look* like they do.

I am actually glad to see Perl 6 extending this trend, as it seems to be 
using { and } for Good Things. I wouldn't argue at all that it's 
important to keep familiarity for C programmers anymore (so sayeth the 
Haskell programmer), although it might perhaps be a little early to go 
for Python-like syntax. For some reason, lots of people don't like it 
when indentation is what's controlling their code structure...

Re: A12: syntax to call Attributes

[Matthew Walton]

Jonathan Lang wrote:
How would I call attributes?  Specifically, what if I'm calling a list
attribute from a scalar object?  

  my Dog $spot;
  my Dog @pack;
  $spot->@.legs; # INCORRECT (I hope)
  [EMAIL PROTECTED];   # INCORRECT?
  @spot.legs;# What if you also have @spot declared?
As a guess, I'd say that it's

$spot.legs;

because as I understood A12 the only way to get at an attribute is 
through an accessor method (be it autogenerated or otherwise), which is 
quite definitely going to look like that. At least, I hope it is. And it 
doesn't matter that it returns a list, because the funny characters 
don't mean the same thing they mean in Perl 5 - at least, not all of the 
time. They're a bit saner now (IMO).

Re: A12: default accessors and encapsulation

[Matthew Walton]

Mark J. Reed wrote:

Let me just chime in with my support for John's basic idea.  I would
definitely prefer that it be easy to arrange things such that
	$obj.foo = 'bar'

winds up invoking a method on $obj with 'bar' as an argument, rather
than invoking a method on $obj that returns an lvalue to which
'bar' is then assigned.  (Yes, like Ruby's def foo=; I have a Rubyometer
and I'm not afraid to use it!)  It doesn't need to be the default 
rw accessor behavior, but I would like it to be accomplishable without
jumping through a lot of hoops.

-Mark
It sounds a lot like C#'s properties, which are in my opinion one of the 
best things in C#. Nice easy syntax for those as well, although I can't 
remember it well enough right now to give an example, as I don't 
generally keep a C# reference lying around at work where I never use it. 
Effectively though, if you have an object foo with a property bar, 
things like

foo.bar = 5;

seem to get turned into

foo.set_bar(5);

where set_bar() was pulled from the property declaration's set {} block, 
where some magic goes on.

However, it would appear that what John is asking for is already 
possible, just not necessarily particularly obviously, as returning a 
proxy object to act as the lvalue and then do the appropriate magic 
would work, but seems a little mucky. Even if that's what happens behind 
the scenes.

On the other hand, just as a thought from a crazy C++er, couldn't you 
accomplish a similar effect by defining your $.foo attribute to be of a 
custom class, then overriding the = operator for that class...

I know, messy messy. Don't go that way. I shouldn't even have thought of it.

Re: A12: Mutating Methods and hyperoperators

[Matthew Walton]

Luke Palmer wrote:

Matthew Walton writes:
But can I do

@things».=method();


Of course.
Excellent. Thankyou.

Not this time :-)
Next time then, probably.

A12: Mutating Methods and hyperoperators

[Matthew Walton]

I know these were discussed to death not that long ago, but reading 
Apocalypse 12 I had a query I couldn't remember if it had been covered 
before or not, and I certainly don't recall seeing it in the Apocalypse, 
although I've not read the entire thing with as much attention as I 
might like yet (it's great work though).

So, simple query. I know I can do

@things».method();

But can I do

@things».=method();

which would presumably be the same as

map { .=method() } @things;

And if I can't do it, why not? I think I should be able to do it, but 
it's entirely possible I've missed something, because I usually have.

Thanks

Matthew

Re: backticks

[Matthew Walton]

Juerd wrote:

Sean O'Rourke skribis 2004-04-15  8:55 (-0700):

I find that there are still plenty of contexts in which `` is nice and
security is irrelevant.
This is the second time in this thread that I read about security being
unimportant. I still don't know what to say about it, though I feel like
ranting.
Security is of course extremely important, but changing a language so 
that doing anything insecure becomes impossible or at least extremely 
difficult strikes me as a bit too much nannying. One should of course 
never accept user input without validating it first - especially stuff 
coming in over a network - but once you know what's in it, there's nowt 
wrong with interpolating that into a `` or qx// kind of structure.

Well, other than the usual mistakes you can make by forgetting how it's 
going to interact with the shell, but this really doesn't bother me in 
the slightest. And as has been said, there's a vast amount of one-liners 
and short utility scripts out there which use backticks quite happily 
and safely. As with many things, they're only dangerous if you don't 
know what you're doing.

Probably you know when you can use qx safely, but many, MANY people out
there have no clue whatsoever and use qx with interpolation *because* it
is easy.
Which is exactly why I use it. I'm just not foolish enough to trust the 
variables I'm interpolating into it unless I've constructed them 
entirely myself and I know the code that constructs them is bug-free.

Having said all that about lack of knowledge though, I'm sure everyone 
on this list knows about how to deal with tainted data and such things, 
but there are a lot of fresh Computer Science graduates and other people 
learning programming who never hear a thing about it. I don't see that 
as an excuse to turn Perl into a hand-holding nanny language though.

Re: backticks

[Matthew Walton]

Juerd wrote:

chromatic skribis 2004-04-14 12:32 (-0700):

That's exactly my objection to this idea.  I think it goes too far to
make simple things simpler while making complex things impossible.


Absolutely false.

This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)

I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.


There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo<<$bar>> doesn't quite do the same as %foo{$bar}.
That's one method, really - <<>> being like {' '}, and really just 
carrying on the very familiar idea of different kinds of quotes. Like ' 
and ".

The ` idea is completely different.

Also, ditching `` quotes strikes me as a fairly dreadful idea. I for one 
use them almost perpetually. Yes, I could use qx// instead, but I could 
also use qq// instead of "".

Ultimately, ` looks like an opening quote character, and so people will 
expect it to behave like one. I think that violates the principle of 
least surprise.

Re: Compatibility with perl 5

[Matthew Walton]

Thomas A. Boyer wrote:
The original question was "how do I label my code as Perl 5?" The 
correct answer, according to Apocalypse 1, is to start your source with 
"package." If you didn't want to put your code in a package, then start 
it with "package main".

The other question was "how do I label my code as Perl 6?" The correct 
answer, according to Apocalypse 1, is to start your source with "module" 
or "class".

Here is the relevant paragraph from the apocalypse:
  I hereby declare that a |package| declaration at the front of a
  file unambiguously indicates you are parsing Perl 5 code. If
  you want to write a Perl 6 module or class, it'll start with
  the keyword |module| or |class|. I don't know yet what the exact
  syntax of a module or a class declaration will be, but one
  thing I do know is that it'll set the current global namespace
  much like a |package| declaration does.
Righty-ho then. That's not actually all that bad, I'm used to starting 
files with 'module' in Haskell (where it's not always compulsory but is 
a good idea) so I'm sure I can cope with a similar thing in Perl 6.

Thanks

Re: Compatibility with perl 5

[Matthew Walton]

Thomas A. Boyer wrote:

Matthew Walton wrote:
That could be problematic, because if Perl 6 sees something like:

my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?


It's going to think 'ahah', perl 5'. Because it doesn't contain any Perl 
6 keyword (such as 'module' or 'class'), as Mark said.
But then trying to process that as Perl 5 will result in an error. This 
doesn't seem particularly sane to me. Will we have to say

use 6;

on all Perl 6 programs to avoid this kind of thing?

Forgive me if I'm missing something obvious here.

Re: Compatibility with perl 5

[Matthew Walton]

Mark J. Reed wrote:
On 2004-04-13 at 13:16:02, David Cantrell wrote:

Perl 6, we are promised, will try to run "legacy" code unchanged.  How
will it spot such legacy code?  


My understanding has been that perl6 will assume a program is Perl 5 unless
it sees a Perl 6 keyword such as 'module' or 'class'.
That could be problematic, because if Perl 6 sees something like:

my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?

That's assuming my understanding of hash subscripting and variable 
declarations in Perl 6 is even slightly correct, of course.

Re: Funky «vector» operator

[Matthew Walton]

Robin Berjon wrote:
Specifying the OS is not enough, you need at least the keyboard layout. 
It would be impossible to have shortcuts involving | or \ on a French 
keyboard since they are respectively Alt-Shift-L and Alt-Shift-:

OS X / iBook / fr-fr

  « Alt-è
  » Alt-Shit-è
Good point. I tend to be a bit shortsighted on things like that.

OS X / Powerbook / en_GB

« Option-\
» Option-Shift-\

Re: Funky «vector» operator

[Matthew Walton]

Angel Faus wrote:
Most people know about this sequence because the ~ character is a 
common one in URLs, so the situation is not as bad as i may look. 
Neverthless, I definetly hope that a future FAQ of perl6 has a big 
section labeled How do I Write These Funky Chars in My OS.
That sounds like a good idea. Might help avoid people being put off by 
operators like « and ». Another section close by on ASCII equivalents 
for those which have them would also go down well.

For the record, on Mac OS X it's Option-\ for « and Option-Shift-\ for » 
(where Option-Shift-\ may also be seen as as Option-Shift-|). It is 
entirely possible that this is different on a normal Apple keyboard as 
opposed to the one in my Powerbook, but that strikes me as unlikely.

Probably getting a little ahead of myself here though, as we can't 
actually use this masterpiece language yet. :-(

Re: Mutating methods

[Matthew Walton]

Larry Wall wrote:
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:
: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
: 
: > Well, okay, not a boolean.  More like a troolean.
: 
: Unless it's a falselean.

It's more truelean than falselean by a 2/3rds majority.  And it's
much more if you include 2, -2, 3, -3,... in the data type.  And it's
*very* much more if you include the reals
So that's a (numeric) scalar then...

I'm new to this list, although I've been keeping an eye on Perl 6 for 
quite a while now as it's looking like it's going to be an extremely 
pleasant language to work with. Seems I joined at the right time as 
well, for these mutators are an interesting thing. Please excuse my no 
doubt numerous abuses of conventional formatting used here as I don't 
know it yet, and I've got a very shaky knowledge of some parts of the 
Perl 6 grammar that everyone posting seems to know.

However, it strikes me that notation like

int method =foo(String $bar) {...}

is at risk of causing serious confusion to people coming from other 
languages. This may not be a concern, of course (and isn't really one of 
mine despite being a C++/Perl 5/Haskell kind of person at the moment). 
It seems that

int method self:foo(String $bar) {...}

is clearer and easier to read, but I did actually prefer

int method mutate:foo(String $bar) {...}

or

int method inplace:foo(String $bar) {...}

which seem to have been dismissed in favour of the form using C, 
although I can see that it does have a valid interpretation. Perhaps I'm 
just too stuck in writing member subs of objects in Perl 5 by saying

sub foo {
  my $self = shift;
  # something useful here
}
so I always see 'self' as reading something like 'this' does in C++ or 
Java (or as 'self' does in Python, if I'm remembering that correctly). 
There is undeniable logic in using it to define mutators though, as they 
do most certainly act upon 'self' or 'this' or whatever it's called.

One is lead to wonder if the most appropriate definition might not be

int method mutator:foo(String $bar) { ... }

but that's getting very silly, so maybe just ignore everything I said 
just now and cheer the introduction of C as the most practical and 
least prone to the introduction of finger trouble.

And having said all that, I like .= as invocation syntax for it, even if 
I keep thinking it means 'append string'.

Anyway, thankyou for listening, I shall return now to watching in awe.

Matthew