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: 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: 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: 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
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: 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: 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: 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
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: 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: 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: 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: 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: 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: Hyper operator corner case?
David Christensen [EMAIL PROTECTED] wrote: Example: (1,2,3,4,5) + (1,2) Is this equivalent to: a) (1,2,3,4,5) + (1,2,undef,undef,undef) (undef padding) b) (1,2,3,4,5) + (1,2,1,2,1) (repetition) c) (1,2,3,4,5) + (1,2,2,2,2) (stretching) d) (1,2) + (1,2) (truncation) e) something else, ie, warnings about mismatched dimension, die(), segfault, kill -9 1 (whatever your sadism level is). IIRC, it's f) (1,2,3,4,5) + (1,2,$identity,$identity,$identity), where $identity's value is determined by a table something like this: infix:+0 infix:-0 infix:~'' infix:*1 infix:/1 infix:%mumble infix:x1 I could be wrong, though; I can't find any support for it in the design docs. -- 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: 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: 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: 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: 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: 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: Angle quotes and pointy brackets
Larry Wall [EMAIL PROTECTED] wrote:
Speaking of at the moment, I just now updated the Synopses at
dev.perl.org.
The new S2 says:
# Heredocs are no longer written with , but with an adverb on any other
# quote construct:
#
# print qq:to/END/
# Give $amount to the man behind curtain number $curtain.
# END
Does any other quote construct include rx//? I've wanted that for a
while in Perl 5 (although with anonymous rules, I suppose it's no
longer that important...).
# In order to interpolate an entire hash, it's necessary to subscript with
# empty braces or angles:
#
#print The associations are:\n%bar{}
#print The associations are:\n%bar
Am I to assume you can use empty French/Texas quotes, too? (i.e.
%bar«» or %bar).
This paragraph also made me realize: am I the only one who foresees
somebody doing this?
$OUT.printf(We produced b%d/b somoflanges this month!\n, $content);
(Granted, the fix is trivial--just replace the double-quotes with
single-quotes, or add some of that optional spacing HTML lets you
splatter around--but it seems like an easy mistake to make.)
Finally, I noticed that the Files section only talks about iterating
over all lines. Do you have a decision on single-line reads yet?
[And a note to the editors of dev.perl.org: can we get tables of
contents on these documents? While it's nice to exercise Firefox's
slick find-in-page interface so much on, say, Apocalypse 12, it'd be
more convenient to just have a TOC.]
--
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
Juerd [EMAIL PROTECTED] wrote: A request to everyone who wants to discuss this again: please, read the Backticks thread. Almost everything that can be said about this subject has already been said before. Not to put too fine a point on it, but everything includes Larry's rejection of 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: Angle quotes and pointy brackets
I like this in general. However... Larry Wall [EMAIL PROTECTED] wrote: * Since we already stole angles from iterators, «$fh» is not how you make iterators iterate. Instead we use $fh.fetch (or whatever) in scalar context, and $fh.fetch or @$fh or $fh[] or *$fh in list context. I believe you tried this one a couple years ago, and people freaked out. As an alternative, could we get a different operator for this? I propose one of: $fh - $fh» (and $fh) $fh All three have connotations of the next thing. The first one might interfere with pointy subs, though, and the last two would be whitespace-sensitive. (But it looks like that isn't a bad thing anymore...) Any other suggestions, people? -- 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
Rod Adams [EMAIL PROTECTED] wrote:
$fh -
$fh» (and $fh)
$fh
++$fh
That kind of breaks the metaphor, unfortunately.
I've been thinking more on this, and I may have a better reason for
not liking this proposal. I'm going to pull a Larry and think out
loud for a minute here. Note that I speak authoritatively here, as if
I'm the language designer; this is just to avoid putting I would...
everywhere.
I think my problem with the proposed syntax is metaphor shear. This
example code:
for (@$input) {
...
}
works whether $input is a filehandle or an arrayref. So a user may
decide to do this:
say $input[42];
which I suspect won't work. Even if it does, this code:
for(@$input) {
...
}
say $input[0];
probably wouldn't.
The problem is that filehandles are iterators--which aren't arrays.
An iterator has different characteristics from an array--i.e. it's
accessed more or less sequentially and access is destructive.
Treating it like an array is wrong.
On the other hand, what if a filehandle *is* an array? What if you
can access it randomly and non-destructively?
If it is, we already have a name for fetch. In Perl 5, we call a
destructive fetch from the front of an array shift.
So:
$fh=open foo.txt;
say $fh.shift;
for $fh.shift($fh.elems) {
...
}
Of course, $fh.shift($fh.elems) deserves a shortcut. Perhaps
$fh.shiftall(), which creates a lazy copy and empties the
filehandle.
But .shift looks a bit awkward. I suggest a name change for .shift
and .unshift, so that we have:
push, pop
pull, put
So now we have:
my $fh=open foo.txt;
say $fh.pull;
for $fh.pullall {
...
}
And what about iterators in general? Well, if we can do it to
filehandles, why not all iterators? An iterator is simply a lazy
array copy that isn't accessed randomly; instead, the .pull and
.pullall methods are used for access. .push can be used to append to
it, .put can be used to put an item back on the front. .pop is a bit
useless, but that's not really a problem.
That doesn't mean you *can't* randomly access an iterator--after all,
it's just a lazy array copy. But it might be slower, or otherwise
unwise.
At the point where a filehandle is just an array and you can use most
normal array operations on it, I can see not having a special operator
for reading a file. Without that, though, I think the metaphor shear
of @$fh is too harsh, and the duplication between .fetch and
.[shift|pull] isn't necessary.
--
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: Perl6/Parrot and Backwards Compatability
Matthew Walton [EMAIL PROTECTED] wrote: I suggest you read more about Parrot... it's designed to allow these things. There is a project (Ponie) to make Perl 5 run on Parrot, and there will be other languages as well - which will be able to call each others libraries. Making the Perl 5 libraries available to Perl 6 being a primary motivation. I'm not sure about how well XS will work on Ponie, but I assume that it will be made to work if at all possible. XS modules that use the proper macros to deal with Perl 5 SVs should work fine with Ponie. Ones that muck around in the internals of SVs, or deal with things like the parse tree (B::*), will need to be rewritten. (But many of those things are necessary because Parrot does them very differently--e.g. it uses bytecode instead of executing the parse tree directly.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: S5: array interpolation
John Siracusa [EMAIL PROTECTED] wrote:
An interpolated array:
/ @cmds /
is matched as if it were an alternation of its elements:
/ [ @cmds[0] | @cmds[1] | @cmds[2] | ... ] /
As with a scalar variable, each one is matched as a literal.
Like this? (Assuming single quotes don't interpolate @foo[...])
@a = ('a', 'b', 'c');
'@a[0]' ~~ m:/ @a /; # true
'@a[2]' ~~ m:/ @a /; # true
'@a[9]' ~~ m:/ @a /; # false
I think he means as opposed to a subrule. In Perl 5 terms, there's
an implicit \Q\E around each value in the array.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
Re: Return with no expression
Aaron Sherman [EMAIL PROTECTED] wrote: I've always thought that particular bit of sugar was rather dangerous. I'd even prefer a longhand: $foo either 0 or split(); The overloading of 'or' there is (IMHO) far more dangerous than the overloading of '::' being discussed in this thread. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: A thought for later -- POD tables
Aaron Sherman [EMAIL PROTECTED] wrote: Still, tables are useful, so here's a simple way to get the kind of table we see above, without the HTMLish trap of pseudo-layout: Because one of the features of POD is that documentation tends to be readable in markup form, an C=-introduced markup seems like it would not work well. Instead, we use C H... (headings) and C T... (table body) like so: H C$_ | C$x | Type of Match Implied | Matching Code T Any | CodeC $ | scalar sub truth | match if C$x($_) I worry that, with that syntax, someone might try to nest a table. I also think that the H/T syntax is a bit wrong--to use CSS terminology, tables are a block construct, not an inline one.[1] Instead, I'd recommend something like this: =table C$_ | C$x | Type of Match Implied | Matching Code =row Any | CodeC $ | scalar sub truth | match if C$x($_) (I'm not sure how good the alignment is on that--Gmail's compose window uses a variable-width font.) This makes it syntactically impossible to nest a table, removes the slightly odd-looking H/T syntax, and is still very readable. It's also not dependent on the distinction between tabs and spaces (see 'make' for why this is a Good Thing). To help deal with wide tables, lines that don't have a =table/=row directive (but do have other content) would be appended to the previous line: =table C$_ | C$x | Type of Match Implied | Matching Code =row Any | CodeC $ | scalar sub truth | match if C$x($_) [1] Actually, in CSS a table is neither an inline nor a block construct--it's considered its own category, because normal block constructs have a default width of 100%, while tables are only wide enough to hold their contents. Same difference... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: Synopsis 4 draft 1
Larry Wall [EMAIL PROTECTED] wrote:
Final blocks on statement-level constructs always imply semicolon
precedence afterwards regardless of the position of the closing curly.
Statement-level constructs are distinguished in the grammar by being
declared in the statement syntactic group:
macro statement:if ($expr, ifblock) {...}
macro statement:while ($expr, whileblock) {...}
macro statement:BEGIN (beginblock) {...}
And he answers another but how do we... question with a simultaneous
[unific|simplific|generaliz]ation. Larry, you're a genius.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
Re: This week's summary
Piers Cawley wrote: Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes: Care to explain what those are, O great math teacher? What's a math teacher? It's the right^H^H^H^H^HAmerican way to say maths teacher. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: This week's summary
The Perl 6 Summarizer wrote: The infinite thread Pushing onto lazy lists continued to exercise the p6l crowd (or at least, a subset of it). Larry said that if someone wanted to hack surreal numbers into Perl 6.1 then that would be cool. Care to explain what those are, O great math teacher? *ducks* -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Why do users need FileHandles?
Jonadab the Unsightly One wrote: Surely, at bare minimum, there must be something included in core to allow things that are not in core to be easily installed, the equivalent of what CPAN.pm is for Perl5 (hopefully even better, and I believe that's the current plan--the core will include CPAN, LWP, and not much else. hopefully without dependencies on external non-Perl things like gcc). Don't think it'll be possible for modules that have C components, although Parrot's Native Call Interface ought to make a lot of XS uses obsolete. (With NCI, Parrot provides opcodes to load a shared library, then retrieve functions from it and treat them like normal Parrot subs--all without writing any C. That includes converting arguments and return values from Parrot types to C types.) Oh, and here's me resisting the urge to suggest that use ought to automatically install from the CPAN anything that isn't present, as a core behavior right out of the box. Security nightmare. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Why do users need FileHandles?
David Storrs wrote:
#!/usr/bin/perl6
#use warnings; # Note that I am NOT explicitly using these
#use strict;
{ no 'warnings'; no 'strict'; # These must be explicitly turned off...
no installation_security; # or this would throw warning error
use SomeModule; #
use OtherModule;#
use Foo;# If these are not installed,
use Bar;# they will be auto-installed.
use Baz;#
use Jaz;#
}
use FrobNitz; # If this is not installed, the script fails.
script goes here
__END__
This is really something you want to enable or disable per-run, IMHO (so
e.g. the first time you run the script, you run it with perl -Minstall
or something). Or you could just make it part of the 'cpan' program:
brent:~$ wget www.somesite.com/somescript.cgi.gz
brent:~$ gunzip somescript.cgi.gz
brent:~$ cpan --prereqs=somescript.cgi
brent:~$ cp somescript.cgi /www/cgi-bin
brent:~$ chmod 755 /www/cgi-bin/somescript.cgi
# somescript.cgi is now ready for use
This would require 'cpan' to parse the script with a modified grammar
that noted all the 'use's (and 'require's, I guess), then install each
module. Or something like that.
Hmm...maybe this could be done for Perl 5...
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: xx and re-running
Michele Dondi wrote:
Quite similarly, for example, I'd like to have a fold() function like the
one that is available in many functional programming languages, a la:
my $tot = fold 0, { + }, 1..10; # 55
my $fact = fold 1, { * }, 2..5; # 120
Those blocks would be a syntax error; the appropriate way to do that
would be to refer to the operator by its proper name:
my $tot = fold 0, infix:+, 1..10;
OTOH, Perl 5 already has List::Util::reduce:
use List::Util;
my $tot=reduce { $a + $b } 1..10;
my $fact=reduce { $a * $b } 2..5;
Your fold() can be trivially expressed with reduce(), IIUC. I would
hope that Perl 6 will have reduce() as well--perhaps even in a form that
doesn't require using List::Util explicitly.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: String interpolation
Luke Palmer wrote:
I admit there's a certain interest to Larry's new idea. I've been
looking for more distinction between $, @, and % in Perl 6, since they
start to become mostly irrelavent. In the new proposal:
my @a = (1,2,3,4,5);
my $a = @a;
say @a; # @a
say $a; # 1 2 3 4 5 (perhaps?)
I think that's a bad kind of distinction, personally. It breaks an
obvious parallel.
But I'll admit that I'm much more a fan of $() and @() than I am of {}.
Form.pm would get very angry at this decision indeed.
Amen. Please don't steal unnecessary metacharacters in qq()
strings--although I still think we should keep it, @ causes a lot of
problems.
On the other hand, this is another step unifying strings and regexes. I
can say pretty confidently that that's a Good Thing.
The equivalent regex syntax isn't interpolating, even to the extent that
a bare $foo or @bar is, so this would be sort of a false cognate--IMHO
another reason not to have interpolating {}.
and what about @a[1]('arg')[3]?
That probably wouldn't.
Actually, I have to wonder why foo('bar', 'baz') wasn't on Larry's
list. Is there a reason for that?
(On the other hand, what will happen with HTML entities like nbsp; or
copy; if that *is* allowed?)
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
I would think you'd use a property:
my @foo = (1,2,3,4,5) but separator('//');
Or maybe a trait:
my @foo is separated('//') = (1,2,3,4,5);
Or perhaps even a (gasp!) attribute:
my @foo = (1,2,3,4,5);
@foo.separator='//';
Roles are nice, but don't forget about the other mechanisms in Perl for
such things.
[Forgot to send it to the list. D'oh.]
[And then I sent it to the wrong one. D'oh * 2.]
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: String interpolation
Luke Palmer wrote:
I suppose another good thing is that it makes unneccesary the balanced
brace rule in qq{} that was there in Perl 5: all braces need to be
backwhacked now. However, all braces need to be backwhacked now. Ugh.
I was dreading code-generating heredocs, but with the inclusion of
\qq[], that turns out not to be a problem:
my $code = eval 'CODE';
sub () {
my \qq[$name] = 0;
...
}
CODE
Didn't know that worked in single-quoted strings. Cute.
Actually, I have to wonder why foo('bar', 'baz') wasn't on Larry's
list. Is there a reason for that?
Probably because foo('bar', 'baz') isn't a function call. All that
does is refer to a function foo with a siglet ('bar','baz'), which
means either nothing or a syntax error. The function call looks like
foo('bar', 'baz');
Hmm...breaks the parallel with {} and []. But it seems to me that
foo.('bar','baz') should work, at least outside a string.
Roles are nice, but don't forget about the other mechanisms in Perl for
such things.
Erm, properties *are* roles. Your example is the same as mine.
True, I suppose...
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: String interpolation
Uri Guttman wrote: how would you put in the literal string $foo.bar()? escaping the . or the ( ? The dollar sign. (Or, if you wanted to interpolate $foo while leaving the .bar() intact, I would imagine that either \. or \( would suffice.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: enhanced open-funktion
Greg Boug wrote: I have always felt that keeping it the same as shell scripting was a handy thing, especially when I have been teaching it to others. It also makes the ol' perl5 open FH, |/usr/bin/foo; make a lot more sense. Using something like open p, /usr/bin/foo; just wouldn't have the same ring to it. Aside from which, it gets even worse when you consider how you would have to change: open FH, /usr/bin/foo|; My personal preference is for: $in=open :r |/usr/bin/foo; $out=open :w |/usr/bin/foo; $both=open :rw |/usr/bin/foo; The pipe would be legal on either side of the string. This would still allow the often-useful type a pipe command at a prompt for a file, while matching the trait-based syntax suggested elsewhere. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: push with lazy lists
Ph. Marek wrote:
On Thursday 08 July 2004 05:25, Larry Wall wrote:
: say @x[rand]; # how about now?
Well, that's always going to ask for @x[0], which isn't a problem.
However, if you say rand(@x), it has to calculate the number of
elements in @x, which could take a little while...
I'd expect to be rand(@x) = rand(1)[EMAIL PROTECTED] = rand(1)*Inf = Inf or NaN.
Perl can't tell the difference between finite and infinite gather/take
lists. (It literally can't--this is practically a perfect example of
the halting problem.) So if you ask a gather/take for its length, the
best thing Perl can do is to start gathering elements, hoping to
eventually find an end.
Unfortunately, since gather { take time } is an infinite list, it's
quite impossible for the gathering to ever finish, short of the universe
coming to an end, the computer crashing, or a sysadmin killing the
program. (Unless safe mode restricts the length of lazy lists, which I
would recommend given the existence this little ball of hate.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: if not C, then what?
Except people don't actually read the documentation, and when they
do read it, they don't understand it, and when they do understand it,
they'll write it wrong anyway out of habit. You might as well write
your warning in Russian for all the good it'll do. :-)
So we'll force people who want any loop that exits other than at the
top to use:
loop {
...
last if CONDITION;
...
}
And that means we disallow modifier loops on do-{}.
Makes me wonder if we shouldn't rename do {}...
run { foo; bar } while baz;# uses a valuable identifier
exec { foo; bar } while baz; # assuming we rename exec
execute { foo; bar } while baz;# longer, still stupid
eval { foo; bar } while baz; # we just escaped overloaded eval
{ foo; bar }() while baz; # bare-bones
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: The .bytes/.codepoints/.graphemes methods
Aaron Sherman wrote: On Tue, 2004-06-29 at 11:34, Austin Hastings wrote: (2) Perl6 should equitably support all its target locales; (3) we should set out to make sure the performance is damn fast no matter what locale we're using. Well, that's a nice theory, but you can prove that low-level encodings (e.g. ASCII, EBCDIC) will be more efficient than high-level encodings (e.g. UTF-8), so the only way to accomplish what you suggest in (2) is to break (3) by slowing down the faster handling (not what you wanted, I'm sure). At the Parrot level, codepoint operations will generally be the most efficient, even on strings with exotic charsets. Parrot uses an internal encoding that allows O(1) access to codepoints; essentially, it uses an array of 8-, 16-, or 32-bit integers, depending on the highest codepoint value. This is the default even for character sets with shift characters, like Shift-JIS. On strings where all codepoints have values under 256, bytewise and codepointwise lookup are equivalent; otherwise, though, bytewise lookup will actually be *slower* than codepointwise, as Parrot will maintain the illusion that each codepoint is stored in an integer that's the perfect size for it. If you force Parrot to use the UTF-8 encoding internally then bytewise lookup becomes fastest, and codepointwise slows down a lot. But you really shouldn't do that--UTF-8 is ill-suited for actually *manipulating* text, unlike the Parrot internal encodings. (UTF-16 and UTF-32 will presumably be available too, although I've seen no specific mention of them.) You can also force it to use a raw or bytes encoding, where bytes and codepoints are identical. But you can't store Unicode characters in such a string and have them behave in a reasonable way. (Note: this is all based on my own, possibly false, memory.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Cmap Cgrep and lazyness
Alexey Trofimenko wrote:
apply to it perl6 GC, which wouldn't always free memory immediately,
so it could eat 3_000_000 or more.
Parrot runs a DOD (Dead Object Detection) sweep whenever its memory
pools fill up, so this is probably a far smaller problem than you
suggest. (If there still isn't any space in the existing pools after a
DOD, it malloc()s a new one.)
ok, I know, that 1..n will return an iterator in perl6, which is
called only when new item needed. great.
what I want to ask - would map and grep return an iterators too?.. if
it's true, then previous construct becames very memory efficient, like
if I write
loop ( ... ; ... ; ... ) {...; next if ...; ...; say}
As you mentioned below, this causes problems if the code in question has
side effects. But there are other cases where it messes up:
sub even($_ = $CALLER::_) { ! $_ % 2 }
my @e=grep { even() } 1..1024;
#Okay, we don't need even anymore...
undef even;
say @e;
Put that Cundef in an Ceval, and all of a sudden you can't tell if
the laziness is safe even at compile time.
I suggest that this laziness be confined only to places where it's
specifically asked for:
my @e=grep { even() } :lazy 1..1024;
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: undo()?
Rod Adams wrote:
Well, that's another explanation that jives with my understanding of
them. But I still don't have an idea of when I would actually want
to use them in something I'm writing.
You can use them to implement all sorts of interesting control flow
constructs.
For example, here's an implementation of exceptions (though not the one
we'll be using):
our Continuation $try_cont;
sub try(try_block) {
temp $try_cont = take Continuation;
unless defined $! {
try_block();
}
}
sub catch(catch_block) {
if defined $! {
catch_block($!);
}
undef $!;
}
multi sub throw(Exception $except) {
$!=$exception;
throw();
}
multi sub throw() {
$try_cont();
}
try {
throw new Exception: Whoa there!;
}
catch {
print Caught exception: $!;
}
(Disclaimer: untested, and I've never actually used continuations.)
Note here that we don't want the changes to $! to be undone--that's what
determines whether try_block or catch_block is executed (this time
around). If the $! changes were undone, then try_block would either be
called repeatedly until it finally managed to succeed. In the case of
the try_block used here, the program would get stuck in an infinite loop.
That example's a bit obvious, since continuations are similar to
setjmp()/longjmp(), and one of the things those functions are often used
for is exceptions. But there are other cases, too...
Suppose, for example, you're writing a disk checker (fsck, scandisk,
etc.). Like all such programs, yours has the infuriating habit of
starting over every five seconds:
for @ARGS - $partition {
my cont := take Continuation;
my $timer=new Timer: cont
:interval5sec :repeat(1);
do_scan($partition);
#Aren't race conditions fun, children?
#Like this'll ever happen.
$timer.cancel();
}
Could this be done with redo()? Sure. But realize that *redo() itself
could be implemented with continuations*. Nearly any control flow
construct can. (I think a goto() can't, but that's about it.) Loops,
exceptions, and subroutines can all be implemented in terms of
continuations--but so can almost any other control flow construct you
can think of, and most likely some you can't.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: undo()?
David Storrs wrote: Well, at least that's a nice simple explanation. Why couldn't anyone have explained it to me that way before? Unfortunately, it means that continuations are a lot less useful than I thought they were. : Actually, I think you're underestimating the little guys. After all, if they rolled back *all* of your changes, all they could do was repeatedly execute the same code! How do continuations and threads interact? When you take a cont, are you taking it only within the current thread? Or does it snapshot all threads in the process? Continuations are an operation on the call stack (although it's usually a call chain for continuations), so a continuation only operates on the current thread. I think. (Incidentally, IIRC you can implement user-mode cooperative threading with continuations--yield() enqueues its return continuation and then dequeues and invokes another thread's continuation. But that's not what you're asking at all.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: definitions of truth
Paul Hodges wrote: --- Spider Boardman [EMAIL PROTECTED] wrote: You need ord() for character/grapheme/byte/whatever testing that's equivalent to what C does. Since C doesn't really have strings, and Perl does, this is just one of those differences between the languages where (essentially, and perhaps abusing some linguistics theory and terminology) you've run into a 'false cognate'. lol -- C doesn't have strings, but Perl does? He's absolutely correct. C does not have a string type, just as Perl does not have a character type. In C you can *represent* a string as an array of characters, just as in Perl you can *represent* a character as an integer. But there's no built-in, native type for either of these. You could write your own data structure to represent a string (Parrot, Perl 6's runtime engine, does this), but it's still not a first-class, built-in type the way an int or float or char is. You wouldn't be able to compare it with or have it behave rationally as the condition of an if() or copy it with =. (You could do all of these things with C++, though--but it still wouldn't be a built-in type.) Similarly, you could write a class to represent a character in Perl 6, but it wouldn't be built-in like Int, Num and String are. It could come very close--it could work correctly (for some value of correctly) in boolean context, for example, unlike C strings--but it would still require a use statement to get at, and people often wouldn't design their modules to use it the way they do for Int, Num and String. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
The .bytes/.codepoints/.graphemes methods
As currently designed, the String::bytes, String::codepoints, and String::graphemes methods return the number of bytes, codepoints, and graphemes, respectively, in the string they were called on. I would like to suggest that, when called in list context, these methods return an array of strings split by bytes, codepoints, and graphemes, respectively. This would make it unambiguous whether certain string operations referred to bytes, codepoints, or graphemes: $str.bytes[0].ord $str.codepoints[0..4].join #substr As well as allowing some operations that are currently much more difficult: $str.bytes[3].ord $str.graphemes[144].lc Issues: * Limits lvalue substr (doesn't allow it to be a different size) unless splice is used (or a substr method is also provided). * Memory consumption. * A bit odd-looking. Benefits: * Removes ambiguity in an area that needs said ambiguity removed. * Allows us to reuse constructs (e.g. slicing). * Opens up a few previously-difficult constructs (like getting the ord() of an arbitrary character). -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: definitions of truth
Paul Hodges wrote:
So a null byte is still Boolean true.
But just tell me thisam I the only guy who thinks this *feels*
wierd? Understanding the reason doesn't make it any more ~comfortable~.
I think you are. Perl considers null to be data--it's that simple.
Remember, while Perl can work with binary, it's really designed for text.
Incidentally, if you really want to, you can always define your own
string that does what you want:
class BinaryString is String {
method prefix:? () {
if($_ eq \0) {
return 0;
}
else {
next METHOD;
}
}
}
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: definitions of truth
Scott Bronson wrote:
That's the plan? Happy day! I was not aware of that. Because I didn't
see anything about this in Perl 6 Essentials, I just figured that
Perl5's '0'==undef was being brought forward into Perl6. The horror!
Sorry for the bad assumption. :)
Perhaps not as happy as you think:
my $foo = '0';
my String $bar = '0';
if $foo { say 'foo true' }
if $bar { say 'bar true' }
Would print 'bar true', but not 'foo true'. (In other words, variables
of type Any keep the Perl 5 behavior, but variables of type String have
the behavior you want.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: cmd line like switches for functions and operators.
Michele Dondi wrote:
Specifically I'd like to have the possibility of doing something like
this:
rename -v = 1, $orig, $new;
It's already being done:
rename $orig, $new :verbose;
sub rename($orig, $new, +$verbose) {
say Renaming `$orig' to `$new' if $verbose;
...
}
The colon is just a different syntax for a pair constructor; say is
what many languages call printline.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Yadda yadda yadda some more
Aaron Sherman wrote:
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
From A12:
**
New Grammatical Categories
The current set of grammatical categories for operator names is:
CategoryExample of use
--
coerce:as 123 as BigInt, BigInt(123)
self:sort @array.=sort
term:...$x = {...}
prefix:++$x
infix:+ $x + $y
postfix:++ $x++
...
**
It's not exactly clear how that's used, considering that you can't do
multi-dispatch on the return type (right?)...perhaps like
multi sub coerce:as(Int $dest is rw, MyObj $src) {...}
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: $foo.s/foo/bar/
Juerd wrote: Juerd skribis 2004-05-12 20:15 (+0200): But I think I still want to have some non-mutating version of s/// that returns the modified string, so that you can just write something like print s:gx/\w+/WORD/ for ; Actually, can't we just use the . for s///? You'd then use $foo.s/// to get the new string ang $foo.=s/// to mutate $foo. Working from the other direction, parens are not valid pattern delimiters, leaving s() open for use: print s(/:g \w+/, 'WORD'); (Or somesuch...dunno about the positioning of :g.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
