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 t
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
: 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
dis
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 requeste
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 tha
I don't mind if you implement this ".dbi" feature though, I just want it
to be invisible :) i.e. don't check this file, if I explicitly supply
username and password (this is obvious, right?) and show some warnings
if don't. Say, make a connect parameter "use_dot_dbi", which is zero by
default.
- 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
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 par
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 cas
> 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 th
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
is
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,
sin
: 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
With my occasionally-stated preference for keeping the Perl 6 core
slimmer than it already is, I feel a little silly about suggesting new
features for P6, but I'd like to stimulate debate on one that I'd like
to see.
Last year I was having some issues with a large web application that
needed
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; # O
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,
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 s
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
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 explic
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:
[»+^=«] 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 th
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 pru
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 that
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 dis
we call :method
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
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 Algor
the very very distant "sparkle in my eye"
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 pro
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 i
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.
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.
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 gramm
he issue of parsability would be
welcome. I'm not sure if Damian is involved in Perl 6 language stuff any
more, but if he or anyone else language-related is going to be at
YAPC.AU next week I would dearly love to meet up and have a chat.
My currently-being-API-frozen perl parser is visible at
http://search.cpan.org/~adamk/PPI-0.831/
Thanks for your time
Adam Kennedy
37 matches
Mail list logo
