Re: Synposis 26 - Documentation [alpha draft]
On 10/7/06, Damian Conway [EMAIL PROTECTED] wrote:
The CI formatting code specifies that the contained text is
to be set in an Iitalic style
I've probably been hanging around Web standards nazis for too long,
but can we get a separate code to mark the title of a document that
can't be linked to (say, a book) along the lines of HTML's cite tag?
=begin item :term('Chttp: and Chttps:')
A standard URL. For example:
This module needs the LAME library
(available from Lhttp://www.mp3dev.org/mp3/)
=end item
=begin item :termCfile:
A filename on the local system. For example:
Next, edit the config file (Lfile:~/.configrc).
=end item
=begin item :termCman:
A link to the system man pages. For example:
This module implements the standard
Unix Lman:find(1) facilities.
=end item
=begin item :termCdoc:
A link to some other Perldoc documentation, typically a module or core
Perl documentation. For example:
You may wish to use Ldoc:Data::Dumper to
view the results. See also: Ldoc:perldata.
=end item
Actually, a couple more link schemes could probably handle my previous request:
LPerl 6 and Parrot Essentials|urn:isbn:059600737X
LParrot Magic Cookies in The Perl Review|urn:issn:1553667X/3/0#11
If a renderer cannot find or access the external data source for a
placement link, it must issue a warning and render the URL directly in
some form. For example:
=begin indent
BCOPYRIGHT
See: /shared/docs/std_copyright.pod
BDISCLAIMER
See: http://www.megagigatera.com/std/disclaimer.txt
=end indent
Oooh, transclusion--shiny. Perhaps the pipe character can be used to
provide alternative text:
PSee standard copyright terms in the
distribution.|file:/shared/docs/std_copyright.pod
Also, what about non-textual files? If I type
Phttp://www.perlfoundation.org/images/onion_64x64.png, will an onion
appear in my Pod document? That would obviate custom =Image
directives.
Perldoc provides a mechanism by which you can extend the syntax and semantics
of your documentation notation: the C=use directive.
Um...how can this be made to work? Are renderers going to have to
know about every possible plugin? Are plugins going to have to know
about every possible renderer? Will dogs and cats be living together?
C=config specifications are lexically scoped to the block in which
they're specified.
=config head3 :numbered
=cut
method foo($bar, $baz) {
...
}
=head3 Cfoo(RbarC, RbazC)
...
Is that =head3 numbered, or is it in a different lexical scope?
(Actually, I don't see any reference to =cut in this spec. Is it
still there or not?)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Flunking tests and failing code
Luke Palmer [EMAIL PROTECTED] wrote: I wonder if there is a macroey thing that we can do here. That is, could we make: ok(1); is(1, 1); like(foo, /foo/); Into: ok(1); ok(1 == 1); ok(foo ~~ /foo/); And lexically analyze the argument to ok() to find out how to report the error? Something in the style of Smart::Comments which looks at subexpressions and tells you about them automatically. It strikes me that the test framework is probably the one part of the libraries where simplicity is more important than DWIMmery, lest a Perl bug manifest itself somewhere deep in the bowels of the test framework itself. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Solving '=' confusion: ':=' for aliasing
Chip Salzenberg [EMAIL PROTECTED] wrote: P0 := P1 # aliasing: P0 and P1 point to same PMC P0 := opcode # aliasing: P0 points to PMC returned by opcode P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS S0 := S1 # aliasing: S0 and S1 point to same header S0 := opcode # aliasing: S0 points to header returned by opcode S0 = ... # assignment: modifies S0, NO MATTER WHAT '...' IS I0 := ... # ILLEGAL I0 = ... # assignment: modifies I0 N0 := ... # ILLEGAL N0 = ... # assignment: modifies N0 I'm not sure about the last two (in a lot of ways, they're more like := than = ), but it's certainly far better than the status quo. I suppose that copying looks like: S0 := copy S1 -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Solving '=' confusion: ':=' for aliasing
Chip Salzenberg [EMAIL PROTECTED] wrote: On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote: I'm not sure about the last two (in a lot of ways, they're more like := than = ), I don't see that. Well, for one thing, my way would mean that `set` is always `:=`. Basically, though, my way would mean that copying the register's exact contents would always be done with `:=`, and more complicated assignments with potentially complex semantics would always be `=`. On the other hand, I can see why you would consider alias/not-alias to be a more important consideration. I suppose that copying looks like: S0 := copy S1 Yes, modulo the choice of the word copy. I might call it clone, which emphasizes that the return value has its own identity. `clone` does sound better. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Classification syntax [Was: Renaming grep]
Larry Wall [EMAIL PROTECTED] wrote: The name is relatively unimportant in the overall scheme of things. I'm more worried about the fact that it's difficult to partition a list into multiple lists in one pass without declaring temp arrays. Didn't the list agree long ago on a `part` builtin? I certainly wrote List::Part based on that discussion... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Hashing: avoid MD5 and SHA-1; use SHA-2 or Whirlpool
Chip Salzenberg [EMAIL PROTECTED] wrote: Similarly, we should avoid SHA-1 for any permanent purpose, though in the short term it's not quite dead yet. No one has demonstrated an ability to create SHA-1 collisions on demand (as far as I've heard, anyway), but SHA-1 is a wounded fish in shark-infested waters[*], and an MD5-scale failure may be just a matter of time. My understanding is that the best attack on SHA-1 which can find two plaintexts with the same hash value in 2^63 operations. (Brute force for this is 2^80 operations; cryptographers consider 2^64 to be practical, although it'd still take tremendous resources to attack in any reasonable time.) The attacker has to control both plaintexts; he can't use this attack to find a collision for an existing plaintext. For an example attack, imagine that Parrot has a security scheme in which extra privileges are granted to code by signing a SHA-1 hash of the code with a particular key. (Public-key signing is so slow that hashes are always used with digital signatures.) This attack means that, in 2^63 operations, an attacker could generate two pieces of bytecode with the same hash value. If he could get one of them signed (say, the one that draws pictures of cute kittens on the screen), he could then attach its signature to the other one (say, the one that installs a rootkit and sends all your credit cards to Russia). Note, however, that the attacker needs to control *both* plaintexts. Finding a collision for bytecode in the standard libraries would still require a brute-force attack. Basically, SHA-1 isn't a problem for us yet, but it's looking weak. I'm getting the feeling that the real lesson is that any hash header system we build will require pluggable hash algorithms, because anything we pick as strong today may be broken tomorrow (or in ten years). From what I've read, that was one of the conclusions of NIST's recent hash workshop. (The other is that cryptographers need to do a lot of theoretical work on hashing--they don't really know how to design a strong algorithm yet.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Hyphens vs. Underscores
Daniel Brockman [EMAIL PROTECTED] wrote: So what is my suggestion? Obviously disallowing underscores and instead allowing hyphens would just replace one problem with an even worse problem (not only would there still be people who don't like hyphens, but it would alienate a large portion of the user base). Therefore, to make the language more appealing (i.e., less alienating) to the group of people I am going to refer to as Lispers, it's obvious that both characters should be allowed. I see a few syntactic problems with this idea: the subtraction and negation operators you already mentioned, but also the fact that dashes are already used in package names to indicate version and author (`class Foo::Bar-2.10-cpan:BRENTDAX;`). I suspect that both of these problems will be more troublesome than you might guess. But there's a philosophical problem too. This proposal is an instance of what I'm going to call the dimmer switch problem. In American cars at least, virtually every control on a car's dashboard has an immediate purpose and utility. There are steering controls (i.e. the wheel), cruise control settings, controls for exterior lights, controls for the radio and air conditioner, and so on; all of these need to be within easy reach of the driver, either because he needs them to safely operate the car or because he's likely to want to twiddle them while he's driving. And then there's the dimmer switch, used to control the brightness of the dashboard's lighting. This is not something the driver often changes, and it's not crucial to the car's operation. A driver will adjust it once if he bothers adjusting it at all. It's there solely because different people have different preferences for the brightness, and there's nowhere else to put it. Perl has a lot of different ways of doing things. But if you examine the design, you'll realize that they aren't mere cosmetic differences--each form lends itself to different tasks. For example, `for`` and `map` are functionally equivalent, but implementing a Schwartzian transform is much easier with `map`, and a large loop body is much easier to visually parse with `for`. A lot of the suggestions I see for Perl 6 are dimmer switches; they add an option or two to better suit someone's tastes but don't add any power to the language. This is hardly the first case; the suggestion a long time ago to use backtick as a subscript operator comes to mind, but there have been many others. Car designers, of course, are stuck with the dimmer switch: they do need to provide some way to provide this feature to their customers, and there are only so many ways to do it with a physical piece of plastic and vinyl. Language designers are luckier, though, and Perl 6 is better than most. This feature can be added as grammar-modifying pragma. If you want the hyphen, simply type something like `use hyphens;` and you can use hyphenated identifiers in the surrounding scope. And unlike Ruby, this will be easy to do unambiguously: just override the Perl 6 grammar's identifier rule. All the edge cases will be resolved by the longest token principle, so `foo-bar-baz` will be an identifier. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: perl6
BuildSmart [EMAIL PROTECTED] wrote: I've visited both these sites, I was unable to find a download for perl6 I'm not particularly interested in an implementation of it, what I'd like is the source code for it so I can build it. Perl 6 is still in the design phase. The only version of it that's even slightly working is Pugs (linked previously), which implements a useful subset of the language, but is meant more for experimentation than production use. We hope to have something more useful within a year or so--with the all-important grammar engine coming together and the Parrot runtime getting to the point that Pugs can reasonably emit code for it, we should be able to bootstrap Perl 6 within a year or so, giving us a beta release. Sorry it's taking so long--we really want to get this thing right! (Note to the rest of the list: the Status page on dev.perl.org/perl6 is hopelessly out of date; that should probably be rectified.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: HLL Debug Segments
Leopold Toetsch [EMAIL PROTECTED] wrote: On Nov 15, 2005, at 0:07, Jonathan Worthington wrote: What's the fascination with overloading comment syntax? Because a compiler can emit it right now w/o any change to Parrot. That's an advantage for the week it takes to implement the feature. For the remaining age of the universe, however, it's a detriment, because Parrot will silently ignore any syntax errors and programmers will have to be careful to ensure their comments aren't magic. If it walks like a pragma and quacks like a pragma, it should have the syntax of a pragma. Use a leading dot; you'll thank yourself later. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Ways to add behavior
Larry Wall [EMAIL PROTECTED] wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Then evolutionists could make jokes about the K(T) boundary, and creationists could make jokes about reproducing after their kind. Some of us could make either kind of joke. But perhaps it wouldn't be kind. Flavor. (Shades of CLOS, but we're already building the most flexible object system since it...) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: new sigil
Steve Peters [EMAIL PROTECTED] wrote:
~ seems to be available for a sigil, if my reading of S02 is correct, and
the cent sign is replacing :: in all cases. If not (that is $::foo is
still the global variable named foo) then * may also be available.
Sigils can't conflict with unary operators (like, say, the
stringification and flattening operators, ~ and *) and ideally
shouldn't conflict with binary ops either (although % breaks this
rule).
This has been done before several times on p6l, but I'll do it again:
Chr TermOperator
===
~ Stringify Concatenate
` Reserved for user Reserved for user
! Not
@ Array sigil Array sigil
# Comment Comment
$ Scalar sigilScalar sigil
% Hash sigil Hash sigil, modulo
^ (Not sure) one() junction
Subroutine sigilall() junction
* Unary splat Multiplication
( Open paren Subroutine call
) (technically unused)Close paren
- Negate Subtract
_ Identifier (technically unused)
= Iteration Assign
+ Numify Add
\ Take reference
| any() junction
[ Anonymous array Array index
{ Block Hash index
] (technically unused)Close square bracket
} (technically unused)Close curly bracket
; (technically unused)Statement delimiter, anonymous array
: Pairsuper comma
' Single quotes (technically unused)
Double quotes (technically unused)
, (technically unused)List items
quote words Less than
. Method call on topicMethod call
(technically unused)Greater than
/ Anonymous rule Divide
? Boolify
There are very few unary operators available, and none (besides the
user-defined backticks operator) unused in both term and operator
context.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: What the heck is a submethod (good for)
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a cascade method syntax would
be better for that:
post method BUILD($foo, $bar) { ... }
pre method DESTROY() { ... }
Cascade methods would be called (before|after) the indicated method in
a superclass was called. Their return values would probably be thrown
away. I think they might actually be a sort of syntactic sugar for
inserting `call` in the method body, but that's an implementation
detail, really...
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Proposal to make class method non-inheritable
Stevan Little [EMAIL PROTECTED] wrote: I would like to propose that class methods do not get inherited along normal class lines. I think you're not thinking about many major usage cases for class methods. For one example, look at my Cipher suite. (It's in Pugs's ext/Cipher directory.) The Cipher base class implements most of the visible API, while subclasses simply override a few internal methods; Cipher turns the wide-ranging, convenient external API into a smaller, more easily implementable internal API. Some of Cipher's methods are class methods, including the pseudo-procedural .encipher/.decipher and the pseudo-functional .encipherer/.decipherer methods. These methods are included specifically *to* be inherited. In my opinion, class method inheritance is an important part of class-based OO--almost as important as object method inheritance. Removing features simply because their implementation is inconvenient is not The Perl Way. If it were, Perl 6 would be Java With Sigils. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: my $key is sensitive;
Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: So, such a sensitive modifier could be added, but its precise meaning would be highly dependent on the underlying implementation. Okay, but there needs to be some minimum standard for it, like the memory in question no longer contains its original contents after garbage collection. The security of the key keeping my information from the Secret Police shouldn't be compromised because the particular Perl backend I'm using doesn't implement is sensitive in a meaningful way. I would like is sensitive to be defined to mean that any data stored in that variable, at any level of recursion, will be zeroed out as soon as it is garbage collected. Particular implementations can add extra features on top of that--such as stopping the VM from swapping it or even actively encrypting that area of memory--but without a minimum standard there's no point in supporting the feature at all. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: rx ops and support is deprecated
Leopold Toetsch [EMAIL PROTECTED] wrote: As Brent is listed as author in rx.ops I wanted to make sure, if it's ok to remove ops/rx.ops, src/rx.c and associated files. See also the file DEPRECATED in parrot's root dir. I have no problem with this--the rx ops were an early experiment based on an incomplete understanding of the problem. I wrote the optimized int stack too for the rx ops--are you planning on keeping that? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
my $key is sensitive;
For the last couple days, I've been implementing a cryptographic cipher framework for Perl 6. (It's in the Pugs repository if you want to see it.) Dealing with this sort of algorithm has brought forward a feature that I think Perl 6 and Parrot ought to support. Basically, I'd like to be able to mark a variable as sensitive or secret. This implies that the language should overwrite the memory it uses before deallocating it, and that if possible it should tell the virtual memory system to avoid swapping it out. Moreover, it should probably do so recursively, and to any value that has ever been stored in the variable. (In essence, the *variable* marks all *values* it ever contains as sensitive.) This feature could make Perl 6 a better language for security work than any other I've seen. C and C++ could do this, but only with the programmer's assistance (by calling a wipe function or making sure a destructor is correctly called), and optimizers have been known to helpfully remove such code. Many higher-level languages, including Perl 5, make it hard to know when a piece of data is being overwritten, rather than a pointer being changed. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: [perl #16622] [PATCH PDD07] Document struct naming conventions
I submitted the patch below my sig way back in August 2002, in ticket 16622. It documented the then-current naming conventions for structures. Is it still accurate and/or a good idea? Should it (or an up-to-date version of it) be committed? Yet another year has rolled by. Do you still want this change to be considered? Certainly. Note that the naming conventions are now being followed by Interp and friends. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: item and slurpy
On 9/9/05, Juerd [EMAIL PROTECTED] wrote: I am glad item is as official as it gets, but I have no personal favourite between list and slurpy. Please, list members, start a flame w^W^Wdiscussion about this so that it can be settled. I'll fire the first shot: type names should be nouns, not adjectives. But Pugs's internal type names are fairly irrelevant, as long as they have the right names on the outside. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: multisub.arity?
On 9/7/05, Luke Palmer [EMAIL PROTECTED] wrote:
And this is based on lexical expansion. Which is cool. In fact, once
upon a time I was going to propose that junctions are a purely lexical
entity, expanded into greps and whatnot by the compiler; that you
can't ever stick them in variables. Your examples above are just more
attestment to that, since there is not one of them that I can't write
confining all junctions to lexical areas.
Here's a Real Live Perl 6 module I wrote recently. I've omitted a few
magic portions of the code for clarity.
module Trace-0.01-BRENTDAX;
my $active;
...
sub activate(*%newtags) {
$active |= any(keys %newtags);
}
sub trace([EMAIL PROTECTED] is copy, *%to is copy) is export {
...
if $active eq any('all', keys %to) {
...
print $ERR: @msg;
return [EMAIL PROTECTED] #but true;
}
return;
}
I rather like that non-lexical use of junctions.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
[RELEASE] WWW::Kontent 0.02: Release and revelations
= WWW::Kontent 0.02 I am happy to announce the release of WWW::Kontent 0.02: File: $CPAN/authors/id/B/BR/BRENTDAX/WWW-Kontent-0.02.tar.gz Size: 62121 bytes MD5: 513018f0f2f8a0533a79d0b642323f2b http://search.cpan.org/~brentdax/WWW-Kontent-0.02/ Please note that it may take some time for the distribution to reach your local CPAN mirror. Kontent is a flexible web content management system written in Perl 6 and executable with Pugs. I am writing it with the help of The Perl Foundation and Google's Summer of Code program. This release is an early alpha, largely feature-complete but requiring a good deal of work, including security work. However, it is suitable to be tested out and run on localhost. In its initial configuration, Kontent looks quite similar to a wiki, with the ability to create and edit pages through a web interface and view a revision history. Examination of the code, however, will reveal a fairly sophisticated architecture capable of giving each page unique behavior and rendering the same content in multiple formats. A command-line tool is provided which can manipulate pages at a low enough level to change a page's class. Although the distribution is on the CPAN, it cannot be automatically installed by CPAN.pm or CPANPLUS, largely because I haven't decided what should be installed where. I recommend you simply download the tarball and extract it in your home directory. The INSTALL file included in the distribution will explain how to get it running. Note that you will need both a copy of Pugs configured with Perl 5 interop, and a copy of Parrot to execute Perl 6 regular expressions. You will also need a SQL database engine and the Perl 5 DBI drivers to access it. = Perl 6 Notes Part of the purpose of this project was to test Perl 6, and I'm happy to report that it passed with flying colors. Perl 6 feels like a much-enhanced Perl 5, with all the wrinkles removed and very few new ones added. It seems to be a very solid design, and is a joy to program in. A few specific points: * gather/take is one of the hidden wins of Perl 6. If you've ever written a function that builds up data throughout its entire body (for example, a bunch of [X|HT]ML), you will *adore* gather/take. It turns what used to require declaring a variable and repeatedly pushing (or concatenating) into something akin to good ol' fashoned print statements. * Object programming is a dream. The new object system fits together very well; I never felt that I wanted to do something Perl 6 wouldn't let me do (although there are some things I want to do that Pugs doesn't implement yet). Although roles aren't really available to me yet, I can already see some very useful places to to use them in later versions of this system. Two comments on the object system, however: * In one class, I wanted to initialize an attribute with data that wouldn't be available until its subclass had its turn BUILDing; I ended up having to write a private method to initialize the attribute and then arrange to call it before using the attribute anywhere in the class, which wasn't exactly optimal. There may be a place for some sort of POSTBUILD method which is called after the entire BUILD chain is finished. * Prior to writing Kontent, I saw submethods as something of a hack, and actual use of Perl 6 hasn't changed my opinion about them. I never used or wanted to use a submethod except to handle BUILD, DESTROY, and the like; it might be better to replace submethods with some sort of cascade method construct which implicitly calls all the way up the inheritence tree. * Junctions are useful just the way they are. I only used junctions a few times, but where I used them they saved a lot of code duplication. I sometimes, but certainly not always, found myself using them simply for their autothreading side effect and ignoring the boolean meaning of the junction. I don't think junctions were ever critical to the system's logic, but they helped reduce duplication and made things quite a bit clearer. * The new pattern-matching engine is a win for small regexes, too. Due to its half-implemented state, I was not able to write a substantial grammar (although I definitely have a place I can use one). However, I did use the Perl 6 pattern engine wherever I could, and even on short regexes it resulted in clearer, more concise code than the Perl 5 equivalent. I could not have done this project without the support of Google and the Perl Foundation, especially my mentor at TPF, Ovid. Nor would this project be possible wtihout the efforts of the Perl 6 design team and the Pugs implementation team. Thanks to everyone involved. Share and enjoy, -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Optimizer Documentation
() move an invariant instruction outside of the loop, TURNED OFF (not currently working) =back 4 =head1 AUTHOR Curtis Rawls [EMAIL PROTECTED] -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Classes as special undefs
Stuart Cook [EMAIL PROTECTED] wrote:
On 11/08/05, Larry Wall [EMAIL PROTECTED] wrote:
I'll have to think about the rest of your proposal, but I was suddenly
struck with the thought that our platonic Class objects are really
forms of undef:
say defined IO; # prints 0
That is, we already have an object of type IO that doesn't really
have a value yet. And maybe that's the real difference between the
class object and the metaclass object. And maybe we can reason
about objects of type IO without worrying about the definedness,
if all classes already include their own personal undef.
Wow, that's crazy enough to actually work!
This approach has a few nice properties:
One that you missed was that this syntax:
my Dog $spot .=new();
Falls out of it quite naturally.
On the other hand, there are other things that don't work quite so well:
my Dog $spot;
$spot.can('bark');# Not until he's instantiated...
On the gripping hand, maybe you should have to ask the metaclass about
that anyway:
$spot.meta.class_can('bark');#No
$spot.meta.instance_can('bark');#Yes
Hmm.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
TSa [EMAIL PROTECTED] wrote: you wrote: Perl 6 in its unannotated form is also (mostly) a typeless languages, with only the five builtin types, much like Perl 5 is. Counting the sigil quadriga as 4, what is the fifth element? And $it.does(LookGood)? $ @ % :: -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: undef.chars?
Luke Palmer [EMAIL PROTECTED] wrote: On 8/4/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: my $undef = undef; say $undef.chars? # 0? undef? die? say chars $undef; # 0? undef? die? I'd opt for undef.chars to be an error (no such method) and chars undef to return 0 (with a warning printed to STDERR^W$*ERR). Well, I think that chars $undef should be exactly equivalent to $undef.chars. In fact, I think it is: chars $undef is just the indirect object form. Didn't $Larry rule that method calls on undef return undef, for the same reason array and hash subscripting does? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
[RELEASE] WWW::Kontent 0.01
I am happy to announce the release of WWW::Kontent 0.01: File: $CPAN/authors/id/B/BR/BRENTDAX/WWW-Kontent-0.01.tar.gz Size: 27402 bytes MD5 : 1295736bac6b0ef3339998ea47b9ad61 http://search.cpan.org/~brentdax/WWW-Kontent-0.01/ Please note that it may take some time for the distribution to reach your local CPAN mirror. Kontent is a flexible web content management system written in Perl 6 and executable with Pugs. I am writing it with the help of The Perl Foundation and Google's Summer of Code program. This release is an incomplete preview, demonstrating my progress and giving a hint of what's to come. It is not feature-complete, and what's written isn't yet suitable for use in production, but it's certainly good enough to download, untar and play with on localhost. In its initial configuration, Kontent looks quite similar to a wiki, with the ability to create and edit pages through a web interface and view a revision history. Examination of the code, however, will reveal a fairly sophisticated architecture capable of giving each page unique behavior and rendering the same content in multiple formats. A command-line tool is provided which can manipulate pages at a low enough level to change a page's class. Although the distribution is on the CPAN, it cannot be automatically installed by CPAN.pm or CPANPLUS, largely because I haven't decided what should be installed where. I recommend you simply download the tarball and extract it in your home directory. The INSTALL file included in the distribution will explain how to get it running. Note that you will need both a copy of Pugs (the just-released 6.2.9 will do nicely) configured with Perl 5 interop, and a copy of Parrot to execute Perl 6 regular expressions. You will also need a SQL database engine and the Perl 5 DBI drivers to access it. I am rather excited about this project, and I hope you will be too. Share and enjoy, -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Curious use of .assuming in S06
Autrijus Tang [EMAIL PROTECTED] wrote:
In S06's Currying section, there are some strange looking examples:
textfrom := substr.assuming(:str($text) :len(Inf));
textfrom := substr.assuming:str($text):len(Inf);
woof ::= bark:(Dog).assuming :pitchlow;
Why is it allowed to omit comma between adverbial pairs, and even
omit parens around method call arguments? Is .assuming a special form?
Isn't this just another form of the syntactic rule that gives us
@array.grep:{ ... } ?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
$value.confess()
While trying to track down a type error in a Pugs program today, I thought of what could be a handy debugging feature. I would like Perl 6 values to capture the call stack when they're created and store them into a property called confess (Autrijus's name). $value.confess would then return an array of Caller objects, which could be inspected to determine where a value came from. It might even be wise to have it capture the call stack each time the value is mutated. Since this would likely be expensive, I suspect it should be optional and turned off by default; however, this would probably be a global setting, not a lexical one. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: s/rx.ops// ?
Will Coleda [EMAIL PROTECTED] wrote: What's the plan for the regular expression ops, given PGE? As the guy who wrote them, I think at this point that they're basically unsalvageable, save the intstacks and *maybe* the bitmap handling code. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Exposing the Garbage Collector
Piers Cawley [EMAIL PROTECTED] wrote:
It seems to me, that the way to get at all the instances of a class is to ask
the Garbage Collector to do the heavy lifting for us, and ideally I'd like to
see this exposed at the Perl level.
It's entirely possible that Perl will be used on virtual machines
where this can't be done.
I'd suggest that we simply declare that every metaclass must support a
.all method which returns an arrayish thing containing all active
objects it is managing:
grep { .isa($class) } MetaClass.all;
Whether this works by interfacing with the garbage collector, keeping
an array of weak references, or waving a wooden wand and yelling
Accio objects is completely up to the metaclass in question.
(Sorry, been reading too much Potter lately...)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Do I need has $.foo; for accessor-only virtual attributes?
Larry Wall [EMAIL PROTECTED] wrote: $x is visible only in the rest of the lexical scope. In contrast, $_y would presumably still be visible if the class were reopened. This strikes me as an exceedingly bad idea. Encapsulation is a very good thing, and I'm glad it's being added to Perl 6. But once in a while, you really *do* need to break encapsulation. Maybe a shortsighted module author didn't add an accessor you need, or maybe you're doing something highly magical for (e.g.) debugging. In any case, though, you'll need an escape hatch, and I really think extending a class should be it. By extending a class, you're explicitly saying I'm going to butt into your affairs; at this point, if you're not sure what you're doing, you're probably going to mess things up *anyway*. (If not this, I at least would like to see a way to make roles and/or class extensions optionally merge their namespace with the class they're being composed into; a simple 'is merged' on the role/extension's definition might do.) Also note how subtle this point is (it's about the only point I didn't get from the original message); the degree to which it requires the class's programmer to predict how others might want to extend his class; and the syntactic kludge required to specify it (namely, the sometimes-magical underscore). I really think this is a very fine distinction, which programmers will get wrong half the time, and which you don't even have enough syntax to cope with *anyway*. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Tail method calls, can(), and pre-currying
On 21/07/05, Adriano Ferreira [EMAIL PROTECTED] wrote: But is there any other case where we need an explicit tail call with goto? When the callee uses `caller -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Tail method calls, can(), and pre-currying
brentdax Is there a Perl 6 tail call syntax, and if so is it
implemented in Pugs?
autrijus sub.goto(...);
autrijus and yes.
brentdax Oh...are tail method calls possible?
autrijus tail method calls. hrmph.
I have a few methods where I'd like to perform tail calls into another
object's methods. If I were calling one of my own methods, I'd
probably use meth.goto($?SELF, [EMAIL PROTECTED]) as Autrijus suggested before,
but these are calls into another object, based on its runtime class.
As far as I can tell, the easiest way to do this in Perl 6 is thus:
$obj.can('meth').goto($obj, [EMAIL PROTECTED]);
Besides the fact that this isn't possible in current Pugs (which seems
to lack a can() method), it has several other problems: it's too long,
the method name is being treated as a string, the object is included
twice, it will fail silently if $obj doesn't have a `meth` method, and
so on.
One suggestion was a tweak of `can`'s definition: instead of returning
a reference to the method, it returns one with the invocant already
curried into it. Thus, the above becomes this:
$obj.can('meth').goto([EMAIL PROTECTED]);
While quite a bit better, this still has many of the problems I
mentioned before. My recommendation is thus:
$obj.\meth.goto([EMAIL PROTECTED]);
The .\meth takes a precurried reference to the `meth` method (throwing
an appropriate tantrum if `meth` doesn't exist), which can then be
treated like any other subroutine reference, in this case being
invoked as a tail call.
Of course, this adds *another* piece of syntax to an already large
language, so I'm not sure if it's a good idea.
Am I missing something? How do you think a tail method call should be
performed?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Strange interaction between pairs and named binding
Autrijus Tang [EMAIL PROTECTED] wrote:
This currently works in Pugs:
for [1..10].pairs - Pair $x { say $x.value }
But this does not:
for [1..10].pairs - $x { say $x.value }
Because the ruling that pairs must not be bound to parameters that are
not explicitly declared to handle them. Is this a desirable behaviour?
How much violence would be done to the language if we declared that
block (i.e. closure with no sub keyword) parameters defaulted to
Item|Pair, while sub parameters defaulted to plain Item? I can't
imagine named arguments are going to be used very often on blocks,
which tend to be things like loop bodies...
Right now one of my biggest Perl 6 nits is that the combination of
subroutines everywhere and the Pair type's special role in subroutine
dispatch makes Pairs a real pain to work with. This would help to fix
the problem without creating a new SuperPair type or something
similarly silly.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: field `_crypt_struct' has incomplete type
Sam Vilain [EMAIL PROTECTED] wrote: Has anyone got any more information to add to this problem? I'm particularly interested to know which platforms it affects. It seems to affect Debian and derivatives (including my distribution, Ubuntu). I'm seeing it on both my x86 laptop and my AMD64 desktop. My x86/Gentoo server is unaffected. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: proposal: binding with a function
On 6/20/05, BÁRTHÁZI András [EMAIL PROTECTED] wrote: - in natural languages, synonims are very often - alias is a synonim Perl is modeled on natural languages, but that doesn't mean it is one. At its core, Perl is a limited, artificial language being explicitly designed with certain goals. One of those goals is that it should be as small as possible given the feature set we want it to support; an `alias` built-in that essentially duplicates an existing feature goes against that goal. - in Perl 6, currently there's no way to create a reference to a variable, _with the context of the variable_, too (binding just give me possibility to bind a variable into another, but the new variable won't be automatically have the same context, as the binded one) I'm not sure what you mean by context here. Context has a very specific meaning in Perl, representing the type a function's caller is expecting; this doesn't seem to be what you're talking about here. alias kilobytes, kilobyte; This is a couple punctuation symbols short of: kilobytes := kilobyte; Or maybe: kilobytes ::= kilobyte; I'm not really sure what behavior you have in mind for alias. (By the way, a simple name like alias is ambiguous about argument order, where an operator isn't.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: proposal: binding with a function
On 6/20/05, BÁRTHÁZI András [EMAIL PROTECTED] wrote: Hi, - in natural languages, synonims are very often - alias is a synonim Perl is modeled on natural languages, but that doesn't mean it is one. At its core, Perl is a limited, artificial language being explicitly designed with certain goals. One of those goals is that it should be as small as possible given the feature set we want it to support; an `alias` built-in that essentially duplicates an existing feature goes against that goal. I can agree with it, but I think it would be a great feature. And it doesn't depends on Perl 6, but it depends on Parrot, as I think. - in Perl 6, currently there's no way to create a reference to a variable, _with the context of the variable_, too (binding just give me possibility to bind a variable into another, but the new variable won't be automatically have the same context, as the binded one) I'm not sure what you mean by context here. Context has a very specific meaning in Perl, representing the type a function's caller is expecting; this doesn't seem to be what you're talking about here. alias kilobytes, kilobyte; This is a couple punctuation symbols short of: kilobytes := kilobyte; Or maybe: kilobytes ::= kilobyte; I'm not really sure what behavior you have in mind for alias. kilobytes := kilobyte; will not work for you (try it), because you have to declare the variable kilobytes - in the default strict mode. But you can't say for ex. my kilobytes, if you want to export it. So you say `our kilobytes ::= kilobyte` (or `:=`, you still haven't said if alias works at compile time or runtime) and call it a day. IIUC, traits like `is exported` are attached to the container, not the name; since aliasing connects a name to a container, you should be fine on that front. (If it doesn't work, that's because `is exported` does something funky that `alias` would have to treat as a special case; certainly other traits like `is rw` would follow a `:=`-binding.) Anyway, alias is a Ruby term, and if Parrot will be able to support Ruby, then it will be able to support this function, too. As I've said before, Perl supports `alias`--it's just spelled `:=`. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: %hash1 ... %hash2
David Formosa (aka ? the Platypus) [EMAIL PROTECTED] wrote: If you consider arrays to be hashes keyed by integers then @a .. @b does the equiverlent of an inner join. I would suggest that if we are going to have outer join versions then we have something like this It does? I thought that when [EMAIL PROTECTED] != [EMAIL PROTECTED], the shorter one got extended with undefs... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Pondering the unification of @MULTI and get_params
On 6/14/05, Chip Salzenberg [EMAIL PROTECTED] wrote: .sub __add .param MyType $P0 :flags(0x40) # or @flags(0x40)? - inv. w/o colon (e.g.) .param $I0 :flags(0x20) # invocant with colon (e.g.) ... What do you think? I think the typecodes are unnecessary with a metadata syntax, and the numeric codes in general are looking increasingly silly. If this isn't a normal opcode, why not just detect the register type and use a space-separated list of keywords, and save people the mental bit-twiddling? .param Int $P0 .param Str $P1 .param Array $P2 fold -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
On 6/13/05, Chip Salzenberg [EMAIL PROTECTED] wrote: Oh no ... it's even worse than you think. Almost *any* opcode that operates on a PMC can trigger a continuation. And I only need two words to prove it: Tied variables. Isn't this *exactly* why Perl 6 is requiring you to mark tied variables when they're declared? In this thread and the other one, I'm seeing a lot of people getting scared of the degenerate case, which is the most dynamic behavior possible. But the degenerate case is rarely the common one, and we always knew it would come at a speed penalty. More importantly, the degenerate case can be ruled out pretty well by a fairly simple lexical analysis. In the common case of no tied variables, I think we can assume that PMC code isn't going to do zany things like invoking some random continuation. If there are tied variables present which might do strange things like that, the compiler should emit a PIR directive saying anything goes in this section. Perhaps some languages will always do that, but that's the price of working in those languages. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: How much do we close over?
On 6/12/05, Dave Mitchell [EMAIL PROTECTED] wrote:
You may be using slow evals, but other fast code may not be. Should the
closure in
sub foo { my $x = 1; return sub { 1 } }
also capture the current instance of $x? You are basically condeming any
code that creates any closure, however simple, to basically hang on to
just about any data that has ever existed, in the vague hope that maybe,
just maybe, some day some code may use an eval and make use of that data.
A simple analysis of the parse tree should show that sub { 1 } isn't
going to access $x. I personally don't see what's wrong with marking
certain constructs (eval, symbolic dereference, stash access, etc.) as
dirty and forcing a closure to close over everything if one is
present. This is optimizer stuff, really, in the same class of
problems as optimizing Parrot's continuation-based sub calls into
bsr/ret where possible.
Hmm...maybe the answer is that most destruction isn't guaranteed to be
timely, and any object which *is* guaranteed to have timely
destruction is illegal to close over unless the programmer marks it as
okay. Or maybe that's only with an appropriate stricture...
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Transparent / Opaque references
Juerd [EMAIL PROTECTED] wrote:
There is no way to get an anonymous rw scalar, is there?
There's always the Perl 5 hack:
\do { my $x }
Although that's not truly anonymous, I suppose.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Perl development server
On 5/23/05, Juerd [EMAIL PROTECTED] wrote: Also, this new machine needs a hostname. Please help me think of a cute name! I prefer a short hostname with less than 9 letters. I seem to remember that the camel's name is Abigail... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Perl development server
Andy Bach wrote off-list: Isn't Abigail the golfer, YA excellent PH, FunWithPerl, er guy? I think camels are Fido and Amelia: http://www.perlmonks.org/?node=31716 You're right, of course. I knew it was one of those A names... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Argument Type Checking
David Storrs [EMAIL PROTECTED] wrote: If so, wouldn't it make sense that 'int' is the boxed type (one less keystroke) and 'Int' is the special case? Optimize for the common case, and all that. Think of it as being like module names--all-lowercase modules are special (pragmata), while intercaps modules are normal (modules and classes). Similarly, all-lowercase types are special (unboxed), while intercaps types are normal (boxed classes). -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Roles and BUILD
On 5/16/05, Larry Wall [EMAIL PROTECTED] wrote: Yes, role BUILD submethods are magically composed into the class's BUILD method somehow (or at least called at the appropriate time). Could this be a feature of all submethods, not just BUILD? (DESTROY, for instance, would need it too...) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Plethora of operators
Damian Conway [EMAIL PROTECTED] wrote:
3. To drill down a hierarchical data structure, following the path
specified by a list of keys:
$leaf_value = [.{}] %hash, @keys;
When I saw this, the following happened.
*pause for a second*
Wow.
*a few more seconds*
Holy /f---/.
I think that means this should be in core.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: ^method ?
Damian Conway [EMAIL PROTECTED] wrote: [an extremely well-thought-out explanation] Thank you, Dr. Conway. That was very enlightening, and I think I agree with all of it. Larry Wall [EMAIL PROTECTED] wrote: You guys are all ignoring that I said it could be set via pragma or macro. If you want ^, just say use self '^'; or some such. Then we can let it be decided culturally. I think this is one of those solutions that is elegant, accomodating, and wrong. I don't think it's a good idea to have every Perl programmer choose their own way of writing the current object. When I see an error like Use of undefined value at Foo/Bar.pm line 441, I want to be able to jump to line 441 of Foo/Bar.pm and instantly understand what's going on. I don't want to check every line of code that falls before Foo/Bar.pm line 441 to see what this programmer chose as his invocant. Even Perl 5 wasn't that bad--you just had to find the line that unpacked the arguments. I can understand that being required to get the power of syntax modifications, but there's little power gained in choosing your own 'self'. And I'm not even asking for self.pm to be removed--just for a default to be provided. Way back in Apocalypes 1, you said this: I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good. Considering the tiny amount of power given by 'self', is it really a good idea to require it whenever somebody wants to talk about their own object? Like the decision about which side of the road cars should drive on, it really doesn't matter *which* choice is taken, as long as *something* is decided. I've seen other languages use this, self, and even me, and few people complain about a particular language's choice. (My suggestion would be o or O, as suggested in another thread, but I'm certainly not attached to those keywords.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: trait and properties thru getter/setters
On 5/13/05, Stéphane Payrard [EMAIL PROTECTED] wrote: There is syntax to define trait and properties but is there an API? my $b = eval '$a but true'; # setting a true property # API to do it without an eval? My question is more generic than my example. I may not know at compile time what is the value/trait name and its value. Well, the value's pretty easy--just pass in a variable: my $b = $a is foo($bar); As for the name, I'd be surprised if the standard symbolic-ref syntax didn't work: my $b = $a is ::($foo)($bar); -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: trait and properties thru getter/setters
On 5/13/05, Larry Wall [EMAIL PROTECTED] wrote: On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: : my $b = $a is foo($bar); As we currently have it, that is not legal syntax. is may only be applied to declarations. Sorry, think-o. I meant 'but' in my examples (and Stéphane used 'but' in his). Should I construe the fact that you didn't comment on the ::() to mean that the symref syntax works here? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: Binding to a sub's return value
Juerd [EMAIL PROTECTED] wrote:
:= is the thing that implements subroutine arguments. Ask yourself the
same question with:
sub another_routine ($rv) {
...
}
another_routine(some_routine());
I'd expect $rv to be an alias to a copy of $foo's value, 42.
Really? Because the default parameter binding is constant reference,
last I checked.
I actually like that answer. It means that you can bind the return
value, but you can't mutate it, unless the function 'is rw'. (And
perhaps you could mark it as 'is copy' and 'is ref', too...)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: reduce metaoperator
On 5/5/05, Stuart Cook [EMAIL PROTECTED] wrote:
+-+---+-++
| Meta-op | is| operates on | to produce |
+-+---+-++
| [ ] | circumfix | infix | prefix |
+-+---+-++
| | circumfix | infix | infix |
+-+---+-++
| = | postfix | infix | infix |
+-+---+-++
| | prefix| postfix | postfix|
+-+---+-++
| | postfix | prefix | prefix |
+-+---+-++
I find this table very interesting, in that it shows the fundamental
difference between reduce and the existing meta-ops.
The existing meta-operators alter the semantics of the opoerator, but
don't really change its syntax; a unary operator is still unary, a
binary operator is still binary, and so on. Reduce is irreducibly
(pardon the pun) different, in that it alters the syntax as well as
the semantics.
My suggestion is simple:
multi *reduce(block, [EMAIL PROTECTED] is copy) {
my [EMAIL PROTECTED];
while(@list) {
$r = block($r, [EMAIL PROTECTED]( :elems(block.arity - 1) );
}
return $r;
}
macro *reduce ($op, $expr) is parsed( / \[ (infix_operator) \]
(expr)/ ) {
# Would be reworked to produce a parse tree
return reduce(infix:$op, $expr);
}
That would result in the following syntaxes:
reduce { $^a / $^b } @foo;
reduce [/] @foo;
$sum = reduce[+] @array;
$fact = reduce[*] 1..$num;
$firsttrue = reduce[||] @args;
$firstdef = reduce[//] @args;
@sumrows := reduce[+«] @rows;
@foo[0..9; reduce[;](@dims); 0..9]
Clearly we could squabble about the exact bracketing operators to use
(I chose square brackets because I thought they'd be less ambiguous
than parentheses or curlies), but I trust you get the idea.
I agree that reduce is very useful, and I even agree that it should be
in core, but it's not *so* useful that it needs to be invokable
without a keyword. Summing a list--which, let's face it, is likely to
be the most common use for this--isn't common enough an operation to
need such a compact syntax; I can think of more useful meta-ops, like
one that tags each result with the operands that created it, allowing
junctions to be used for the stuff people currently complain they
can't be.
multi sub *infixmetaop:[ ] ( $lhs, $rhs ) {
return call but operands($lhs, $rhs);
}
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: Formal Parameters To While Block
On 5/1/05, Luke Palmer [EMAIL PROTECTED] wrote: Anyway, for doesn't need is lazy, because it simply evaluates the list it is given and iterates over it. The fact that evaluating the list may be a no-op because of laziness is unrelated to is lazy (another hint that it's the wrong name). To start off the name game: `is deferred`? `is closure`, `is coderef`, `is sub`? `is condition`? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Junctions of classes, roles, etc.
Aaron Sherman [EMAIL PROTECTED] wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
I do not see how any auto-threading occurs in that code. It is completely
innocuous in that sense, and I don't think that is what horrified David.
What was troublesome was, I think:
my Str|Int $x;
$x.foo(); # runs two methods and returns a junction
That would be absolutely horrible.
Then tell me what $!.can(chars) returns, assuming that $! is
implemented as an any junction of Int and Str values? My take would be
that it returns false|true, which is true in a boolean context, but feel
free to talk me out of it.
`$!` is an `Exception` (or somesuch) object, not a `Str|Int`, but in
general, that depends on the contents of the variable. If a Str|Int
was assigned a `Str`, `can` would be true; if it were assigned an
`Int`, `can` would be false. If it were assigned a disjunction of a
`Str` and an `Int`, it'd return `true|false`, which evaluates to
`true`.
Str|Int is simply the type of Yes|1, isn't it? That would certainly
make signature matching on different kinds of junctive types trivial.
Nope. The type `Str|Int` doesn't mean this variable contains a
disjunction of `Str`s and `Int`s; it means This variable can contain
either a `Str` or an `Int`. (Actually, it means this variable can
contain anything consistent with a Str or Int, which also includes
subclasses and certain junctions.) When you see a declaration like:
my Foo $bar;
Think of it as being like:
my $bar where { $_ ~~ Foo };
If the latter, then what is the type of Yes|1?
I suspect it's `Disjunction of Str | Int`.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Junctions of classes, roles, etc.
David Storrs [EMAIL PROTECTED] wrote:
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
Could we see some code that shows why this is a good idea? My initial
reaction is horror; I can very easily see huge numbers of subtle,
hard-to-reproduce bugs coming out of this. On the other hand, I do
not immediately see major applications...most of what I can see is
things that reduce the amount of code needed, but don't actually
accomplish anything fundamentally new. What do junctions of
Class|Role objects give us that can't be achieved in other ways?
I'm quite willing to believe that there are such things, but I'm not
coming up with them.
What do you think this is?
sub foo(Str | Int $bar) { ... }
Or this one, which is even more important?
sub foo(Any | Junction $bar) { ... }
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: [RFC] assign Px, Py
Just to de-Warnock this thread: Leopold Toetsch [EMAIL PROTECTED] wrote: 3) PIR syntax It was already discussed a few times that we might change PIR syntax: current: Px = Pyset Px, Py alias Px and Py Px = assign Py assign Px, Py copy values future: Px := Py set Px, Py Px = Pyassign Px, Py This would much more resemble the HLL's (and programmers) POV. Sounds like a good idea to me. For completeness, can we come up with a clone operator? Perhaps: Px - Py -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: alarm() and later()
Larry Wall [EMAIL PROTECTED] wrote:
Assuming we
rehuffmanize kill to sendsignal or some such, we have:
signal is a verb as well as a noun.
sub alarm ($secs) {
{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
}
It even reads pretty nicely: signal 4242.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Context of hash slices; quotation adverbs
Larry Wall [EMAIL PROTECTED] wrote:
: First, context of hash slices:
: Hash slices with {} notation are trivially either scalars or lists:
: $h{'foo'} = want(); # Scalar
: $h{'foo','bar'} = want(); # List
Right.
Tangentially, that makes me wonder: is there a difference between
scalar context and one-element array context?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Truely temporary variables
Aaron Sherman [EMAIL PROTECTED] wrote:
What I'd really like to say is:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
Anything wrong with:
my $sql = q{...};
temp $sql = q{...};
temp $sql = q{...};
(Assuming Ctemp is made to work on lexicals, of course.)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: [perl #34912] Badly balanced at classes/pmc2c2.pl
Leopold Toetsch [EMAIL PROTECTED] wrote: BTW: a nice to have: include SVN revision of local copy in bug report. Remember how I set things up so that Configure would add a timestamp to config.h and Config.pm? I only did that because CVS didn't have a repository-wide revision number like Subversion. SVN revision number is an excellent idea. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Slicing conflict
Luke Palmer [EMAIL PROTECTED] wrote: In Perl 5: my @a = (1,2,3); my @b = @a[0..3]; print scalar(@b); # 4 But in Perl 6: my @a = (1,2,3,4); my @b = @a[1...]; # elements from 1 onward say [EMAIL PROTECTED]; # should probably be 3, but with Perl 5 semantics is Inf We have to break one of these. I think the former is the one to break, even though that might cause some unexpected surprises here and there. Any ideas? I was thinking about this today, actually, because my CS textbook was talking about multidimensional arrays. If we make an infinite index mean slice until you can slice no more, then we can possibly have a Cterm:* which is the same as C0 That means we can slice like this: @foo[1,3; *; 7] Which I rather like. (Although term:* might conflict with prefix:*...hmm. I'm not sure it would in common usage--the only things I can think of that could follow are a dot, opening or closing bracket, semicolon or comma, or hyperoperator, none of which are ambiguous if we stick to the no-whitespace-before-postcircumfix rule.) By the way, this also shortens the common idiom: @[EMAIL PROTECTED] To simply: @foo[3...] Which strikes me as a win. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Slicing conflict
Larry Wall [EMAIL PROTECTED] wrote: On Tue, Apr 12, 2005 at 12:08:43AM -0700, Brent 'Dax' Royal-Gordon wrote: : @foo[1,3; *; 7] : : Which I rather like. Me too. Unless my memory is failing me, I believe that's what S09 already specifies. It does include a Cterm:* (d'oh, should've checked), but it doesn't specify how it works. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Configuration (was Re: Monthly Release Schedule)
Chip Salzenberg [EMAIL PROTECTED] wrote: According to MrJoltCola: I can tell you now Sparc / GCC is broken for most due to our broken Configure. Our config pulls out the params that were used to build Perl with, and this is invalid because most Sparc folks are running a pre-built Perl and GCC binary that was built on a distributor's system. Not specifically about SPARC: Is there already a configuration roadmap, something for me to start with as I look to What Should Be? From what I recall, we're planning a bootstrapping system. The configuration/build system will be written in a Parrot language (possibly, but not necessarily, Perl 6), with PBC files included in the distribution. To bootstrap, we'll have platform-specific shell scripts or batch files sufficient to build Miniparrot, a stripped-down, no-configuration, ANSI C-only version of Parrot. So the steps will be something like: $ CC=gcc makemini/generic-unix.sh# Skip if you have an old Parrot $ (mini)parrot configure.pbc $ (mini)parrot build.pbc $ ./parrot test.pbc $ su # ./parrot install.pbc This implies that we won't require a 'make' (and won't have to attempt to make different 'make's work); all you'll need is a compiler, linker, and C library. This also implies that configure.pbc and build.pbc will probably have to be carefully written to work with the limited process-manipulation abilities of an ANSI-constrained Miniparrot. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Subversion in the wings
Robert Spier [EMAIL PROTECTED] wrote: Any questions? I assume current committer bits will be transitioned over too? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Definitive and Complete Perl 6 Operator List
Luke Palmer [EMAIL PROTECTED] wrote: Andrew Savige said: Is there a definitive, official, complete list of all Perl 6 operators, along with their precedence levels? Well, Synopsis 3 is the list you're looking for, but it's clearly not all there. Take the table there to be your definitive list, and mail questions about its accuracy here. I'll do my best to keep up with you and maintain it. Uploaded so it doesn't get word-wrapped and thus rendered useless to tools: http://www.brentdax.com/junk/perl6/perl6op.txt I've included assignment forms of all operators in the exponentiation, multiplicative, additive, junctive, and tight logical levels; this may be overkill or underkill. I've not included hyper forms of these operators, as I figure they're handled by metaoperators. Also, the terms level isn't really exhaustive. In any case, let me know if anything's missing--or for that matter if anything's there that shouldn't be. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Passing on the hat
Dan Sugalski [EMAIL PROTECTED] wrote: As such, I'd like to say a big thanks to Chip Salzenburg who's agreed to take the hat. The perl folks on the list will recognize Chip as the perl 5.004 pumpking and the guy who took the first shot at Perl: The Next Generation (aka Topaz). Chip's a darned sharp guy, desperately over-qualified, and one of the few people I know who can do off-the-cuff MST-ing of modern cinema. Congratulations to Chip, our new Fearless Leader. And thanks for your time and guidance, Dan--Parrot wouldn't be where it is today without you. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Slices
Luke Palmer [EMAIL PROTECTED] wrote:
Can I use slice notation when dealing with strings?
say $string[-1]; # say substr($string, -1);
$string[0..2] = Hello;
No. I'm pretty sure that's the Right Thing, too. First, the sixth
element in a string depends on how you're defining element: byte,
codepoint, grapheme, etc. Second, if you think you're using an array,
and it's actually a string (even ), then you'll be missing an error
(though I understand that this is a weak argument). Third, we already
have substr.
A while back, I think I suggested that .{bytes,points,graphs,chars} be
defined to return an array with the contents of the string split into
the indicated pieces. If this was a tied array which updated the
underlying string, would we get the OP's behavior for free?
say $string.chars[-1];
$string.points.splice(0, 2, Hello); # Or Hello.points
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
David Storrs [EMAIL PROTECTED] wrote: Aside from links, that's pretty much the entire perlpodtut boiled down into 7 bullets; a little experimentation to get the hang of it and it all holds together nicely, easy to remember. Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly right. It's simple, intuitive, and stays out of your way. It gives you most of the formatting primitives you actually *need*, and nicely balances the need for easy-to-remember and easy-to-type formatting codes with the need to avoid using them on accident. It's a very clean, low-punctuation format, which makes it visually distinctive from the surrounding code. Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width fonts; they're associated with formatting codes in my (HTML-influenced) mind. The most common use of them in Perl 5--method call/dereference--is going away in Perl 6, which makes them even more usable. (I never have a problem correctly marking up C $foo $bar , but occasionally I carelessly type C$foo-bar.) Pod needs incremental improvements--tables, (maybe) footnotes, simpler links, tweaks to =begin/=end, etc. Pod does *not* need to be ripped out and replaced with something very different, especially something that involves adding line noise to documents intended for human consumption. In my mind at least, Pod has five goals: 1. Simple. 2. Adequate. 3. Easy to write. 4. Easy to convert. 5. Readable without a formatter. #5 may be last on the list, but it's not least. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman [EMAIL PROTECTED] wrote: Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width This is aesthetic preference. I could cite the reasons that I have an aesthetic preference for the other syntax, but the reality is that angle brackets aren't angle brackets; they are less-than (Elt) and greater- than signs (Egt). We ignore this fact at our peril, Only in name. Years of HTML and Perl have trained me to treat these as bracketing constructs, and Perl 6 is set to increase that use. and the hacks in pod syntax (e.g. C ) to get around this are glaring anti- huffmanisms. Whatever bracketing character we decide to use, there will always be occasions where we need to use it in an unbalanced way within a formatting code. (Though I do admit that angle brackets are more likely to be unbalanced than other characters.) The problem I have with square brackets specifically is that they get lost really easily, especially in variable-width fonts. Gmail, for example, displays e-mail in a sans-serif font, and virtually all such fonts have narrow square brackets. The square brackets in your examples were visually lost in the surrounding text--without spaces, square brackets are invisible. That's okay when you're subscripting, because your brain doesn't really need them to understand what's going on, but it's not when you're applying and reading formatting codes. Further, although Perl 6 is the time to make such a change, I'm not convinced the change is really necessary. We might be able to avoid a few uses of C , but is that a big enough win to change *yet another* aspect of Perl? Especially an aspect programmers can--and traditionally did--ignore? The most common use of them in Perl 5--method call/dereference--is going away in Perl 6 Hmm, I remain unconvinced of that as the most common use, especially with the copious use of =. Still, in my local source tree you're right, though by a factor of 2. Are you looking at your entire source tree, or just the Pod in it? The code in Pod--and especially the short snippets of code typically included in a C construct--is very different from arbitrary Perl code. Perl 6 also adds new uses of Egt and Elt for pipelining, and further expands the usefulness of the = operator as a pair constructor. Rules also add new uses of these characters, but those are balanced, so improving POD with a real grammar specification would solve for that. I definitely support intelligently defining the way Pod handles angle brackets which aren't part of a formatting code. I also think writing a reference grammar would be an excellent idea. Thanks Brent, I'm not sure if you intended your mail as an endorsement, but other than one sticking point, you and I appear to be on the same page. Thank you for your message. I intended my e-mail to be an endorsement of Pod as it exists, with extensions rather than a redesign. I think you have mostly the right idea, but I really don't think switching to square brackets is necessary. By the way, I think I've seen a few people suggest some sort of syntax-switching mechanism for Pod6. The day people have to think about what dialect of Pod they're using is the day Pod dies as a useful documentation language. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: New S29 draft up
Larry Wall [EMAIL PROTECTED] wrote:
: Cdo filename I'll tackle at the same time as Ceval. It's likely
: staying in some form. I use it from time to time when I'm patching
: together several automation scripts. (Remember that Perl gets used for
: the quick and dirty as well as the big and elegant.)
But probably huffmanized to something longer like evalfile.
eval :file(somefile.pl6);
eval :string('{$^x + ' ~ $y ~ '}');
eval :file(otherfile.pl), :lang('perl5');
eval :string(lamda x: x + $y), :lang('python');
Since as long as we're huffmanizing, eval STRING deserves to be longer
than do STRING.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: A possible solution for s?pintf
Juerd [EMAIL PROTECTED] wrote:
Without introduction, I'll just present the syntax idea:
f/%03d %15s/$foo, $bar/;
Of course, this is s///-like in quoting behaviour, so f[][] or f
should work just as well. The RHS is not a string, but parsed as an
expression in list context. If this feels weird, just think of s///e,
where the RHS is also not a string.
I think s///e is going away, since you can just use s/pattern/{code}/
now anyway.
Besides, I think as will do just fine, especially since you can now
interpolate method calls as well. You can even do something like this
if you want to perform bulk formatting:
say join ' ', ($n1, $n2, $n3) .as('%d');
Or, if that's not quite sufficient:
say map { .key.as(.value) }
$num = '%d',
$str = '%s',
...;
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: some misc Perl 6 questions
Darren Duncan [EMAIL PROTECTED] wrote:
A question: Would has PkgNameArray @.tmpl_set_nms; do what I
expect, where the array as a whole is the sub-type, or would it make
an array where each element is the sub-type?
I think this declares an array of PkgNameArrays, but has
@.tmpl_set_nms is PkgNameArray; will do what you want.
New question: Is there a way to say that two classes have a
privileged relationship, sort of like a marriage, such that each can
see and/or change otherwise private attributes in objects of the
other class, and yet the attribute list of each class is completely
different from the other? Neither of the two objects is a subclass
of the other, nor fulfills a role defined by the other.
S12:
Attributes are never visible outside a class definition, so a multi
method can only directly access the attributes of a class it's defined
within. However, it may call the private attribute accessors from a
different class if that other class has indicated that it trusts the
class the multi method is defined in:
class MyClass {
trusts Yourclass;
...
}
(end quote)
So for the relationship to work both ways, each class would have to
mark the other as trusted.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Optional binding
Luke Palmer [EMAIL PROTECTED] wrote:
What is output:
sub foo($x, ?$y, [EMAIL PROTECTED]) {
say x = $x; y = $y; z = @z[];
}
my @a = (1,2,3);
foo($x, @a);
IANALarry, but I'd think
x = ($x's value); y = 1 2 3; z =
The $y is implicitly typed Any, and Ref of Array (or maybe just Array)
is consistent with Any; hence $y receives [EMAIL PROTECTED]
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Sets vs Junctions
Jonathan Lang [EMAIL PROTECTED] wrote: There are a couple of problems: first, a hash's keys are limited to strings; a set ought to be able to handle a wider range of data types. Last time I checked, there was going to be a way to declare a different data type for the key (which could easily be Any). -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Lingering questions about Junctions.
Rod Adams [EMAIL PROTECTED] wrote:
- Can junctions be used as array/hash subscripts?
In an rvalue context, this makes sense, in that you can simply return a
junction of the deferences. But in an lvalue context, this gets dubious
for everything except all() junctions. Consider:
@x = 1..10;
@x[any(4,3)] = 7;
What does @x look like now?
@x[all(4,3,2)] = 7;
makes sense, as long as it means:
@x[4,3,2] »=« 7;
I don't want to even think about what:
@x[none(1,2)] = 7;
does.
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3)
all(map { @x[$_] = 7 } 4,3,2)
one(map { @x[$_] = 7 } 1,2)
none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
- Can you have non-scalar junctions?
As the discussions surrounding C .. demonstrated, it's not that hard
for someone to create a situation where a junction of lists might come
into existence. But let's consider something a step beyond.
%x = (a = 1, b = 2, c = 3) | (d = 4, e = 5, f = 6);
@y = %x.keys;
Does this explode, or does @y have something useful in it now?
Do junctive operators force scalar context on their arguments? If so,
we know what happens (you get a junction of arrayrefs); if not, I
suppose it's up for negotiation.
- What does it mean to sort a list of junctions?
@x = any(1,6), all(2,5), one(3,4);
@x = @x.sort;
Does sort() carp on junctions, or is it just one of the weird things you
have to live with if you're playing with junctions?
Good question. Spaceship and cmp aren't quite like the normal boolean
ops, unfortunately; I'm not quite sure what to do about that.
...actually...
Pretend for a moment that cmp is implemented exactly as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 0 if $lhs eq $rhs;
return 1 if $lhs gt $rhs;
}
Then things compare this way:
any(1,6) cmp all(2,5) = -1 (1 is less than both 2 and 5)
all(2,5) cmp any(1,6) = 1 (both 2 and 5 are greater than 1)
all(2,5) cmp one(3,4) = undef (no conditions match)
one(3,4) cmp all(2,5) = undef (no conditions match)
one(3,4) cmp any(1,6) = undef (no conditions match)
any(1,6) cmp one(3,4) = undef (no conditions match)
Happily, all of these are commutative (is this generally true?), and
the Cundefs would be treated as 0s. So this actually would work,
although it would sort in an...interesting...order.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Junction Values
Damian Conway [EMAIL PROTECTED] wrote: Yes, it's a side-effect of the new default prohibition on junction assignments (though I'm still working hard to convince everyone that that prohibition cripples junctions and that having to use junctions before you can assign a basic Perl 6 scalar datatype to a variable is an abomination). Point of consideration: is accidentally autothreading over a junction any more dangerous than accidentally looping forever over an infinite lazy list? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Junction Values
Rod Adams [EMAIL PROTECTED] wrote:
Larry Wall wrote:
Junctions can short circuit when they feel like it, and might in some
cases do a better job of picking the evaluation order than a human.
I was afraid someone was going to say that. And I now must convert my
reservations about junction autothreading from very disturbing to
you've got to be kidding.
...
Not to mention it contradicts S09:
... that routine is autothreaded, meaning the routine will be called
automatically as many times as necessary to process the individual scalar
elements of the junction in parallel.
Now there is some wiggle room in there for short circuiting, but not very
much.
The wiggle room is that the junction knows when it's being asked to
collapse into a Boolean, and can know if there's no possible way the
function it's running will have side effects. (That's why we're
declaring ties now. There may be cases where we can't know for sure
if there will be side effects or not--Halting Problem stuff--but we
can make sure the junction optimizer is conservative. The Halting
Problem becomes a lot easier if you ask whether a program *might* halt
instead of whether it *will*.)
In general, it seems to simply be an amazingly bad idea to autothread
a function with side effects. In fact, I'd recommend that we warn if
a side effect occurs during autothreading.
Besides, people were telling me that my Sets were not needed, because
they could be rendered with Arrays and Hashes. I fail to see how
junctions are that different.
Junctions are intended to be used mainly within conditionals and other
statements; it's sort of a happy accident that they can be assigned to
variables. At the intra-statement level, there's nothing else (short
of involving a function like Cgrep) that'll do the job. From what I
saw, your sets are mainly designed to be used at the inter-statement
level, where we have arrays and hashes to do that sort of thing.
I think junctions are important at the statement level because they
help make similar things look similar. Consider these two statements:
if($foo == $bar) { .. }
if(grep { $foo == $_ } $bar, $baz) { ... }
What makes these two statements so fundamentally different from each
other that they should be expressed in ways that *look* so different?
: - Edge cases which, IMHO, do not merit the huffman level of several
: single character operators. All of which can be accomplished without the
: use of junctions, though not as gracefully.
Grace is important. Even more important is mapping naturally to human
linguistic structures, to the extent that it can be done unambiguously.
In my experience, English tends not to superimpose several values on a
given noun at once.
No, but nor does it have a concept quite like a variable. There's a
reason many people have trouble understanding what 'x' and 'y' are all
about in algebra. (And remember, algebra variables can sometimes have
multiple values--consider y = x ** 2, for example.)
Junctions are equivalent to the English sentence Get eggs, bacon, and
toast from the store. (In Perl, that'd be something like C
$store-get(eggs bacon toast) .) It's just a bit of
orthogonality that allows you to give eggs, bacon, and toast a name
and use it later.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Junction Values
Rod Adams [EMAIL PROTECTED] wrote:
if $x == 3|4|5|6 {...}
would thread over infix:== without any funkiness, since we'll assume
operators are well written, and can take junctions as parameters, same as:
if is_prime(3|4|5|6) {...}
Would pass the junction to is_prime, to do with as it pleases, including
throwing an exception. However,
if is_prime(»3|4|5|6«) {...}
would thread over is_prime, and collate the results outside of call.
So basically you're proposing that, rather than do one implicit loop
that'll probably do what you want, the default should be to do an
unknown number of implicit loops in somebody else's code, and you have
to ask explicitly for the more sensible behavior. Somehow this
doesn't strike me as an improvement.
These semantics also give us the ability to easily mix and match what we send
to a function, so we can say:
if funky_test(all(@A), »any(@B)«) {...}
sub funky_test ( Junction|Any @a, @b ) { ... }
Basically I'm putting all the power of threading into the hands of the caller.
The caller is not in a position to know if the callee is internally
structured in such a way that passing in a raw junction makes sense.
The right place to say I can handle a junction, don't autothread is
in the callee; that's the behavior @Larry is proposing.
As for C .. , I'd say that it should handle junctions being fed into it by
throwing an exception.
Why is this more sensible than returning a list of junctions in list
context and a junction of arrayrefs in scalar context? (I believe
infix:.. will return an arrayref in scalar context, though I could
be wrong.)
(The array of junctions is negotiable, by the way; whatever it is,
though, it should probably be the same as the default meaning for list
returns from an autothreaded function.)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Junction Values
Rod Adams [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
2..sqrt($x)
What the hell does that mean? Do you get a junction of lists out? Or
does sqrt die because it's not expecting a junction?
What on earth does C for (2..sqrt(3|5)) {...} mean in the current
state of junctions?
In the current state of junctions, the autothreading is done at the
level of the call to do_prime, so $x is never a junction. Only under
your notion of junctions as just another object with no autothreading
until the operator level will $x ever be a junction.
But if it somehow *did* become a junction, I would imagine something
like this would happen:
for (2 .. sqrt( 3 | 5 )) { ... }
for (2 .. ( sqrt 3 | sqrt 5 )) { ... }
for ( ( 2 .. sqrt 3 ) | ( 2 .. sqrt 5 ) ) { ... }
for ( 2 .. sqrt 3 ) { ... } | for ( 2 .. sqrt 5 ) { ... }#notionally
However, it's clear that the last step doesn't make a whole lot of
sense, since Cfor has no return value. Maybe Cfor would be
declared with a signature that didn't allow junctions at all.
However, in the current scheme, if is_prime() is written to accept a
slurpy list of parameters (either by design, or just a habit from the P5
days), we can have:
I will readily admit that the behavior of junctions in a slurpy
subroutine call is suboptimal, and it might be a good idea to
reexamine it. However, I will also point out that most newbie
programmers probably won't use the @_ behavior, and likely won't be
using slurpy parameters either, while more experienced programmers
will know better.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Junction Values
Rod Adams [EMAIL PROTECTED] wrote:
Suppose funky_test is a derivative of C printf . Only this printf let's
you feed it a junction for the format, and it will sort through them and see
which one matches best depending on actual number of parameters, parameter
types, etc. Ordinarily, this would be fairly cool stuff.
But let's say you instead wanted it to print the same data with all the
different formats. With my calling, you could make the distinction rather
easily. With yours, you have to set up the looping yourself.
I would argue that this function is badly designed.
Junctions are intended to ultimately be used in boolean tests. That's
why the values of the junction have an any/all/one/none relationship.
The proper data structure here is an array. (Actually, ironically
enough, it's probably a set, not an array.)
IMHO, there are three cases where it's legitimate to specifically ask
for junctions to be passed in:
1. When it makes absolutely no sense to use a junction in a particular
function, especially one with side effects.[1]
2. When doing some sort of junction-aware serialization, a la Storable
or Data::Dumper.
3. When the author of the function can optimize the way junctions are
handled without changing their basic semantics.
Outside of these cases, it's probably wrong.
A junction is *not* a meaningless data structure to be slung around at
will; it is a construct that implies a certain type of behavior when
used.
The caller is not in a position to know if the callee is internally
structured in such a way that passing in a raw junction makes sense.
Sure
they are. It's called reading the documentation. If it doesn't say it can
handle junctions, it probably can't.
I don't want to have to stop in the middle of a hundred-line function
to think, Does Store::Market.get act sanely when I give it a
junction? Do I need to explode it manually, or will it handle the
junction nicely on its own? Nor do I want to work in a language
where most functions don't handle a basic construct elegantly, even
when they can.
About the only thing is could return
would be a lazy list of junctions. And about the only places C .. gets
used is inside C for and inside array slice indices. Lists of junctions
certainly make no sense in a for loop... the loop cannot simultaneously exit
and not exit at the same time.
You don't think this makes sense? (Cfor itself wouldn't autothread;
the calls and operators inside the loop body would.)
for 1|2, 3|4, 5|6 { ... }
(Actually, Synopsis 3 talks about what happens when you give Cfor a
single junction--essentially, it loops over the contents of the
junction in whatever order it feels is most optimal. But in this case
we're giving it an array of junctions, which presumably would act
differently)
Feeding a list of junctions into an array
slice index is asking for what? Another list of junctions out?
Synopsis 3:
print if @foo[any(1,2,3)]
[1] Note, however, that this needs to be done carefully. For example,
while it doesn't really make sense for the string arguments of a call
to Cprint to be junctions, the object argument is another matter
entirely:
#!/usr/bin/perl6
# naive tee
$OUT=$OUT open( $_) for @ARGS;
print or die Can't write to $!.filename: $! for *$IN;# Or
however it's done this week
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Junction Values
Rod Adams [EMAIL PROTECTED] wrote:
Larry Wall wrote:
That, and we'd like a novice to be able to write
given $x {
when 1 | 2 | 3 {...}
when 4 | 5 | 6 {...}
}
Or just change Cwhen to accept a list of things to compare against,
followed by a coderef.
And change if, unless, while and until to do the same thing. And lose
the ability to say:
when none(1, 2, 3) { ... }
when 1 ^ 2 ^ 3 { ... }# More useful with classes, regexen, etc.
when 1 2 3 { ... }# Likewise
All so that a newbie doesn't confuzzle himself.
Personally, I'd rather have a chain saw than a nail trimmer, even if
I'm less likely to hurt myself with the nail trimmer. And it looks
like we'll have a warning or stricture to keep newbies from chopping
their legs off anyway.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Retry: ITypes and VTypes.
Alexey Trofimenko [EMAIL PROTECTED] wrote:
my $var = test;
my @arr := $var;
error? or maybe it would be the same weirdness, like in former example? or
maybe it's a [test]?
The := operator uses the same rules as parameter passing. So, what do
you think this does?
sub foo(@arr) {...}
foo($var);
I would assume the answer is syntax error. (Remember, array
parameters don't slurp in Perl 6 unless they have a *.)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
For those of you that can't spell, this site also contains free
imags, iamges, imges, picturs, pcitures, picktures, picturess, and
pistures.
Re: Retry: ITypes and VTypes.
Autrijus Tang [EMAIL PROTECTED] wrote: However, I'd still like to know whether my understanding on punning (same class 'Array' used as both Implementation Type and Value Type) and the validity of matching on $var is TraitName in subroutine signatures is correct. That, and types of hash keys. :) Either that, or the Ref value type is designed to wrap an implementation type. I'm not sure which is the case. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker For those of you that can't spell, this site also contains free imags, iamges, imges, picturs, pcitures, picktures, picturess, and pistures.
Re: test_main.c oversight
William Coleda [EMAIL PROTECTED] wrote: Then lets remove the file to avoid further confusion. test_main.c is being retained as an example of a non-trivial, but still clean, Parrot embedding. imcc/main.c is way too complicated and incestuous with internals to fill this role. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker For those of you that can't spell, this site also contains free imags, iamges, imges, picturs, pcitures, picktures, picturess, and pistures.
Re: forany, forall...
Both of your questions are quite elegantly handled by junctions. If
the condition were, say, $elem 10:
Jonathan Lang [EMAIL PROTECTED] wrote:
if a given condition is true for every element in a list, do something.
if all(@list) 10 { ... }
if a given condition is true for any element in a list, do something.
if any(@list) 10 { ... }
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
For those of you that can't spell, this site also contains free
imags, iamges, imges, picturs, pcitures, picktures, picturess, and
pistures.
Re: Native data structure for parrot?
Graciliano M. P. [EMAIL PROTECTED] wrote: What I'm thinking is that in Parrot, as is in Perl, we have dynamic data structures, like dynamic HASH and ARRAYs, with SCALARs that can grow as they want. To write our code this help a lot, but some parts of our algorithms need memory and speed, specially if we are working with big matrix and hash tables. In Perl 6, you'll be able to get an array with a compact representation by using a lowercase type name with it: our bit @array; At the Parrot level, this would probably be represented by a PerlBitArray PMC. You can also get at a C-level struct using the ManagedStruct and UnManagedStruct PMCs, though access is a bit clumsy IIRC. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: svn
Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: specifying the key Type for a Hash
Larry Wall [EMAIL PROTECTED] wrote:
Also says maybe you could attach a block to a hash or array to
define what subscripting does. Hmm.
That's...wow.
class Patient {
my DBI::Connection $db;
my Patient @byid[Int $id] {
select_patients(SELECT * FROM patients WHERE patientid = ?, $id)[0];
}
multi my Patient %byname{String $last} {
select_patients(
SELECT * FROM patients WHERE lastname = ?,
$last, $first
);
}
multi my Patient %byname{String $last, String $first} {
select_patients(
SELECT * FROM patients WHERE lastname = ? AND firstname = ?,
$last, $first
);
}
...
}
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I might be an idiot, but not a stupid one.
--c.l.p.misc (name omitted to protect the foolish)
Re: specifying the key Type for a Hash
Matt Diephouse [EMAIL PROTECTED] wrote:
On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon
my Patient @byid[Int $id] {
select_patients(SELECT * FROM patients WHERE patientid = ?,
$id)[0];
}
multi my Patient %byname{String $last} {
select_patients(
SELECT * FROM patients WHERE lastname = ?,
$last, $first
);
}
multi my Patient %byname{String $last, String $first} {
select_patients(
SELECT * FROM patients WHERE lastname = ? AND firstname = ?,
$last, $first
);
}
...
}
for @byid - $patient { ... }
for %byname.kv - $key, $value { ... }
Point. Maybe you just have to make all objects handled through this
method multi, though, and provide an empty-arguments variant:
multi my Patient @byid[] {
return select_patients(SELECT * FROM patients);
}
If the underlying code returns lazy lists, this can be a fairly
efficient way to do things.
The usefulness of this might be limited to providing several views an
underlying data (as above), but if you're doing something much more
complicated, chances are you really ought to use a class and an Cis.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I might be an idiot, but not a stupid one.
--c.l.p.misc (name omitted to protect the foolish)
Re: iteration (was Re: Angle quotes and pointy brackets)
David Green [EMAIL PROTECTED] wrote: Aren't lazy lists a funny kind of iterator? Ones that memoise their results. And supply an indexing method []. As I mentioned the other day, I fail to see any material difference between an iterator and a lazy list, except that a few operations are allowed on a lazy list that aren't on an iterator. (And all of those could be emulated, albeit inefficiently, with one; even with a pipe, if the user does $pipe[1024], there's no technical reason you can't store the first thousand-odd lines and return the one they asked for.) Also note that there's no difference between iterating over a lazy copy of an array, and iterating over a lazy copy of a lazy copy of an array, except for the amount of indirection; thus, there would be no need for for() to distinguish between Cfor $array and Cfor $iter (though both of those forms might need a splat). -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: pull put (Was: Angle quotes and pointy brackets)
Smylers [EMAIL PROTECTED] wrote: Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. Cunshift's only virtue, IMHO, is that it's clearly the inverse of Cshift. But I think the spelling and aural relationship between Cpush, Cpop, Cpull, and Cput is clear enough to negate that. But then, I'm a little biased. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: pull put (Was: Angle quotes and pointy brackets)
On Sat, 4 Dec 2004 23:33:24 -0700, Dan Brian [EMAIL PROTECTED] wrote: If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending shell heritage. That actively opposes sixty years of computer science terminology setting push and pop in opposition. (Well, maybe not *sixty* years, but you get the idea.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: state vs my
Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
John Siracusa [EMAIL PROTECTED] wrote: On 11/30/04 9:54 PM, Matt Diephouse wrote: use CGI «:standard»; [...] use CGi :standard; Who is doing this? I'm just saying... use CGI ':standard'; And won't we just be doing: use CGI :standard; anyway? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
Juerd [EMAIL PROTECTED] wrote:
but talking about oneliners and short shell-like scripts, where `` is
pretty useful.. hm.. things good for oneliners are rarely as good for
larger programs, and vice versa. Of course, Perl5 proves opposite, but
Perl6 tends to be a little more verbose, and even in Perl5 we use quite
different toolbox and style for mentioned above. Why not to make an
average sized module of various shortcut grammars, with a very short
name (x, f.e.), with defaults to export :all, so we could just do
perl -Mx -e 'print `echo this is a perl5qx`'
For oneliners, I think I'd appreciate using -o for that. The module
itself can be Perl::OneLiner.
module e {
module *::Main {
# Or whatever we'd need to do to switch to the top-level Main
close $*CODE;# if there is such a thing
no strict;
no warnings;
my macro circumfix:` ` (String $cmd)
is parsed(/ [^`\\]* [ \\ . [^`\\]*: ] * /) {
{ run :capture $cmd }
}
use File::Copy qw(mv cp);
...
# I do hope we get something better than #line.
eval #line 1 '-me'\n ~ @ARGS.shift;
}
}
perl -me 'say This is my one-liner!'
One-liners with no specific support in the core--and it's different
from Perl 5, so we can detect old one-liners. How's that for
orthagonal?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I might be an idiot, but not a stupid one.
--c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
On Sat, 27 Nov 2004 10:28:28 -0800, Larry Wall [EMAIL PROTECTED] wrote: On Fri, Nov 26, 2004 at 02:10:06PM -0800, Larry Wall wrote: : I know everone has their reflexes tuned to type qw currently, but : how many of you Gentle Readers would feel blighted if we turned it : into q:w instead? Of course, if we wanted to really drive it into the ground, we could turn qq// into q:q//, and then there's only one quoter. I'm sure if we tried hard enough we could find someone this appeals to. You don't even have to look very far. This seems like a decent idea to me (although I won't be sad if it doesn't happen). We also haven't quite detangled the backslash options. Seems there are four levels of support (using \/ to stand for any terminator character): 0) none # '' default 1) \\ and \/# q// default 2) list # (nothing builtin) 3) all # qq// default We need some way of specifying level 0 for a non-heredoc. We could turn q// into that, I suppose. If we did, either we'd have to make '' the same, or let it differ from q//, neither of which quite appeals to me, but I might let myself be argued into one of them or the other. Actually, I'd like to see '' be a simple, completely raw quoting construct. But if we don't do that, we might be able to take a page out of C#'s book with @ as the short form of the raw quoting construct. (Or something like that--I suspect C# picked @ because it's otherwise unused.) Actually, if we do something else with backticks, we can steal backticks for totally raw quoting... I'm open to other ideas, though we must remind ourselves that this is all very bike-sheddish. Oh, I vote for blue paint on that bike shed. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: [perl #32643] [TODO] Remove Perl* PMCs from opcodes
Will Coleda wrote:
The following opcodes return 'PerlUndef' on failure, instead of 'Undef' or
null.
open, socket, fdopen, dlfunc, dlvar, find_global
Patch attached that changes all these to Undef.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
? patch.txt
Index: ops/core.ops
===
RCS file: /cvs/public/parrot/ops/core.ops,v
retrieving revision 1.377
diff -u -r1.377 core.ops
--- ops/core.ops25 Nov 2004 11:15:20 - 1.377
+++ ops/core.ops27 Nov 2004 07:29:41 -
@@ -1134,7 +1134,7 @@
const char * err = Parrot_dlerror();
Parrot_warn(interpreter, PARROT_WARNINGS_UNDEF_FLAG,
Symbol '%s' not found: %s\n, name, err ? err : unkown reason);
- $1 = pmc_new(interpreter, enum_class_PerlUndef);
+ $1 = pmc_new(interpreter, enum_class_Undef);
}
else {
$1 = pmc_new(interpreter, enum_class_NCI);
@@ -1152,7 +1152,7 @@
const char * err = Parrot_dlerror();
Parrot_warn(interpreter, PARROT_WARNINGS_UNDEF_FLAG,
Symbol '%s' not found: %s\n, name, err ? err : unkown reason);
- $1 = pmc_new(interpreter, enum_class_PerlUndef);
+ $1 = pmc_new(interpreter, enum_class_Undef);
}
else {
/* At this point we have the symbol's address. We just need to build
Index: ops/io.ops
===
RCS file: /cvs/public/parrot/ops/io.ops,v
retrieving revision 1.51
diff -u -r1.51 io.ops
--- ops/io.ops 29 Sep 2004 15:44:29 - 1.51
+++ ops/io.ops 27 Nov 2004 07:29:41 -
@@ -58,7 +58,7 @@
$1 = PIO_fdopen(interpreter, NULL, (PIOHANDLE)$2, mode);
if (!$1) {
-$1 = pmc_new(interpreter, enum_class_PerlUndef);
+$1 = pmc_new(interpreter, enum_class_Undef);
}
/* string_cstring_free(mode); */
/* TODO all results from string_to_cstring() need freeing
@@ -155,7 +155,7 @@
/* string_cstring_free(mode); */
/* string_cstring_free(path); */
if(!$1 || !PMC_struct_val($1)) {
-$1 = pmc_new(interpreter, enum_class_PerlUndef);
+$1 = pmc_new(interpreter, enum_class_Undef);
}
goto NEXT();
}
@@ -169,7 +169,7 @@
$1 = PIO_open(interpreter, NULL, path, +);
/* string_cstring_free(path); */
if(!$1) {
-$1 = pmc_new(interpreter, enum_class_PerlUndef);
+$1 = pmc_new(interpreter, enum_class_Undef);
}
goto NEXT();
}
@@ -526,7 +526,7 @@
op socket(out PMC, in INT, in INT, in INT) :base_network {
$1 = PIO_socket(interpreter, $2, $3, $4);
if(!$1) {
-$1 = pmc_new(interpreter, enum_class_PerlUndef);
+$1 = pmc_new(interpreter, enum_class_Undef);
}
goto NEXT();
}
Index: ops/var.ops
===
RCS file: /cvs/public/parrot/ops/var.ops,v
retrieving revision 1.21
diff -u -r1.21 var.ops
--- ops/var.ops 6 Aug 2004 12:23:55 - 1.21
+++ ops/var.ops 27 Nov 2004 07:29:41 -
@@ -330,7 +330,7 @@
Global '%Ss' not found\n, $3);
}
else {
- stash = pmc_new(interpreter, enum_class_PerlUndef);
+ stash = pmc_new(interpreter, enum_class_Undef);
VTABLE_set_pmc_keyed(interpreter, globals, $2, stash);
}
}
@@ -343,7 +343,7 @@
Global '%Ss' not found\n, $3);
}
else {
- $1 = pmc_new(interpreter, enum_class_PerlUndef);
+ $1 = pmc_new(interpreter, enum_class_Undef);
}
}
else {
Re: IEEE 754 double floats
Adam Warner [EMAIL PROTECTED] wrote: I've taken a first look at Parrot and I'm very impressed. I'd like to perform some micro-benchmarking of double floating point code. I have the latest CVS version of parrot. I've compiled it upon Debian unstable x86 with the: perl Configure.pl --floatval=double option. Yet the Leibniz summation for PI http://www.parrotcode.org/examples/ still appears to be performing its calculations using single floats and continues to print 3.141591. Parrot usually uses double as its floating-point type. The problem is probably with the precision of 'print N0'; try using the 'sprintf' opcode and printing the resulting string instead. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: [PATCH] A little more Configure info
Luke Palmer [EMAIL PROTECTED] wrote: This adds information about the result of a test if the information is terse enough. i.e. changes: Determining whether your cc is actually gcc...done. Into: Determining whether your cc is actually gccyes. Thanks, applied. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: [perl #32356] AutoReply: [PATCH] update to embed.pod
On Mon, 8 Nov 2004 02:38:16 +0100, Stéphane Payrard [EMAIL PROTECTED] wrote: +#include parrot/parrot.h #include parrot/embed.h Unless things have changed far more than I thought, this is very, very, very, very, very wrong. parrot.h is an internals-only header--including it exposes all of Parrot's guts to the embedder. Note this comment at the top of parrot.h: # /* Only parrot core files should include this file. #Extensions should include parrot/extend.h. #Programs embedding parrot should include parrot/embed.h. # */ And the define a few lines down: # #define PARROT_IN_CORE -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: Search paths and library routines
Dan Sugalski [EMAIL PROTECTED] wrote:
To make this actually work we need some standards, and the ability to
embed bytecode segments into an executable (like, say, parrot :) so
they're always at hand.
The attached patch implements one (evil) way to do this. (Even if we
don't end up using the pbc2cc utility I've written, the patches to
embed.[ch] might be useful; they implement a new embedding interface
function for loading a packfile that's already in memory.)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
--- /dev/null Wed Jan 7 17:19:56 2004
+++ pbc2cc.pl Thu Nov 4 19:09:45 2004
@@ -0,0 +1,86 @@
+#!/usr/bin/perl -w
+
+=head1 TITLE
+
+pbc2cc.pl - Convert a Parrot bytecode file to a C constant
+
+=head1 SYNOPSIS
+
+pbc2cc.pl foo foo.pbc foo.c
+#Generates a foo.c with a Parrot_pbc2cc_read_foo function
+# containing foo.pbc's contents.
+
+=head1 DESCRIPTION
+
+Fpbc2cc.pl converts an input file into a C constant, then outputs some code
+to load that file as a Parrot packfile. The program takes a C identifier and
+an input file on the command line (the input file defaults to STDIN if not
+specified) and writes its output to STDOUT. It also takes a C identifier to
+be used as part of the function name to retrieve the packfile.
+
+The function generated has the signature:
+
+Parrot_PackFile Parrot_pbc2cc_read_name(Parrot_Interp interpreter);
+
+Where name is the C identifier given on the command line.
+
+=cut
+
+use strict;
+use File::Temp qw(tempfile);
+
+my($name, $in)[EMAIL PROTECTED];
+$in ||= '-';
+my $size=0;
+
+open(IN, $in) or die Can't open input file $in: $!;
+my $temp=tempfile() or die Can't create temporary file: $!;
+
+binmode(IN);
+binmode($temp);
+
+{
+local $/=\1024;
+while(IN) {
+$size += length;
+print $temp $_;
+}
+}
+
+seek $temp, 0, 0;
+
+print END;
+/*
+ * DO NOT EDIT THIS FILE
+ * This file has been automatically generated by $0 in the Parrot distribution.
+ */
+#ifndef PARROT_PBC2CC_${name}_GUARD
+#define PARROT_PBC2CC_${name}_GUARD
+
+#include stdlib.h
+#include string.h
+#include parrot/embed.h
+
+static const Parrot_Int Parrot_pbc2cc_size_$name=$size;
+/* gcc gives a warning about variable-size objects if we try to use that constant
here */
+static const unsigned char Parrot_pbc2cc_bits_${name}[$size]={
+END
+
+{
+local $/=\16;
+while($temp) {
+print \t0x, join(, 0x, map { sprintf %2.2x, $_ } unpack C*, $_),
,\n;
+}
+}
+
+print END;
+};
+
+Parrot_PackFile Parrot_pbc2cc_read_$name(Parrot_Interp interpreter) {
+\tunsigned char * rawfile=malloc(Parrot_pbc2cc_size_$name);
+\tmemcpy(rawfile, Parrot_pbc2cc_bits_$name, Parrot_pbc2cc_size_$name);
+\treturn Parrot_readbc_ptr(interpreter, $name (embedded), rawfile,
Parrot_pbc2cc_size_$name, 0);
+}
+
+#endif
+END
Index: include/parrot/embed.h
===
RCS file: /cvs/public/parrot/include/parrot/embed.h,v
retrieving revision 1.25
diff -u -r1.25 embed.h
--- include/parrot/embed.h 2 May 2004 10:47:51 - 1.25
+++ include/parrot/embed.h 5 Nov 2004 03:25:33 -
@@ -36,6 +36,8 @@
Parrot_PackFile Parrot_readbc(Parrot_Interp, const char *);
+Parrot_PackFile Parrot_readbc_ptr(Parrot_Interp, const char *, unsigned char *,
size_t, Parrot_Int);
+
void Parrot_loadbc(Parrot_Interp, Parrot_PackFile);
void Parrot_setup_argv(Parrot_Interp, int argc, char ** argv);
Index: src/embed.c
===
RCS file: /cvs/public/parrot/src/embed.c,v
retrieving revision 1.119
diff -u -r1.119 embed.c
--- src/embed.c 22 Oct 2004 13:29:36 - 1.119
+++ src/embed.c 5 Nov 2004 03:25:33 -
@@ -201,7 +201,7 @@
Parrot_readbc(Interp *interpreter, const char *filename)
{
INTVAL program_size, wanted;
-char *program_code;
+unsigned char *program_code;
struct PackFile *pf;
FILE * io = NULL;
INTVAL is_mapped = 0;
@@ -325,14 +325,7 @@
/* Now that we have the bytecode, let's unpack it. */
-pf = PackFile_new(is_mapped);
-
-if (!PackFile_unpack
-(interpreter, pf, (opcode_t *)program_code, program_size)) {
-PIO_eprintf(interpreter, Parrot VM: Can't unpack packfile %s.\n,
-filename);
-return NULL;
-}
+pf = Parrot_readbc_ptr(interpreter, filename, program_code, program_size,
is_mapped);
#ifdef PARROT_HAS_HEADER_SYSMMAN
@@ -347,6 +340,20 @@
return pf;
}
+struct PackFile *
+Parrot_readbc_ptr(Interp *interpreter, const char *name, unsigned char *ptr, size_t
size, Intval is_mapped) {
+struct PackFile *pf = PackFile_new(is_mapped);
+
+if (!PackFile_unpack
+(interpreter, pf, (opcode_t *)ptr, size)) {
+PIO_eprintf(interpreter, Parrot VM: Can't unpack packfile %s.\n,
+name);
+return NULL;
+}
+
+return pf;
+}
+
/*
=item Cvoid
