RE: backticks
Perhaps this is naive, but couldn't something like this be achieved in a
manner similar to how I just implemented it in Ruby? Surely Perl will have
similar capabilities to handle unknown methods.
class Hash
def method_missing(method_name)
str = method.id2name
if str =~ /^\w+$/ then self[str] else super(method_name) end
end
end
h = {"foo" => "bar"}
h.foo# "bar"
h.baz# nil
h.length # 1
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004
"hyper variables/references?
I may have missed an obvious answer to this question, but has any thought been given to allowing for variables which behave as though ever operation on them is the hyper version of that operation? Sort of an automagical way of redefining a LOT of operators. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.686 / Virus Database: 447 - Release Date: 14/05/2004
Re: RFC 107 (v1) lvalue subs should receive the rvalue as anargument
Can we please cut down on the traffic to perl-announce, maybe make it moderated? Thanks, -- Chris Nandor | [EMAIL PROTECTED] | http://pudge.net/ Andover.Net| [EMAIL PROTECTED] | http://slashcode.com/
spaces and transliteration
I am working on the transliteration method operator (trans()) for
Rakudo and wanted to get some input on how character ranges are to be
used.
Should spaces be ignored in ranges like 'A .. Z'? Currently the
implementation I have ignores those spaces but counts any other spaces
as important, so (using parrot perl6.pbc with my patch):
> say "Whfg nabgure Crey unpxre".trans(' a .. z' => '_n .. za .. m',
'A .. Z' => 'N .. ZA .. M')
Just_another_Perl_hacker
chris
spaces and transliteration
I am working on the transliteration method operator (trans()) for
Rakudo and wanted to get some input on how character ranges are to be
used.
Should spaces be ignored in ranges like 'A .. Z'? Currently the
implementation I have ignores those spaces but counts any other spaces
as important, so (using parrot perl6.pbc with my patch):
> say "Whfg nabgure Crey unpxre".trans(' a .. z' => '_n .. za .. m',
'A .. Z' => 'N .. ZA .. M')
Just_another_Perl_hacker
chris
S05 and S29 may conflict on behavior of $string.match(/pat/)
I'm trying to pin down what $string.match(/pat/) should be returning. >From S05: Under "Return values from match objects" "A match always returns a Match object..." >From S29: Under the definition of Str.comb Saying $string.comb(/pat/, $n) is equivalent to $string.match(rx:global:x(0..$n):c/pat/) [ ...and later... ] "If there are captures in the pattern, a list of Match objects (one per match) is returned instead of strings." Which implies that $string.match(/pat/) should indeed return a List of Str and $string.match(/pat_with_groups/) should return a List of Match. I expected the S29 definition when first approaching $string.match I feel it is more intuitive than what happens with S05. Could someone clarify what the behavior should be? Best Regards, -Chris Davaz
Re: S05 and S29 may conflict on behavior of $string.match(/pat/)
Thanks for clarifying however I'm still unsure what a Perl 6 user should expect to get back from running $string.match(/pat/). This is the ""one high-level call to the .match method" yes? So it should be returning a List of Str (or List of Match in case of capture groups), is this correct? I ask because in the current Rakudo implementation it returns the Match object (what I would expect from the "one low-level run of the regex engine"). Best Regards, -Chris On Thu, Sep 18, 2008 at 11:52 PM, Larry Wall <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 06:11:45PM +0800, Chris Davaz wrote: > : I'm trying to pin down what $string.match(/pat/) should be returning. > : > : >From S05: > : > : Under "Return values from match objects" > : "A match always returns a Match object..." > : > : >From S29: > : > : Under the definition of Str.comb > : > : Saying > : > : $string.comb(/pat/, $n) > : > : is equivalent to > : > : $string.match(rx:global:x(0..$n):c/pat/) > : > : [ ...and later... ] > : > : "If there are captures in the pattern, a list of Match objects (one > : per match) is returned instead of strings." > : > : Which implies that $string.match(/pat/) should indeed return a List of > : Str and $string.match(/pat_with_groups/) should return a List of > : Match. > : > : I expected the S29 definition when first approaching $string.match I > : feel it is more intuitive than what happens with S05. Could someone > : clarify what the behavior should be? > > S05 is using a different definition of "match". In S05 it means > more like "one low-level run of the regex engine" rather than "one > high-level call to the .match method". In other words, the .match > method can do multiple matches. > > Larry >
Re: Split with negative limits, and other weirdnesses
If someone wants to make the final word on what the behavior should be
I can go ahead and implement it.
On Tue, Sep 23, 2008 at 11:41 PM, Jonathan Scott Duff
<[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 9:38 AM, TSa <[EMAIL PROTECTED]> wrote:
>
>> HaloO,
>> Moritz Lenz wrote:
>>
>>> In Perl 5 a negative limit means "unlimited", which we don't have to do
>>> because we have the Whatever star.
>>>
>>
>> I like the notion of negative numbers as the other end of infinity.
>> Where infinity here is the length of the split list which can be
>> infinite if split is called on a file handle. So a negative number
>> could be the number of splits to skip from the front of the list.
>> And limits of the form '*-5' would deliver the five last splits.
>>
>
> As another data point, this is the first thing I thought of when I read the
> email regarding negative limits. But then I thought "we're trying to get
> away from so much implicit magic". And I'm not sure the failure mode is loud
> enough when the skip-from-the-front semantics /aren't/ what you want (e.g.,
> when the limit parameter is variable-ish)
>
>
> A limit of 0 is basically ignored.
>>
>> Here are a few solution I could think of
>> 1) A limit of 0 returns the empty list (you want zero items, you get them)
>>
>
> I think this is a nice degenerate case.
>>
>
> Me too.
>
>
> 2) A limit of 0 fail()s
>>
>
> This is a bit too drastic.
>
>
> Indeed.
>
>
>
> 3) non-positive $limit arguments are rejected by the signature (Int
>> where { $_ > 0 })
>>
>
> I think that documents and enforces the common case best. But I would
>> include zero and use a name like UInt that has other uses as well. Are
>> there pragmas that turn signature failures into undef return values?
>>
>>
>> Regards, TSa.
>> --
>>
>> "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
>> "Simplicity does not precede complexity, but follows it." -- A.J. Perlis
>> 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
>>
>
>
> my two cents,
>
> -Scott
>
> --
> Jonathan Scott Duff
> [EMAIL PROTECTED]
>
Re: Split with negative limits, and other weirdnesses
Ok, so 0 returns the empty list and -1 violates the signature? In PIR can we have such signatures that put a constraint on the range of values for a given parameter? On Sun, Sep 28, 2008 at 7:25 PM, Carl Mäsak <[EMAIL PROTECTED]> wrote: > Jason (>): >> It makes sense to me to go with option 1; you get what you ask for. It also >> makes sense to make to not use magical implied numbers, such as negatives, >> to accomplish things that either ranges or whatever star can accomplish. > > Aye, agreement. There's a whole lot of consensus already... reading > through the discussion once more, I don't find anyone saying anything > contradicting the above summary. > > Chris, I'm not in a position to provide a final word, but it seems > very possible already to use what has already been said here as a > basis for an implementation. > > // Carl >
{*} and actions
1) Will the "{*}" syntax to invoke an external action method from
within a grammar be an official part of the language, or an
implementation hack?
2) If it becomes official, how should people specify the action class/
instance to be used with a grammar?
Currently in Rakudo, I use the following deprecated hack:
my $method := &My::Grammar::TOP;
my $match := $str.$method(:action(My::Grammar::Actions.new));
but I'd greatly prefer something more like
my $grammar = My::Grammar.new(:action(My::Grammar::Actions.new));
my $match = $str ~~ $grammar;
Chris
Re: References to parts of declared packages
On Feb 11, 2009, at 2:46 PM, Carl Mäsak wrote:
Jon (>), Jonasthan (>>):
If we declared, for example:
role A::B {};
Then what should a reference to A be here? At the moment, Rakudo
treats it
as a post-declared listop, however I suspect we should be doing
something a
bit smarter? If so, what should the answer to ~A.WHAT be?
I'd go with one of two possibilities:
* Don't allow the declaration of A::B unless A has already been
declared.
[...]
Please don't go with this former alternative. In a project even of
moderate size like Druid, many packages of type A::B are declared
before the corresponding A package is, for perfectly legitimate
reasons.
Agree completely. Bio::* currently has the same issue.
* A should be treated as a post-declared package.
Whatever this means, it sounds preferable. :)
// Carl
Agree again. The latter is definitely preferred.
chris
Re: r25325 - docs/Perl6/Spec
Argh! I submitted a patch implementing $?PROGRAM in Rakudo literally 5 minutes before you sent this... http://rt.perl.org/rt3/Ticket/Display.html?id=63228 Chris On Feb 13, 2009, at 11:21 PM, pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2009-02-14 06:21:13 +0100 (Sat, 14 Feb 2009) New Revision: 25325 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] $?PROGRAM makes no sense Modified: docs/Perl6/Spec/S19-commandline.pod === --- docs/Perl6/Spec/S19-commandline.pod 2009-02-14 05:13:04 UTC (rev 25324) +++ docs/Perl6/Spec/S19-commandline.pod 2009-02-14 05:21:13 UTC (rev 25325) @@ -14,8 +14,8 @@ Maintainer: Jerry Gay Date: 12 Dec 2008 - Last Modified: 11 Feb 2009 - Version: 24 + Last Modified: 13 Feb 2009 + Version: 25 This is a draft document. This document describes the command line interface. It has changed extensively from previous versions of Perl in order to increase @@ -67,7 +67,7 @@ and performs the requested actions. It looks something like Fbin/perl6>, F, or F, and is followed by zero or more I. Perl 6 does not do any processing of the I portion of the command -line, but it is made available at run-time in the read-only C<$? PROGRAM> +line, but it is made available at run-time via the C<< PROCESS::< $PROGRAM_NAME> >> variable. Command line I are broken down into I and I.
Re: r25325 - docs/Perl6/Spec
On Feb 13, 2009, at 11:50 PM, Larry Wall wrote: On Fri, Feb 13, 2009 at 11:34:03PM -0600, Chris Dolan wrote: Argh! I submitted a patch implementing $?PROGRAM in Rakudo literally 5 minutes before you sent this... http://rt.perl.org/rt3/Ticket/Display.html?id=63228 Indeed, why do you think I fixed the spec? :) But don't worry, we tend to do thing on the basis of forgiveness rather than permission, so I'm glad you did that or I wouldn't have noticed the $?PROGRAM problem. (The reason it can't be $?PROGRAM is that the name of the eventual executable program can't necessarily be known at compile time, which $? implies. $? variables have to be constants known at compile time.) Larry Aha! Thanks for clarifying that. However, now S19 and S02-magicals/progname.t disagree on whether PROCESS::<$PROGRAM_NAME> means $^X='/usr/bin/perl' or $0='foo.pl'. S02 suggests $*PERL is $^X. Maybe PROCESS::<$PERL_EXECUTABLE> for $^X? Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote: On Thu, 19 Feb 2009, Larry Wall wrote: Well, leaving that rant aside, I'm still tempted to say that times in Perl 6 are TAI seconds since 2000. Standard TAI would work too. I've wondered sometimes about the idea of having a dual/moving epoch. By this, I mean that you have eg. two Ints, one which represents the years since 1AD or whatever, and the other of which represents the number of seconds from the beginning of that year. I'm sure many of you can see the advantages and disadvantages of that scheme better than I can, but I thought I'd throw it out there so you can all see whether or not you like it. I don't see the advantage of either of those. TAI 2000 is just UTC 1970 plus a constant offset. 1AD is just UTC 1970 minus a bigger constant offset. Sure, those are slightly easier epochs for a human (ignoring the Julian/Gregorian shift), but not any easier for a computer. UTC 1970 has the big advantage that it is already the underlying value returned by most operating systems and many date/ time libraries, so there's no extra additive operation to perform if that's what you want. A much more important issue is the use of integer seconds. Milliseconds is a much more useful precision for humans and micro- or nanoseconds is a better precision for machines. I think Time::HiRes with a better API as a builtin would be a big win. Aside: I just learned the other day that Java's Thread.sleep(long millis, int nanos) method just rounds the nanos to the nearest millis and invokes Thread.sleep(long millis). I guess that's a forward looking API for when the OS really can timeslice that small, but it's a little silly today. http://krugle.org/kse/entfiles/jdk/sun.com/jdk-1.5/j2se/src/share/ classes/java/lang/Thread.java#246 Maybe Perl 6 should be really forward looking and include a time dilation factor so it can be the first language designed from the ground up for interstellar travelers who want to use a non-inertial reference. Or GPS? :-) Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
> Considering time scales, there are three that significantly > interrelate, and no matter what Perl 6 uses internally, it needs to be > able to convert to and from these: > > TAI: continuous count of time using SI seconds as measured by atomic > clocks, 60 seconds in every minute, 60 minutes in every hour, 24 hours > in every day. > > UTC: TAI with an offset, as corrected for the actual revolution of the > Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 > minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in > every day (86399, 86400, or 86401 seconds). > > time_t: the value you get by taking the UTC time since Jan 1, 1970 at > midnight and converting to a simple count of seconds, pretending there > have been no leap seconds along the way. > > Right now as I type this it is 17:13:38 UTC. That's 17:14:12 in TAI > (which is 34 seconds ahead of UTC until the next leap second). The > corresponding time_t value is 1,235,150,018, but there have actually > been 1,235,150,042 seconds since the UNIX epoch. Yes, just as I said: a constant offset between each of the proposed epochs. But my point remains: from the user's point of view it doesn't matter which epoch you choose to use behind the scenes, so you might as well pick the one that's easiest on the software (time_t) and leave the transformations to the libraries. Chris
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Feb 22, 2009, at 12:39 AM, Brandon S. Allbery KF8NH wrote: On 2009 Feb 20, at 14:36, Chris Dolan wrote: UTC: TAI with an offset, as corrected for the actual revolution of the Earth: usually 60 seconds in a minute, but occasionally 59 or 61. 60 minutes in every hour (so 3599, 3600, or 3601 seconds), 24 hours in every day (86399, 86400, or 86401 seconds). Yes, just as I said: a constant offset between each of the proposed Read again; a leap second was added at the end of last year, that's not exactly "constant". You missed the trivial point I was trying to make: the number of seconds between January 1, 1970 UTC (aka time_t epoch) and January 1, 2000 TAI *epochs* is a constant. I did not claim that the time systems differed by a constant. An epoch is an instant in time from which other times are measured, so you can measure UTC time flowing from a TAI epoch and vice versa. Astronomers do this all the time to avoid the complexity that the Earth's rotation precesses, so the time to orbit the Sun once it not exactly the same as a solar year. Astrometric coordinates are thus claimed relative to an epoch, say B1950 or J2000, and can be easily transformed between epochs. Nevertheless, Larry has closed the issue declaring that Perl 6 will use TAI, and I'm cool with that. With just 30-odd lossy exceptions in the last 40 years, we can translate between TAI and time_t as needed. When the OSes catch up and stop using time_t, it will be a glorious day. ... unless we decide to use Stardates instead. Floating point time would be cooler. :-) Chris
$*DEFOUT vs. $*OUT
Smack me down if this has already been discussed to death, please... S16 (and now S28) say that $*DEFOUT, $*DEFIN and $*DEFERR are what most programs should use instead of $*OUT, $*IN and $*ERR. That seems anti-huffman to me, and I'll bet many programmers will use $*OUT when they should be using $*DEFOUT because the former is shorter and more obvious. Perhaps instead the default handles should be $*OUT, $*IN and $*ERR while the standard handles should be $*STDOUT, $*STDIN and $*STDERR? Chris
Re: Comparing inexact values (was "Re: Temporal changes")
On Feb 23, 2009, at 11:16 PM, Larry Wall wrote:
if $x ~~ $y ± $epsilon {...}
where infix:<±> turns the single value into a range for the
smartmatch.
That's very cool. However, my first impression is that "$y ±
$epsilon" maps more naturally to "any($y-$epsilon, $y+$epsilon)" than
to a range.
Chris
Re: $?OS change
On Mar 2, 2009, at 12:04 AM, Timothy S. Nelson wrote: Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $* counterparts). I'd like to recommend that we eliminate $?OS, and replace it with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts? I disagree. User-space code cares much more deeply about the operating system than the kernel, largely thanks to libc or the equivalent. For example, BSD systems can be built on a number of different kernels. Mac OS X is in principle FreeBSD on Mach, but there are a huge number differences from "plain" FreeBSD that have nothing to do with Mach. Instead, it would be even more useful to represent $?OS.family, $? OS.version.major, $?OS.version.minor, etc. Linux distros often support switching kernel versions out from under the OS. % uname -mprsv Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 i386 Chris
Re: Dallas.p6m
On Mar 19, 2009, at 2:35 PM, Andy Lester wrote: I love love LOVE starting to get people together to talk about Perl 6. It's a crucial step in letting people know that Perl 6 is real. However, starting social groups that say they are specifically about Perl 6 makes me uncomfortable. I think it would be better to call it Dallas.pm and just talk about Perl 6 in the meeting announcements. The key is that we don't want people to think they must choose one or the other. Technologically, Perl 5 and Perl 6 are very different, but culturally, they're very similar. Keeping Perl 5 and Perl 6 groups together also means that we will increase cross-pollination of Perl 6 onto the Perl 5 people. At Madison.pm, I give a 5-minute Perl 6 update each month. It's easy to collect material because Rakudo and Parrot each release monthly, so I can always just rehash the release announcements. I've found that the Perl 5 users are quite interested (and occasionally amazed). Chris
Re: Module naming conventions
On Jun 2, 2009, at 5:11 PM, Daniel Carrera wrote: John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel. Speaking as an almost complete outsider (I'm a bioperl core dev writing up a perl6 port), I find the tone of several of these more recent posts (re: CPAN6 and module conventions) counterproductive. TimToady recently posted about snippiness and 'tensegrity', so I'm not the only one sensing it. chris
Re: Counting characters
Would you want to use something else for that, maybe .comb? From the spec: 'The comb function looks through a string for the interesting bits, ignoring the parts that don't match. In other words, it's a version of split where you specify what you want, not what you don't want.' chris On Jan 27, 2010, at 7:08 AM, Mark J. Reed wrote: > What does trans return in numeric (+) context? > > On Wednesday, January 27, 2010, Carl Mäsak wrote: >> How is "character counting" done in Perl 6? >> >> In Perl 5, it is `scalar tr/CG//` if I want to count the number of Cs >> plus the number of Gs in a string. >> >> S05 describes tr/// in terms of the .trans function, a handsome but >> very different beast. Specifically, it doesn't seem to have a "scalar >> context", with which one could count things. >> > > -- > Mark J. Reed
suggested properties of operator results
Currently, this expression:
VALUE1 < VALUE2
is functionally equivalent to this:
$v2 = VALUE2;
$v1 = VALUE1;
return ($v2-$v1 == abs($v2-$v1));
After reading the Apocalypse & Exegesis articles, and seeing some examples
of properties and the "is" operator, I'd like to suggest that the
less-then operator be changed, so it is functionally equivalent to:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which (assuming the operator's association was changed to "left") would
cause the following code to mean what beginning programmers always think it
should mean:
if ($foo < $bar < $baz) { ... }
It should be obvious how "> <= >= lt gt le ge" can similarly
be modified. Then even this would make sense...
if ($foo <= $bar > $yak lt $wak) { ... }
"== != eq ne" could be similarly modified (with the addition of a valueL
property to deal with precedence) but I haven't convinced myself it's a
good idea -- too many people like using == in place of xor...
if (($foo < $bar) == ($yak < wak)) { ... }
(I haven't even begun to consider <=> and cmp, but I'm sure there's
someone smarter then me out there with an idea on how/why they could
be modified as well (if for no other reason then to make obfuscated perl
contests even more interesting))
--
-------
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Re: suggested properties of operator results
For the record, bwarnock pointed out to me that damian allready proposed
this behavior in RFC 25...
http://dev.perl.org/rfc/25.html
That RFC doesn't suggest having the comparison operators set properties
on their result -- instead it recomends that "multiple chained comparisons
should be automagically expanded to the equivalent binary conjunction."
... I think I like his way better. Mainly because I didn't consider the
ramifications of scenerios like this...
$input = 4;
$bool = $input < 22;# $bool = 1 is valueR(22)
print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR
But as long as we're on the subject, dstorrs raises some good issues on
"should we do it at all"...
: someone (was it tchrist?) pointed out, beginners don't stay beginners for
: long, so writing a language for beginners may cost you people when they
: "grow out of" your language. I don't this we should do this just because
I agree with that sentiment, but I don't think it applies in this case.
We're not talking about a feature that will be usefull for beginers, and
a hinderence to experienced users who move on to to another language
because being able to write "1 < $val <10" is making more work for them.
: 2) This feature would be very prone to abuse (makes it easier to
: obfuscate code), but that isn't a reason to disqualify something either.
I disagree, I think that this...
if (1 <= $x <= 10 and 1 <= $y <= 10) { # inside grid?
is much less obfuscated then this...
if (1 <= $x and $x <= 10 and 1 <= $y and $y <= 10) { # inside grid?
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
(proto)typing, return types, polymorphism, ... ?
A few questions regarding typing. (first some assumptions/axioms)
Axiom #1: perl6 will enable programs to be more explicit about the typing
of variables -- even allowing them to specify dynamic-ish properties about
the values in those variables.
Damian's Attribute::Types has examples like this...
my %handler : CODE; # Entries can only store sub refs
my $arr : ARRAY; # Can only store array ref
my $score : NUMBER(0.1..9.9); # Can only store a num between 0.1..9.9
my $guarded : Type(&odd);# Can only store values for which
# odd($value) returns true
while Exegesis 2 has examples whose syntax is probably a little closer to
what will finally be in perl6...
my int ($pre, $in, $post) is constant = (0..2);
Axiom #2: perl6 will allow more more robust subroutine prototyping for
compile time / run time type checking.
>From Exegesis 2...
sub insert (HASH $tree is rw, int $val) { ... }
sub search (HASH $tree is rw, *@_) { ...; return $tree }
(which will presumably cause a fatal error if called as insert(1,"foo")
Quandary #1: How "deep" of type specifications should / will perl6 allow?
For example, could something like this work?
my ARRAY(int(0..9)) $ref # $ref can only store an array ref
# ...and that array can only hold ints
# ...and those ints must be between 0 & 9
Quandary #2: Should / will subroutine prototyping provide any support
for specifying the return type? perhaps...
sub search (HASH $tree is rw, *@_) HASH { ...; return $tree }
If so, this opens up all sorts of questions ... the influence of
calling context (ie: "wantarray") comes to mind.
Quandary #3: Should / will perl6 support polymorphic typing? In the past,
it really hasn't mattered -- but as perl begins to support stricter typing
(if you want it) people may find themselves having to choose between
strongly typing their subroutines to make their code more explicit to
callers, or excluding typing info to make them useful in more situations.
All of these quandary's occurred to me as I started to wonder how you could
write a reusable Tree class whose insert/search/delete methods could be
prototyped to require an argument of the type specified when the Tree
was constructed. (without requiring the class to do it's own type
checking)
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Apoc4: Block scoping
Does the alias operator, C<< -> >>, work for C blocks too?
if $a * $b / $c + $d -> $abcd { ... }
Where $abcd would be lexically scoped to the if block and else block,
if defined. I expect it could be used with any block statement,
since Apoc 4 demonstrates it with for, grep, loop, and given.
Thanks,
cd
Re: Loop controls
On Tuesday, April 30, 2002, at 01:22 PM, Dan Sugalski wrote:
> At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote:
>> > Damian, now having terrible visions of someone suggesting
>> C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep,
>> elstry ...
>
> Has anyone brought up elselse or unlessunless yet?
All of this is a bit silly, but if loops in Perl6 had some sort of
boolean value of their own, then it seems the language already has a way
to approach this. Scoping might be a problem, but...
for @foo -> $bar {
...
} // print "The loop didn't... uh... loop.\n";
Just a thought.
Re: Accessor methods ?
On Thursday, May 9, 2002, at 03:16 PM, Aaron Sherman wrote:
> Then you can declare them as such:
>
> sub get_bar() { .bar }
> sub get_baz() { .baz }
> sub set_baz($newbaz) { .baz = $newbaz }
Seeing this, an idea mildly Eiffel-ish comes to mind. Could we get away
with something like the following?
method set_baz(type($.baz) $newbaz) { $.baz = $newbaz }
Which would force the new value to be of the same type as the current
value, without having to strongly declare the type of the variable
elsewhere. Sort of like, in Perl5...
sub set_baz {
my $self = shift;
if (@_) {
my $new_baz = shift;
$new_baz_type = ref($new_baz) || "SCALAR";
$current_baz_type = ref($self->{baz}) || "SCALAR";
$self->{baz} = new_baz if $new_baz_type eq $current_baz_type;
}
return $self->{baz};
}
or in Eiffel...
set_baz(new_baz: like baz) is
do
baz := new_baz
end
Re: Accessor methods ?
On Friday, May 10, 2002, at 09:54 PM, Damian Conway wrote:
> That's getting a little ugly, so maybe we'd "lift" the syntax from
> Eiffel instead:
>
> method set_baz($newbaz is like($.baz)) { $.baz = $newbaz }
This is exactly what went through my mind about a half second after I
posted the message.
$newbaz is like($.baz), I would think, would have to raise a run-time
exception if $newbaz isn't "like" $.baz. Where would the exception be
handled, though? Inside the method/subroutine, or outside of its scope?
Selective exporting of properties/methods
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes. For instance(as I understand
Perl6 syntax):
class Foo {
method hello is public {
return "hello";
}
method world is public_to(Bar) {
# is only public to objects of class Bar
return "world";
}
}
class Bar {
method say_hello {
# this works fine
print Foo.new.hello, "\n";
}
method say_world {
# as does this
print Foo.new.world, "\n";
}
}
class Baz {
method say_world {
# generates a run-time exception for trying to call a private method.
print Foo.new.world, "\n";
}
}
Re: Selective exporting of properties/methods
On Sunday, May 12, 2002, at 02:18 PM, Miko O'Sullivan wrote:
>> While thinking Eiffel-ish thoughts the other day, I began to wonder if
>> Perl6's classes could go beyond the simple private/public/protected
>> scheme by optionally allowing for a property or method to only be
>> accessed by a certain set of classes.
>
> Many times when I've used OO languages I've wished for something like
> this.
> What I've often wanted would be standard method that is called before
> every
> subroutine call. If that method returns false then the method that was
> called is not called.
I think maybe what you're looking for is another Eiffel/Sather-ism. I
know Eiffel at least has both pre and post-conditions that look
something like this(it's been a while, so if this isn't quite right):
class
ACCOUNT
creation
make_with_balance
feature { BANK }
balance: INTEGER
make_with_balance(initial_balance: INTEGER) is
require
initial_balance >= 0
do
balance := initial_balance
ensure
balance >= 0
end
end
I too have thought this might be useful in Perl6. Perhaps...
class Account {
my INT $balance;
method new(INT $initial_balance //= 0) {
REQUIRE { $initial_balance >= 0; }
$.balance = $initial_balance;
ENSURE { $.balance >= 0; }
}
}
Re: Selective exporting of properties/methods
On Wednesday, May 15, 2002, at 10:17 AM, Aaron Sherman wrote:
> On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
>
>> method world is public_to(Bar) {
>
> Might as well make that:
>
> method world is private(Bar)
>
> I tend to take any opportunity to recycle syntax, plus keywords with
> underscores give me gas. ;)
I had considered "is public(Bar)", but this works too.
Idea
Everyone,
Please correct me if I am emailing the wrong address/list. Thanks.
I have an idea for the int() function. I think it would be cool if it
returned false/undefined when the argument passed to it is a whole number.
For example:
int(1) or print "argument passed to int() is something other than a
decimal number";
A friend came up with this:
sub myint { return if $_[0] =~ /\A\d+\z/; $_[0] =~ /^(\d+)/ ? $1 : 0 }
What do you guys think?
Thanks,
Chris Angell
A Perl 6 class question
Since Adam Lopesto asked a non-regex question, I don't feel quite as out
of place for doing the same.
This one actually came to me just the other night. Would it be possible
in Perl 6 to create "anonymous classes"? Something like:
my $foo_class = class {
method new {
# yada yada yada
}
}
my $foo_obj = $foo_class.new;
Re: A Perl 6 class question
On Saturday, August 10, 2002, at 06:25 PM, Piers Cawley wrote:
> Chris Dutton <[EMAIL PROTECTED]> writes:
>
>> Since Adam Lopesto asked a non-regex question, I don't feel quite as
>> out of place for doing the same.
>>
>> This one actually came to me just the other night. Would it be
>> possible in Perl 6 to create "anonymous classes"? Something like:
>>
>> my $foo_class = class {
>> method new {
>> # yada yada yada
>> }
>> }
>>
>> my $foo_obj = $foo_class.new;
>
> I hope so.
The only problem I could see, and I wanted to wait for at least one
other opinion before mentioning this, is rewriting the above as:
my $foo_class $foo_obj = $foo_class.new;
Still I can see this as occasionally being useful for having instance
variables which can effectively be initialized, but afterwards are
constant. Then again, there's probably another, more graceful way to do
this using the new method and properties.
sub foo(int $bar //= 0) {
return class {
int $.baz is constant = $bar;
method out(int $multiply_by //= 1) {
print $.baz * $multiply_by, "\n";
}
}
}
foo(5).new.out(2); # 10
foo(6).new.out(3); # 18
Re: A Perl 6 class question
On Monday, August 12, 2002, at 01:27 PM, Allison Randal wrote:
> On Sat, Aug 10, 2002 at 07:30:19PM -0400, Chris Dutton wrote:
>>
>> The only problem I could see, and I wanted to wait for at least one
>> other opinion before mentioning this, is rewriting the above as:
>>
>> my $foo_class $foo_obj = $foo_class.new;
>
> I'm not exactly sure what you're trying to do with this.
Sort of like:
class A { ... }
my A $a = A.new;
Where A is $foo_class. Probably not terribly useful, but I just
wondered if it'd work anyway.
> You can create
> an object within the same statement as you define the class:
>
> my $foo_obj = class {
> method new {
> # yada yada yada
> }
> }.new;
I figured that would work, but wasn't entirely sure. Thanks.
>> sub foo(int $bar //= 0) {
>> return class {
>> int $.baz is constant = $bar;
>> method out(int $multiply_by //= 1) {
>> print $.baz * $multiply_by, "\n";
>> }
>> }
>> }
>>
>> foo(5).new.out(2); # 10
>> foo(6).new.out(3); # 18
>
> As it stands, you're not gaining anything over:
>
> sub foo(int $bar //= 0, int $multiply_by //= 1) {
> print $bar * $multiply_by, "\n";
> }
>
> foo(5,2);
Granted, it was a trivial example. :-)
> attr int $.baz is constant = $bar;
I like it.
>> foo(5).new.out(2); # 10
>
> I suspect this will be allowable syntax. But if you find yourself using
> it you might want to re-think the code. Creating a class and an object
> for single use isn't tremendously efficient. Then again, you may be
> golfing. :)
Hmmm could I have instead written the following and ended up with
both a lexically scoped anonymous class($fc), and an instance($fo)?
( my $fo = ( my $fc = foo(5) ).new ).out;
One thing is obvious... it's been way too long since I read the various
Exegesis documents.
Just reading up on Pike...
and this just jumped out at me:
class Foo {
private string|int bar;
static create(string|int newBar) {
bar = newBar;
}
}
In other words, as I understand it, you can type the variable bar as
either an int or a string.
Aside from simply, "my $bar;", will we be able to repeat this behavior
in Perl6 programs?
Let me guess, though, this is one of those instances where I should have
read A1..5 and E1..4 more closely. :-)
Ok, Pike is... (was: Perl 6 Summary for week ending 2002-08-18)
Explained far more throughly at http://pike.ida.liu.se/ than I can in an e-mail. It really looks like an intriguing language, with a (supposedly) very fast runtime, (again, supposedly) beating Perl, Python, Tcl, and Java in execution times. Unfortunately I've been unable to get it to compile anything successfully after building the compiler, due to an error regarding a file (master.pike) that doesn't appear to even be in the source distribution.
A few thoughts on inheritance
We are supposedly going to be able to set a class to be "uninheritable". Will we be able to set a single method or attribute to be uniherited by any subclasses? Please forgive me if this is one of the seven deadly OO sins. I haven't yet had any formal education with regards to programming(aside from a short intro class using Fortran, but I've almost completely repressed those memories). Also, I think this might have been discussed and I just didn't catch the answer, but can a method be declared in such a way that no subclass may redefine it? In cases of multiple inheritance, will we be able to specifically say "don't inherit method 'z' from class C, where the inheritance looks like the following: A / \ / B - redefine method "z" / \ C D \ / \ / \ / E So instead, class E inherits method "z" from class D, which inherits it from class B, rather than getting the original from class A via class C. I'm a little bit afraid that trying to do inheritance as it at least *looks* right now will limit the flexibility of it. I'm not sure how this psuedo-code to accomplish the above would translate into Perl6. class E inherit C except z end # or... # inherit C #rename z as C_z # end inherit D end
Re: Interfaces
On Monday, September 30, 2002, at 11:19 PM, Michael G Schwern wrote: > On Mon, Sep 30, 2002 at 06:04:28PM -0700, David Whipp wrote: >> On a slightly different note, if we have interfaces then I'd really >> like to follow the Eiffel model: features such as renaming methods >> in the derived class may seem a bit strange; but they can be useful >> if you have have name-conflicts with multiple inheritance. > > I'm not familiar with the Eiffel beyond "it's the DBC language and it's > French", but wouldn't this simply be covered by aliasing? Eiffel can either rename a "feature"(method, attribute), which is pretty much the same as aliasing as you might see it in Ruby, or you can redefine the method entirely. Again, you also would see this in Ruby, which might be more approachable for those familiar with Perl. class BAR inherit FOO rename output as old_output end end or... class BAR inherit FOO redefine output end end
Re: Private contracts?
On Thursday, October 3, 2002, at 05:19 PM, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: >> With pre/post conditions, a subclass is allowed to weaken the >> preconditions or strengthen the postconditions. > > How exactly does one "weaken" a precondition? At least in Eiffel, if you redefine a method, you may not give it stringer preconditions than the original method, but you may have stronger postconditions. In essence, you're not requiring any more of the client, but you can ensure more to them on completion, thus maintaining the parent's contract.
Re: Private contracts?
On Friday, October 4, 2002, at 06:23 PM, [EMAIL PROTECTED] wrote: > On Fri, Oct 04, 2002 at 09:13:45AM -0400, Chris Dutton wrote: >>> How exactly does one "weaken" a precondition? >> >> At least in Eiffel, if you redefine a method, you may not give it >> stringer preconditions than the original method, but you may have >> stronger postconditions. In essence, you're not requiring any more of >> the client, but you can ensure more to them on completion, thus >> maintaining the parent's contract. > > But what does it mean to be "stronger"? How does Eiffel figure out if > a given precondition is "stronger" or "weaker" than another? Perhaps an example is the best way to demonstrate this: class FOO creation make feature make(input: SOME_OTHER_CLASS) is require input /= Void do -- something here ensure input /= Void end end -- Good: class BAR inherit FOO redefine make end creation make feature make(input: SOME_OTHER_CLASS) is -- no requirements, weaker precondition do -- yada yada ensure input /= Void old input.some_attribute /= input.some_attribute -- stronger postcondition is ok. end end -- Bad: class BAR inherit FOO redefine make end creation make feature make(input: SOME_OTHER_CLASS) is require input /= Void input.some_attribute = 1 -- requiring more than the parent's make procedure is bad. do -- yada yada -- Not ensuring anything to the client is bad. -- The parent honored that in its contract, so -- the child must also. end end
Re: Draft Proposal: Attributes: "public" vs. "private"
On Sunday, October 6, 2002, at 12:57 AM, Noah White wrote:
>>
>>> Note that an alternate definition of "private" is often used, as
>>> follows:
>>>
>>> A "private" attribute is an attribute whose scope is restricted
>>> such that
>>> it may be accessed only within the class in which it has been
>>> declared,
>>> OR WITHIN ANY CLASS THAT INHERITS FROM THAT CLASS.
>>
>> I'll agree with that.
>>
>
> ACK! After re-reading this I about puked. No, that notion of private
> would not be something I'd agree with :-) That's more like protected.
As I think I've mentioned once before, and will again as Eiffel's been
mentioned recently...
Is there any chance Perl6 could simply avoid the can of worms that is
public/private/protected and have a single accessibility property? It
would seem to clean the debate up handily, and provides even greater
flexibility for programmers. Along the lines of:
class Foo {
attr $.bar is accessible(Bar, Baz);
# Makes $.bar attribute accessible only to the Bar and Baz classes.
attr $.baz is accessible(Foo);
# Protected
attr $.hello is accessible(None);
# explicitly Private
attr $.world is accessible(Any);
# Public
}
Of course, if Perl6 went down this road, Ruby-ish read, write, or
read/write attributes would also be nice. I might want to let another
class read an attribute, but not write to it, while I might for some
reason want another class to be able to write to an attribute, but not
read it. But maybe I'm just weird that way. :-)
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
One first thing I notice while I'm supposed to be doing homework. :-) Wasn't "class MyClass;" supposed to work along the line of Perl5's "package MyClass;" and make everything following that statement the definition of MyClass?
Re: Fw: perl6 operator precedence table
On Wednesday, October 9, 2002, at 05:03 PM, Trey Harris wrote: > In a message dated Wed, 9 Oct 2002, Michael Lazzaro writes: > >> >> Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs >> that were caused by a single mistyped character. Now I'll be spending >> days hunting obscure bugs that were caused by a single *pixel*. >> > > I've already been there, my friend. :-) MacOS X's pretty anti-aliased > fonts make it impossible to tell the difference between colon and > semi-colon at small type sizes. It didn't used to matter, but now it > really does. I have a hot key to make my terminal's font bigger > whenever > I'm reading perl6 mail. :-) Andale Mono is all fun and games until someone loses half an hour of their life to: int x, y, z: char ch; :-)
Re: Private contracts?
On Saturday, October 12, 2002, at 01:10 PM, Luke Palmer wrote:
>> Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
>> From: Larry Wall <[EMAIL PROTECTED]>
>>
>> If we use | and & as sugar for any() and all(), then their precedence
>> should probably be the same as || and &&.
>
> Should they? I had in mind something just above comparisons. That
> way:
>
> if $x == 3 || $y == 4 {...}
>
> and
>
> if $x == 1 | 2 { ... }
>
> both DWIM. Is there a case for not doing this?
Just a thought, but don't we already have this with the "smart match"
operator?
if $x =~ (1, 2) { ... }
Or would & and | be a bit more strict in use, and thus easier for the
compiler to optimize? For instance, would we be able to:
if $x == 1 | "hello" { ... }
or would both operands have to be of the same type?
Re: perl6 operator precedence table
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except that it would get new type information if the type of $string is
changed at some point. Might be useful for generic classes.
class LimitedStack {
attr @.array;
my $init;
method new($first, *@others are like $first) {
$init = $first;
@.array.push($first, *@others);
}
method push(*@items are like $init) { ... }
method pop { ... }
}
Also, this brings to mind the one thing I actually remember about
Sather, and as long as we're discussing operators...
Will we have similar to Sather's "::="? That was essentially the
"statically type this variable at run-time based on the type of it's
initial value" operator.
Re: Perl6 Operator List
So many operators... It's now clear what we need. Unicode operators. That should buy us at least another week to hash out the rest of the necessary operators. ;-) It'd also silence the legions of critics who complain about Perl being too easy to read if we, for instance, used the Kanji character for watashi in place of $self, and the character(s) for anata for the default topic.
Re: plaintive whine about 'for' syntax
On Thursday, October 31, 2002, at 10:03 PM, John Siracusa wrote:
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
but why ? I am just curious about details.
Yeah, I'd like to hear those details too, because the alternate syntax:
1) for @a -> $x ; @b -> $y { ... }
sure looks a lot more attractive and sensible to me, and I agree with
all
the arguments in favor of it so far. In particular:
* No "look here, then look there" connection between (possibly) widely
separated items.
* Simple to add or remove/comment-out individual stream/item(s) pairs
without having to "count" what are essentially positional parameters to
make
sure you haven't mis-mapped anything in the process.
* More familiar use of the semicolon (IMO)
The current syntax offers a significant advantage, though. I'm assuming
parser knows to look for equal numbers of things on both sides of
the ->. If we go with the proposed alternate syntax, won't we run into
the problem where it sees:
for @a -> $a; as a complete postfix for loop that just happens to do
nothing?
I suppose the same could be said for the existing syntax. "for @a;"
would look like a loop with the default topic variable. Maybe I'm just
wrong, but the proposed syntax seems to introduce ambiguity by breaking
the for loop up a bit too much, while the current use of the "->" and
semicolons holds the whole thing together.
As for maintaining the sanctity of the semicolon, I would offer that
consistency of the arrow operator is more important.
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote: Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members? How about something like what Ruby's irb does? % irb irb(main):001:0> class Foo irb(main):002:1>def initialize irb(main):003:2> @a, @b, @c = 1, 2, 3 irb(main):004:2>end irb(main):005:1> end nil irb(main):006:0> Foo.new # irb(main):007:0>
Re: Everything is an object.
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I realize the problem of namespace pollution involved in
having a bunch of builtins called grep, map, whatever.
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can still
be called in a fashion similar to [1]. That would, I suspect, satisfy
everyone.
Well, if the source file were considered to be just a big giant class,
sans
class main {
...
}
then it becomes as simple as having a method in Object, grep, something
like:
class Object {
method grep($a_closure, *@input) {
...
}
}
Pike 7.4
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Automap
To perform per-element operations on arrays, there is now a convenience
syntax for map(), that can make code more readable in some situations.
Summing up two arrays element by element using automap looks like this:
a[*] + b[*]; // the result has as many elements as the shortest array.
Multiplying all elements in a by a constant:
a[*] * 4711;
Make an array of what sprintf("%O", a[n]) returns for all elements in a:
sprintf("%O", a[*]);
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: Murat Ünalan wrote: print "date" if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print "date" if $var == any(1 .. 31); I was under the impression the "smart match" operator would cover that implicitly. print "date" if $var =~ 1..31; Has this changed somewhere without my noticing it? Hmmm... thinking about another form of the above, I wonder... is there a postfix version of "given"? print "date" if 1..31 given $var;
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: print "date" if 1..31 given $var; Except that this would always be true. Nevermind, I'm an idiot.
Re: Pike 7.4
On Tuesday, January 7, 2003, at 11:20 PM, Damian Conway wrote:
Chris Dutton wrote:
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that vectorized operators give more
flexibility.
For example, I'm struggling to see how one could use the [*] to do this:
@names = «Gödel Escher Bach»;
@ages = $today »-« %date_of_birth{@names}
While I agree that hyper-operators are the better way to go(though I can
see advantages either way), I was bored, so I tried to figure out a not
entirely unpleasant Perl6-ish version of the Pike syntax.
@ages[*] = $today - %date_of_birth{@names}.values[*]
Re: Array Questions
On Wednesday, January 8, 2003, at 01:32 PM, Michael Lazzaro wrote:
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve C-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Sorry, but I gotta ask. :-)
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Re: Pike 7.4
On Thursday, January 9, 2003, at 05:36 AM, Damian Conway wrote:
Chris Dutton wrote:
@ages[*] = $today - %date_of_birth{@names}.values[*]
Well done. Thanks for working that out, Chris. And, in the process,
confirming my sense that vector ops are a better solution here.
;-)
Glad I could contribute in some small way.
a thought on multiple properties
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method bar is public is rw {
}
}
Becoming:
class Foo {
method bar is public & rw {
}
}
Guess it just reads a bit better to me.
And you might even be able to do some weird stuff like:
class Foo {
method bar is public | rw {
}
}
Whereby bar is only an lvalue subroutine/method internally.
Re: a thought on multiple properties
On Thursday, March 13, 2003, at 02:13 PM, Jonathan Scott Duff wrote:
I don't think that junctions make sense here. Besides, the "is" is
optional:
class Foo {
method bar is public rw const frob knob { ... }
}
Ah yes, I'd forgotten about this. Thanks. Still I wonder a bit about
the idea of mutually exclusive properties, where one can take effect if
the other(s) doesn't make sense in the current context.
Getting mired in life can really detract from following the developments
in this community.
Re: A6 questions
On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
==QUESTION
- Page 8 says "In some languages, all methods are multimethods." I
believe that Java is one of these. Is that right and what are some
others? (This is really just curiousity.)
==/
Doesn't C++ work this way? Also I believe Pike allows overloading of
methods by default.
==QUESTION
- Given the following code, what is called by $ride.current_speed()?
class Vehicle {
my $speed;
method current_speed() { return $speed; }
method set_speed($n) { $speed = $n; }
}
class Car {
submethod current_speed() {
print SUPER.current_speed();
return SUPER.current_speed();
}
}
class A6 { }
my $ride = new A6;# Perl with German engineering???
$ride.set_speed(60); # Calls Vehicle.set_speed()
print $ride.current_speed(); # Calls what?
Unless this is more complicated than I think, Car's current_speed() is
called.
That said, a minor nitpick is that you'd want something more like
class Vehicle { ... }
class Car is Vehicle { ... }
class A6 is Car { ... }
Re: Suggested magic for "a" .. "b"
On Jul 28, 2010, at 1:37 PM, Mark J. Reed wrote: > On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields wrote: >> On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote: >>> Can I get an Amen? Amen! >>> -- >>> Mark J. Reed >> >> +1. I'm agnostic ;> > > Militant? :) ( http://tinyurl.com/3xjgxnl ) > > Nothing inherently religious about "amen" (or me), but I'll accept > "+1" as synonymous. :) > > -- > Mark J. Reed Not militant, just trying to inject a bit of humor into the zombie thread that won't die. chris
Re: Suggested magic for "a" .. "b"
On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote: > On Wednesday, July 28, 2010, Jon Lang wrote: >> Keep it simple, folks! There are enough corner cases in Perl 6 as >> things stand; we don't need to be introducing more of them if we can >> help it. > > Can I get an Amen? Amen! > -- > Mark J. Reed +1. I'm agnostic ;> chris
Persuasive Business Writing Workshop, SZ & SH,Oct 2016 (by John Sturtevant, Former Harvard Business School Lecturer)
Hi There, Good Afternoon! SIS Conference is delighted to invite Mr. John Sturtevant, experienced business writer and trainer, who taught business writing courses at Harvard Business School (HBS) to address the below persuasive writing skills workshop in China. This workshop is an advanced level program designed for anyone who frequently write business emails/proposals/memos in English. Through case studies, hands-on exercises & guided assignments, you will learn to think analytically and communicate your ideas persuasively. Persuasive Business Writing Skills 说服力商业写作技巧 -- Learn To Think Clearly & Write What You Mean Shenzhen: 21 Oct, 2016 Friday 09:00 -17:00 Shanghai: 25 Oct, 2016 Tuesday 09:00 -17:00 Early-Bird Fee: RMB 3,880 / person ( by 16 Sept) Language: English Trainer: John Sturtevant (USA) John was a successful business writer for twenty years. He also taught writing courses at Harvard Business School & was Professor of Business Communications at The European School of Economics. What You Will Learn John Sturtevant's Persuasive Business Writing combines real-world business examples and interactive accelerated-learning techniques to give you practical, relevant skills • Apply analytical-thinking techniques to assess key issues and decision points • Define and identify audience perceptions and expectations • Create and structure logical, persuasive, and clearly organized documents • Recognize, consider, and effectively address opposing points of view • Assess and measure the effects of your writing through active listening Please download course brochure at below link for more details http://broadcast2.futuremail.com.au/lt.php?c=16722&m=27636&nl=5879&s=f2b1d5a97de0c426228bb525dbfab0c3&lid=199821&l=-http--www.sis-conf.com/uploads/soft/160829/1-160R9150914.pdf Yours Sincerely Chris Wang SiS Conference Consulting Tel: 86 21 51600280-800 Email: chris.w...@sis-conf.om _ SIS Conference operate a strict policy not to send unwanted emails to any of its past clients or prospective customers. We do not buy or sell email addresses and treat all customer details as being strictly confidential. You can contact remo...@sis-conf.com to unsubscribe or to report any misuse of your details
Roles and Mix-ins?
I'm still digesting the vocabulary thread, but while I do, let me ask a
question that's probably crystal clear to everyone else.
Do roles act as a form of mix-in, as Ruby modules may, and Objective-C
protocols do?
Would the following two snippets be at all equivalent?
# Perl6
role Talk {
method say_hello {
print "Hello world!\n"
}
}
class Foo does Talk { ... }
Foo.new.say_hello;
# Ruby
module Talk
def say_hello
puts "Hello world!"
end
end
class Foo
include Talk
end
Foo.new.say_hello
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 11/27/2003
