Change Propagation
Backing off from the esoterica, is Per6 lazy machinery going to include a feature like the one I suggested for MooseX here: http://www.perlmonks.org/?node_id=1050219
Re: Commensurability as Key
The terms function and relation as used in programming languages have meanings carved out of the pure concepts by the, sometimes, judicious application of Ockham's Chainsaw Massacre in order to get things done. I am speaking of the pure concepts. Procedures are sequences of statements. Statements are state transitions. The before state is the input to the statement viewed as a pure function. The after state is the output of the statement viewed as a pure function. On Tue, Aug 20, 2013 at 10:41 AM, yary not@gmail.com wrote: I'll bite... this concept of commensurablity is not one I grasp from your email. functions are (sugarably) degenerate (many to 1) relations and procedures are (sugarably) degenerate (state-transition) functions. Perl many other languages don't have a strong distinction between functions procudures (as I'm sure you know), a function is a subroutine returning a scalar, a procedure is a subroutine with no return value, side-effects only. A subroutine returning many values- a parcel of containers, perhaps, or an iterator, etc- is a many-to-many relation. I understand relational algebra from decades of SQL work, and have seen ORM's replicate relations in object systems with some success. What's missing for creating a relational wonderland in perl6? (Also: a ton of apples should _not_, in general, be added to 3000 kg of oranges- unless I operate a refrigerated shipping line, in which case all I care is that they are subclasses of perishables... Adding an acre of orchard to a season in the sun might be less commensurable, though they could both be subclasses of gifts to a lucky winner... hmmm... what was the point again?)
Re: Commensurability as Key
Maybe Perl 7. On Mon, Aug 19, 2013 at 2:30 PM, Parrot Raiser 1parr...@gmail.com wrote: Let's get the basics nailed down and working so that we can learn them, before wandering any further into theoretical CS. On 8/18/13, James Bowery jabow...@gmail.com wrote: Of the two key conceptual gaps in current programming language philosophy -- commensurability and change propagation -- commensurability, if filled with due rigor, has the greatest potential for clearing up confusion by recasting other core features as derivative. Change propagation (eg: properly voiding memoization in lazy functional evaluation aka incremental tabling maintenance in relational evaluation) is something I attempted to address in Perl back in 1999 but was blocked by a bug in recursive use of the tie machinery. However, since that time I've come to the conclusion that as important as change propagation is to put into the core machinery, it isn't nearly as fundamental as is commensurability. Let me introduce commensurability with the seemingly trivial example of units conversion. Units conversion is normally tacked on as an after-thought in programming languages. (Digression: One programming language that had units built into the compiler was the PLATO system's TUTOR programming language -- a generally nasty language which I encountered while programming Spasimhttp://en.wikipedia.org/wiki/Spasim -- that, nevertheless, pioneered some interesting concepts due to the relative lack of precedent in programming languages targeting ordinary people like teachers.) However, while doing real world calculations, correct handling of units via automatic conversion is, in fact, more important than type checking. Underlying units checking (and conversion) is commensurability. For example, apples are not, in general, commensurable with oranges: a ton of apples should _not_, in general, be added to 3000 kg of oranges -- although adding a ton of apples to 3000kg of apples makes sense as we are dealing with commensurable quantities although in differing units. Moreover, by incorporating dimensional analysis into the arithmetic machinery, not only can units conversion be automated, but arithmetic expressions themselves can frequently be automatically inferred from the inputs provided along with the units of the output demanded (see the semicolon ';' operator of the Calchemy units calculatorhttp://www.testardi.com/rich/calchemy2/ ). While well-designed type machinery, based on things like assertions and coercions, can be adapted to implement automatic units conversion (hence checking), that is getting the cart before the horse. Here's why: If we accept the idea that the higher level of expression we allow the programmer, the better (as it leads to more disciplined separation of 'how' pragmas from 'what' specification during the authoring process) then we should recognize that relational expression should be core since functions are (sugarably) degenerate (many to 1) relations and procedures are (sugarably) degenerate (state-transition) functions. If we have relational expression as core, commensurability, hence units handling, falls out of what Bertrand Russell called relation arithmetic in Principia Mathematic volume IV. The most advanced work in applying relation arithmetic to programming language design was done by the late Tom Etter while at Paul Allen's thinktank Interval Research, with Tom's follow-on work at HP funded under my (very limited) authority there. Tom's paper, Relation Arithmetic Revived http://www.boundaryinstitute.org/bi/articles/Relation-arithmetic_Revived_v3.pdf documents Russell's conflation of relational similarity with relational congruence as the mistake that blocked practical application of relation arithmetic in Codd's work on relational algebra -- hence things like the object relational impedance mismatch. However, if we look deeper into what was going on, we find that the very idea of sets -- hence the normal notion of data types -- is similarly ill founded, as we can, and should, bootstrap set theory from a more fundamental theory of relative (or relational) identity http://www.boundaryinstitute.org/bi/articles/Three-place_Identity.pdf . Just how far do the implications of this go? Well, for starters, the core laws of quantum mechanics fall out as completely general theorems of relation arithmetic generalized to include negative relationships (opt cit). Among the implications of this are core programming language constructs for quantum information systems. Sorry if this throws a monkey-wrench at, if not into, the works -- but the Perl culture is one of the few places that is has the philosophical equipment to take such a lofty concept as commensurability and commit just enough Ockham's Chainsaw Massacre to retain much of its value
Parrot 3.6.0 Pájaros del Caribe Released
We are proud to announce Parrot 3.6.0, also known as Pájaros del Caribe. Parrot is a virtual machine aimed at running all dynamic languages. Parrot 3.6.0 is available on Parrot's FTP site, or by following the download instructions. For those who want to hack on Parrot or languages that run on top of Parrot, we recommend our organization page on GitHub, or you can go directly to the official Parrot Git repo on Github. To clone the the Parrot Git repo into a directory called 'parrot', use the following: git clone git://github.com/parrot/parrot.git If you want it to be in a directory other than 'parrot', then just give that as a second argument to clone: git clone git://github.com/parrot/parrot.git parrot_foo Parrot 3.6.0 News: - Core + Class.add_vtable_override now allows you to overwrite an override + Integers, floats and strings can now be stored in lexical variables. Previously, only PMCs could be stored in lexicals. + VTABLE_substr has been removed. VTABLE_substr_str has been renamed to VTABLE_substr + Added a new PackfileView PMC type, an intended replacement for the deprecated Eval PMC. + The is_integer vtable on the String PMC now works for all string encodings. + Unicode error messages on Win32 now work correctly. + A memory leak in IMCC was fixed. - Languages + The snaphost of Winxed included with Parrot was updated to version 1.0.0 + Winxed has migrated to Github: https://github.com/NotFound/winxed The SHA256 message digests for the downloadable tarballs are: a6ae5c4a1af3602043d1139a12ae9d4dfe2dd000250b1a76fc339bf4a004f8c7 parrot-3.6.0.tar.bz2 8280930a12a66c384b397b31482df2efc1fcc65efd723b279c71b1e283c2638f parrot-3.6.0.tar.gz Thanks to all our contributors for making this possible, and our sponsors for supporting this project. The following people (in random order) contributed to this release. Thanks! Julian Albo, Matt Boyle, Vasily Chekalkin, chromatic, Will Coleda, Bruce Gray, Brian Gernhardt, Michael H. Hind, James E Keenan, Bob Kuo, Andy Lester, Jonathan Duke Leto, Peter Lobsinger, Patrick Michaud, Christoph Otto, Felipe Pena, Francois Perrad, Gerd Pokorra, Kevin Polulak, Tadeusz Sośnierz, Andrew Whitworth, Jonathan Worthington. Our next release is 16 August 2011. Did you think we were going to leave without a quotation? Wrong! El concierto de tantos pájaros distinto llegó a ser tan aturdidor, que Úrsula se tapó los oídos con cera de abejas para no perder el sentido de la realidad. La primera vez que llegó la tribu de Melquíades vendiendo bolas de vidrio para el dolor de cabeza, todo el mundo se sorprendió de que hubieran podido encontrar aquella aldea perdida en el sopor de la ciénaga, y los gitanos confesaron que se habían orientado por en canto de los pájaros. The Release Manager will offer a public commendation and a suitable prize to the first person who correctly identifies the source of this quotation WITHOUT USING THE INTERNET. Send your determination of the source to jkeenan at cpan dot org and testify that you did not use the http(s) protocol, directly or indirectly, in researching the source. Enjoy! James E Keenan jkeenan at cpan dot org; IRC #parrot kid51 Release Manager, Parrot 3.6.0
Re: Ordering in \bbold{C}
M == Minimiscience minimiscie...@gmail.com writes: M Assuming that the last line should be A ≥ B if a₁ b₁ ..., Indeed, yes. Is there a worse off-by-one typo than '' vs ''? M this is called lexicographic ordering, Oh. Yes. Of course. Obviosuly. I should have noticed that and do not know why I missed it. [SIGH]. I guess I must think of lex ordering mostly when thinking of /real/ polynomials How narrow-minded. ☺ M Specifically, because -1 is a square in ℂ, ℂ being an ordered field M would require that -1 0, which leads to a contradiction. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Ordering in \bbold{C}
Some time ago there was a thread disucssing numeric ordering issues; the fact that ℂ lacks an ordering was part of that discussion. A recent paper on arxiv proposes inflicting an ordering on ℂ using: , excerpt from http://arxiv.org/abs/1003.4906 | | Given A = a₁ + i·a₂ and B = b₁ + i·b₂, then: | | A ≤ B if a₁ b₁ || ( a₁ == b₁ a₂ ≤ b₂ ) | A ≥ B if a₁ b₁ || ( a₁ == b₁ a₂ ≥ b₂ ) | ` I wonder whether having such an ordering available would be beneficial for Perl, or for coding in general? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: numerics, roles, and naming
DD == Darren Duncan dar...@darrenduncan.net writes: Some tiny thoughts: DD ... I would consider Numeric more broad, such as to include DD anything that might conceivably be called a number, probably DD user-defined, that isn't representable by a complex. Is Numeric intended to have a guarantee of commutability? Ie, is it a ring? Or, put another way, would a Quaternion be a Numeric? DD Or maybe better yet for completion sake, make Gaussian a role and DD something like Gaus the type or something. Wasn’t his name Gauß? If so, then Gauß or Gauss, yes? In general, though, I agree with the thesis. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Comments on S32/Numeric#Complex
It would be reasonable for perl6 to have .arg to match .angle. [SIGH] ☹ Obviously, I meant to say: It would be reasonable for perl6 to have .arg to match¹ .abs. 1] or to complement, perhaps? ☺ -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Comments on S32/Numeric#Complex
Doug == Doug McNutt dougl...@macnauchtan.com writes: Any ideas for a good name [for the angle]? Doug In pre-computer times the angle was called the argument. And that is still used. C99, as an example, calls the functions carg(3), cargf(3) and cargl(3), for operations on double complex, float complex and long double complex values, following its convention of using an f suffix for float, l suffix for long double and a c prefix for complex. It would be reasonable for perl6 to have .arg to match .angle. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: 1.23 becomes Rat (Re: Synopsis 02: Range objects)
Karl == Karl Brodowsky lis...@brodowsky.com writes: Karl - or should there be a new numeric type similar to Rat that is always Karl having powers of 10 as denominator (like BigDecimal in Java or Karl LongDecimal for Ruby or decimal in C# or so)? If so, please use something compatable with ieee 754 decimal floats, so that they can be used when running on hardware which supports them. Even w/o such hardware, gcc (at least) has support for software emulation of _Decimal32 and _Decimal64 (and _Decimal128?). -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Synopsis 02: Range objects
Michael == Michael Zedeler mich...@zedeler.dk writes: Michael The Range 1.0001 .. 2.15 makes sense as an interval definition, but Michael there can hardly be a useful list definition without defining a step Michael size, at least, making it possible to use step sizes less than one. The obvious (default) choice for a step size would be the precision of the more precise of the two values. So 0.0001 in your example above. Michael Well... maybe. How do you specify the intended precision, then? If I Michael want the values from 1 to 2 with step size 0.01, I guess that writing Michael 1.00 .. 2.00 The parser would have to note the precision as represented. On systems which have ieee-754 decimal floats that will be automatic (1., 1.0, 1.00, etc all have different representations in 754 decimal floats); it would not be a bad idea for Perl to keep track of that for all numerics. Complex .. Complex should have a defined meaning in p6. Michael there is no natural ordering of complex numbers, and without Michael some ordering, you may be able to decide what should be in the Michael list to return, but not which order to use. [I'm merging stuff here.] Indeed, for interval arith it isn't ordering but inclusion which is relevant. If order is of value, it seems that it would have to be imposed. I can imagine that some people will want to zigzag from the point closest to (−∞,−∞) to the point closest to (+∞,+∞), whereas others might prefer to start at the point with the least r, sweeping θ through either [0°,360°) or (−π,π] or [−π,π) or Michael I believe that anything we put into Perl 6 should have obvious Michael use cases and fall natural into place in the domain that the Michael construct in question belongs to. That is reasonable. Michael but I must admit that I'd prefer if Complex .. Complex was left Michael undefined in the Perl 6 core, leaving it up to anyone to Michael specify it later. BTW, it I should have written a disc with diameter running between the two points rather than specifying an enclosing circle. It is true that when I think of p6, I think of more than core. But I would like support for interval arithmetic as ingrained in the p6 culture as, say, regexps. The set of problems which would benefit from widespread use of efficient interval techniques is significant. All that said, it may be the case that the .. syntax, though useful for specifying intervals, may not be preferred by those doing such coding. The may prefer a ± syntax, or something like ΤεΧ’s strech and shrink syntax for glue. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Rukudo-Star = Rakudo-lite?
how about 'raku' then the final version could be called 'rakudone' Jim Fuller
Re: r27605 - docs/Perl6/Spec/S32-setting-library
lwall + enum TrigBase is export Radians Degrees Gradians Circles; Is Circles of much value? I can see Semicircles, since that would make the range (-1,1] or [-1,1). But a range of [0,1) or (0,1] seems *much* less useful. Or am I missing an obvious use case? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Logo considerations
creating a logo by committee is probably the worst way to design such things ... perl6 logo will be seen in the context of other more professionally designed logos and like it or not using the basics of modern branding and marketing will result in something that is more recognizable no matter how much we may despise these kind of techniques realize that commercial entities (which compete in some way directly with perl6) will spendmillions on such activities and perl6 should consider at a minimum professional execution of a design. Is there any sponsorship money to spend on a very good graphic designer to create something based on a small list of requirements as to what meaning it should convey ? Of course the logo should represent the community fundamentally, but I find all of the suggestions little to do with addressing needs of a logo versus needs of what I would call more of a 'club' badge. I mention these concerns because I would like perl6 to be adopted to as wide a developer audience as possible. my 2p, Jim Fuller On Tue, Mar 24, 2009 at 8:51 PM, Conrad Schneiker conrad.schnei...@gmail.com wrote: From: Guy Hulbert [mailto:gwhulb...@eol.ca] On Tue, 2009-24-03 at 11:38 -0700, Conrad Schneiker wrote: Here's my latest suggestion: http://www.athenalab.com/Rakudo_logo_2.htm It combines Damian Conway's suggestions (please see below) and Ross Kendall's suggestions at (http://www.rakudo.org/some-rakudo-logo-ideas). For a smaller sized Rakudo logo, just remove the text between the proposed Perl 6 logo and the Parrot logo. For the small logo, you could super-impose the Parrot on top of the molecule ... and for pugs: http://www.bnpositive.com/blog/wp-content/uploads/2006/10/starwars-pugs.jpg That's awful! And outrageously hilarious. The Yoda image + molecule (aka hexa-flower) gets my vote for Pugs (although it's not my decision to make). Best regards, Conrad Conrad Schneiker www.AthenaLab.com
Re: Logo considerations
to further comment, I would never believe a logo actually influences which programming languages one chooses to develop in ... but I would argue that a logo needs to convey the right 'messages' to those who pay for software projects ... as with any logo; my point is to identify these messages prior to instantiation e.g. graphic design ... though doing both ain't bad either. here is a stab at some simple messages. for developers: inclusive, easy to use, fast, powerful, linguistic based, DIY, all computing paradigms allowed (func, proc, oo, etc), fun, subversive for wider audience: robust, trusted, straightforward, safe, supported colors evoke meaning, shapes/animals, etc do as well ... thats enough from the 'marketing corner' ... back to programming. cheers, Jim Fuller On Tue, Mar 24, 2009 at 10:34 PM, Guy Hulbert gwhulb...@eol.ca wrote: On Tue, 2009-24-03 at 21:10 +0100, James Fuller wrote: creating a logo by committee is probably the worst way to design such things ... perl6 logo will be seen in the context of other more professionally designed logos and like it or not using the basics of I hate the java stuff (professional). I don't think much of the debian stuff either (amateur). Some of the things suggested here have been pretty good. [snip] Is there any sponsorship money to spend on a very good graphic designer to create something based on a small list of requirements as to what meaning it should convey ? How was the parrot logo created ?? I saw a suggestion here that it is professionally designed but that wasn't confirmed. It looks good enough to me regardless. I don't see a problem with a long list ... Of course the logo should represent the community fundamentally, but I find all of the suggestions little to do with addressing needs of a logo versus needs of what I would call more of a 'club' badge. ... I see the suggestions here as necessary input. I mention these concerns because I would like perl6 to be adopted to as wide a developer audience as possible. I don't think the logo will make much difference. I don't particularly care much about *what* the logo is or *how* it is created. I've only been offering comments as feedback to the people who are actually working on it. Beauty is better than not. my 2p, Jim Fuller [snip] -- --gh
Re: treatment of isa and inheritance
On Wed, Apr 30, 2008 at 9:14 PM, Jon Lang [EMAIL PROTECTED] wrote: Brandon S. Allbery KF8NH wrote: TSa wrote: I totally agree! Using 'isa' pulls in the type checker. Do we have the same option for 'does' e.g. 'doesa'? Or is type checking always implied in role composition? Note that the class can override a role's methods at will. It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is :strict Dog''. Agreed. I'm definitely in the category of people who find the difference between is and isa to be, as Larry put it, eye-glazing. I can follow it, but that's only because I've been getting a crash course in type theory. +1 Brandon's alternative has the potential to be less confusing given the right choice of adverb, and has the added bonus that the same adverb could apply equally well to both 'is' and 'does'. On a side note, I'd like to make a request of the Perl 6 community with regard to coding style: could we please have adverbal names that are, well, adverbs? is :strict Dog brings to my mind the English Fido is a strict dog, rather than Fido is strictly a dog. Not only is is :strictly Dog more legible, but it leaves room for the +1 possible future inclusion of adjective-based syntax such as big Dog (which might mean the same thing as Dog but is big or Dog where .size Average). To misquote Einstein, things should be as simple as is reasonable, but not simpler. and can I add another quote, from someone who's last name is appropriate ;) 'Simplicity does not precede complexity, but follows it.' (Alan Perlis) cheers, Jim Fuller
Re: New specdoc available
nice work, I think this kind of redrafting can be a good foundation for refactoring ... though I would go further and suggest an xml based format ... if u have a .odt you can convert this to docbook ;) one nit pick; drop 'rigorous' in title Jim Fuller
Re: Perl 6 fundraising and related topics.
can I add a few unsolicited ruminations from a lurker; * just release perl 6 now and move on * do not hire 40 year olds with responsibilities, convince the young to spend their time for free ... isn't that what one is supposed to do after the age of 40 ? * use all funds to promote its usage, not fund its development * promote its usage past perl's borders, e.g. perl should be an ingredient not a closed garden at some Perl conference ... * look at successful OS orgs like mozilla and apache (different to each other yes) and copy their techniques a systematic plan past these points will then be possible. cheers, Jim Fuller
Re: Perl 6 fundraising and related topics.
On Wed, Mar 26, 2008 at 7:44 PM, Richard Dice [EMAIL PROTECTED] wrote: What all of myself, chromatic and Richard Hainsworth seem to appreciate is that a plan without resources to back it up is almost guaranteed to be ineffective. Even more than that, we have an appreciation that planning I always relate OS development to how the genetic algorithm works; e.g. a successful OS development typically works quite happily even without a lot of upfrontplanning (though major 'weeding' can be required) or a major spot on the horizon to navigate towards. its ruthless in what dies (projects failing) and what succeeds however it does need a few self organizing principles; a large gene pool, heterogeneity and the ability to mutate to respond to short duration events, oh ya and the ability to mate right we can leave the last one off ;) I do not pretend to know how this specifically relates to getting 'critical mass' of development on perl6 to be feature complete ... my comments were a bit casual; I do not think that its right to release perl6 for the language, but it might be 'right' to do for language adoption no doubt cathedral / bazaar forces are in effect. cheers ,Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 12:01 PM, Smylers [EMAIL PROTECTED] wrote: So, to make a claim for any 'domain-specific' functionality to be added there are plenty of core perl functions that you or I will use rarely (both in perl 5 and perl 6). my claim is that XML is significantly common place, that any new language that descends from the gods, could have some basic XML processing support in place. It's an opportunity to formalize xml processing idioms in all those external modules, as well as ensuring high performance. to the core, you would have to be better at making predictions than those who added modules to Perl 5. _Are_ you better at such predictions? What evidence have you got for that? the only evidence I have is anecdotal. When XHTML1 launched did you correctly predict that XHTML2 would turn into an ignored project that no web-browser vendors are interested in implementing, and that instead they would be implementing HTML5, a language based on HTML4 that encourages authors not to bother with XML? no, I didn't predict this ... but this is not really a valid analogy,I am not predicting XML usage I am using it all the time, as is most of the folks I know are . I am sure there is a silent majority of perl users who interact with XML on a regular basis but yes I agree it is impossible for me to prove ;) as already mentioned, I am sure that perl 6 will have XML processing my point is if we should have some bits in the core which I see as being an advantage over other languages; also will , the vocal majority here is saying 'no' . but doesn't every good idea meet resistance. It would be interesting to hear from someone who does use perl and XML if this is not the case on the perl 6 language list, then perhaps perl 6 is not the language for me ;) cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote:
This has become quite the flame war. There seem to be two sides of
the argument, you arguing one, everybody else arguing the other.
good to see there is passion underlying perl 6 development ;)
So to bring some perspective back into this discussion, I'd like to
ask you, what would it mean to you for there to be an XML type in
core? That is,
from a user's perspective, disregarding implementation of the
language? What would you be able to do with it that you couldn't do
if it were a module
(arguments such as use it without putting 'use XML::Foo' at the top
considered valid)?
well, if my previous posts didn't attract flames this post certainly will ;)
but you did say 'from a users perspective' ... so I will play 'make
believe' with some syntax
first a few assumptions;
we will probably never want to 'address' xml in perl ... e.g. perl
format will never become declarative markup and there is no reason to
start wanting to somehow mix code/data lisp style in perl
another thing to admit is that an XML type would probably just be an
XML document well formed and adhering to the rules of XML v1.0
going beyond that and stating it must be an XML Infoset is going
too far.
---
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
-
declaring some xml in one's perl program;
-
my $sales = sales vendor=John
item type=peas price=4 quantity=6/
item type=carrot price=3 quantity=10/
item type=chips price=5 quantity=3/
/sales;
no surrounding quotes seems about right.
however this leads to some 'other thoughts, like how does perl and xml
play nice together
what about;
my $html = htmlhead/body
span
h1{ $sometitlevar }/h1
ul
{
loop ($counter = 1; $counter 20; $counter++) {
liTry to count electric sheep . . . /li;
}
}
/ul
/span
/body/html
I have eschewed with explicitly having a print statement, as a
syntactic shortcut.
when it comes to manipulating XML, there are a few axioms...
-
How to Address parts of an XML document variable ?
-
It is common to want to address a portion of an XML document
my $select_li_elements = $html.html.body.span.ul ;
this syntax is ok (actually I do not like this approach), but I like
my 'scanability' to be in xpath form ala:
my $select_li_elements = $html[/html/body/span/ul/li];
and then u have the expressive power of xpath inside of these brackets.
so when declaring a var as xml, it would be this
my $data is XML;
( as an aside, is there any concept of the native types, Scalar,
Array, Hash being in a different namespace then all the other symbols
e.g. could I override Scalar type ?)
next,
-
How do I update an XML document variable ?
-
Here are a few edit type examples reusing the XPATH syntax introduced earlier;
This would replace text context node of div id=mydivid/
$html[/html/body/[EMAIL PROTECTED]'mydivid'] ] = new text value;
This would replace text context node of a div with an id of the value
of $myperlvar
$html[/html/body/[EMAIL PROTECTED] ] = new text value;
This would replace XML children of ul element
$html[/html/body/span/ul] .= lisome new bullet point/li;
This would remove XML children of ul element
$html[/html/body/span/ul] .= null;
I am unsure of what an append scenario would look like.
-
And what about validation?
-
Perhaps one would like to be able to decide if this xml must be
checked for validaty against some schema technology (DTD and relaxNG
as basic) are there any 'adjectives when declaring a type ... I
guess I am suggesting a new sigil enforcing an XML context ;0
then there is the 'processing' XML bit .
-
Iterating through XML
-
should print out the value of each div contained in html
for $myxmlvar[/html/body/div]]{
print; # prints $_, the current loop variable
}
I will stop here ... so I can put on my flame proof suit.
cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote: language? What would you be able to do with it that you couldn't do if it were a module (arguments such as use it without putting 'use XML::Foo' at the top considered valid)? and to answer specifically the question; 'What would you be able to do with it that you couldn't do if it were a module ?' there is no difference in usage. but by making some fundamental xml processing available by the core (like file access, regex, and a host of other fundamental bits n bobs), u do promote a common and systematic approach to working with XML in all perl modules. I see some real benefits to this (more associated to lingua franca type design patterns). cheers, Jim Fuller
Re: xml and perl 6
On Nov 29, 2007 3:44 PM, Smylers [EMAIL PROTECTED] wrote: What makes you so sure that nobody will come up with a better way of working with XML there is power in everyone doing the same thing ... this is a variation of lingua franca design pattern. For example, would we say that the reason why HTML is powerful today based upon the right mix of angle brackets and hyperlinks, etc... I would argue no; its simply because everyone is using it. HTML 'could' just as easily been pure SGML or s-expressions for all I care. Back to the arguement; By placing some basic xml handling in core, then you are enforcing a single authoritative approach to using XML inside of perl ... you are not restricting it ... yes someone can come up with a 'better' way as well. I have been arguing that having some simple functionality, provided by the core, would potentially harmonize usage across modules and promote better understanding of code, in general, through consistent usage. There is a recent analogs in perl, of what happens, for example; the lack of a case statement in perl (which I am personally fine with) meant a multiplication of the ways one implements such a logic structure, in turn reducing understandability in the end we now have 'given'. I would not include XML::Parser though I would expect an XML parser (like expat) to have to 'live' somewhere in perl or be dynamically linked is there one in parrot I wonder . to underpin the structures I have shown in my previous email with faux perl syntax. Once again, the point is that I would like to manage and process XML using native types, structures and xml aware operators, from within perl. If I inherit XPATH, then I get 90% of everything I need. cheers, Jim Fuller
Re: xml and perl 6
Thanks to all for taking the time to respond at a minimum the discussion has taught me where perl 6 is headed and where the major architectural brake points currently are. gl, Jim Fuller
xml and perl 6
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? cheers, Jim Fuller
Re: xml and perl 6
all makes good sense, to make a poor analogy (and to make my point); the java build tool, Apache Ant went through the same sort of cycle (at a much smaller scale) whereby initial architecture forced a lot of extraneous functionality into the core hard to maintain and limited deployment profile capability was the result. With Ant's latest incarnation, they finally have a good model for extensibility and have been successful at segregating axiomatic functionality to the core and relegating extensions to external libraries. I completely agree that this is also good approach for Perl 6 but I would weakly argue that XML ubiquity is fast making it the 'text' format of the day and perl having many text processing facilities built into its core might want to reconsider some basic premises about how it perceives XML. A few things I could imagine; native XML data type (and whatever that means at this late stage) xml parser, xpath processor built into Perl6 core making it very quick, since we are late stage I would call this an optimization ;), I can even see in a moment of madness a nod to 'whatever' programming and embed some triple inference processing deep into perl6. making perl 6 XML-neutral is a mistake. imho. cheers, Jim Fuller On Nov 28, 2007 7:12 PM, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully its time to review what could live in the core versus an external module. thoughts? If I remember the plan correctly, it's roughly that the core consists only of the mechanisms for getting and installing other extension modules - anything that doesn't need to be in the core, isn't. This slim core intentionally won't be useful for that much, other than the basis for building larger Perl 6 distributions aimed at broad types of tasks. The idea being that an ISP would install the web serving distribution, which would be bundled with the sorts of modules appropriate for that task, but not burned with the sorts of modules useful for bioinformatics. The aim is to avoid the problem that Perl 5 finds itself in, where things once added to the core can never be removed, and 15 years later you find that there are several generations of this is current modules in the distribution that are a maintenance burden. Usually a burden that falls on volunteers. Nicholas Clark
Re: xml and perl 6
On Nov 28, 2007 7:31 PM, C.J. Adams-Collier [EMAIL PROTECTED] wrote: On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote: On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps before Perl 6 is fully baked its time to review what could live in the core versus an external module. thoughts? If I remember the plan correctly, it's roughly that the core consists only of the mechanisms for getting and installing other extension modules - anything that doesn't need to be in the core, isn't. This slim core intentionally won't be useful for that much, other than the basis for building larger Perl 6 distributions aimed at broad types of tasks. James, Perhaps you should create a distribution for xml processing? If there is not yet a Standard Operating Procedure for creating a perl 6 distribution, I think the community would benefit from the creation of such. Start small, with only enough to do a simple XML processing task. Allow for inheritence/extension of the distribution. I see these 'distributions' as deployment profiles. It would be very easy to package up (more akin to customizing a linux distro) perl6 with all those lovely XML pm tweaking here and there, etc. in the meantime, I have yet to get latest trunk perl6 running properly, on parrot, or freebsd then I will start thinking of such a task (everything compiles fine). as an aside I am getting an; load_bytecode couldn't find file 'Protoobject.pbc' current instr.: 'parrot;PGE::Match;__onload' pc 0 (compilers/pge/PGE/Match.pir:14) called from Sub 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) also I do not want to emulate perl6 in perl5; will try on the OSX box now. cheers, Jim Fuller
Re: xml and perl 6
On Nov 28, 2007 7:39 PM, Andy Armstrong [EMAIL PROTECTED] wrote: On 28 Nov 2007, at 18:28, James Fuller wrote: A few things I could imagine; native XML data type (and whatever that means at this late stage) What might that mean at any stage? from a syntactic point of view, here are 2 interesting examples of representing XML in a programming context http://en.wikipedia.org/wiki/E4X and http://en.wikipedia.org/wiki/XQuery there is lots to learn here. J
Re: xml and perl 6
On Nov 28, 2007 7:50 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: Not too put too strong a bias on it, but: XML processors are a dime a dozen. There is no way for us to know *now* what the best XML processor(s) will be a decade from now, and Perl 6 is intended to be a very long term language. And frankly there are enough different use cases to ensure that no single XML processor could possibly be best in all circumstances anyway. We should not canonize a single XML processor (now especially) by putting it in the core. XML Parser is what I am talking about and I would argue that XPATH is simple and standard enough to be included as well. As Nicholas pointed out, it's unlikely that vanilla will be the Perl 6 flavor that any vendor actually ships. But I definitely want to be able to choose between strawberry and chocolate, and perhaps a new flavor of my own (or my company's) design. I really do not want to always get Baskin-Robbins in a blender because everything's in core. The grammar engine is core. A *particular* grammar is not. putting it more harshly ... I expect my basic programming language to solve my basic problems without having to resort to some layer of abstraction in the form of a framework or external module for the simplest scenarios. I have a lot of XML in front of me in all projects that I work on in every programming context and have had so for the past 3-4 years. I am a bit biased, but I can only see more XML for all of us. I do not nec. agree with 'a particular grammer is not' part of the core ... if that grammar is so common to every problem (like regex is) then why not include it? I am going on now but you get the point. cheers, Jim Fuller
Re: Synchronized / Thread syntax in Perl 6
On Tue, May 30, 2006 at 03:41:06PM -0600, John Drago wrote:
I asked this via the Google Groups interface a few weeks ago, but I'm not
sure if it made it here.
I am asking again in case the question never made it onto the list.
Has the syntax for synchronized/threaded @things been worked out?
For example:
class Foo is synchronized {
...
}
I don't like the name synchronized -- it implies that multiple things are
happening at the same time, as in synchronized swiming, which is exactly the
opposite of what should be implied. Serialized would be a nice name,
except it implies serializing to a serial format, like disk. Locked is
the best name I can think of, and it frankly isn't that good -- it's so
vauge as to be able to mean almost anything.
(Also, of course, all those /z/ names should have a s/z/s/ version, for
those who speak a z-impared dialect of English.)
-=- James Mastros
Re: A rule by any other name...
On Tue, May 09, 2006 at 04:51:17PM -0700, Allison Randal wrote: I'm comfortable with the semantic distinction between 'rule' as thingy inside a grammar and 'regex' as thingy outside a grammar. But, I think we can find a better name than 'regex'. [...] Maybe 'match' is a better keyword. Can I suggest we keep match meaning thing you get when you run a thingy against a string, and make matcher be the thingy that gets run? 100% agree with you, Allison; thanks for putting words to doesn't feel right. -=- James Mastros
Re: using the newer collection types - Interval
On Sat, May 06, 2006 at 01:41:41PM -0700, Darren Duncan wrote: Some people may confuse it with a Range, but I don't think so since a Range progresses in discrete increments, while an Interval would be continuous. A range listifies to a (potentially) finite list of discrete elements, but it compares as a range. 1.1 should ~~ 1..2; pugs thinking that's false is a bug, not a feature. Of course, that doesn't mean implementing range in a subset of perl6 without it isn't interesting, and possibly useful for bootstrapping. -=- James Mastros
Re: RFC: Community education page
On Thu, May 04, 2006 at 10:44:29AM -0400, David K Storrs wrote:
Also, the page should talk about why it is difficult to do what is
being done. Ask the reader questions: You want to support
continuations / have coroutines / embedd yacc in your language /
whatever. How do you do it? Then offer up an analysis of various
design choices that were considered and rejected and why.
I think this will see a lot of use, not just in terms of people really
outside the perl6 project, looking at it, and wondering what's taking so
long, but also people on the semi-inside, trying to remember things like
I'm sure there's a reason other then C if condition_without_parens
{block} that we can't have C %foo {'bar'} DTRT, but I can't
remember it, which certianly happens to me fairly often.
Also, as a checklist for proposals. If you're thinking of proposing
something, go look there. If it's already there, do you have any new pros
to put against the existing cons?
-=- James Mastros
Re: [svn:perl6-synopsis] r9076 - doc/trunk/design/syn
On Wed, May 03, 2006 at 02:10:29AM +0800, Audrey Tang wrote: [EMAIL PROTECTED] wrote: Is my ($foo, *, $bar) = 1..3 legal perl6? my ($foo, undef, $bar) = 1..3; is valid perl5, but AFAIK that is completely undocumented. (It's quite useful from time to time Most likely yes, as lvalue * can just act as a /dev/null. -- now if only my (@rest, $almost, $last) = function_returning_many_thingies could work... This may be implemented by allowing slurpy scalar _after_ slurpy array. But what would be the use case? Hm, possibly I should specify what I mean by work -- as if I'd specified C my (@last, $almost, @rest) = reverse(function_returning_many_thingies); . As to use case... um, I'm sure I've had it come up for me, but I can't think of where it'd be terribly common such that the extra cognative overhead is worth it, come to think of it. I withdraw the (stupid) suggestion. -=- James Mastros
Re: [svn:perl6-synopsis] r9076 - doc/trunk/design/syn
On Mon, May 01, 2006 at 10:32:02AM -0700, [EMAIL PROTECTED] wrote: Log: * S03.pod: Retire lvalue undef and replace it with lvalue Whatever: # Perl 5 (undef, undef, $x) = (1,2,3); # Perl 6 (*, *, $x) = (1,2,3); Is my ($foo, *, $bar) = 1..3 legal perl6? my ($foo, undef, $bar) = 1..3; is valid perl5, but AFAIK that is completely undocumented. (It's quite useful from time to time -- now if only my (@rest, $almost, $last) = function_returning_many_thingies could work... -=- James Mastros
Re: S02 - s/environmental variables/environment variables/g please
On Sat, Apr 29, 2006 at 07:50:02AM -0700, Randal L. Schwartz wrote: Please, let us agree to use the traditional name of environment variables in the docs, and not re-introduce its bastardized cousin, which hurts my ears. Thanks. I think they are different things. An environment variable is something in %*ENV. An environmental variable is a variable which was declared with env $foo, and which can be seen by callers. I rather dislike this naming scheme, but can't think of a better one. -=- James Mastros
Re: S5 - Question about repetition qualifier
On Tue, Apr 25, 2006 at 09:57:58PM -0400, Joe Gottman wrote:
According to Synopsis 5, the repetition qualifier is now **{.} where the .
must correspond to either an Int or a Range. This seems rather restrictive.
Why are we not allowed a junction of Ints, for instance
m/^ a**{1|3|5} $/ ; # Match 1,3, or 5 a's.
It would seem to me that the Right Thing is for the closure to return
something to ~~ against. However, this obviously means that the regex
engine is going to have a harder time optimizing, and be somewhat more
complex, since it has to keep calling out to the smartmatcher.
Possibly we should make the syntax be a smart match, but only require that
conformat implementations implement ranges and integers.
-=- James Mastros
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 08:00:55AM -0700, Larry Wall wrote: On Mon, Apr 24, 2006 at 09:49:36AM -0500, Jonathan Scott Duff wrote: : But what if your subrule needs to know exactly which key matched or : needs to match the key again for some reason? The second passage says : that you may access they actual text that matched with $KEY and you : may again match the actual key that matched with the KEY assertion. Close, but that last bit isn't quite true. If you read the passage again carefully, you'll note the magic words as if. There is no actual KEY assertion, only the remaining smile, like a Cheshire cat. If you want to reset to before the key for some reason, you can always set .pos to $KEY.beg, or whatever the name of the method is. Hmm, that looks like it's unspecced. Why don't we just have KEY work as an assertation, instead of having this strange as if thing? -=- James Mastros, theorbtwo
Re: backtick units (Was: File.seek() interface)
Wolverian wrote:
On Thu, Jul 07, 2005 at 05:58:53PM -0700, Larry Wall wrote:
$fh.pos = $fh.pos + 10`lines
I'm sorry if this has been discussed, but is the ` going to be in
Perl 6? I like it. :)
I was hoping it was going to be in the standard library, but non-core.
Using it for manipulating .pos, OTOH, would seem to make it core, which
I suppose is probably worth it.
How does it work, though?
sub *infix:` (Num $amount, Unit $class) { $class.new($amount) }
Or so?
Now I'm tempted to make it a generic infix .new.
(args)`Class;
The problem with it is that somehow we have to get 5`m / 30`s to work,
even though m is an operator, which AFAIK means it needs to be a macro,
or the moral equivalent (is parsed).
Also, having every unit be a like-named class would very much crowd the
root of the namespace.
-=- James Mastros
theorbtwo
Re: Idea for making @, %, $ optional
Millsa Erlas wrote: I have thought of an interesting idea that may allow Perl 6 to make the $, @, and % optional on many uses of variables. This involves simply extending the function namespace to include all kinds of structures, and thus the function namespace does not require symbols, they are optional. Also, a goal I have tried to follow here is to implement this feature without affecting the existing usage grammar and rules of the Perl 6 language at all. This is a good goal i believe, my intention is just for this to be an additional extension to Perl 6, not change its existing grammar and parsing rules at all, just expand upon it. Perl 6 is a great language and I like what has done so far. This is not an attempt to change what has already been defined, but rather provide an additional usage. In that case, you should be looking into how to make it a pragmata, rather then pushing the idea on perl6-language. It shouldn't be too hard -- a matter of using the equivalent of perl5's UNIVERSAL::AUTOLOAD, and the OUTER:: scope. -=- James Mastros, theorbtwo
Re: single element lists
Larry Wall wrote: : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the : matching .[] multisub under Int or its superclasses. Maybe we should just let someone poke a Subscriptable role into some class or other to determine the behavior if they care. Why is this a role, rather then just implementing postcircumfix:«[ ]»(Whatever $self: Int $index) ? (I'd hope the error message is a bit more newbie-friendly, but that's the only special-casing I see it needing...) -=- James Mastros
Re: identity tests and comparing two references
Larry Wall wrote: On Fri, Apr 01, 2005 at 08:39:52AM -0700, Luke Palmer wrote: : I'm pretty sure that =:= does what you want. If you have two scalar : references, you might have to spell it like this: : : $$x =:= $$y Unnecessary, I think. I want $x =:= @y to tell me whether the reference in $x is to the same array as @y. $x = 42; $a = \$x but false; $b = \$y but blue; $a =:= $b ??? If it's true, then the =:= operator is pretty useless -- two things that are =:= to each-other can have very different semantics. If it's not, then there needs to be some other way to tell. $$a =:= $$b feels sane to me. So does $a == $b. I generally don't like it when things half-smudge important differences. Either there should be no difference between a reference and a referent, or there should be. We shouldn't try to hide important truths. (This is why I don't like CGI.pm's HTML generation, for example -- it makes you feel like you don't need to know HTML, when you do.) -=- James Mastros
Re: Units on numbers [was Re: S28ish]
Craig DeForest wrote: Yet another point: there are plenty of non-obvious reductions that people worry about, such as N m - J (energy) but m N - m N (torque); but it's probably not worth worrying about such things: if the coder knows that s/he wants a torque, s/he should be able to ask for reduction to a particular form [e.g. 'units( $val, $template )' should exist and return $val in whatever units $template has, if possible.] Oh, and don't underestimate the usefulness of doing things in non-base-ten mixed units, and useful fractions: my height is 5`ft+(6+1/4)`in, not 66.25`in, thank you. In any case, I'd love something like this, and I suspect many other people would as well... but remember, again, extensibility is key. C $d=22`AWG; $a=pi*($d/2)**2; print $a`mm**2. qm; # buying wire in Germany doesn't work very well if there is no way to specify insane units like AWG. 25`USD*1.06+5`EUR can't be computed at all without extensibility, because the conversion rate from USD to EUR doesn't stay static over time. For that matter, monetary conversions are going to take some effort to get right, though they will be very useful if they are gotten right, because going through a common intermediary isn't correct. You won't get the same results converting USD to EUR to JPY as you will from converting USD to JPY. (OTOH, if you want to convert from DEM to FRF, you /must/ convert to EUR in the middle, or you will get the wrong result. Of course, neither the DEM nor the FRF have existed in several years, so it probably isn't that important...) -=- James Mastros, Who certainly looks forward to this.
Re: eval (was Re: New S29 draft up)
Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file(foo); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. ...unless read returns a Str but source(foo). -=- James Mastros
Re: Auto My?
Luke Palmer wrote: James Mastros writes: Does this imply that it's now possible to type Cmy @foo[23] = 42;, and declare @foo? In the current perl, this doesn't work -- it's a syntax error. It'd certainly make many constructs easier. That looks weird to me. But as Rod points out, it can be useful with hashes. Yes, that's the primary case I was thinking of. I was trying to find a smaller example. OTOH, I realize now you can do that with zip in P6, in which case you do have a mention of the whole variable to stick a my on -- Cmy %foo = zip(@keys, @values); I think Cmy [EMAIL PROTECTED] = @values; reads better though, even though looking at it literally, you're attempting to lexicalize an element. -=- James Mastros, theorbtwo
Re: Auto My?
Juerd wrote: Just typing my before the first use of a variable isn't hard, and it makes things much clearer for both the programmer and the machine. Does this imply that it's now possible to type Cmy @foo[23] = 42;, and declare @foo? In the current perl, this doesn't work -- it's a syntax error. It'd certainly make many constructs easier. -=- James Mastros
Re: Angle quotes and pointy brackets
Larry Wall wrote: I'm ready to propose a Great Angle Bracket Renaming. Hajleuja! Praise the Larry!* It looks wonderful, and just fixed half about half the things I was worried about having to do when programming perl6. (Not that hard -- I can't think of any more at the moment, but I'm sure they're there somewhere.) -=- James Mastros *I think I just broke two or three commandments.
Re: Angle quotes and pointy brackets
Austin Hastings wrote:
Larry Wall wrote:
* We get the cute, clean and rather more typeable
$varkey1key2[3]key3
No more or less typeable for me, or anyone else who can remap their
keyboard. I'm presuming there's something costly about {} on non-US
keyboards, but how much does it cost? and do those non-US perl hacks use
remapping already?
German keyboard, for example:
{ -- right alt, and the 7 key
[ -- right alt, and the 8 key
] -- right alt, and the 9 key
} -- right alt, and the 0 key
German keyboard under xfree86 but not windows:
« -- right alt, z (Well, the key that's z on an American keyboard).
» -- right alt, x
Those are /really/ hard to type, esp }, which comes up a /lot/ in perl,
weather 5 or 6, which is a big reason that I use the American keymap,
which is a constant annoyance to my girlfriend, who uses the British
keymap. (We're an American and a Brit, living in Germany.)
The problem with {} for a hash dereference operator is not it's
typeablility, but rather it's autoquoting behavior from perl5. In
perl5, the contents of {foo} are a string -- except when they aren't.
Quick:
$wheel-{roll} = 3;
$wheel-{shift} = 4;
In perl5, the first is a literal, the second shifts from @_. Whoops.
In perl6, the contents of {} is an expression. The first is an error
unless a function named roll is available (or a method on the topic?).
The second is good old shift (on the topic now).
OTOH, $wheel.roll and $wheel.shift are both literals. (The dot
there is optional.) (Until a little bit ago, that was $wheel.roll
or $wheel.«roll». (Note that I had to switch keyboard layouts again to
type that.))
-=- James Mastros
Re: Angle quotes and pointy brackets
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
: qx:noparse 'echo $VAR' ?
I think we need two more adverbs that add the special features of qx and qw,
so that you could write that:
q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/
I think I'd like that much better if we consider execution and
word-splitting to be the primary operations, and interpolation and
noninterpolation the adverbial modifiers then the other way around,
making that qx:q/echo $VAR/ or qx:qq/$cmd/. OTOH, I expect backticks to
be rare enough that I wouldn't mind writing
use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');
Much more clear, saves ` for other things, and allows for easy
specification of the many adverbs of spawn (weather it returns the
return status, the PID/FH set object, or output, if it waits right
there, or runs in the background (and makes the return value lazy), if
it replaces the current process (exec)...
Likewise a qw/a b/ is short for
q:w/a b/
qw:q/a b/
$fromvar = 'foo bar';
qw:qq/a something with spaces b $fromvar/
# ?? -- slightly OT, but is that a, 'something', with, 'spaces',
# b, 'foo bar', or... um, what? Is qw smart enough to allow
# internal quotes? Does splitting take place before or after
# interpolation if it's interpolating?
: I notice that in Perl6 thoose funny « and » could be much more common
: than other paired brackets. And some people likes how they look, but
: nobody likes fact that there's no (and won't!) be a consistent way to type
: them in different applications, wether it's hard or easy.
:
: But to swap «» with [] or {} could be real shock for major part of
: people..
: We also have another ascii pair, and . maybe they could be better than
: « and » ?:) i'm not that farseeing, but isn't problem of distinguishing
: as a bracket and as an comparison operator no harder than distinguishing
: as bracket and as part of heredoc?..
It would get very confusing visually, even if the computer could sort it out:
We could force whitespace disambugation, possibly -- require that ...
bracketing have whitespace on the outside and none on the inside. But
that's ugly.
But there are some things that would be completely ambiguous:
%hashfoobar
Bracketing operator.
%hashfoobaz()
Very long bracket operator, which quite likely has a syntax error
directly after it.
: or maybe even we could see consistant to go after + + and alike, and
: make old and written as + and + (and then lt and gt suddenly could
: become ~ and ~ :)
I think people would rise up and slay us if we did that. We're already
getting sufficiently risen up and slain over Perl 6.
Could be worse. They could rise from the grave and eat us!
Well, yes, but sometimes the weights change over time, so it doesn't
hurt (much) to reevaluate occasionally. But in this case, I think I
still prefer to attach the exotic characters to the exotic behaviors,
and leave the angles with their customary uses.
...of which they have plenty already. Backtick has exactly one, and not
an often-used one at that... I'm fine with axing it. Of course, there
are a lot more people in the world then just me.
If you're a White Russian I suppose the yolk is on me.
In Russia, the yokes throw you!
-=- James Mastros,
theorbtwo
Re: Lexing requires execution (was Re: Will _anything_ be able to truly parse and understand perl?)
Randal L. Schwartz wrote: All the handwaving in the world won't fix this. As long as we have dual-natured characters like /, and user-defined prototypes, Perl cannot be lexed without also parsing, and therefore without also running BEGIN blocks. And user-defined prototypes that change when the argument list of a function ends, that is. If we forced the argument list for all functions to have parens (including empty parens for argument less functions), then we'd be OK, I'm fairly certain. For that matter, if we stick to declaration syntax for declarations, and not BEGIN blocks and reflection, then we're OK -- you have to do some execution, but of a minilanguage that can't express concepts that you wouldn't be OK running... though you do still have to descend through require/use, and thus have to have the files being required or used (or at least a description of their declarations). -=- James Mastros, theorbtwo
Re: anonimity
Larry Wall wrote: On Sat, Nov 06, 2004 at 10:37:39PM +0100, Juerd wrote: : Larry Wall skribis 2004-11-06 13:32 (-0800): : Easy, just one of : my $named := anonymous(); : my @named := anonymous(); : my %named := anonymous(); : my named := anonymous(); : my ::named := anonymous(); : : That's a lexical name. Are they used in error messages? (Can they be?) Generally not, unless we make aliasing smart enough to latch onto the first name and add it as a property to the anonymous object if it doesn't already have one. It would seem, then, that the answer is there's some property of thingies that gives the name that error messages will use to refer to them. (I want to thank the man who made thingy the proper technical term, BTW.) So what's it called? -=- James Mastros
Re: What Requires Core Support (app packaging)
Nicholas Clark wrote: On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) Er, right -- I'd meant to say that there, but I must have lost it when I decided my verbiage was horrible and rewrote it. (There's a reason I don't post often.) Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The and as you say all this really isn't about perl 6 the language. Exactly -- most of this sort of thing is about perl's standard library, which I think is a discussion for much, much later, and a discussion (one that, for the most part, is finished) for perl6-language (the part of the list that should be renamed to parrot). -=- James Mastros
Re: What Requires Core Support (app packaging)
John Siracusa wrote: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. We can support this in several ways. We can say that core perl also supports the above if the file is a gzipped tar file, and contains a main.pl (including adding the archive to @*INC). We can ship a script with perl, and have the user use the #! mechinisim to run it, with the actual file being specified to be a #! line, ending with some combination of CR and LF, then a tarball. This is probably a lot more work for perl core, but would be quite nice. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. Parrot supports this well enough that it will be hard for perl6 to mess it up. Parrot, indeed, already supports... 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to bootstrap community implementations. Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The others require standard-library support, but all the major bits are things that should already be in the standard library (because a front-end to C6PAN should come with, and that means extracting some sort of .tar.gz files -- calling out to external utilities doesn't cut it too often). -=- James Mastros PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's and postfix:'th? It's 80s and postfix:th!
Re: String interpolation
David Green wrote: I was also going to say something tongue-in-cheek about Unicode quotation marks, but curly-quotes could actually be quite useful. Reasons not to use them as anything but synonyms for normal double quotes: 1) They look too much like each-other. 2) They look too much like normal quotes. 3) Some editors will give you one when you want the other. - David ³wondering how likely curly-quotes are to come out right² Green 4) Many people think they're in Latin-1, but they aren't, they're only in Microsoft's perversion of Latin-1. -=- James Mastros
xx and re-running
Recently on perlmonks, at http://perlmonks.org/index.pl?node_id=375255,
someone (DWS, actually) brought up the common error of expecting x (in
particular, listy x, which is xx in perl6) to not create aliases. What
he was doing in particular, I don't have any expectation of making it
work, but what about the also-common problem of C @randoms = (int rand
100) xx 100 ? In perl5, this picks one random integer between 0 and
99, and copies it 100 times -- not what was intended. The best way to
do this is C my @randoms = map {int rand 100} 0..100; , which is
rather yucky -- conceptually, you aren't trying to transform one list
into another. OTOH, C my @randoms; push @randoms, int rand 100 for
0..100 is even yuckier.
Perhaps if the LHS of a xx operator is a closure, it should run the
closure each time around... or perhaps there should be an xxx operator.
(Both suggestions from BrowserUk's reply,
http://perlmonks.org/index.pl?node_id=375344). The former raises the
question of what you do if you really want to repeat a coderef, and the
later raises the possibly of being blocked (really), and starts to
become confusing -- the difference between x and xx is sensical -- the
former repeats one thing, the later many... but what's the reasoning for
xxx, other then that it's like xx? How will users be able to remember
which is which?
-=- James Mastros,
theorbtwo
Re: scalar subscripting
Larry Wall wrote:
I suppose another approach is simply to declare that dot is always a
metacharacter in double quotes, and you have to use \. for a literal
dot, just as in regexen. That approach would let us interpolate
things like .foo without a variable on the left. That could cause
a great deal of cultural confusion in the short term, however.
[...]
Ouch. I'm thinking we allow $foo.bar in both strings and regexen, but
not .bar in either case. Gotta use $_.bar inside strings and regexen.
(Or $(.bar) would work too.) Possibly we even complain about /.bar/
and force them to write /. bar/.
Please, think of Csay This is a sentence. This is another
sentence.;. Dots with whitespace or end-of-string after them should
just be literal dots in qq strings. Dots should always be literals in
q() strings, of course. And dots are /already/ metacharacters in
regex^Wrules; forcing a space after the dot isn't giving the power of
formatting to the user; it's forcing formatting upon them that they
don't want. (I don't remember if there's an adverb to treat spaces as
literals, but if not, there should be.)
I think method calls in strings should be Foo's bar is $($foo.bar).,
plain and simple. Dot is too useful here already. @{[...]} needed to
be replaced with something easier to type, and with clearer (and
cleaner) semantics. We did that; $(...) is far better. Not requiring a
set off for method calls is Huffman coding the wrong direction, unless
you can find one that won't disturb useful things that you'd want in
double-quotes -- which includes patterns common in any natural language,
which includes even the literal versions of / (which I can't type
easily at the moment).
-=- James Mastros
Re: Yadda yadda yadda some more
Austin Hastings wrote:
So, how wrong is this:
class VerticalYadda
{
extends Yadda;
multi method coerce:as($what) {
say Coercing VerticalYadda to ~ ($what as Str);
next METHOD;
}
}
sub *\U{VERTICAL ELLIPSIS}()
{
return new VerticalYadda;
}
=Austin
macro \N{VERTICAL ELLIPSIS} :parsed«term» {
return '...';
}
Re: Yadda yadda yadda some more
Luke Palmer wrote:
Aaron Sherman writes:
Ok, so in the case of:
my int $i = ...;
we should apply Cconvert:as(..., ::int) and fail at run-time,
correct? There's nothing wrong with TRYING to do the conversion, just as
there should not be anything wrong with:
my int $i = 4;
which has some pretty simple semantics in Perl.
Right. Though, constant folding at CHECK time might be able to tell when
you're *going* to do an invalid conversion and complain about it right
then.
In the case of ..., give it type error semantics. That is, any
expression involving ... gets type Except instead of reporting
at the end of the statement, just suppress the errors and move on.
Huh? Um, no, your ideas as to what happens don't give the desired
semantics for ..., and don't make other desired semantics fall out
naturally.
The basic semantic for ... is that use of it gives an error at runtime,
when the code has been hit. Unless a pragmata changes things, it
should not be possible to trigger an error from use of ... without the
code being actually run.
Thus, I propose the following: A convert routine should be able to tell
if it's being run at runtime or compile time, and do a fail with reason
matching :i/not yet/ or :i/too early/, to defer the conversion until
runtime.
This gives the desired semantics for ... -- an error at runtime, not
compile time. It also allows for desired semantics elsewhere. Say I
have two classes, Net::IP::Addr and Net::HostName. It should be
possible to convert a Net::HostName to a Net::IP::Addr, but that
conversion should not happen until runtime (because I may be keeping
around the bytecode for a long time, and the hostname-IP mapping may be
different by then).
(Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was
the syntax changed, or is he wrong?)
multi sub *coerce:as (Net::HostName $name, Net::IP::Addr ::to) {
fail 'Too early to convert hostname to IP address' if
(we_are_in_compile_time);
$name.lookup;
}
(Yes, I know those parens around the condition of the if are optional --
even in perl5. I like them.)
What I don't know is how to write Cwe_are_in_compile_time. A property
of the object that Ccaller gives?
I don't really like using fail with regex matching here, but we need to
be able to return a real undef (we don't mind converting early, but the
correct conversion is to undef -- C0 as bool), should be able to
really fail (it's not a valid conversion, and waiting won't help
anything -- Csqrt(-1) as Real).
BTW, since that example above isn't the hottest, imagine defining a
conversion from a hostname to a DNS lookup, that saves the expiry time,
and defining a second coercion from that to an IP address, that reruns
the lookup if the TTL has expired. The first coercion should take place
at compile time, the second not until runtime.
-=- James Mastros
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall wrote: Yes, * was originally a no-op in list context, but I think now we can use it to deref a list that would otherwise not interpolate itself. It maps better onto how a C programmer thinks, and if in scalar context it also happens to defer the signature checking to use the interpolated values, that's just an extra bonus. No! Please, God, no! I like perl, in no small part, because references are less confusing then pointers. Pointers, in no small part, are confusing because * means both this is a pointer (as in int*), and give me the thingy at (as in chr=*str). It seems like this is creating the same confusion. $foo = 0...;# take ref to an infinite range @bar = $foo;# puts in the iterator as a reference say @bar.elems; # prints 1 @bar = *$foo; # puts in 0... say @bar.elems; # prints Inf @bar = **$foo; # throws exception: Please install a lot more memory I hope that Perl will be intelegent enough to notice that the range is infinite, and say attempt to flatten infinite list rather then ENOMEM here. Also, how does the use of *$foo differ from @$foo here? Is the later going away? (I'd think that horrible, for the same reason as above: C is confusing because it's not always clear what you get when you *.) By the way, I like say, but wonder if we're going to become a horrible mix of APL and PHP. At least we don't have a Unicode alias for say (yet, why do I suspect we're about to get a unary » operator for it? Perhaps I'm just pessimistic this morning.) -=- James Mastros
Re: z ip
Mark J. Reed wrote: One obvious reason for reaching out to unicode characters is the restricted number of non-alphanumeric characters in ASCII. But why do infix operators have to be non-alphanumeric? They don't - but they do have to look like operators. Thanks to the multiplication symbol, lowercase 'x' looks like an operator to many people. Most alphanumerics don't. The rule is that, since the infix operator space and the sub-without-parens space intermix, and the subs namespace is very user-extensible, we shouldn't create places where they're likely to intersect and surprise the user. This is primarily in non-aphenumerics. Also, users expect operators to look more or less like the ones they know, which are funny symbols. x and xx is a bit of a corner case -- I think it's a bit far, perhaps, but OTOH, x does look like the operator people use for this, and if we already have x (and we do), xx is reasonable. I think the ¥(yen) suggestion is great, especially since it does indeed look like a zipper. Still, I would very much like an ASCII infix alternative for zip(). I propose z as the ASCII alternative for the infix zip operator (either broken bar or yen). With some imagination, it is a good candidate for representing interleaving. Besides that, zip() starts with a z so it is easy to remember even if you don't think it looks like something that zips. I think if we go with ¥ for the Unicode operator, the logical choice for an ASCII equivalent would be Y. You could read it as Spanish and, if you like. :) I like ¥ for the zip operator. It looks like a zipper, it's a funny symbol, it's latin-1, and it's typeable on my keyboard (altgr-shift-z, German xfree86 keyboard). Japanese users used to having problems with ¥ vs \ may be confused by that, but I think it's livable. I don't think it needs an ASCII equivlient, though -- it isn't /that/ useful, and it already has an ASCII equivalent: the zip() function. Let Y be used by user subs, or as a user operator; it's too likely to confuse.
Re: Latin-1-characters
Karl Brodowsky wrote: Mark J. Reed wrote: The UTF-8 encoding is not so attractive in locales that make heavy use of characters which require several bytes to encode therein, or relatively little use of characters in the ASCII range; utf-8 is fine for languages like German, Polish, Norwegian, Spanish, French,... which have = 90% of the text with ASCII-7-bit-characters. Add perl to that list, by the way. I rather strongly suspect that most perl code will consist mostly of 7-bit characters. (Even perl code written by traditional-Chinese-speakers (and I pick on traditional Chinese only because it has a very large character repituar -- one of the reasons there's a simplified variant).) but that's why there are other encoding schemes like SCSU which get you Unicode compatibility while not taking up much more space than the locale's native charset. These make sense for languages like Japanese, Korean, Chinese etc, where you need more than one byte per character anyway. But Russian, Greek, Hebrew, Arabic, Armenian and Georgian would work fine with one byte per character. But the kinds of of encoding that I can think of both make this two bytes per character. So for these I see file sizes doubled. Or do I miss something? Yes. You're missing the fact that SCSU is a very good encoding of Unicode. http://www.unicode.org/reports/tr6/#Examples In general, SCSU is one byte per character, except when switching between half-blocks (that is, 0x7f contiguous characters), which take one additional byte -- except switching between a single half-block and ASCII. Thus, most of your second list of languages take one byte per character for most code, and two bytes for encoding « and ». Hebrew, Greek and Arabic take one additional byte (for the whole file) to encode what half-block that the non-ASCII characters fall into. (Arabic and Cyrillic are in default blocks.) The first list of languages is hard to predict -- it changes depending on how often you change between the different Japanese alphabets (and pseudoalphabet), for example. Their example Japanese input compresses to about 1.5 bytes per character. (Note that SCSU is really an encoding, if it claims to be or not.) Anyway, it will be necessary to specify the encoding of unicode in some way, which could possibly allow even to specify even some non-unicode-charsets. By the way, there is (should be) nothing that is encodable in a non-Unicode character set that is not encodable in (any encoding of) Unicode. That's where the uni bit comes from. If there is, it's means that Unicode is not fulfilling it's design goals. IMHO the OS should provide a standard way to specify such a charset as a file attribute, but usually it does not and it won't in the future, unless the file comes through the network and has a Mime-Header. I think the answer is multi-fold. 0) Auto-detect the encoding in the compiler, if a U+FFEF signature, or a #! signature, is found at the beginning of the input. (If there is a FFEF signature, it should get thrown away after it is recognized. It may be possible to recoginze on package or module as well, and possibly even on #.) 1) Beleive what the underling FS/OS/transport tells us. (This is likely to be a constant for many OSes, possibly selectable at the compiler's compile-time. It's the encoding on the end of the content-type for HTTP and other MIME-based transports.) 2) Support a use encoding 'foo' similar to that in recent perl5s: It states the encoding that the file it appears in is written in. (the higher-numbered sources of encoding information override the former ones.)
Re: Compile-time undefined sub detection
Larry Wall wrote: And how would it differ from END? You can't predict when the last time a module is going to get used... Unless we support an explicit unload action on modules. This seems highly useful for long-running processes. (I don't think making them DODable is useful, since there's no way to tell if a future eval STRING (or equiv) might be useful.) -=- James Mastros
Re: Partially Memoized Functions
On 12/10/2002 5:46 PM, Smylers wrote: OK. There was something on MJD's QOTW recently where using the current Perl 5 Memoize module slowed code down -- that gave me the impression that caching had the potential. It does. In fact, all caching has that potential. Specificly, if the time to look up somthing in the cache is greater then the time to recompute it, caching is a loose. Additionaly, if the hit rate (probablity; 0..1) times the time to recompute the datum is less then the time to look up the result in the cache, it's a loss for that datum. MJD has a set of presentation slides on this at http://perl.plover.com/yak/memoize-quant/ -- Quantitative Analysis of Memoization. -=- James Mastros PS -- This is getting offtopic, even for p6l.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/12/2002 5:50 AM, Aaron Crane wrote: Damian Conway writes: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I'd say that you can override .id, but if you do, you deserve what you get. That is to say, if your .id method lies, and somebody tests that two objects are the same with .id, you should be sure that you're prepared to accept all the complications of answering the way you do. Also, it's likely that .id will be implemented with a single Parrot opcode, so you'll loose a lot of efficency by overriding it. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore. Thus, there should be one ID for all constants of the same value, which is different from all constants of different value. (This is probably unimplementable if we gaurntee IDs are of some constant length.) Two objects should only have the same ID if they are aliases of each-other: they always have the same instance values, and the same value (but) properties. Promotable, but unpromoted, Ints should have different IDs, because they may at some point, have different values. Any unconsidered cases? That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. Some of both. Not all constants of the same number neccessarly have the same reprensentation in PBC -- to whit, a constant float in different compilation units will get different slots in the constant table, but are really identical. The same is true of constant strings. (Constant integers are inlined, and thus this doesn't apply to them -- they really are identical.) -=- James Mastros
Re: Comparing Object Identity
On Thursday, December 12, 2002, at 10:49 am, Piers Cawley wrote:
Luke Palmer [EMAIL PROTECTED] writes:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Wed, 11 Dec 2002 19:21:35 -0500
From: John Siracusa [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On 12/11/02 6:16 PM, Damian Conway wrote:
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal Cid method is *for*.
I must have missed this (or forgotten it?) Any chance of it
becoming .ID or
.oid or even ._id? I'm kind of attached to using an id method on
objects
that represent things in a database... :-/
Well I use .str all the time, an .eq is one of my favorites! Don't
take those, put a prefix on them!
Theoretically, there are sufficiently few Object methods to warrant
normal names.
Right now there are 'sufficiently few' Object methods, but I'm betting
that before the game is over there's going to a be a whole pile
more, just take a look at any Smalltalk image if you don't believe
me. But that's no reason for upcasing said methodnames. Anyway, you
haven't lived 'til you've added a suite of methods to
UNIVERSAL/Object; it's how we make Pixie work for instance.
But in fairness we do distinguish our method names with a different
convention 'px_'. We prefix the methods more because people aren't
used to the UNIVERSAL::* hierarchy being mucked around in, and methods
suddenly cropping up may be surprising.
I think there may be a cultural issue here - in Smalltalk if someone
messes with a method higher up in the hierarchy its visible quickly by
virtue of the browser and the image. Adding a method in Smalltalk's
MetaObject/Class/Object hierarchy isn't going to be that dangerous,
because everybody can see that it has been added, and its therefore
culturally exposed and therefore subject to debate[0]. Not so in Perl.
Perl, of course, lets you stick a method that exists in any package
anywhere on the system[1]. You can add methods to UNIVERSAL from
anywhere, and this gets really complex when you start overriding
existing methods. For example, if you're not happy with UNIVERSAL::isa,
it can be replaced with a sub UNIVERSAL::isa {} pretty much
anywhere[2]. You may get a warning but its pretty easy to turn it off,
and tracking it down would be a real pain without some pretty serious
reflection capabilities.
Of course pretty serious reflection capabilities would be Very Nice
Indeed, but anyway...
--james.
[0] Read: argument.
[1] This is not a bad thing, its just a different thing.
[2] This probably is a bad thing in most circumstances.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(This is a reply to a mail accidently sent to me personaly instead of the list. Buddha, care to resend your other mail? I havn't quoted it in total.) On 12/12/2002 9:43 AM, Buddha Buck wrote: James Mastros wrote: Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore. If I wrote the Perl6 code correctly (and no guarantees that I hit this moving target), then once created, a Complex object cannot be modified and is indistinguishable by behavior from any other Complex object with the same value: Is it reasonable to have $a.id == $b.id? No, as you can still change the properties of the objects independently. If you can't even do that, then yes. -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/2002 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
It would, logicaly, mean that the class Module has a method foo if
true -- applying can on an object tells you if the class of that object
can do somthing, and Main is an object of class Module... right?
(%Main:: is a hash, but Main (bareword) is an object, no?)
-=- James Mastros
Exists and hypotheticals (Was: Re: Comparing Object Identity)
On 12/12/2002 8:07 PM, Larry Wall wrote:
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
I thought that was now spelt exists %Main::{foo} -- that the symbol
tables were now just plain hashes? (And what's the methody syntax for
testing for hashkey existance -- %hash{key}.exists should get the key
element of hash, then run it's exists method, logicly. Is it
%hash.exists('key')?
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Or hypothetical variables in a non-regex context...
-=- James Mastros
Re: Comparing Object Identity
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no object id's are *ever* reused -- so mem addresses
are out, since the same address may be used for different things at
different points in time.
There'll definitely be memory address reuse. If .id returns the current
object's memory address, it shouldn't be cached any place, as otherwise
you'll find things going bang with some regularity.
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above. (That IDs should be
unique across a process over all time.) If that'd require that an
object's ID be a combination of the header address and a generation
counter, that's OK. It means a serilization point in the allocator, but
I think we'd need one no matter what (Dan?).
-=- James Mastros
Re: how to code a lazy pipeline?
On 12/10/2002 4:54 AM, Me wrote:
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
I belive the short answer is make sure all elements of your pipeline
return a lazy list. Exactly how one does this, and the distinction
between a lazy list and an iterator, I belive is still somwhat up in the
air. (If I'm wrong, please correct me.)
IOW:
foreach (map {$_+1} grep {$_0} @foo but lazy) {
do_somthing_here($_);
die Bye-bye universe! if ($_=42);
}
Will never compute anything after the first 41 element in @foo occours.
(I'm assuming map, grep, and any other list-oriented function that can
get away with it will act lazily when given a lazy-list argument.)
-=- James Mastros
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/05/2002 12:18 PM, Michael Lazzaro wrote: On Thursday, December 5, 2002, at 02:11 AM, James Mastros wrote: On 12/04/2002 3:21 PM, Larry Wall wrote: \x and \o are then just shortcuts. Can we please also have \0 as a shortcut for \0x0? \0 in addition to \x, meaning the same thing? I think that would get us back to where we were with octal, wouldn't it? I'm not real keen on leading zero meaning anything, personally... :-P You misinterpret. I meant \0 meaning the same as \c[NUL], IE the same as chr(0), a null character. (I suppse I should have said \0x[0].) Which means that the only way to get a string with a literal 0xFF byte in it is with qq:u1[\xFF]? (Larry, I don't know that this has been mentioned before: is that right?) chr:u1(0xFF) might do it too, but we're getting ahead of ourselves. Hmm... does this matter? Sorry. It does, in fact, not matter... momentarly stopped thinking in terms of utf8 encoding being a completly transparent process.
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/04/2002 3:21 PM, Larry Wall wrote:
On Wed, Dec 04, 2002 at 11:38:35AM -0800, Michael Lazzaro wrote:
: We still need to verify whether we can have, in qq strings:
:
:\033 - octal (p5; deprecated but allowed in p6?)
I think it's disallowed.
Thank the many gods ... or One True God, or Larry, or whatever your
personal preference may be. (So have a merry Christmas, Happy Hanukah,
Kwazy Kwanzaa, a tip-top Tet, and a solemn, dignified Ramadan.)
\0o33 - octal
\0x1b - hex
\0d123 - decimal
\0b1001- binary
\x and \o are then just shortcuts.
Can we please also have \0 as a shortcut for \0x0?
\c[^H], for instance. We can overload the \c notation to our heart's
desire, as long as we don't conflict with its use for named characters:
\c[GREEK CAPITAL LETTER OMEGA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI]
Very Cool. (BTW, for those that don't follow Unicode, this means that
everything matching /^[^A-Z ]$/ is fair game for us; Unicode limits
charachter names to that to minimize chicken-and-egg problems. We
/probably/ shouldn't take anything in /^[A-Za-z ]$/, to allow people to
say the much more readable \c[Greek Capital Letter Omega with Pepperoni
and Pineapple].
: There is also the question of what the bracketed format does. Wide
: chars, e.g. for Unicode, seem appropriate only in hex. But it would
: seem useful to allow a bracketed form for the others that prevents
: ambiguities:
:
:\o164 ne \o{16}4
:\d100 ne \d{10}0
:
: Whether that means you can actually specify wide chars in \o, \d, and
: \b or it's just a disambiguification of the Latin-1 case is open to
: question.
There ain't no such thing as a wide character. \xff is exactly
the same character as \x[ff].
Which means that the only way to get a string with a literal 0xFF byte
in it is with qq:u1[\xFF]? (Larry, I don't know that this has been
mentioned before: is that right?) chr:u1(0xFF) might do it too, but
we're getting ahead of ourselves.
Also, an annoying corner case: is \0x1ff eq \0x[1f]f, or is it eq
\0x[1ff]? What about other bases? Is \0x1x eq \0x[1], or is it
eq \0x[1x] (IE illegal). (Now that I put those three questions
together, the only reasonable answer seems to be that the number ends in
the last place it's valid to end if you don't use explicit brackets.)
(BTW, in HTML and XML, numeric character escapes are decimal by default,
you have to add a # for hex. In windows and several other OSes (I
think, I like to play with Unicode but have little actual use for it),
ALT-0nnn is spelt in decimal only. Decimal Unicode ordnals are
fundimently flawed (since blocks are always on nice even hex numbers,
but ugly decimal ones), but useful anyway).
-=- James Mastros
Re: String Literals, take 2
On 12/03/2002 2:27 PM, Michael Lazzaro wrote:
I think we've been gravitating to a language reference, geared
primarily towards intermediate/advanced users. Something much more
rigorous than beginners would be comfortable with (since it defines
things in much greater detail than beginners would need) and written to
assume *no* prior knowledge of Perl5. It will be useful to the
developers -- in that it will describe required P6 behaviors in much
greater detail than the Apocalypses and Exegesis -- but it will be
written for users.
I quite agree... which still means we need more rigor then this document
has. The defintion of a pair and the semantics of \c[ and friends is
important so that users know exactly what \c~ means ('',
Cchr(ord('['-64)) ), and if Cqq◄some words here► will work (no,
those aren't a matched Pi/Pf or Pb/Pe pair, they're just Misc. Shapes
that have no direction information, and we can't do them reasonably
without looking at every character in Unicode visualy -- if somebody
wants to, be my guest!).
Do we want to change shorthand octal literal numbers to 0o123 (I
don't like this, it's hard to read), change octal chars to \c123
(can't do this without getting rid of, or changing, \c for
control-character), get rid of octal chars entirely, or somthing
else? (Baring a good somthing else, I vote for killing octal chars.)
As of Larry's last writings, there will definitely be an octal (it still
has good uses), and it's syntax will definitely be 0o777 -- with an 'o',
not a 'c'. The 'o' is a little hard to read, but the best anyone can
come up with. It has to be lowercase 'o', not uppercase 'O', which
helps *enormously*. :-)
Huh? In that case, somebody should tell Angel Faus; Numeric literals,
take 3 says 0c777, and nobody disented. IIRC, in fact, nobody's
descented to 0c777 since it was first suggested.
(But since I assume you can use \d, \b, \h anywhere you use \o, you
won't have to use octal at all if you don't want to.)
\d is pure speculation on my part. (As is \0 == chr(0).)
In fact, for this, and \o777 vs. whatever, I'm cc-ing perl6-language on
this.
p6l guys and the Design Team, if you havn't been following the
conversation, here's how it goes:
In perl5, octal numbers are specified as 0101 -- with a leading zero,
and octal characters in strings are specified as \0101. In perl6, our
current documentation lists 0c101 as being the new way to write octal
numbers, because it lets people use leading zeros in numbers in an
intuitive way, and 0o101 was decided to be too difficult to read. The
last writing of Larry to address this, as far as I (or anybody else who
I've noticed) knows, says 0o101.
It's generaly been agreed on, I think, that 0c101 is the way to go.
Now, we're working on string literals, and the question is how we write
octal character literals. The current writer of the string literal spec
wants \o101 to be the new way to write what is \101 in perl5 (and
C). I'd prefer this to be \c101, to match up with how the current doc
says octal numerics are written. Unfornatly, \c is taken for
control-characters (ie \c[ eq chr(ord '[' - 64) eq ESC), which is a
more important use of \c.
What do we do, oh great and wonderful design team?
Numeric StringUpsideDownside
--- ----
0101 \101 p5/C compatable Unintutive
0o101 \o101 ConsistentHard to read
0c101 \o101 keeps \c for Inconsistent
control-char
0c101 unsupported Consistentoctal string chars
unsupported
0t101 \t101 Consistentwhat's tab?
Or somthing else?
All choices are bad, which one is best?
-=- James Mastros
RE: http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
How 'bout:
$foo = 'def';
$bar = 'ghi';
$y = 'abc$foo$bar';
$z = eval qq{$y};
Of course, for security and correctness reasons, you'd probably want
to:
$y =~ s/\\//g;
$y =~ s/!/\\/g;
Why would \\t not double-interpolate to a tab? Also, why would \\
not double interpolate to a syntax error?
Given $(...), you might as well give up on correctness and security.
It
seems like you really just want to have a limited version of eval
called
interpolate, e.g.:
$z = interpolate interpolate $y;
Then you have ultimate control. Of course, you have to check $ (er,
$!)
just like you do with eval.
Thanks for the excellent feedback from both of you. Using eval does
have its drawbacks, as Aaron points out, but along with some
substitutions like Luke suggested, it is fine for my purposes.
http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
Hi, I was wondering if anything ever became of the comments at http:[EMAIL PROTECTED]/msg00318.html? I have an application that would benefit from double interpolation. Of course I can work around it, but double interpolation would be so much cleaner. Was it ever implemented, or will it be? Sincerely, James
Re: ~ for concat / negation (Re: The Perl 6 Emulator)
From: Nathan Wiger [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 4:41 PM Subject: ~ for concat / negation (Re: The Perl 6 Emulator) Does anyone else see a problem with =~ ? Plus, it makes the pre-plus-concat that many desire impossible, since =~ is taken. God, yes. I constantly have problems with ~= vs. =~; this is only helped by the fact that =~ is normaly a syntax error. (It isn't when you use a qx//ed regex, which I don't do often.) In summary: 1. I don't like ~ for concat 2. But if it does become concat, then we still shouldn't change ~'s current unary meaning I 100% agree. It's shenanagnins like this that make perl people look like fringe wackos. I still fail to see why . is such an advantage over -. The only real benifit I see is typing ease, and - isn't that hard to type. That's what editor macros are for. It's rather unfornate that we've run out of characters to use for operators, but we've got to deal with it better then flipping around operators willy-nilly. -=- James Mastros
Re: suggested properties of operator results
From: Dave Storrs [EMAIL PROTECTED]
To: Chris Hostetter [EMAIL PROTECTED]
Sent: Sunday, June 10, 2001 9:07 PM
Subject: Re: suggested properties of operator results
On Fri, 8 Jun 2001, Chris Hostetter wrote:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which ... would cause the following code to mean ... think it
should mean:
if ($foo $bar $baz) { ... }
I'm assuming that you're correct (I see no reason that you wouldn't be; I
just havn't checked it out myself, and am not clear on where valueR is
defined.)
...
1) The do this because it will be more intuitive for beginners
argument comes up a lot, and is pretty appealing at first. However, as
someone (was it tchrist?) pointed out, beginners don't stay beginners for
long, so writing a language for beginners may cost you people when they
grow out of your language.
Which it is indeed. (The feature is a good idea, and tchrist is right.)
It's a lot easier to read, and a lot easyer to write ($a $b $c) then
($a$b) ($b$c). Moreover, when the varables have names longer then a,
b, and c, then it gets rather easy to change only one of several instances
of a varable. (That is, $a$b $b$c into $a$d $b$c).
2) This feature would be very prone to abuse (makes it easier to
obfuscate code), but that isn't a reason to disqualify something either.
Certianly not in perl. Hell, I think sometimes it's a reason /to/ put a
feature in perl.
3) Used for what it is intended for, it seems like a very concise,
expressive way to do multiple relationship tests without needing all those
s and such.
Indeed. (Though, as defined above, this won't work on the string
operations, only the numerics.)
-=- James Mastros
Re: Properties and stricture and capabilities
From: [EMAIL PROTECTED] To: David L. Nicol [EMAIL PROTECTED] Sent: Friday, June 08, 2001 8:01 PM Subject: Re: Properties and stricture and capabilities On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote: That would prevent further shoving of anything onto the symbol table without proper authorization as defined by holding the capability. Getting into details about this doesn't make much sense as we don't yet know what the new symbol table interface will look like. I thought Larry had said that it would be a plain hash, with funny- character included in the key. -=- James Mastros
Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
From: Michael G Schwern [EMAIL PROTECTED] To: Nathan Wiger [EMAIL PROTECTED] Sent: Friday, May 11, 2001 2:27 PM Subject: Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation) On Fri, May 11, 2001 at 10:56:38AM -0700, Nathan Wiger wrote: 2. Do we want to be able to switch between Perl 5 and Perl 6 in a single file (by using module to dictate P6 and package P5)? I'd say no. Although it would allow for incremental upgrades of legacy modules, the idea of mixing two versions of Perl in a single file makes the short hairs on the back of my neck stand up. It will be extremely confusing. Yes, it will be, and /I/ wouldn't do it if I could avoid it. OTOH, we're already talking about having support for multiple languages (parsers) within one file, and having perl5 being another parser. Put them together, and you get exactly this. -=- James Mastros
Re: Apoc2 - STDIN concerns
From: Larry Wall [EMAIL PROTECTED] To: Eric Roode [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 11:03 AM Subject: Re: Apoc2 - STDIN concerns Eric Roode writes: : And, while I'm on my soapbox here, I don't get how ... is a vast : improvement over qw :-) Please pardon my hyperbole. I don't loathe qw() so badly that I want to get rid of it. I merely want to put it in the same status as the other general quote operators that also have a non-general pair of standard quote characters. I would feel the same about qq// if there weren't a . Might I suggest, then, that instead of making foo bar a synonym for qwfoo bar, we use it for iterators, and use foo bar (by which I mean the character twice, not the « character -- though probably either should work). That lets us keep foo for somthing iteratorish, which saves special-caseing (I do occasionaly use a qw list with one element), and lets us keep continuity. Anyway, I'm fairly certian that I'll use iterators more then qw lists. -=- James Mastros
Re: Apoc2 - STDIN concerns
From: Michael G Schwern [EMAIL PROTECTED]
To: Nathan Wiger [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 9:46 PM
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still work normally.
Here's what I'd like (in general interators):
1) Using in a scalar context gets the next value. $line = $STDIN;
2a) Using in a unknown-length list context gets all the values. @lines =
$STDIN;
2b) Using in a known-length list context gets enough values. ($line1,
$line2) = $STDIN;
3) Using on the LHS of a = outputs a value (or a bunch of values if RHS is a
list).
4) Using on the RHS of a := copies. $STDOUT := $STDERR;
5) Using with a $() operator won't get. if ($($STDOUT) eq $($STDIN)) {foo}.
(?)
That is, getting without somthing special gets values out of the iterator,
getting
with a := gets the iterator itself (: for inner), and $() derefs it to a
filenameish thing (?).
This leaves free, and I think the use of := agrees with what is planned.
It also avoids the use of a verbose .next (and the dot, which I still don't
like G).
-=- James Mastros
Re: Apoc2 - STDIN concerns
From: Nathan Wiger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 10:02 PM Subject: Re: Apoc2 - STDIN concerns You know, I hear what you're saying, but it really makes the little hairs on my neck stand up. Just imaging trying to teach this: $a = $b;# assignment or readline? It's really spooky. You're changing what = does, indeed what method it calls (copy vs next), based on the contents of the variable. I'd much rather have to do: $a = next $b; I think that = should always be get a value, and := should always be get the thing itself. For normal things, the thing itself and it's value are the same, so := is equivlent to =. Truthfully, I've always liked the 's (and personally don't think we need a qw alternative), so I'd rather we stay with: $a = $b; # same as next $b or $b.next Hey, maybe we can convince Larry... ;-) I'd tend to agree. Especialy that we don't need a qw() alternative. However, I don't think Larry's in a convincable mood -- coughdotcough. -=- James Mastros
Re: Please make last work in grep
From: Alexander Farber (EED) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 02, 2001 5:13 AM Subject: Please make last work in grep Here I am looking for a button with a special name - Delete ... - and there can be only one such button, so I have to interrupt the grep after I find it I'd rather see grep have split-like magic, where it sees the length of the list it is being assigned to, and stops when it has filled the list. So ($a, $b) = grep /!(.*)/, qw(1 4 0 5 !0!0 98 46 !9 !097!0!9080; would stop looking after it had found and returned 0!0 and 9, and never even glance at the 98. Basicly, if you assign to a list of lvalues, @returnlist, it will stop looking after it has found scalar(@returnlist) matches or end-of-input. -=- James Mastros
Re: Tying Overloading
From: Larry Wall [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:10 PM Subject: Re: Tying Overloading Helgason writes: : I _really_ think dot-syntax would make perl prettier as well as make it : more acceptable to the world of javacsharpbasic droids. Which is some : kind of goal, no? Consider it a given that we'll be using . for dereferencing. (Possibly with - as a synonym, just for Dan. :-) Larry I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? Reasons I have seen are: 1) Two less keys to press. 2) Looks cleaner. 3) Looks more like other languages. Counterarguments: 1) Produces confusion for perl5 programmers. I think that we should be kinder to perl5 programmers switching to perl6 then to java[script]/vb programmers switching to perl6. (C and C++ shouldn't be an issue; we stole - from C in the first place.) I submit that := is far uglyer and harder to type then -. I don't think that we should change around huge amounts of other things just so we can s/-/./. If we really want an easyer-to-type method call operator, I'd go with \. It's use currently outside of a qq is erronious. It can't interoperlate inside of qq, but nor can any other operator discussed here. It doesn't look much like whitespace (if that's what you mean by looks nice). If you want that, you could go with `, which could produce some ambiguity, both with qx and with ', which looks very similar in many fonts. BTW, I think that considering no-whitespace cases of indirect object is quite silly -- does anybody acatualy use that? This is the first I thought it wasn't a syntax error. -=- James Mastros
Re: YA string concat proposal
From: Jonathan Scott Duff [EMAIL PROTECTED] To: Nathan Wiger [EMAIL PROTECTED] Sent: Tuesday, April 24, 2001 4:08 PM Subject: Re: YA string concat proposal On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote: Under the above plan, maybe this is: $a ca $b; For concat after? I'd rather it be called pp for prepend. :-) I'd rather it be spelled $a =. $b; (or $a=.$b, or $a=./index.html; I don't see how any of those are subject to misparse. $a=.5 would be, of couse, but you can disambugate by $a=. 5 or C$a=.5. It's good that we decided to let Larry design the language, otherwise we'd be mired in muck like this for a long time. Yah. And it looks like we're going to be as it is. It's been said elsewhere on these threads: What does changing to . from - buy us? I can see that . is shorter to type then -, but, say, \ would be just as good. I can't really say changing because . is more standard. It isn't standard to C or perl5. It's possible to misparse . as concat with . as a sepperator on version-strings, but that's more of a problem with using it for method-call. -=- James Mastros
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 11:17:49AM -0700, Larry Wall wrote: Hence, :+ would be pairwise array addition. Sounds quite reasonable. There will probably be optional modifiers before colon for various reasons. This has the result that we could distinguish an inner:* operator from and outer:* operator. (Labels would be required to have whitespace after the colon, in this scenario.) It also means that every operator has a function name, so you could call inner:*(@a, @b) or @a-inner:*(@b) or some such. Hm. If I assume that s/:/::/, I like it. Otherwise, I really really don't. Why? Because it introduces more namespaces (and probably syntax) when they aren't really neccessary. If you use a ::, and make packages able to define operators straight-up, then you could do, say, $a dB::+ $b. There would be a :infixable attribute on subs, so you could make infix operators with arbitrary names: use Game::DnD 'D'; $hp = 3 D 6; It might even mean that we can have a URL literal type, if we can figure out how to parse it, and if there's any good reason to treat a URL as more than just a string: print $::OUT http://www.wall.org/~larry/index.html; Please, no! A URL isn't a /new/ type of literal, really. Either it's a wierd form of a literal list, or it's a wierd type of file name, so you should open() it. Or it's a self-quoting literal, like Packagename::. If you really want to be able to read from a URL in one line, let yourself do open(foo). But make opening a URL an explicit act. But I really mustn't spill too many half-digested beans here. :-) If you have to, at least do it in the toilet. P.S. Larry's Second Law of Language Redesign: Larry gets the colon. May He (or You) do Good Things with it. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
OK, there's probably somthing simple I'm missing here, but... 1. Cuse 5 or Cuse 6 (and, in general, Cuse vervect) import the definitions of the language as it existed at that time (more or less), or die if they can't. (Or run through p52p6, or whatever.) Advantage: matches existing precedent. The real perl 5 won't choke on it, and will even give the right error. 2. If the name of the executable (from argv[0] or the beginning of #!) contains "perl.?[56]", then there is an implicit Cuse 5 or Cuse 6. (And why not any other version number? Just don't ship them in core, please!) Advantage: reasonably non-intrusive. 3. Otherwise, assume perl 6. Advantage: we require trivial changes in existing scripts instead of baggage we'll be carrying around forever. If you object to that much change as an admin, feel free -- install perl6 under the name "perl6", symlink perl5 to it, and make a symlink from perl to perl5. (This would work only if we had #2 follow symlinks until it saw a "perl5" or "perl6", which is probably fine). If you don't have symlinks on your system, then get a better system, use a site-policy file, or bite the bullet and change the #! lines. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 06:12:30PM -0400, John Porter wrote: Michael G Schwern wrote: ETOOMAGICAL. Shades of zip/unzip here. On some systems zip and unzip are just hard links to the same binary. It figures out what it supposed to do by what name is called. Very magical. Very bad. Well, the proposed trick for perl would be bad; what zip does isn't. argv[0] is just another arg, afterall. Hmm. I rather fail to see the difference between the zip vs. perl. On the other hand, I don't like it when bzip2 does it either -- you can't symlink bunzip - bunzip2 and bzip - bzip2 and have it do the Right Thing. On the gripping hand, when combined with other mesures, not so bad. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote: Are we over-optimizing? The Perl is just an interpreter language. Who really needs this kind of optimization for Perl? Even C does not provide this feature. Umm, art thou sure? C can optimize better then we currently do many times, because it doesn't have to worry about side-efects as often because it doesn't have the concept of ties/overriden operators. (It does, and we do, have to worry about aliasing, but that is somthing of a smaller problem.) Just because C doesn't memonize, doesn't mean we shouldn't have that optimization available to us. So many other optimizations that are doable in C aren't in perl. Though Pascal/Ada have distinctions like function/procedure, it does not make them any faster than C. Umm, I don't know Ada, but in Pascal, the only difference is that one returns a value and the other does not (IE like void vs. nonvoid functions in C, or sub vs. function in VB). Just given its ugly name, I hate to see it in the core language. If people really want to optimize Perl, they can write a native compiler for Perl with advanced garbage collector, just like Scheme or Strongtalk compiler? We want to make it as fast as reasonably possible. Writing a native compiler might not be _reasonably_ possible. And an advanced GC will almost certianly be part of perl6; they're orthogonal issues. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Thu, Mar 29, 2001 at 10:36:48AM -0800, Hong Zhang wrote: I have to say that I agree to disagree. Since it has been so controversal, I just don't think this optimization is a good one. Hmm, we aren't talking sort() specificly anymore. Look at the subject line. G The function in Ada can not have any side effect, i.e. no change to globals. The procedure can have side effect. It gives compilers some more chances for optimizations. For example (pseudo code), function comp(int n, int m) : int; the compiler can safely remember the result of comparison for the same arguments. Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Wed, Mar 28, 2001 at 09:38:59AM -0500, John Porter wrote: Mark-Jason Dominus wrote: I have to agree with whoever followed up that this is a really dumb idea. Yahbut... (See last paragraph, below). OK, I'm agreeing with MJD on this one, and it was my idea. There is no easy way to check for statelessness in all cases. In some cases you can -- sin($a) = cos($b) is obviously stateless (if $a and $b aren't magic), because it is composed only of stateless primitives. This runs afoul of the halting problem real quick. Or so I'm told, and I belive it. If the comparison (or key extraction) function is not idempotent, that is a much worse situation than simply one of degraded performance. It means the result of sort() won't be (or at least will not be guaranteed to be) sorted! My intuition says that it will either be sorted, for a simple def of sorted ($s[i] = $s[i+1]), or will take infinite time. (The "take infinite time" is, I assume, the one that made things dump core.) if my_compare(a,b) 0, and my_compare(b,c) 0, then it should also be the case that my_compare(a,c) 0 Hm. We could call that "relative idempotency", I suppose. I'd go with "transitive", since this is a property of the comparator, not the extractor. If you seperate the comparator and the extractor(s), then the comparator must be transitive, and the extractors must be internaly stateless. But, aaui, it is not a question of the comparison function being idempotent, but the key extraction function being so. aaui? Hm. Let's define some terms like "idempotency". These are also my (current) ideas for sub attributes. Stateless: The function neither depends on state, nor modifies it. This makes it a pure (IE mathematical) function. f(a) == f(a), and there is no side-effect. sin() is stateless. This means the function is memonizeable. Internaly stateless: f(a) == f(a), but there might be sideefects that do not effect the return value. printf is internaly stateless (ignoring linenoize vars). This is the essencial property of key extractors. Note that all stateless functions are internaly stateless. Transitive: if my_compare(a,b) 0, and my_compare(b,c) 0, then it should also be the case that my_compare(a,c) 0 I can't define it better then that. (Though there's more to it then that). Note that only the sign of the answer is gaurnteed, so it doesn't even have to be internaly stateless -- but it probably doesn't make sense for it not to be. Give the braindead no head. You might want to change that to "heed". -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian transforms
On Wed, Mar 28, 2001 at 11:11:20AM -0500, Dan Sugalski wrote: "Can perl automatically optimize away function and tie calls inside a sort function, and under what circumstances?" Agreed. It doesn't really matter if the functions inside the sort function are idempotent--what matters is whether it's OK for us to go and memoize the things (or whatever else we might choose to do) As far as I can see, this, in essence, gives a few basic cases: 1) The sort function is ill-defined. 2) The sort function is stateless. 3) The sort function is simply internaly stateless. 4) The function is well-defined, but not stateless whatsoever. In case 1, The sort won't work anyway, so we can ignore this case. I'm of the opinion that we should consider 3 to be Just Plain Silly and not worth worring about overmuch. (These would be functions that increment a counter every time they are accessed, for example.) I think that the difference between 43 dosn't matter. We only have things in 4 and not 3 that vary in abs(), but not sign. We're left with 12, and for 1, the sort won't work anyway. So long as we consider 2 Just Plain Silly, we're OK memonizing. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 04:36:58PM -0500, Dan Sugalski wrote: With perl, though, this does potentially unexpected things if $i is tied. Do we still optimize it away? Do we only do it if we can tell that $i's not tied? Yep. And in non-trivial cases, the only way to do that might be for $i to be :simple. Do we force the programmer to explicitly note which variables are potentially tied with the "my Dog $spot" syntax and assume that everything else is fair game? I'd rather see that things that will never be tied or otherwise magic be marked as :simple. Code always works, and will be faster with a little effort. Can we even do that in the face of runtime requires, dos, or evals? (Or does that force a complete reevaluation of the optimized bytecode) It is a catchable error to remove a behavorial restrictor attribute such as :simple or :stateless. So let it be spoken, so let it be done. This isn't any more preverse then the "you can't assign to constants" rule. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 05:57:30PM -0500, James Mastros wrote: [A bunch of stuff] Oh, and I agree with sombody else on this thread that unless otherwise stated, the sort should always assume statelessness (and thus the ability to cache at will). If it's trivial to see that the sort function isn't stateless (IE it's a named sub that doesn't have the :stateless attribute set), then have an optional warning, because you probably don't want to be using that function, or the function should be marked :stateless. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
The only issue there is whether memoization is appropriate. It could be
argued that it isn't (it certainly isn't with perl 5)
Hm. I don't see a linguistic reason why it isn't with perl5. Unless the
comparisign function as a whole is stable (IE {f(a) = f(b)}, the sort
function is documented as being undefined.
The only way f(a) can not be stable and f(a) = f(b) can be is somthing of
a corner case. In fact, it's a lot of a corner case.
though I for one
wouldn't mind being able to more aggressively assume that data was
semi-constant...
Well, you can. Unless it has magic (and more specificly, scalar get magic).
(Imagine returning tied data from a function loaded in via
do(). Imagine the optimizer. Imagine Dan's brain popping out of his head
and hiding behind the bookcase)
That's a really wierd image. Twisted, even.
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Perl culture, perl readabillity
On Mon, Mar 26, 2001 at 01:11:06PM -0700, Dan Brian wrote:
As for the English influence, you're welcome to identify ways that the
syntax could be extended or tightened to be less so. That's the intent of
the mailing list. But please, no more Latin ... I like positional
dependency. :)
Hmm. I just relized what he's talking about. As an example, most nonsimple
statements (IE past-tense, ones with modal and action verbs, etc) end in the
verb. For example, an english-speaker would say:
I must walk the god. (Subject modal-verb action-verb direct-object.)
A german-speaker would say:
I must the god walk. (Subject modal-verb direct-object action-verb.)
(Yes, I am a dislexic, agnostic insomniac.)
This is exactly analgous to the perl form (english-perl):
sort { f(a) = f(b) } @list; (Action-verb subordanate-verb (adverbal form)
direct-object.) OTOH, for a german-speaker, sort @list {f(a) = f(b)}
would be more natural (Action-verb direct-object subordanate-verb
(infinitive form)). (Note, BTW, that gramaticly, perl statements always
have a implied subject of "Intepreter" [0]. (Also note that in english, the
adverbal form of a verb normaly ends with ly, in german it ends with en, and
in perl is surrounded by curly-braces.))
Hmm, in fact, perl statements are always in command form, which means that
in german, they are always non-simple sentances, and the verb is always at
the end.
OTOH, there are cases where perl is more readable for not
matching a natural language structure. For example, hit $ball
$outfield; is a normal structure: verb indir-obj dir-obj. OTOH,
$ball-hit ($outfield) is indir-obj verb dir-obj, which is just screwy from
an english point of view, but perfectly normal from a perl viewpoint.
Then again, if you think of objects (in the OO sense) as doing things, then
they normaly are the subject, and _not_ the indirect-object (in the english
sense).
(Note, BTW, that both my german and my lingustics aren't so hot.)
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 07:31:29PM -0500, Dan Sugalski wrote: At 06:51 PM 3/26/2001 -0500, John Porter wrote: As for :idempotent, I think sort() needs to assume the comparison sub is idempotent, rather than requiring such an attribute explicitly. Assuming idempotency's fine, though I don't know that I'd go so far as to require it. I certainly wouldn't complain, though. I'd think /perl/ should complain if your comparison function isn't idempotent (if warnings on, of course). If nothing else, it's probably an indicator that you should be using that schwartz thang. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 06:31:22PM -0500, Dan Sugalski wrote:
At 04:04 PM 3/26/2001 -0500, James Mastros wrote:
The only way f(a) can not be stable and f(a) = f(b) can be is somthing of
a corner case. In fact, it's a lot of a corner case.
You're ignoring side-effects.
Damm. I hate it when I miss the obvious. It's still a corner case, but not
so ignorable of one.
Well, you can. Unless it has magic (and more specificly, scalar get magic).
Yeah, but figuring out whether data isn't magic is rather tricky.
It shouldn't be, since we have to check for scalar get magic every time we
get the value as a scalar anyway. Figuring out whether it is depenedent on
some other thing which is magic, on the other hand, is really freeking nasty.
Once a
little uncertainty comes in (Say, from AUTOLOADed subs, or from subs whose
contents we don't know at compile time because of runtime requires, or
because we really do have magic data and the potential uncertainty from it
flares out quickly) it really cuts down on what the optimizer can do.
Youch. I tend to forget how "incestuous" perl is (as another message on a
perl6 list said quite some time ago).
I'm definatly with the guys who say we should have a :constant and a
:idempotent attrib for subs, and make them unremovable.
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Thu, Mar 22, 2001 at 11:13:47PM -0500, John Porter wrote:
Brent Dax wrote:
Someone else showed a very ugly syntax with an anonymous
hash, and I was out to prove there was a prettier way to do it.
Do we want prettier? Or do we want more useful?
Perl is not exactly known for its pretty syntax.
If you have to explicitly specify both the forward and inverse transforms,
then it isn't very useful -- it's nothing more then map/sort/map. OTOH, if
you only have to specify the forward mapping, it becomes more useful. Thus,
I think the best syntax is
tsort({xform}, {compare}, @list), where the {}s are anon blocks or curried
expressions (same thing) and xform specifies the forward mapping (IE (lc
^_)) and compare specifies the comparator (IE (^_ cmp ^_)).
This would always (do the equiv to) create a LoL in the inner map, sort on
the -[0] elem, and extract the -[1] elem. Thus, it might not be as
effecent as a hand-crafted schwartzian, but will be at least as efficent as
a naieve straight sort (except in pathalogical cases, like tsort((^_),
(^_=^_), @list)).
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
@s = schwartzian(
{
second_map = sub { $_-[0] },
the_sort= sub { $a-[1] = $b-[1] },
first_map = sub { [ $_, /num:(\d+)/ ] },
},
@t );
Hm. I'd rather see:
schwartzian({/num:(\d+)/}, {^_=^_}, @t), and have perl figure out how to
do the forward and backword mappings. Hmm, I don't see why you couldn't
write that right now. (Other then synthatical shugar -- currying and
getting rid of the need for "sub {}"s.)
Indeed,
map $_-[0], sort {$sort($a-[1], $b-[1])} map [$_, $attrib($_)], @list;
does what I intendeded. (Where ex $sort = sub {$_[0] cmp $_[1]}, and
$attrib = sub {lc $_}.) (Of course, this doesn't always use the optimal
form.)
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
