Ingo Blechschmidt wrote:
Hi,
Yuval Kogman wrote:
On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote:
This section will contain all information needed:
* User-defined operators
* Other symbols exported by is export
* Exported macros
Okay, this raises a distinction:
Compile
Larry Wall wrote:
On Wed, Aug 17, 2005 at 01:56:35PM +1000, Adam Kennedy wrote:
:
: : If not a special form, should this work?
: :
: : my $pi is constant;
: : $pi = 3;
:
: That could be made to work by defining constant to mean you can assign
: to it if it's undefined
: If not a special form, should this work?
:
: my $pi is constant;
: $pi = 3;
That could be made to work by defining constant to mean you can assign
to it if it's undefined. But then it gets a little harder to reason
about it if $pi can later become undefined. I suppose we could
No - you don't seem to understand. The challenge-response protocol can ask
someone for the RSA key fob number this time, their mother's maiden name the
next time, their employee number the time after that, and nothing on the
fourth occasion. You cannot predict what the extra information
Michael Hendricks wrote:
In other words, Huffman coding works and Perl6 hackers had better start
watching their waistlines. Or maybe we should spin it that Perl6 helps
reduce global warming ;)
Anyway, I collected a small sample (~300 lines each) of Perl5 code along
with equivalent Perl6 code.
In particular, the DBI must not mandate impossible levels of support from
the drivers. It will benefit you nothing if the DBI is immaculate and
wonderful and incredibly all-singing and all-dancing, but no-one can write a
driver for it because the requirements cannot be met by the actual DBMS
4. All host parameters should be named (like :foo) rather than
positional (like ?), meeting with the SQL:2003 standard. The named
format is a lot easier to use and flexible, making programmers a lot
less error prone, more powerful, and particularly more resource
efficient when the same
- optional treatment of the statements as an AST, similar in concept to
SQL::Routine, or Tangram::Expr. Death to SQL templating systems!
I suspect during this process people are going to want a lot of things
that layer on top of what we currently see as DBI.
Personally I think Tim got
Autrijus Tang wrote:
On Tue, Jun 28, 2005 at 09:49:58AM +1000, Brad Bowman wrote:
Autrijus' journal mentions quasiquoting (Perl 5).
Yes... quasiquoting in Perl 5 is currently crudely emulated
by feeding things to PPI::Tokenizer and PPI::Transform. :-)
You're doing what now? :)
Just in
I think there exists an even simpler way to avoid any mess involved.
Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call the sub?
sub AUTOLOAD ($whatever) { # but no
John Siracusa wrote:
On 6/18/05 8:28 PM, Juerd wrote:
The unix shell and things resembling it will still be in use much fifteen
years after today, Perl 5 will not.
Ooo, a bold prediction :)
Heh, it is indeed. And it means given the 16,000,000 lines of Perl in
CPAN, we only have to keep
The reason we ended up at ./method was simply because it was the best
suggestion anyone had.
Compared to the previous suggestions it was way ahead.
It's other advantage is that (except for on nordic keyboards) dot and
slash are generally right next to each other, so the expense of using it
: If it can be done in less than 10 lines lines of code, to get the most
: minimal hooks into the core, I'd like to see it done.
10 lines? I laugh in your general direction.
No really. In perl itself, I just to see...
throw Event(CORE::prefork) if $Event::Manager::VERSION;
...or something
Gaal Yahas wrote:
On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
There will certainly be an event manager for all sorts of events floating
around in Perl 6. The main trick will be to hide this from the people
who aren't interested. The other trick will be to actually spec it,
Ingo Blechschmidt wrote:
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
Forgive my ignorance here, but for all of these different ways of doing
constants, will they all optimize (including partial
evaluation/currying) at compile/build/init/run-time?
my $gravity is constant = 10; #
You get all those possibilities whenever you install any new version of
a module you get from someone else, regardless of a p5-p6 hop. In p6,
when you say use Digest;, you are specifically asking for what p6
considers the latest version. In p5, it was first match on libpath.
Except that
On the migration front, when someone ports Digest.pm to Perl6, I get a
free upgrade, assuming the module author was kind enough to up the
version number.
You are making a pretty huge assumption here that whoever has a
namespace in p5 CPAN has first dibs at the P6 namespace of the same
name,
For starters, about the only combination harder to hit with on
spanned hand might be ctrl-F5.
I've remapped my keyboard so that I push shift for numbers and leave
it off for the various symbols on the top row. ^ isn't hard to type
for me. (Plus, is it that hard to use two hands with shifted keys
Juerd wrote:
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
./method
to mean $?SELF.method, and
../method
to mean $?SELF.SUPER::method, or however that's normally written.
I'm opinionless on the latter, since in my opinion cross-calling
supermethods (calling a
[»+^=«] reminds me of a P5 regex that has a comment saying This is
black magic. Don't touch!. --That's-- my complaint.
Indeed. There's a time and a place for that sort of black magic, and
it's usually about once per 5,000 lines of code, and so deep and well
wrapped in comments and unit tests
Autrijus Tang wrote:
Juerd informed me today that .method should still means $_.method.
However, for the OO modules we're writing, there still needs to be a way
to invoke methods on the current invocant, when the invocant name has
been omitted from the method() declaration.
Currently Pugs has:
The obvious way to do it is to declare the invocant.
Wasn't one of the original headline features for Perl 6 not having to do
that any more for basic normal code? Or at least from a couple of damian
talks it was one of the things that practically _everybody_ wanted.
On the plus side, with
Er, I'm not sure you will want to--I'm using PPI's evil twin brother,
PPD (the actual Perl parser). I've just modified it so it doesn't
forget anything I want it to remember. (As you know, the standard
parser throws away gobs of useful information, everything from
whitespace and comments to
I thought I'd just drop in a quick note to people to let you know that
PPI 0.903 was just release, which fixs the last significant performance
bug. PPI is now completely leak-free and implicitly-DESTROY's correctly.
Anyone who wanted to have a short at doing any kind of mass-processing
of Perl
At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically.
At some point, adding another thing people have to remember in order to
save one character gets a bit self-defeating, surely.
The good thing about $_.method is
Err, wait, I don't think we are discussing whether $_ is to be outlawed
in map {}. I think the proposal is for .method always mean $invocant.method
and make it illegal when there is no invocants in sight, mush as $.attr
would be illegal without an invocant. To use $_.foo, write $_.foo.
Luke is
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style policies will be to _always_ use
explicit invocants (except of course for one liners).
In the case of the
for a private method?
Adam K
Michael G Schwern wrote:
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote:
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style
for PPI is to build something for perl similar to IntelliJ IDEA.
If the PPI-like mode of the perl 6 parser happens (don't touch anything
outside the file) then I don't see why it can't be done, at lease in
some form.
Adam Kennedy
It's quite a disappointment in some ways, but we've lived with it in
Perl 5, and I'm sure we can live with it in Perl 6.
And I still think Perl 6 will have fewer cases in which it's completely
impossible for not-Perl to parse it. Unfortunately, fewer still implies
some, and some is still a
Let's say you want to write a yacc grammar to parse Perl 6, or
Parse::RecDescent, or whatever you're going to use. Yes, that will be
hard in Perl 6. Certainly harder than it was in Perl 5.
In the end, I concluded there was _no_ way to write even a Perl 5 parser
using any sort of pre-rolled
Michele Dondi wrote:
On Thu, 25 Nov 2004, Adam Kennedy wrote:
I thought it was about time I brought some concerns I've been having
lately to the list. Not so much on any particular problem with perl6,
but on problems with perl5 we would seem to have the opportunity to
fix but aren't. (So far
Smylers wrote:
Adam Kennedy writes:
perl itself would also appear unable to understand perl source,
instead doing what I would call RIBRIB parsing, Read a bit, run a
bit.
RIBRIB? RABRAB, surely!
Smylers
Yes, you are right, typo.
Herbert Snorrason wrote:
On Thu, 25 Nov 2004 22:00:03 +1100, Adam Kennedy [EMAIL PROTECTED] wrote:
And just after the snip you will see I qualify parse in this context
as loading the perl in some form of DOM-type tree.
And yet you disqualify the Perl6 rule system, with its tree of match
objects
://search.cpan.org/~adamk/PPI-0.831/
Thanks for your time
Adam Kennedy
35 matches
Mail list logo
