Re: Perl 6 code - a possible compile, link, run cycle
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 time exports
Runtime exports
Well, all exports happen at compile-time, but you're right, some exports
(regular subs) will probably not be used before runtime.
Excuse my stupid question, but what about the equivalent Perl 6 case to
the following.
use Module qw{symbol};
BEGIN {
die Not ready to compile if symbol();
}
Re: my $pi is constant = 3;
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. But then it gets a little harder to reason : about it if $pi can later become undefined. I suppose we could : disallow undefine($pi) though. : : Which would basically throw away compile-time optimizations relating to : constants wouldn't it? You could still reason about it if you can determine what the initial value is going to be. But certainly that's not a guarantee, which is one of the reasons we're now calling this write/bind-once behavior readonly and moving true constants to a separate declarator: my $pi is readonly; $pi = 3; vs constant $pi = 3; or constant Num pi = 3; or if you like, even constant π = 3; Larry OK, so then there is not is constant at all... just is readonly? Makes a lot more sense to me. Adam
Re: my $pi is constant = 3;
: 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 disallow undefine($pi) though. Which would basically throw away compile-time optimizations relating to constants wouldn't it? Adam K
Re: DBI v2 - The Plan and How You Can Help
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 requested is going to be - so you can't provide the extra information in the initial connection attempt because you don't know which extra information is going to be needed. That's what provides the security - the unpredictability of the question, so that it is hard to pre-programme the answer. Ah but you can know in advance! :) You may not know the actual result per instance, but you CAN know the decision process you'll need to go through. Which you can provide as a parameter in the form of a CODE reference. :) i.e. a callback But that's a minor point and overall I completely agree with your general ideas. Adam K
Re: Perl6 burns 18% fewer calories
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. Some came from the Exegeses and others from Pugs' SVN. I had Text::TypingEffort give me some pseudo-scientific results and typing the Perl5 code takes about 18% more physical effort than typing the Perl6 code. My god! What is this wonderful module of which you speak? Finally a chance to help in the argument that ideas that try to force less characters in a huffman-inspired nightmare might make life worse from a actually typing it in real life sense. I wonder if handles different keyboard, I'd like to the differences in using Perl between the different country keyboards. Especially those poor nordics with the / and $ in funny places :) Adam K
Re: DBI v2 - The Plan and How You Can Help
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 that Perl + DBI needs to work with. I concur. Like CPAN as a whole, DBI's strength is in it's complete and near universal coverage of all databases, and insanely great (and occasisionally greatly insane) drivers that do strange and wonderful things. If we start sacrificing drivers by raising the bar too high, DBI as a whole suffers. Anyone proposing new features for DBI needs to be extremely careful of CYJ syndrome. Can't You Just (or sometimes Could You Just) syndrome is described here. http://c2.com/cgi/wiki?CouldYouJust http://www.oreillynet.com/pub/wlg/3593 http://c2.com/cgi/wiki?JustIsaDangerousWord Go read them now. I'll wait... This sort of behaviour can play a big part in ending up with second system problems. I have an increasing suspicion that having open design processes like the Tim's call for comments plays a big part in it as well. People are free to comment on things that 1) They won't have to implement themselves and (in some cases, but not you Duncan) 2) They think they know what they are talking about, but really have no idea what it means underneath the surface. In any case, I still propose that DBI2 split the driver interface into Roles. The main DBI2::Role::Transport role does ONLY what DBI does best now. That is, connecting to the database, preparing and sending queries, and fetching the results. Forget the current -tables interface. Drivers can OPTIONALLY implement the DBI2::Role::Schema interface to handle interrogation of the database schema. The current way we handle it is really messy by my standards, and could use a dedicated interface. As you invent major new features for DBI2, implement them roles. DBI2::Role::Transational, DBI2::Role::RFC90210 (the super flashy Beverly Hills feature), etc etc. Exactly what these roles should be I don't want to state with any certainty. That's the sort of thing that Tim, with his complete understanding of the issues, should be doing on his own. But I _would_ certainly like to see schema/table stuff separated from the base connection/query functionality. While I'm on the topic of DBI, one other feature I'd like to see would be something like better support for large objects or various types. In my personal DBI wrapper I've been using plain SCALAR refs as parameters to signify a BLOB, so I can pass by reference without a copy of a potentially large memory chunk, and then having to do driver-specific translation to bind variables (Oracle) or what have you. Some base way of default method defining a BLOB object (whether provided in memory, or pointing at a file handle to pull the data from at commit time) in would be really nice. Even if the way I have to pass the blobs to each driver differs, I'd like to be at least be able to say, This is a DBI2::Data::BLOB object (or something functionally equivalent). Adam K
Re: DBI v2 - The Plan and How You Can Help
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 parameter is conceptually used multiple times in a SQL statement (it only has to be bound once). If anyone wants to use positional format, it could easily be emulated on top of this. Or, if native positional support is still important, then it should be a parallel option that can be used at the same time as named in any particular SQL statement. See the native API of SQLite 3 for one example that (I believe) supports both in parallel. This also means that execute() et al should take arguments in a hash rather than an array. Yes, native positional support is still important. positions make it very easy to do SQL math. To express it in overly simplistic code $foo = [ a = ?, foo ]; $bar = [ b = ?, bar ]; $baz = $foo and $bar; # $baz now is [ a = ? and b = ?, foo, bar ]; Bearing mind a situation with an arbitrary number and complexity of these sql fragments to be added together, doing this sort of thing using named placeholders would be a nightmare. and we'd just end up with every second person implementing a ? to :p1, :p2 scheme in their database layers. If you want positional placeholders, it needs to be an additional feature, not a replacement for positional placeholders.
Re: DBI v2 - The Plan and How You Can Help
- 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 it right to initially only handle connectivity and preparation stuff in DBI, and not try to deal with schemas or relational-mapping or any of that other gumpf. I see the issues with the table methods in DBI as an example of this. What you want in many situations is something much more details that just a list of table names. So with that in mind. I'd like to see DBI done as a set of multiple interfaces that each driver can choose to support or not support. For example, the connectivity layer. This currently works very very well and has allowed huge numbers of different interfaces to almost every database in existance. Every driver, as they do now, should implement support for this layer. On top of that, if you really must interact with the database to query table names and so on, lets see that done as a separate layer. DBI2::Schema or something. drivers could then specifically advertise support or non-support for that API. And we could get an interface somewhat richer than the current raw hashes one. Adam K
Re: Quasiquoting
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 case this ever comes up again, let me clear something up now. It's worth noting it once here for everyone. PPI is not a code parser. By code parser I mean taking a string and turning it into working code. PPI is a document parser. It parses ONLY on syntax to form a model of a document. Any conclusions it might make on the structure of the resulting code are secondary. It cannot determine implicit parameters for function calls, which also means it has difficulty or cannot determine operator precedence. It is theoretically impossible to (document) parse Perl fully without also executing it, and even then perl doesn't (document) parse Perl, it just (code) parses Perl, or rather runs Perl. So to summarise, PPI is of limited use when it comes to working with bytecode or something that will be executed. It is for working with documents, not code. And I'm done here :) Adam K
Re: AUTLOAD and $_
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 [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return $s; # non-subref indicates failure
}
You are of course assuming that every use of AUTOLOAD, for all time,
will result in
a) Calling another function
b) An error
Wouldn't this lead to hacks where people do things like this just to
prevent perl thinking it's a failure?
sub AUTOLOAD ($whatever) { # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return sub () { 1 };
}
The ability to get complete control over the params and context of the
function, and maybe run something else AFTER the function call is important.
So I suspect there might be some false economy in this optimisation.
Adam K
Re: ./method defunct
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 porting rate up at around a million lines of code a year. Adam K
Re: ./method defunct
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 two chars and one fingering position, as they would likely be hit by fourth and fifth fingers (for touch typist style) and some other two fingers for the rest of us, and only 1 cm travel for hunt and peck. It has a very low RSI index :) (something I don't think we take into account enough as it is when we use the Huffman name to justify shortening something) So call it (2ch|2key|1pos|1cm) cost .::method on the other hand is 2 chars, 4 keystrokes, one of which must be held down between the two colons, is a strech for touch typists, requires you to get you hand completely away from the letters for the rest, and god help the hunt and peckers. Something like (3ch|4.5key|2pos|5cm) cost. And I dislike having a THIRD sigil even more than I dislike the second. Adam K I think $ is way more objectionable to the lily-white non-Perl heathens, but I don't really care about them either way. I'm just saying ./ screams file path to me, or maybe even typo-ed Java/C++ comment or something. Certainly not method invocation or implicit invocant. The .: thing, OTOH, totally works for me and I've always liked it. I'm just trying to stretch it to cover both public and private. Maybe there's something better than both.
Re: Musing on registerable event handlers for some specific events
: 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 equally simple. Fair enough Event::Manager itself might be a little larger... but even then it shouldn't need to be more than a couple of dozen lines. prefork.pm is currently about 30-40, and you should only need the hashified version of it.
Re: Musing on registerable event handlers for some specific events
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,
since up till now I've assumed that it should be specced by the people
who are actually into that sort of thing. Looks like you're one of
them. :-)
There's the touchy issue of what minimum compatibility level we're
promising to deliver on all platforms. This is an issue in pugs already,
where Windows GHC isn't compiled with POSIX libraries so we're stumped on
the interface for even relatively basic things, such as how (or whether)
File.open might offer O_EXCL.
Is part of the vision something like the explicit cross-platform nature
of Java? Will I be able to write Perl6 code with a certain flag that
possibly limits my choice of modules/builtins, but which promises me
identical behavior on all supported platforms?
To take a notorious example, you mentioned fork() -- if this event manager
becomes part of Perl6, does that mean we're required to emulate fork()
on win32?
Your point is well taken. Hell, even I was debating generalising even
further from fork to preload. As in, having Perl emit an event which
says Hey everybody, now would be a _really_ good time to load
everything in, because after we $whatever, it's going to be a lot more
expensive to load them in at run-time that to just load them now and
benefit from copy-on-write/threads/whatever.
Sort of a disable run-time loading and load stuff now event.
The reason I wanted a ten lines of code solution is so that the
fork()-on-win32 issue is less of a problem.
If perl itself ONLY does (in p5 term)...
Some::EventManager-fire('prefork') if $INC{Some/EventManager.pm};
..then it would matter less whether or not fork ever happens on Win32.
The preload.pm module would simply register with Some::EventManager for
a different set of events depending on which platform it is on.
prefork.pm as it exists for P5 today doesn't _really_ care about fork().
What it _really_ wants to know is Should I run-time load or not? Tell
me when we need to stop run-time loading.
Some::EventManager might be part of the core, but it certainly wouldn't
be loaded by default. It's just a normal module that gets loaded when
someone needs to use it.
I'm a minimalist. I want something to does the absolute least amount of
work needed to let me know about events I simply can't find out about
any other way, and that perhaps we can add additional events to later.
I certainly DON'T want something big enough and heavy enough to be able
to write Aspect.pm on top of.
Re: Declarations of constants
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; # One significant figure
sub time_to_ground ($height, $accel) {
...acceleration math...
}
my $time = time_to_ground( 500, $gravity );
... thus simplifying internally to
my $time = 1234;
Adam K
Re: Syntax of using Perl5 modules?
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 within Perl 5, there is an general expectation that the same API will exist across multiple module versions. It is assumed that newer versions of a module will continue to work the same as older ones, with API breakages being a bad and rare thing. The 6 month long mod_perl Apache::-Apache2:: argument was over this very thing. There is a huge difference between an API version and a module (implementation) version. As far as I'm aware, there is no expectation that *every* module in Perl 6 that shares a name with a module in Perl 5 will merely be a re-implementation of the same API in Perl6. If I am expected to reimplement all my Perl 5 modules in Perl 6 without the opportunity to do a better job and take advantage of new Perl 6 API-related features, could someone please point my boot in the general direction of the ass of whoever came up with that idea. Adma K
Re: Syntax of using Perl5 modules?
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, and that they will do a straight port over. Someone else could reimplement the module for Perl 6, or perhaps the author wants to (desperately needed in some cases)completely overhaul the module and API based on lessons learnt the first time. The problem with automatic fallback is simple that you are no longer getting two different versions of the same module, you are getting two completely different libraries, with no guarentee that the API is consistent. Automatic fallback lets changes in environment leak into the process and cause unexpected changes in program functionality, and this is BAD. The only time at which having to do nothing to load a current CPAN module will be during the transition period, before a suffucient body of Perl 6 modules have built up. In the longer run, much better to have to do something special to get the old and redundant versions of modules. Adam K
Re: ^method ?
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 like you were taught in typing class?) Can I assume that there is agreement already that in order to sit a beginner down and have them learn and write basic Perl, they shouldn't have to: 1) Remap their keyboard 2) Use characters that aren't on most keyboards I have horrible visions of newbie Win32 coders getting frustrated when the only way they can see to do something is to open up the Windows Character Map program and copy/paste from there. The current situation of the and characters seems fine in this regard, because it's not something you are going to need to use until you get more advanced. Having the... Start-Programs-Accessories-SystemTools-CharacterMap,Click,Select,Copy,Close,Ctrl-V ... º character as the default invocant method (to use that option as an example) is something I'd much like to avoid. Adam K
Re: ./method
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 supermethod other than the one you are currently in) has been nothing but bad in my experience. But it's definitely the best suggestion so far for implicit invocant method. If this was apache.org, I'd +1 it happily. Looking at various keyboard layouts however, the nordics among us (who have / at shift-7) are probably not going to like it though :) But US/UK/CJK are all to the right of the period, so it's a very friendly combination in that regard. Adam K Adam
Re: Plethora of operators
[»+^=«] 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 that nobody should have to touch it. Ever. If using something like [+^=] (and I'll bet a LOT of people are going to have to type it the long way) is going to involve 5-6 lines of comments just to explain what is going on, what's the point? I look at... but the basic operator there is just ^, with a + modifier to indicate numeric XOR, = to indicate an assignment operator, »« to indicate explicit parallelism, and now [] to indicate reduction ...and I just mind-wipe... so it's doing WHAT exactly? I've read it 5 times and I still have no idea. And reduction? I write 25,000+ lines of Perl a year, and if you are talking about something like List::Util::reduce, I think I've used it maybe twice? That sort of pill is the sort of think I'd assumed I'd start seeing once I wrote. use physics; Which, by the way I'm completely positive about. Loading in special grammars for particular classes of programmers is just an amazing idea. But really, in what circumstances could someone possibly need reduction so badly it needs to be in the core? Adam K
Re: ^method ?
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:
$?SELF.method
^method
Is any of the two forms considered canonical? Or is there some other
alternatives?
I must say after the previous conversation leaning towards .method ==
$?SELF.method I was stunned to see it had flipped back further than
where we started last time...
I don't mean to be disrespectful, but what was whoever suggested ^
thinking? For starters, about the only combination harder to hit with on
spanned hand might be ctrl-F5. You really have to stretch quite hard to
hit it. The current requirement of $, -, and at least contains
_relatively_ easy to reach characters.
Having read back through some recent archives, it seems that we are
selling out the option to provide a basic, clean, symmetric, OO for the
sake what seems basically like a sexy way to do...
if ( $foo == 1 ) {
} elsif ( $foo == 2 ) {
}
If we aren't going to make the invocant method . like everyone else
expects, can I at least have - back?
At some point we just end up with it being not maintainable enough by
normal programmers, and so we end up falling back on ...
method ($self: $string) {
$self.method;
$self.method;
}
...because doing it implicitly just isn't readable, and is going to give
me RSI. Huffman would be turning in his grave.
I don't know if I get a vote, but I write about 25,000 sloc of Perl code
a year, and I'd MUCH rather have clean, simple and terse OO than sexy
control structures.
And please, from another thread, can someone please explain exactly what
the [+^=] operator does? Not what it's components are, but as a
whole. Trying to work it out from a description is giving me flashbacks
of trying to understand haskell in an afternoon.
Maybe I'm just a bit testy from not sleeping in the last 36 hours, but
I'm willing to accept a lot of things as long as we don't treat OO like
a second class citizen WRT notation.
Every time I look at it .method just seems both obvious and symmetrical,
and yet we people keep wanting to give it up because some trickier thing
gets a bit uglier...
Is there any way we could prioritize based on frequency? We're
accumulating quite a little library of P6 code now. What are people
actually _using_ the most?
What gets used in CPAN? How many $self-method calls are there compared
to grep {} and map {}?
/me goes back to work
Regards
Adam K
Re: ^method ?
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 explicit invocants, we don't need all those pesky shortcuts for implicit attributes any more, since there's be a invocant around 90% of the time. Adam K
Re: PPI and the Perl 5 to Perl 6 converter?
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 pruned opcode subtrees. I have a version that doesn't do that, by and large, though I'm still finding fiddly spots.) So I'm presuming that you don't intend this as a tool that can do mass porting of code (due to the dependency issues), but rather as something for helping individual module authors port individual files/modules. Also curious how you handle BEGIN and friends... I take they are executed and then pruned, and end up unpruned in your XML? Also curious if you have managed to keep comments, POD etc... Adam K
PPI and the Perl 5 to Perl 6 converter?
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 5 code to produce docs or pugs AST trees or what have you should be able to safely build on top of PPI now. To summarize, Parsing and Analyzing are getting quite usable. I'll get back to you later on Manipulating. Also, I saw another mention recently (possibly on TPF request for donations) about the Perl 5 to Perl 6 converter, and it being 40% completed? ... Larry? Is anybody working on it? If it's built on something other than PPI, is there anything I can see, so I can steal any parsing tricks I don't know of yet. :) Adam K
Re: .method == $self.method or $_.method?
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 it is familiar, quite compact
anyways by virtue of using $_, and nobody is going to be surprised by it.
Personally (and I'm admittedly leaning towards simplicity lately) I'd
even throw a warning for using .method when there is an explicitly named
invocant as well.
# Good
sub foo {
.bar;
}
# Possibly confusing, throw a warning or forbid under strict?
sub foo ($self:) {
.bar;
}
# More obvious
sub foo ($self:) {
$self.bar;
}
of course, since it is still preferable to be symmetrical, if $.attr is
legal (and no warning) with a named invocant, then so should .method be.
Adam K
Re: .method == $self.method or $_.method?
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 discussing flow-on effects, just as larry was with his 'o' and 'c'.
if ( .process is $_.process ) {
either {
Specify an explicit invocant --- Larry
} or {
Specify an explicit topical variable --- Luke's musing
}
} else {
Call methods on $_ using $_.method --- My preference still :)
}
The only thing that worries me about The OC idea (how curious that a
feature is so easily named after a TV show) is that he is talking about
them being functions. I don't know enough about interals, but would that
get optimised to something faster, or do we suffer a second function
call every time we want to call a method?
I also have some worries about there being three different ways to call
a simple invocant method.
.method
$_.method (except in map/grep)
o.method
It has a faintly similar smell to the workaround-hell mod_perl 2 got
into... I'm all for TMTOWDTI, but surely the language should be elegant
enough that something as simple as calling a not-special-in-any-way
method doesn't need to have three different ways to do it?
An interesting exercise for anyone with a minicpan checkout would be to
scan CPAN and see how often the various uses are needed currently.
($self- compared to $_-).
Granted there are a hell of a lot of caveats in that, but it there's a
10 to 1 ratio of one to the other, surely that would help to make the
prefered preference a little clearer?
Adam K
Re: .method == $self.method or $_.method?
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 Algorithm::Dependency module that is being ported
over as a test, and given that larger chunks of code have a tendency
towards named iterators in loops anyways, and we've ended up with the
only sane way to be the wordiest of the various ways-to-do-it.
Just for the record, I for one would have much preferred to have .foo be
the same as $.foo and @.foo and %.foo and refer to the invocant method,
at the cost of using C map { $_.foo } .
To describe it in emotional terms, the current situation feels
backwards and inside out.
Adam K
Michael G Schwern wrote:
There's a discussion going on #perl6/irc.freenode.org right now wondering
about what .method means. We'd all assumed it meant $self.method (where
$self is always the method invocant) but then had a look at Synopsis 12
which states
Dot notation can omit the invocant if it's in $_:
.doit(1,2,3)
This seems to cripple .method's usefulness by coupling it to $_ which
can change often. Now in order to be safe for anything but trivial methods
you're back to writing out $self all over the place, something that Perl 6
was supposed to fix about Perl 5.
It has also been pointed out that .foo, $.foo, @.foo and %.foo are all
(intentionally) similar and all but one operates on the invocant. Only
.foo operates on $_. This seems like a newbie trap waiting to happen.
MOST of the time .foo will work like $self.foo but every once in a while
they'll get caught in a gotcha.
Thoughts?
Re: .method == $self.method or $_.method?
That is correct. It probably should have read ...our style policies will be to _always_ use explicit invocants, if .foo ends up meaning $_.foo in the final release (as it does now). (of course, I suspect Darren will keep using them anyways, but then he likes to be even more explicit than I am) :) Personally, .foo meaning $self.foo seems more consistent to my mind, and I'd happily standardise on implicit invocants. The only minor thing I can see would be that you will end up with a slight asymmetry question of if we use $:attribute for a private attribute, do 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 concluding that our style policies will be to _always_ use explicit invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: Perl 6 Summary for 2004-12-20 through 2005-01-03
Matt Fowles wrote: Perl 6 Summary for 2004-12-20 through 2005-01-03 All~ Welcome to a New Year of Perl 6 Summaries. I have been doing bi-weekly summaries over the holiday season, but I plan on returning to weekly ones now. Hopefully World of Warcraft won't prevent me, we shall see, but if anyone starts a perl guild drop me a line ;-) Perl 6 Language Perl IDE matisse wondered if an IDE for Perl would be possible given its dynamic nature. The conses arrived at last time was that an IDE that worked for nice code would be possible, but a fully general one would be extremely difficult and quite possibly impossible. http://xrl.us/ekks Strange, I can't see this message at all using nntp.perl.org... or any replies to it at the google groups address that tinyurl points to. I thought I'de throw in that 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
Re: Lexing requires execution (was Re: Will _anything_ be able to
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 problem. Frankly, as the only person who has managed to get together a guessing lexer that is sufficiently accurate to be something other than useless, I see nothing in Perl 6 that makes it any easier than Perl 5. In fact, my reason for starting this thread in the first place is because I was increasingly getting the feeling there would be MORE problems. The prototype and operator/operand content problem is still there. PPI works around it with quite a bit of hackery (look ahead, look behind, look ahead again, and shake it all about. Do the hokey pokie etc etc) For the relevant code, look for '47' in http://search.cpan.org/src/ADAMK/PPI-0.831/lib/PPI/Token/Whitespace.pm This can still be easily tricked if you are trying to (see Randal's examples again), but usually gets most real world code right. Then again, I avoid the whole problem of attaching params to sub calls by not doing it at all. The closest I can get is to list a set of tokens within a statement. Perl 6 has the same problems, and then also adds a higher likelyhood of encountering custom grammars than in Perl 5, where source filters are considered largely bad form. The fundamentals would appear to be the same. As a side note, I may have used parse erroneously. What PPI attempts to do is to be a tokenizer and a lexer, without understanding its function as code. So perhaps a syntax lexer is a closer term. The ability to read in and work with code based purely on syntax, without needing to know what it means. Adam
Re: Will _anything_ be able to truly parse and understand perl?
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 grammar system, as the language does not
have that sort of structure.
PPI was done the hard way. Manually stepping through line by line and
using a variety of cruft (some stolen from the perl source, some my own)
to make it just work.
I would envisage that the same would be true of writing a PPI6, except
with a hell of a lot more operators :)
However, Perl 6 comes packaged with its own grammar, in Perl's own rule
format. So now the quote only perl can parse Perl may become only
Perl can parse Perl (And even only Perl can parse perl, since it's
written in itself :-).
Perl's contextual sensitivity is part of the language. So the best you
can do is to track everything like you mentioned. It's going to be
impossible to parse Perl without having perl around to do it for you.
But using the built-in grammar, you can read in a program, macros and
all, and get an annotated source tree back, that you could rebuild the
source out of.
Again, this is of very little use, effectively destroying the source
code and replacing it with different source that is a serialised version
of the tree.
For a current notional example, it would be like loading a simple...
try {
$object-$do_something;
} catch (Exception $problem) {
handle($problem);
}
... changing -$do_something to -$do_something() to make it
back-portable, and then ending up with...
Module::Exceptions::initialize('line 98');
my $exceptionhandler = Module::Exceptions::prepare();
eval {
$exceptionhandler-update_status('in try');
$object-do_something();
};
if ( $@ ) {
if ( ref $exceptionhandler ) {
require Scalar::Util ();
if ( Scalar::Util::blessed $exceptionhandler eq 'Exception' ) {
do {
my $problem = $exceptionhandler-fetch_exception_as('$problem');
# handler starts here
handler($problem);
$problem-clean_up;
};
}
} else {
# Just die as normal
die $@;
}
}
While technically they may be identical once they get through the parser
and into tree form, trying to changing -$do_something to
-$do_something() and getting back some huge monster chunk of code you
didn't expect is definitely not what the intent of parsing it in the
first place was.
This is what I am talking about when I refer to the Frontpage effect,
the habit Micrsoft's HTML editor (especially the early versions) had of
reuilding you HTML document from scratch, deleting all your template
variables and PHP code and generally making it impossible to write HTML
by hand. For HTML where you arn't MEANT to be writing stuff by hand
under normal circumstances that wasn't always a problem, but perl _isi_
meant to be written by hand.
You could even grab the comments and do something sick
with them (see Damian :-). Or better yet, do something that PPI
doesn't, and add some sub call around all statements, or determine the
meaning of brackets in a particular context.
The question of whether to execute BEGIN blocks is a tricky one.
Sometimes they change the parse of the program. Sometimes they do other
stuff. All you can hope for is that people understand the difference
between BEGIN (change parsing) and INIT (do before the program starts).
Frankly that is a gaping security hole... not only do I have to still
deal with the problem of loading every single dependency or having no
parsing ability otherwise, but I am required to trust every perl
programmer on the planet :(
I love PPI, by the way :-)
Thank you, I do to :)
But I'd like to still have something like it in perl6 :(
Adam
Re: Will _anything_ be able to truly parse and understand perl?
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 as I can tell). So why not discussing this somewhere else? (e.g. clpmisc) One of the biggest problems I have had with perl5 is that nothing, not even perl itself, can truly actually parse Perl source. By this, I mean parse False: [Nothing but] perl can parse Perl. (Tom Christiansen) Please see Acme::BadExample. perl itself cannot parse this at all, and yet it follows the absolutely most basic syntax for the language. 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. Adam
Re: Will _anything_ be able to truly parse and understand perl?
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.
Re: Will _anything_ be able to truly parse and understand perl?
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? What, exactly, is it that you want? What I'm after are 3 critical features. 1. You always get back out what you put in. $source eq serialize(parse($source)). 2. No side effects. Autrijus Tang suggests this may be workable 3. You can parse a document with broken dependencies. There are a myriad of these situations, such as - Dependencies you don't have - Editing on different platform to execution platform (think Win32:: or S390/mainframe/GridComputing) - Unfinished code - Things you can't get installed (ImageMagick etc) - Example code that will never be executed (Imagine if you will a mod_perl syntax highlighting module for search.cpan.org. Should the search.cpan.org host have to _install_ every single one of the modules in CPAN?) PPI can do all of these 3 things. Not 100% reliably, but for normal code (where normal is actually defined fairly broadly). In any case, I would like to suspend this debate for a week, as I'll be talking with Damian (hopefully) at YAPC.AU. I'll report back afterwards, having hopefully imparted the full extent of my problem. Perl 6 rules or some variation therein may indeed be what I'm after, although I need to find out more about the internals. Do we have a working version yet I can create some demonstrations with? Adam
Will _anything_ be able to truly parse and understand perl?
talk of adding extendability in some how, but that's an idea for another year (or decade). Keeping the normal slight changes in grammar under control has been bloody hard, but dealing with arbitrary grammar manipulation would be just plain impossible. But then I'm fairly comfortable in that source filters are consider scary and dangerous and everyone knows not to play with them unless you really need to, so it's fine to say PPI does not support source filters. Getting (finally) to perl6, I could have sworn I saw an RFC early on which said Make perl6 easier to parse. But it would appear the opposite is occurring. Source filters have become grammars and will now be officially approved and acceptable (yes?) while so far as I can tell the problem of prototype vs operator/operand interaction is not being addressed. (I'm a little in the dark here, perhaps it is and nobody has noticed enough) What information I have managed to get from MAGNet #perl suggests that the approved way of manipulating code will be to parse it via a grammar into primitives, manipulate the primitives and then write it back out as those primitives. Excuse my terminology here if I'm not using the exact terms you guys have been using. But in any case, I take it the grammars are like Scheme MACROS (correct term?) or source filters and only work in one direction. That is, you can't take the result of whatever the grammar transformation is and reverse it back into the original code. Suggesting to #perl that manipulating code this way and writing it back would completely destroy the code (certainly from a maintainability standpoint) seemed to just seemed to get shrugs from the audience. I know it's probably a bit late at this point to making huge changes (at the time the RFCs were being done I wasn't really confident enough in my knowledge to suggest anything), but I really would like to make the point that by going down this route of becoming less parsable we may well be sacrificing a huge range of potential analysis and manipulation technologies by making perl source even more impossible to document-parse than it already is. Any comments or feedback you have on the 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
