Re: Perl grammar for Perl5 - Perl6
Hi Peter, There are several source filters that make select changes and modules that give select Perl 6 features to Perl 5. All in all, there's a lot there -- I've written Perl6::Contexts, for example, which diddles the bytecode to give Perl 5 programs most of the new contexts from Perl 6. In fact, I kind of even wrote a book on doing this stuff... http://www.perl6now.com. If you download the code listings, you'll get examples of a couple dozen of these modules. As far as your example of $array[idx], see Perl6::Variables. I have non-release version on Perl6::Variables in my CPAN area, SWALTERS, that adds more of the Perl 6 changes. I know this isn't the approach you had in mind, but I thought I'd mention it, as there is actually stuff there to play with. Fundamentally, regexen to transform a Perl program aren't a bad idea, but this approach, of fixing up Perl 5, is less likely to introduce bugs into the code and keeps the production-ready environment that Perl 5 is. Transforming the code isn't a bad idea where there are transformations, but in many cases, there aren't. I suppose that could be a fatal error, but people would still be trying to convert their Perl 5 programs, much as when people where converting to C from B, and any failure scenario would create a flood of help requests, bug reports, etc. I hope this helps! Best regards, -scott On 0, Peter Schwenn [EMAIL PROTECTED] wrote: Dear Perl6 Language, I am Perl user from near year 0. For me the easiest way to learn (, track, and get to the point of contributing to) Perl6 would be a Perl grammar (a regex rule set in, preferably, Perl6) that transforms any Perl5 script into a Perl6. Of couse, besides learning Perl6 for a regex'r or Perl5'r such as myself, and tracking, and documenting 6, it would have huge use for Perl5 users making or considering the transition. For example one can infer the structure and some of the rules from http://svn.openfoundry.org/pugs/docs/other/porting_howto which is however written out in informal (not regex) rules such as $array[idx] - @array[idx] Is there such a Perl5-Perl6 translator underway? Sincerely, Peter Schwenn www.schwenn.com p.s. I'm not yet up to originating a good one, but believe I could make contributions in extending and checking it. p.s. A Perl5 starting point might be better since running it on itself would provide and initiate at least 2 major test modes. p.s. The developing form of such a grammar could likely lead to a grammar package which facilitates rule sets for languages in other domains, in terms of illuminating means of choosing among modes for rule ordering, collecting, scoping, re-application, recursion, exclusion and so forth.
Re: [Phoenix-pm] Perl grammar for Perl5 - Perl6
Oh, sorry... Larry Wall didn't actually to Phoenix-pm. At least not that I know of. This was a forward from me. Thought ya'll might find this interesting... on a Perl 5 level, in a Perl 6 sort of way, and also on the subject of software refactoring. -scott On 0, Larry Wall [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 11:51:52AM +0200, Yuval Kogman wrote: : On Wed, Dec 07, 2005 at 16:48:11 -0500, Peter Schwenn wrote: : Dear Perl6 Language, : : I am Perl user from near year 0. For me the easiest way to learn (, : track, and get to the point of contributing to) Perl6 would be a Perl : grammar (a regex rule set in, preferably, Perl6) that transforms any : Perl5 script into a Perl6. Of couse, besides learning Perl6 for a : regex'r or Perl5'r such as myself, and tracking, and documenting 6, it : would have huge use for Perl5 users making or considering the : transition. : : IMHO machine translation is not that good a way to start learning - : the real benefit of Perl 6 is in the features which have no perl 5 : equivalents and solve problems much more elegantly. Except it would be lovely to have a smart enough refactoring translator that it could recognize where those elegant solutions are possible and at least give the option of attempting them. Or at least a hint that there might be a better way. : The best thing to do is to hang out on #perl6 and get involved with : the test suite, as well as reading the synopses. : : Perhaps writing a toy program or something like that could also : help. Sure, but some of our toys are bigger than others. :-) : Is there such a Perl5-Perl6 translator underway? : : Larry Wall is working on using the perl (5) interpreter to create : compiled output (as opposed to just something that executes in : memory) that can then be read by a translator without actually : parsing perl 5. Yes, I have a version of 5.9.2 that dumps out some *very* strange XML that represents, as closely as possible, the exact meaning of the code to Perl 5, along with all the syntactic bits. I then filter that strange XML back into something approximating an AST. I am in the process of proving to myself that I'm getting enough information out of this to recreate the original Perl 5, so I jokingly call this my Perl5-to-Perl5 translator. As of today, I'm able to translate 76.57% of the t/*/*.t files that come with the Perl distribution. Considering that last week this number was down at about 5%, it would seem that I've been making a lot of progress. But most of the work went into that first 5%, and a lot of work will likely go into the last 5% as well. To get that first 5% I basically had to completely refactor the lexer and the grammar without changing anything, which is of course impossible. The Perl 5 parser forgets or misplaces an astounding variety of information that the translator needs, and you can't just go and tell it to turn off the optimizations, because in fact most of those optimizations are deeply interwingled with semantic analysis and transformations as well. Basically, every skipspace() in toke.c and every op_free() in op.c and every rule reduction in perly.y loses necessary information. To attempt to do what I'm currently doing you would have to be completely insane like me. It's a total nightmare. If I were Catholic I'd be hoping this all counts as pennance for my past sins, and gets me out of 100 million years of Purgatory or so. But being a Protestant, I'm merely repenting of my past sins, and thinking about maybe repenting my future ones. And if I were Jewish I'd've said Oy vey many times over. :-) Anyway, once I get to 100% of the t/ files, I'll make it translate all of CPAN back to itself. And at some point I'll take a first whack at the Perl5-to-Perl6 translator, then open it up for community participation. It's still just a bit too early for that, though, because there's such a delicate interplay between refactoring bits of perl without changing anything vs trying to guess whether we are getting enough type and structural information out to recreate the original in the backend. There are already more than 1 lines of code in the backend just to undo the damage done by the Perl 5 engine. : Before this happens this will be very very hard - the high level : language has vast amounts of implications on execution etc, but the : opcode tree is much more simpler to predict (for a computer). Right. But my intent is to write a really good translator, and that implies that it has to be a multi-level translation. That involves keeping track of all the subtle semantic and pragmatic information as well as the basic syntactic information. Otherwise we might as well just feed Perl 5 to babblefish and see if Perl 6 comes out... : p.s. The developing form of such a grammar could likely lead to : a grammar package which facilitates rule sets for languages in
community involvement - Was: Re: backticks
Since this horse came back to life, I'm going to give it a good thrashing, and
I've got goons to help me.
I've asked the Phoenix Perl Mongers for their take on the situation. I've posted
a _completely_ unbiased synopsis of the situation. Here are excerpts from the replies:
Tony's take:
Rename Perl 6 to something else.
Tony never posts more than a single line in reply to anything but replies to
everything.
This comment appears to be in response to %foobar, the gullimets, and the behavior
of %foo{shift} changing to mean %foo{'shift'} with no reguard for %foo`bar except to
dismiss it.
Perl 6 i going to end up looking like Morse Code. =)
This was a second, seperate reply, also consisting of a single line. I corrected Tony,
reminding him that Morse Code only has dots and dashes - no gullimets. Ada is the
common analogy, and I reitterated this. Tony then pointed out that he worked at the
Pentagon and many contractors refused to use Ada, holding out with Jovial until after
the Ada push had passed. Funny that now days many government workers hold out
against other languages, refusing to give up Ada.
Eden's take:
I like it, but I don't see why perl can't just adopt the dot like Java and C.
I forgot to mention that . was unusable because Perl 6 autoboxes, so this
misunderstanding
was my fault, not Eden's. Eden went on with a discussion of string concatonation versus
subscripting which made me nod my head. Eden also wanted to know that currying was
still
going to be there - yes, though it is no longer automatic.
Andrew's take:
Scott, I can tell you without hesitation that I /hate/ this. Mostly for
the cons you've already specified.
I agree wholeheartedly here, and with the poster that said, call it
something besides Perl 6.
In a later post, Andrew conceded that %hash`foo isn't really more complex
(I pointed out that it is up in the air whether %hash`foo is more or less
complex), and goes on to say:
True, and I do generally like JavaScript, and do like that syntax
feature. OTOH, it also looks a bit like PHP, and I generally hate PHP.
I've attached my summerized pros and cons at the end for reference. Andrew writes
meticulously clean Perl. He went on to express hope for reduction of complexity
and fewer synonyms in Perl 6.
Doug's take:
Personally, I don't mind typing the {} [edited], so I don't particularly feel the
need for extra syntax. ... I probably just won't use the new syntax.
The new syntax was used to describe %foo`bar specifically. Doug is the head
Perl monger and an unfailing voice of reason.
Victor's take:
I've worked in APL. Terse is *not good*. (Although having
matrix inversion built into the language definitely rocks.)
Sign me stuck in the mud. If the mud is Perl 5.8, it's not
half bad.
Victor wrote a two page email that was interesting and entertaining.
I've attached a slightly edited version to the end of this document.
Michael's take:
... I'd vote against using backtick
in this instance. For one thing, it'll throw my editor's syntax
coloring off, because it assumes that you'll always have a matched
pair. :-)
In general, though, I'm with the group that says there's nothing wrong
with being verbose. I'd rather have a clear %foo{bar()} and
%foo{'bar'} which fit my existing ideas of programming syntax* than
something involving single quote marks.
But, TMTOWTDI, and since I'll never use the single backtick in any
related context, it really doesn't matter for my personal coding.
Michael went on to praise Perl, in its current incarnation, for still being
readable by programmers of other languages, citing ==, =, , and so on,
concluding that standard usage of symbols is a Good Thing, even though it
stretches the use of the symbols a bit.
Michael also writes Java and has shown disposition towards clean code,
having done an excellent presentation on writing tests as a way to
life and increased productivity.
Summary:
I'm doing this as an experiment towards community interest - both generating
it and making it visible.
Unlike PerlMonks or IRC, Phoenix Perl Mongers is a reasonable representation of
people who use Perl - PerlMonks, IRC, and lists tend to attract power users,
academiacs, and hackers.
This makes Phoenix Perl Mongers an interesting test bed. They're largely
professional Perl programmers. They show up to presentations that expose how
other companies are using Perl, share time saving techniques, and explain
how difficult problems were solved. Examples of production code draw
crowds. Academic topics and advanced features are less interesting, but there
is an interest in how things are done outside of the Perl world.
5 people believe they wouldn't use %foo`bar. 1 person likes it. Resolve not
to use it seemed to be the common message. Only a few people hinted that they
would prefer it not be in the language at all, suggesting that there are too
many ways (or agreeing with that point in the Cons). More people cited TMTOWTDI
than complained of too many
Re: backticks
Let me summerize my undestanding of this (if my bozo bit isn't already
irrevocably set):
* %hashfoo retains the features of P5 $hash{foo} but does nothing to counter the
damage of removal of barewords
* %hash`foo occupies an important nitch, trading features (slice, autovivication)
to optmize for the common case, undoing the pain of the loss of barewords,
serving as even a superior alternative
* %hash`foo and %hash ~ `ls` can coexist without breaking anything as this is currently
illegal, unused syntax
* %hash`foo can be added by the user, but users are seldom aware of even a small
fraction
of the things on CPAN and there is a sitgma against writing non-standard code
* %hash`s is an example of a small thing that would be easy to implement in core
but would be used constantly (if JavaScript is any indication, every few lines),
giving a lot of bang for the buck
* Rather than eliciting public comment on %hash`foo (and indeed %hashfoo)
the proposal is being rejected out of hand (incidentally, the mantra of the Java
community Process seems to be you don't need X, you've got Y, and it took
.Net before they woke up and realized that maybe they should consider their
community in the community process - after ignoring a universal call for
generics for over 5 years it's little wonder .Net ate their cake)
-scott
On 0, [EMAIL PROTECTED] Juerd [EMAIL PROTECTED] wrote:
Aaron Sherman skribis 2004-04-15 14:29 (-0400):
On Wed, 2004-04-14 at 16:56, Juerd wrote:
How many of those backticks
Note, those weren't backticks, those were programs. There were 123
PROGRAMS that used backticks or equivalent syntax.
I said backticks, and I meant backticks. I'm not sure why there is
confusion over this.
Perhaps this can disambiguate: how many of those backticks in those 123
programs.
And how often are simple hash subscripts used?
Very often.
Many times as often as qx and friends?
Security is not an issue for this code.
It should be.
code review? You made and assertion: backticks aren't used much. That
assertion is faulty.
I didn't formulate my statement carefully enough. I should have said:
as much as hash subscription.
Executing external code is commonplace, and probably done more often
than method invocation in the wild!
I want to doubt that. Or better: help change that.
It's just one keyword and a set of quotes more: $( readpipe pwd )
And thus, it is not like the bash/zsh style syntax in the least.
Why should Perl have to limit itself to shell-like syntax? It doesn't do
that with if-constructs, foreach-loops, procedures, etcetera, etcetera,
etcetera.
Unless there is substantially new information in this thread, I think
you have presented your case for yet another new subscripting syntax.
I think I have presented two cases. The removal of `` and the
introduction of %hash`key. Either can be implemented without breaking
the other, though I obviously think both letting `` go and introducing
the infix ` is better.
Juerd
Re: backticks
It's you. * My objection to the Java community process applies in _some_ _small_ part to the Perl community process. I present it as a negative ideal with the implication that it should be avoided. * My objection to it being rejected out of hand applies not to the Perl community process nor to the people that think i's ugly. I don't argue subjectives. I say people are eager because they've ignored repeated clarifications, continueing to cite groundless technical reasons. That I can aruge =) I interpret this as haste, and it is this haste I object to. * Hence my goal to summarize and prod gently at the eagerness of some. So, my apologies to who anyone who feels unfairly or excessively criticized, except chromatic. There is no forgiveness for someone who seeks out irked people with the single goal of further irking them. Since chromatic is so eager to be offended on behalf of other people I hope you really enjoy being offended. Na na na! One of these days I'm going to resolve to hunt you down to irritate you as you do to me. -scott On 0, chromatic [EMAIL PROTECTED] wrote: On Thu, 2004-04-15 at 12:27, Scott Walters wrote: Without commenting on the rest of the proposal, please allow me to clear up one point: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand This whole thread *is* public comment. Some people like it, some people don't. Some people think it's useful. Some people think it's ugly. Some people think it simplifies things. Some people think it complicates things. Larry hasn't weighed in. Larry might not weigh in. Larry might like it. Larry might not. Larry might think it solves a real problem and come up with a nicer unification that almost everyone can live with. Hey, it's happened plenty of times before. (incidentally, the mantra of the Java community Process Now that's just rude. You are welcome to think that a certain proposal you like is the best thing ever and should certainly go in Perl 6 for whatever reason -- but claiming that the proposal has been rejected out of hand on a public mailing list where people are discussing the proposal and some people like it and some people don't is rather silly. -- c
Re: backticks
When I announced that I fixed a version of Perl6::Variables to do ,
crickets chirped. I dislike having to place a lot of matching quotes,
brackets, parenthesis, and braces in my code. You must stop and
visually inspect code to make sure it balances out and even then is a
common source of bug causing typos.
I've been working in Pike's predecessor, LPC, lately. Arrays and hashes
are both subscripted with []
foo[bar][10][baz]
Variables are autoconverted to the correct type. This has two drawbacks.
Visually inspecting the dreference sequence, you can't tell whether this
is an hash of arrays of hashes or a hash of arrays of arrays. If { }
were used to deference hashes, you'd be able to tell.
Second, autovivication is impossible for the same reason. We can't tell
from parsing this lone expression whether baz should be converted to numbers
or strings automatically.
Enough science, time for anecdotes!
If you can't remember what a data structure looks like, it doesn't matter if
the code spells out the sequences of hash-array-hash each time - you're
going to spell it out wrong. People new to Perl and new to data structures
have this problem all the time - they can't keep straight what the data structure
*is*.
I adjusted to the lack of autovivication very quickly and easily. I'd sacrifice
autovivication *much* sooner than I'd sacrifice a concise subscript syntax.
Data structures are really only ever initialized in a few places in code
except in pathologically badly written code. This adjustment was akin to the
use warnings's handling of undef reguarding Use of unitialized value.
Hardcoding things around is normally considered bad, and in LPC at least once
in the past month, I've switched an array to being a hash. I was able to do
so without rewritting all of the code that accesses the data structure -
it automatically began accept strings as well as numbers for keys in the
subscript. Hence, using { } vs [ ] might be providing too much redundancy.
And since when have we forced people to be explicit in Perl?
In LPC and apparently Pike, it is all or nothing. Perl can have it's cake and
eat it too. If you want autovivication and information about your datastructures
hardcoded around, use {}, [], and . If you want concise code, use `. I'd
actually go one further and coopt the . operator and emulate JavaScript more
closely, but I admit the visual distinction between method calls and subscripts
might warrent the noise.
Re: the re-adjustment, after 5 years of heavy Perl programming, LPC's relatively
simple syntax is extremely soothing. The only thing I'm really missing is
list flattening, implicit or explicit, frequently doing things like
bar(xyz[foo][0], xyz[foo][1], xyz[foo][2]).
Let me summarize. The gripes about you can't do that with `! miss the point.
Two ways to subscript is not too many. The simplicity available from it is far
from the terse line noise associated with Perl but is something worthy of
languages billed as clean and readable (Pike, not JavaScript). There are
distinct advantages besides concise to this syntax that make it desireable.
So, I strongly support ` or something equivilent.
-scott
On 0, Juerd [EMAIL PROTECTED] 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}.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics.
I agree.
I don't think this proposal does the latter.
I disagree.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
Or I could use something that modifies the grammar Perl uses. Almost any
syntax feature can be added outside the core. I'm not exploring the
possibility of this operator, but suggesting that it be in the core.
This operator is possible, improves readability, eases typing and does
not clash with something that already exists.
Yes, it does mean learning the meaning of one
Re: backticks
Juerd,
You'd do well to not remove the conclusion of my post when the conclusion
is that the I strongly support you. Otherwise, your reply, read out of
context, sounds like you're fending off an attacker ;)
People would do well to seperate the merits of the idea from the merits of the
suggested implementation. I'd like to see people say I like the idea but
the implementation isn't workable or alternatively The ` operator isn't
that important but I'm not sure the idea merits the change. I hate one
negitive with the other implied.
If I understand correctly, Perl looks for either a term or operator
at any given moment. %hash and `rf -rm *` are both terms, hence
%hash `rf -rm *`
makes no sense. Aside from playing hell with editors quoting, something
proposed to be solved by making the real grammar of Perl available in
a modular way for inclusion in editors, is there any reason that they
couldn't coexist?
%hash ~ `rf -rm *`
%hash`rf`rm
Failing that, back to whitespace dependencies?
%hash{'aliens!!'}
for keys %hash {
.ate_my_buick
}
-scott
On 0, Juerd [EMAIL PROTECTED] wrote:
Randal L. Schwartz skribis 2004-04-14 13:56 (-0700):
Juerd == Juerd [EMAIL PROTECTED] writes:
Juerd readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses
Juerd can be found. Most are in Debian's modules.
That's because they aren't particularly interesting in modules, but
in 10 line scripts, they show up quite frequently.
This undermines the rest of your request.
How unfortunate that you didn't notice that I made two separate
requests, that both have to do with backticks.
Request one: Remove `` and/or qx, because its interpolation is dangerous
and solutions like it should be discouraged.
Request two: Add %hash`key
%hash`key can exist without `` gone. `` can be removed without ` meaning
something else. It would, however, for understandability, be nicer if
both requests were granted.
Please, re-read my post and comment on the second request as
insightfully as you did on the first.
Juerd
Re: backticks
I propose we pretend that $$foo = 'bar' stills work and use that as a benchmark
for hash subscripting ease. If it requires fewer keystrokes or neuron fires to
write Perl 4 code, then Perl 6 might be succeding on the programming in the
small but failing at programming in the large.
${'bar'} = 'baz!'
%foo`bar = 'baz!'
%foobar = 'baz!'
On a related note, has anyone seen my semicolon key? It was last spotted in
central park around 5am...
-scott
On 0, Simon Cozens [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Aaron Sherman) writes:
$ find . -name \*.pl | wc -l
330
$ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
123
`` gets used an awful lot
But that's in Perl 5, which is a glue language.
--
Though a program be but three lines long,
someday it will have to be maintained.
-- The Tao of Programming
Re: lists and arrays
What is a list reference?
What is an array?
...
What is a list?
Hi Juerd,
There was a thread on this not long ago. I forgot it's name.
Apo 2 said:
[1,2,3]
is syntactic sugar for something like:
scalar(list(1,2,3))
... suggesting that lists could have references taken to them, much like an
array. But then again, the something like gave some wiggle room there.
More recently, it was amended to:
scalar(array(1,2,3))
(Still no spaces after the commas, grr)
As best as I can find there has been no official announcement.
It has been suggested that all hashes, arrays, and objects are essentially
references. This is consistent with other languages where two things are
true at the same time:
1. Arrays and such are passed by reference
1. You don't have to dereference arrays and such before using them
Heh, there's that thread: It's subject was Re: Arrays, lists, referencing (was
Re: Arrays vs. Lists)
Let me quote a message from it. Juerd's original message is quoted below.
I think this was the most coherent, least objected to message before the subject
line really became a lie:
From: [EMAIL PROTECTED] (Michael Lazzaro)
On Tuesday, February 11, 2003, at 04:56 PM, Deborah Ariel Pickett
wrote:
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just
50%
of them?
(1..10).map {...}
[1..10].map {...}
And somehow related to all this . . .
snip
I think some of this is in A2, but not all of it.
Here are some of the answers from my own notes. These behaviors have
all been confirmed on-list by the design team:
An @array in list context returns a list of its elements
An @array in scalar context returns a reference to itself (NOTE1)
An @array in numeric (scalar) context returns the number of elements
An @array in string (scalar) context returns a join of its elements
An $arrayref in list context returns an arrayref (NOTE2)
An $arrayref in scalar context returns an arrayref
An $arrayref in numeric (scalar) context returns ??? (NOTE3)
An $arrayref in string (scalar) context returns ???
Note that that's pretty consistent with how it works now.
(NOTE1): This is the big change. It's what allows us to treat arrays
as objects, and call methods on them like @array.length. I don't think
anyone will argue that's not a good thing.
(NOTE2): Note that this is a non-change. If we changed it so that an
arrayref flattened itself in array context, you could never have
complex data structures, because [[1,2],[3,4]] would always be the same
as [1,2,3,4].
(NOTE3): I have not been able to find explicitly confirmed behaviors
for these two. It has been implied that they return $arrayref.length
and $arrayref.string (or whatever those methods are called). Maybe.
On 0, Juerd [EMAIL PROTECTED] wrote:
Hi,
I'm lost. I read some Perl 6 related things and think I missed an
important announcement.
What is a list reference?
It is as if lists and arrays are the same thing in Perl 6, but other
documents use the words as they are used in Perl 5.
So I guess my actual questions are:
What is an array?
What is a list?
Regards,
Juerd
Re: hash subscriptor
I've updated Damian's Perl6::Variables module to treat %foo{bar} as %foo{bar()}
and to handle %foobar and %foobar baz. If this syntax is finalized, I'll
send Damian a patch.
This is at:
http://www.cpan.org/modules/by-authors/id/S/SW/SWALTERS/Perl6-Variables-0.02_001.tar.gz
http://slowass.net/~scott/Perl6-Variables-0.02_001.tar.gz
I'm eager to hear if %foobar becomes permanent. Bug reports welcome.
I'm not supporting the utf-8 version of because all of my software
handles them incorrectly in different ways but if there is enough demand, I might
accept a patch. (Just kidding, I will accept a patch).
-scott
PS:
The other thing I was threatening to write, hyper operators in P5 via overload
and hyper keyword, well, I couldn't quite get it to work in a useful way.
Couldn't figure out how to get real arrays out of an over loaded op, and from
what I know about P5, I don't think it is possible.
You can do whatever you like with this excpet time-shift it or view it on Linux.
On 0, Larry Wall [EMAIL PROTECTED] wrote:
On Mon, Mar 15, 2004 at 11:56:26AM -0700, John Williams wrote:
: On Wed, 10 Mar 2004, Larry Wall wrote:
: You subscript hashes with {...} historically, or these days, «...»,
: when you want constant subscripts. So what you're looking for is
: something like:
:
: if / ?foo ... ?baz ... { $?foo{'baz'} ... $?baz } .../
: or
: if / ?foo ... ?baz ... { $?foo«baz» ... $?baz } .../
:
: I'm probably a bit behind on current thinking, but did %hash{bareword}
: lose the ability to assume the bareword is a constant string?
It's thinking hard about doing that. :-)
: And why «»? Last I heard that was the unicode version of qw(), which
: returns an array. Using an array constructor as a hash subscriptor is
: not a least surprise to me.
We'd be trading that surprise for the surprise that %hash{shift} doesn't
call Cshift. Plus we get literal hash slices out of it for free.
Plus it also works on pair syntax :foo«some literal words». And probably
trait and property syntax as well.
And basically because I decided :foo('bar') is too ugly for something
that will get used as often as switches are on the unix command line.
The %hash syntax is just a fallout of trying to be consistent with
the pair notation. Once people start seeing :foo«bar» all over,
they won't find %hash«bar» surprising at all, and will appreciate the
self-documenting literalness of argument.
And unfortunately it's an unavoidable part of my job description to
decide how people should be surprised. :-)
Larry
Re: hash subscriptor
Whoops, that didn't work at all. Forgot about the %foobarbaz case
and it was losing the subscripts entirely.
Let's try that again...
http://www.cpan.org/modules/by-authors/id/S/SW/SWALTERS/Perl6-Variables-0.02_002.tar.gz
http://slowass.net/~scott/Perl6-Variables-0.02_002.tar.gz
This version still doesn't handle %foo{'bar'}baz.
Thanks,
-scott
On 0, Scott Walters [EMAIL PROTECTED] wrote:
I've updated Damian's Perl6::Variables module to treat %foo{bar} as %foo{bar()}
and to handle %foobar and %foobar baz. If this syntax is finalized, I'll
send Damian a patch.
This is at:
http://www.cpan.org/modules/by-authors/id/S/SW/SWALTERS/Perl6-Variables-0.02_001.tar.gz
http://slowass.net/~scott/Perl6-Variables-0.02_001.tar.gz
I'm eager to hear if %foobar becomes permanent. Bug reports welcome.
I'm not supporting the utf-8 version of because all of my software
handles them incorrectly in different ways but if there is enough demand, I might
accept a patch. (Just kidding, I will accept a patch).
-scott
PS:
The other thing I was threatening to write, hyper operators in P5 via overload
and hyper keyword, well, I couldn't quite get it to work in a useful way.
Couldn't figure out how to get real arrays out of an over loaded op, and from
what I know about P5, I don't think it is possible.
You can do whatever you like with this excpet time-shift it or view it on Linux.
On 0, Larry Wall [EMAIL PROTECTED] wrote:
On Mon, Mar 15, 2004 at 11:56:26AM -0700, John Williams wrote:
: On Wed, 10 Mar 2004, Larry Wall wrote:
: You subscript hashes with {...} historically, or these days, «...»,
: when you want constant subscripts. So what you're looking for is
: something like:
:
: if / ?foo ... ?baz ... { $?foo{'baz'} ... $?baz } .../
: or
: if / ?foo ... ?baz ... { $?foo«baz» ... $?baz } .../
:
: I'm probably a bit behind on current thinking, but did %hash{bareword}
: lose the ability to assume the bareword is a constant string?
It's thinking hard about doing that. :-)
: And why «»? Last I heard that was the unicode version of qw(), which
: returns an array. Using an array constructor as a hash subscriptor is
: not a least surprise to me.
We'd be trading that surprise for the surprise that %hash{shift} doesn't
call Cshift. Plus we get literal hash slices out of it for free.
Plus it also works on pair syntax :foo«some literal words». And probably
trait and property syntax as well.
And basically because I decided :foo('bar') is too ugly for something
that will get used as often as switches are on the unix command line.
The %hash syntax is just a fallout of trying to be consistent with
the pair notation. Once people start seeing :foo«bar» all over,
they won't find %hash«bar» surprising at all, and will appreciate the
self-documenting literalness of argument.
And unfortunately it's an unavoidable part of my job description to
decide how people should be surprised. :-)
Larry
Re: Semantics of vector operations
This is still raging. I was going to let it slide. I hate the mechanics
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.
On 0, Luke Palmer [EMAIL PROTECTED] wrote:
Agreed. Cryptic, but in a different way than usual. I'd rather see
plain old keywords as long as I'm typing things out or making that
many key-strokes.
sub each (*);
each @arr += 3;
each @arr += each @foo;
That would be a hard macro to write. Not impossible, of course :-)
I'm not sure it's a good idea to change the syntax just because Unicode
is unavailable. There was a definite reason for bundling the each
modifiers near the operator, and we'd be changing that. You also get
ambiguities regarding to which operator the Ceach applies if there is
more than one.
On the other hand, it does read quite wonderfully, unlike the seeming
alternative:
@arr each += each @foo;
What about just a function?
each(infix:+= , @arr, @foo)
Such that the Unicode is the only way to get at the syntactic shortcut?
We've done a lot to make functions readable in a lot of ways. Indeed,
there are many ways the function could work. A function that operates
on alternating arguments may not be unhandy either:
I really like this too. It is like Lisp's special forms: apply operator to data
in interesting way. It opens the door for numerous other operations in
a generic system. Maybe Damian will champion this for us =)
Taken to an ugly extreme, it could look like the correlation I wrote for
AI::FuzzyLogic, where sets permutate, correlate, or aggregate. Creating a framework
where this can exist outside of core prevents something horrid from being
suggested for core =)
each(infix:+= , zip(@arr, @foo))
But that's getting pretty far away from what the operators originally
intended.
This isn't very far away from map when used on built-ins.
@foo = map infix:*, zip(@foo, @bar);
map - $a is rw, $b { $a *= $b }, zip @foo, @bar; # except that zip would copy in
all probability
each() as a map type operator that applies operators (and other closures), modifying
the LHS, covers what people want to do with vectorized operators and covers
gaps in map.
So, in summary, I really like Luke's proposal.
-scott
Larry Wall suggested reading and as each.
This would require a small comprimise on the p5 each. Or else it could be
named vector. Shouldn't be a problem with %hash.keys, %hash.values,
%hash.each anyway.
Perl5 Ceach is going away anyway, in favor of the new construct:
for %hash.kv - $k, $v {
...
}
This wouldn't implement as an operator very well, admittedly, but more like
a control keyword. It would seem closely related to foreach, though.
Which is also going away :-)
What happens when there are a bunch of the puppies? Vectorizing operators
do the right thing, working according to the rules of precedence. each
would have to just share one iterator per statement, or else do ugly things
to the rest of the statement. It would be very difficult to do something like:
(each @foo + each @bar) + (each @baz + each @baz)
Don't worry about implementation. That's not our job.
It would probably be implemented as a macro that just put it back into
the Unicode notation.
This would lend itself a P5 backport that did overload on its argument, too. If
it found that the thing on the right hand side was also overloaded into the
same class, it is could use a single iterator on both sides, otherwise it would
treat the 2nd argument as a scalar. This would solve the single iterator
per line problem for p5 atleast. It would work correctly. Any number of
vectorized arrays could be floating around in an expression, each interacting
with each other correctly.
Of course you mean 損interacting with束 other correctly. :-)
Would it be possible to subclass things on the fly, returning a specialized
object representing the argument that knew how to vectorize when asked to add?
Aren't add, substract, multiply, and so on, implemented as class methods in
Perl 6, much like Perl 5's overload module?
No! And I couldn't be happier! They're multimethods, dispatching based
on Iboth their arguments, not just the left one.
Luke
