MMD handling (was Re: Hackathon notes)
First off, it seems like there are at least 3 topics being discussed
under the "Re: Hackathon notes" subject line. Could we break them
out into separate threads so that our poor summarizer doesn't go
bonkers?
On Jul 8, 2005, at 4:25 PM, Dave Whipp wrote:
Rod Adams wrote:
multi method foo#bar (Num x) {...}
multi method foo#fiz (String x) {...}
$y = 42;
$obj.foo#fiz($y); # even though $y looks like a Num
$obj.foo($z); # let MMD sort it out.
Instead of changing the parse rules for #, why not just use a trait?
multi method foo is short_name('bar') {...}
Having additional tags might also give us something to hang
priority traits off: "foo#bar is more_specific_than(foo#baz);"
might influence the order of clauses in the implicit given/when
block. It feels like there should be a generalization of operator
precidence here (even thought he two are superficially dis-similar,
the looser/tighter concept appears valid).
Although I like the idea of reusing this concept, I'm not sure that
it really solves the problem. Fundamentally, we're trying to make
MMD behave intuitively with no programmer effort.
--Dks
Re: MML dispatch
On Jul 13, 2005, at 1:12 PM, Larry Wall wrote: If class Dog does role Bark and also does role Wag, then passing a Dog to multi (Bark $x) multi (Wag $x) should result in ambiguity. My understanding is that a Role is an abstract (i.e. cannot be instantiated) blob of methods and, possibly, data. The purpose of a Role is to paste it into a class--in other words, a Role is a not a type, it is a part of a type. Assuming that that understanding is correct, then I would expect the above multi declarations to be a compile time error: 'multi (Wag $x)' means "expect some data, call it $x, which will be of type Wag"...but Wag isn't a type, it's a partial type. I would require that declaration to be written as one of the following: multi (Dog does Bark $x)# Dog is an actual type that can be instantiated multi (Animal does Bark $x)# Animal is an abstract base class multi (Object does Bark $x)# Object (or whatever the name is) is the root of the entire class/type hierarchy I could see stretching a point and allowing the last one to be rewritten as: multi (does Wag $x)# Still references root type, but implicitly The point of this is to force the programmer to give a reasonable constraint...when they expect something that Wags, does it need to be a Dog, or will any Animal that can Wag be sufficient? Or are they really looking for absolutely anything that is capable of Wagging? Doing it this way would (I think) be both more intuitive and would resolve a lot of the ambiguity that was discussed farther on. multi (does Bark $x) multi (Dog does Bark $x)# Dog is more specific than "any data type" ---new example multi (Tree does Bark $x) multi (Dog does Bark $x)# Equally specialized classes in separate parts of the hierarchy. If passed an "Object does Bark" param, this should be an error. ---new example multi (Labrador does Bark $x)# Labrador is a subclass of Dog and therefore more specific if passed a Labrador param multi (Dog does Bark $x) # This catches any other 'Dog' params multi (does Bark $x) # This catches anything else that Barks, including 'Dingo is Dog does not Bark' The interesting question is whether N should be 0 or 1 (or possibly epsilon). If we have multi (Bark $x) multi (Dog $x) arguably Dog is more specialized than Bark, [...] The problem with N == epsilon is in visualizing how Dog is more constrained than Bark. Assuming that the declaration of Dog is 'class Dog does Bark', then yes, I think Dog should be considered more specialized than Bark-- lots of things might Bark, but only a Dog will bark in precisely this way. Or, to put it a different way, a 'Dog' class has a certain specificity and a 'Bark' Role has a certain specificity: the combination of the two produces something more specific than either. (And, of course, 'Dog does Bark does Wag' (or 'Dog does Bark&Wag' if you prefer) is yet more specific.) --Dks
Re: MML dispatch
On Jul 13, 2005, at 4:35 PM, chromatic wrote:
On Wed, 2005-07-13 at 16:07 -0400, David Storrs wrote:
My understanding is that a Role is an abstract (i.e. cannot be
instantiated) blob of methods and, possibly, data. The purpose of a
Role is to paste it into a class--in other words, a Role is a not a
type, it is a part of a type.
Nope, it's a type. What is a type besides a named blob of methods
and,
possibly, data?
A label that says how the data is stored internally. For example,
compare "Int" and "int". The former is a type and a blob of methods
and not necessarily abstract. The second is a type, is NOT a blob of
methods, and is definitely NOT abstract.
That was part of why I was careful to say "an ***abstract [...]
blob of methods" (Emphasis added.)
The point of this is to force the programmer to give a reasonable
constraint...when they expect something that Wags, does it need to be
a Dog, or will any Animal that can Wag be sufficient? Or are they
really looking for absolutely anything that is capable of Wagging?
The latter.
Fine. Make them say that, then. Making people think about what they
really want is a good idea.
As soon as you require signatures to enforce *how* the arguments
fulfill
a type constraint, you've violated a principle design goal of roles,
namely that it's more important that something fulfills the
requirements
of type ("RobotDog understands bark() in the context of Doglike, not
Treelike") than that it fulfills the requirements of the type by
inheriting from a base class, delegating to a contained object,
applying
a role, or whatever other way you can imagine.
That's a reasonable point. However, I wasn't deliberately using
'does Bark' to mean 'has been composed with the role Bark'. I was
using it to mean "is able to perform the interface specified by
Bark". So, if you prefer, I'll invent a new term: isableto. (Which
I think is a lousy choice for the term, but I don't care what color
that bike shed is.)
Note that there are two subtly different kinds of type constraints
under discussion: the first is what class something is, and the
second is what behavior it can exhibit. The two are very slightly
different:
multi foo(Dog $x); # Must be of class
Dog, or a class that is a descendant of Dog
multi foo(Dog $x where { not $x.feral });# Must be of
anonymous class "class Dog (or descendant) with $.feral set to false"
multi foo(Dog isableto Bark);# Must be of class
Dog (or descendant), and must be able to Bark
multi foo(Object isableto Bark); # Absolutely any
object so long as it can Bark...how it does that is up for grabs,
though.
multi foo( isableto Bark); # Same as previous
The distinction I'm drawing is between pure behavior and behavior
+state. I'm drawing this based on the idea that Roles are not
allowed to have state--that they are pure virtuals, only used for
defining interface. If that is not true, then (A) I apologize for
the wasted bandwidth and (B) I'd like to have it explained what Roles
offer that justifies their existence, since they won't be anything
but a restricted form of a class.
--Dks
Re: MML dispatch
On Jul 13, 2005, at 6:16 PM, chromatic wrote:
On Wed, 2005-07-13 at 17:33 -0400, David Storrs wrote:
What is a type besides a named blob of methods
and, possibly, data?
A label that says how the data is stored internally. For example,
compare "Int" and "int". The former is a type and a blob of methods
and not necessarily abstract. The second is a type, is NOT a blob of
methods, and is definitely NOT abstract.
I contend that that's meaningless to Perl.
Um...huh? Sorry, I'm not trying to be sarcastic, but I honestly
don't understand how you can think that. There are things that you
can do with an Int that you cannot do with an int, so how can this be
a meaningless distinction? Or did I miss a decision saying that
'int' was just a request, and that 'int' data could freely be
autoboxed into an Int if necessary? That's quite possible...I
haven't reread the AESs in a long time and things change often enough
that I admit to not having a solid grip on the current state.
Why does the internal
representation of data matter if the interface is the same?
It shouldn't, I agree. My point was that the interface to Int (the
object) is not the same as the interface to int (the low-level
representation). For example, last I heard this was one of the
differences:
Int foo = 0 but true; # no problem
int foo = 0 but true; # problem! nowhere to store the trait
Making people think about what they really want is a good idea.
I agree, but only as far as what they really want is actually what
they
really want. To put it another way, if you have a method that prints
something passed in, do you want a signature that says "This must be a
string, perhaps with a specified encoding and internal representation"
or a signature that says "This must be something that stringifies"?
I want the latter.
Excellent, so do I. Our views are not that far apart after all.
The two are very slightly different:
multi foo(Dog $x); # Must be of class
Dog, or a class that is a descendant of Dog
No, I think it must conform to the type of Dog, whether it is an
instance of the Dog class, an instance of a subclass of Dog, or
something that performs the Dog role.
Ok, but you're begging the question. I'm trying to illustrate my
definition of the word "type"; it doesn't help for you to say 'it
must conform to the type...' when 'type' is what I'm trying to define.
In my mind, 'class' is one component that goes into making up a
type. So is 'where clause'. So is 'roles that have been composited
in'. Etc. A 'type', in my mind anyway, is a promise about the
interface and state (*) that something will provide. Here are some
examples (illustrative, not definitive):
int $a# 4 bytes (on a 32-bit system), can't store traits
Int $a# Can do everything 'int' can do, can also store traits
Int $a where { 0 < $a < 7 }# Can do everything Int can do
but value is between 0 and 7 exclusive
I would contend that that list contains 3 types but only one class
(maybe two if you interpret the where clause as creating a new class).
Does this seem like a reasonable definition of 'type' to you?
Because I think we need to make sure we're using the same terms
before we continue this.
(*) I hestitated on whether to include the 'and state' clause there,
but finally decided to leave it. In that clause, I am only referring
to state that is either publicly visible (and therefore, arguably
part of the interface), or that governs (and therefore constrains)
the behavior of the interface. I am not including internal-only state.
Taking your final question out of order:
Aside from optimization and introspection, why is it useful for a
method
signature to say "This has to be a Dog or something that inherits from
Dog"?
Because it is an assertion that 'This' will be something that behaves
like a Dog, and has the exposed state that I expect to see from a
Dog. In other words, I agree with you--it's all about the
interface. The point I'm trying to make is that, from the
recipient's point of view, all of these statements are exactly the same:
implements the interface of Dog
=== is of class Dog
=== has been composited with the Role Dog
Given that, why do we need the second version? (Don't say
'TIMTOWTDI'. Extra WTDI are only useful if they have different
nuances.)
Roles do have state.
Ok, I didn't realize that. My bad.
They exist because:
1) hierarchies aren't the only way to express type relationships --
nor
are they often even a good way
2) conformity to an interface is more important
Re: MML dispatch
(Taking things slightly out of order.) On Jul 13, 2005, at 7:32 PM, Larry Wall wrote: A class is restricted to having to provide a working interface to real objects. Can't there be pure-abstract, non-instantiable classes? Or are you still considering those to be interfaces to "real objects"? I suppose, arguably, the class pseudo-object could make that work, but it seems a sleight-of-hand. In addition to what chromatic said, I'd like to point out that you've got the abstraction levels backwards by my lights: these days I tend to think of the class as a restricted form of role. Ok, fine, then let's get rid of classes and just use roles. Right now, it sounds like the functionality of one of them is a proper subset of the functionality of the other. If that's the case, why do we need both? Or is there something that one of them can do that the other cannot and that absolutely cannot be rolled into the other one? (I hope that made sense.) --Dks
Re: execution platform object? gestalt?
On Jul 27, 2005, at 6:18 PM, Uri Guttman wrote:
this thingy should encompass
all about this perl and the world it is in and the shell env is
part of
that.
How about *?PERL ?
if ( *?PERL.COMPILED_OS eq 'Unix') {...}
if ( *?PERL.CURRENT_OS eq 'Unix') {...}
*?PERL.Grammars{Regex} = $my_bizarre_new_regex_grammar;
etc.
--Dks
Re: Perl 6 code - a possible compile, link, run cycle
On Aug 25, 2005, at 7:16 AM, David Formosa (aka ? the Platypus) wrote: On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote: [...] perl6 creates a new instance of the perl compiler (presumably an object). The compiler will only compile the actual file 'foo.pl', and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. Conceptually, Yuval's mechanism could still work. It's just that, when you go back and compile the 'use' lines, they may invalidate a compilation unit you thought you were finished with. --Dks
Re: How do you say another_sub(@_) in perl 6?
On Aug 28, 2005, at 5:52 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:18:42 -0400, David Storrs wrote:
On Aug 28, 2005, at 5:12 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:02:25 -0400, David Storrs wrote:
nested_call.wrap(), maybe?
It's not 100% the same thing... Wrapping is for wrapping only. This
applies to super methods, delegate methods, and so forth.
If I understand the semantics of wrap() properly, I believe you
can do everything with wrap that you want. I agree it's not the
optimal way though...for one
thing, you have to write the code inside out.
Not without breaking polymorphism, or doing creepy things like:
our &method = $?CLASS.can("method").wrap {
...
call
...
};
instead of
method method {
$?SELF.SUPER::method; # what's the syntax for this, btw?
# Can't find it under s12
}
Hey, I said you /could/ do it, not that you /should/ or that it was
the best way. :>
Actually, I agreed it wasn't, I was just throwing it out there as a
starting point.
On the other hand, one thing i'd like to borrow is the ability to
use 'call' for "delegating" subroutines:
sub foo will call(&other) {
call; # just like saying other()
}
Seconded. Although it starts to get interesting when you want to
pass in multiple &other()s.
--Dks
Re: How do you say another_sub(@_) in perl 6?
On Aug 28, 2005, at 5:52 AM, Yuval Kogman wrote: oops... Can I forward our correspondence to the mailing list? Sure. I was wondering why you took it private. :> --Dks
Re: skippable arguments in for loops
On Sep 22, 2005, at 3:08 AM, Luke Palmer wrote: On 9/22/05, Carl Mäsak <[EMAIL PROTECTED]> wrote: FWIW, to me it looks fairly intuitive. undef here means "don't alias the element, just throw it away"... gaal joked about using _ instead of undef. :) Joked? Every other language that has pattern matching signatures that I know of (that is, ML family and Prolog) uses _. Why should we break that? Because the way Carl has it is more consistent with Perl 5, from whence most of our users will be coming? Because 'undef' has a nice visual weight, while '_' can all too easily disappear? Because throwing away values is something that we probably shouldn't make too easy? IMO, it's immediately obvious what it means. Not IMO. _ in this context is content-free for me. But, whatever. I'm sure it will end up being _ if this feature is added. --Dks
perl6-language@perl.org
On Sep 26, 2005, at 4:19 PM, Juerd wrote: Perl 5's $& is inefficient because of this. If the variable is used anywhere, Perl will for every regex used capture everything. My understanding is that this died with 5.10. Is that right? --Dks
seeing the end of the tunnel
So, I was thinking about how $Larry's original plan for doing the Perl6 design was something along the lines of "write a series of Apocalypses, one for each chapter of the Camel book". I know that the latest version of the Apocalypses are in SVN, but I checked dev.perl.org just to see what the current list was. I see the following: * Apocalypse 1 - "The Ugly, the Bad, and the Good" * Apocalypse 2 - "Bits and Pieces" * Apocalypse 3 - "Operators" * Apocalypse 4 - "Syntax" * Apocalypse 5 - "Pattern Matching" * Apocalypse 6 - "Subroutines" * Apocalypse 7 - "Formats" (see Exegesis 7) * Apocalypse 12 - "Objects" Hmm, interesting; that actually sounds like a pretty complete design. So, I pulled down my Camel v3 and started checking to see what was left to do. I was surprised how few of the remaining chapters pertain directly to broad issues of language design; most of them are things like "The Command Line Interface", "The Debugger", etc...important, but not fundamentally critical to the language design. Many of the others are things like "Packages"--they probably won't change much, and the differences have already been hammered out, just not consolidated into an Apocalyptic form. Other chapters-- such as Chapter 33, "Diagnostic Messages"--will be better served by being left unwritten until the implementation is released. All in all, I think that might just be the end of the tunnel up ahead. Go us for getting here, and loud applause to @Larry for guiding us so well! --Dks Here are the chapters which haven't been covered yet: The Gory Details * 8. References * 9. Data Structures * 10. Packages * 11. Modules * 13. Overloading * 14. Tied Variables Perl as Technology * 15. Unicode * 16. Interprocess Communication * 17. Threads * 18. Compiling * 19. The CLI * 20. The Perl Debugger * 21. Internals and Externals Perl as Culture * 22. CPAN * 23. Security * 24. Common Practices * 25. Portable Perl * 26. Plain Old Documentation * 27. Perl Culture Reference Material * 28. Special Names * 29. Functions * 30. The Standard Perl Library * 31. Pragmatic Modules * 32. Standard Modules * 33. Diagnostic Messages
Fwd: zip: stop when and where?
Both Luke and I missed the fact that my mail and his response went
only to each other so, with his permission, here it is as a forward.
--Dks
Begin forwarded message:
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = ('a', 'b', 'c');
for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5
undef 6
for @foo ¥ 1..6 :fillin('') # a 1 b 2 c 3 '' 4 '' 5 '' 6
for @foo ¥ 1..6 :fillin(0)# a 1 b 2 c 3 0 4 0 5 0 6
for @foo ¥ 1..6 :fillin(return) # same as: return ('a', 1, 'b', 2
'c', 3);
A couple of things bother me about this, though:
- Bad endweight on the adverb. It looks like you are modifying the
second list, not the ¥ op
That's because you are. I can't seem to find the document that
describes this, but as far as I recall (and my memory may be fuzzy
here), infix operators with adverbs look roughly like this:
rule infixop {? }
Where is, of course, greedy. So since .. is tighter than Y:
for @foo Y 1..6 :fillin(undef) {...}
Is equivalent to:
for @foo Y (1..6 :fillin(undef)) {...}
And to get it modifying Y you need to do:
for (@foo) Y (1..6) :fillin(undef) {...}
(Parens added around @foo for symmetry).
for @foo ¥ 1..6 :fillin(last) # a 1 b 2 c 3
Uh, I don't think that works. First off, it would have to be:
for (@foo) Y (1..6) :fillin{ last } {...}
But I don't think that works either, since you want that last to be
associated with the for loop, which it is not lexically inside.
Honestly, I just don't think it's an option, and that :short/:long (or
:min/:max) is a better option. However, I wonder how you would get
behavior like this:
for (@foo) Y (@bar, undef xx Inf) Y (1...) :short -> $foo, $bar,
$index {...}
Hmm, probably just like that :-)
Could something like this syntax be made to work?
for (@foo ¥:fillin(undef) 1..6) but true # a but true, 1 but
true...undef but true, 6 but true
I think you've stumbled upon the reason why we made adverbs come after
operators. The important thing is the zip, not the fact that you're
filling in with undef.
Luke
Re: zip: stop when and where?
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = ('a', 'b', 'c');
for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5
undef 6
for @foo ¥ 1..6 :fillin('') # a 1 b 2 c 3 '' 4 '' 5 '' 6
for @foo ¥ 1..6 :fillin(0)# a 1 b 2 c 3 0 4 0 5 0 6
for @foo ¥ 1..6 :fillin(return) # same as: return ('a', 1, 'b', 2
'c', 3);
A couple of things bother me about this, though:
- Bad endweight on the adverb. It looks like you are modifying the
second list, not the ¥ op
That's because you are.
Good. That makes sense. I did it this way because it seemed like
others on the thread were doing it this way...but it felt wrong at
the time. Glad to see my intuition is not totally useless.
for @foo ¥ 1..6 :fillin(last) # a 1 b 2 c 3
Uh, I don't think that works.
I know it doesn't, I was proposing it as new functionality. The idea
in my head was a bit fuzzy and I probably should have crystallized it
before writing. Had I done so, it might have come out as something
more like this:
@foo = ;
for @foo ¥ 1..6 :fillin(undef)
# a 1 b 2 c 3 undef 4 undef 5 undef 6
for @foo ¥ 1..6 :fillin('x')
# a 1 b 2 c 3 x 4 x 5 x 6
for @foo ¥ 1..6 :fillin(exception but last)
# a 1 b 2 c 3
FOR_LOOP:for @foo ¥ 1..6 :fillin(exception but last FOR_LOOP)
# zips the lists, never enters the for loop body
for @foo ¥ 1..6 :fillin(exception but return)
# same as: return ; i.e., it returns from a sub
Perhaps 'exception' is spelled 'fail' or 'die' or something like that.
Off the top of my head, I can't think of why you would want to use
the 'exception but return' that I show above--it would return from
the enclosing subroutine, without ever entering the loop body. It
would be a highly obfuscated way to return. However, my
understanding of the current design is that 'return' is just an
exception with a built-in handler, so this is a logical corner case
of what I'm suggesting.
Could something like this syntax be made to work?
for (@foo ¥:fillin(undef) 1..6) but true # a but true, 1 but
true...undef but true, 6 but true
I think you've stumbled upon the reason why we made adverbs come
after
operators.
I'm not quite sure how you are using 'come after operators' here,
since in both of the following the adverb comes after the op (it's
just that in the second, there's something between them):
for (@foo) Y (1..6) :fillin(undef) {...}
for (@foo ¥:fillin(undef) 1..6){...}
The important thing is the zip, not the fact that you're
filling in with undef.
I would phrase it as "the important thing is what you are doing with
the lists". That encompasses both the operator you are using (zip)
and how that operator will behave (fill in with, in this case, undef).
--Dks
Re: zip: stop when and where?
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on C is a suboptimal solution,
because it implies that you would always want to fill in *any* gap
with the same value. While that's likely in a two-way zip, it seems
much less likely in a multiway zip.
I actually have no problem with the solution you suggest (although I
rather like my idea about being able to 'fill in' with a control
exception), but I do have a question. If you want a multiway zip
with differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
Assuming, of course, that it is possible to stick an adverb on the op
as I was requesting.
--Dks
Re: Thoughs on Theory.pm
On Oct 13, 2005, at 6:45 PM, Dave Whipp wrote: I started thinking about the "in general, unverifiable programmatically" bit. While obviously true, perhaps we can get closer than just leaving them as comments. It should be possible to associate a unit-test-generator with the theory, so I can say: [...] And then say "for type T, please generate 1000 random tests of T using axioms of Ring". In an ultra-slow debug mode, the aximons could be propagated as post conditions on every public mutator of T, so that we test them continuously in a running application (or tes suite). While I like the idea, I would point out that 1000 tests with randomly generated data are far less useful than 5 tests chosen to hit boundary conditions. --Dks
Re: Book RFC - Migrating to Perl 6
On Oct 15, 2005, at 7:39 AM, Rutger Vos wrote: Good idea. A fat new O'reilly tome will go some way to capturing mind share for perl6. Gathering ideas wiki-style is also very Web2.0. Perhaps perl6 could be marketed as such, what with the development style - "Perl6, the first Web2.0 programming language". I would suggest we avoid trying to link Perl6 with Web2.0 in people's minds, at least at first. One of the uphill battles that I'm really tired of fighting is convincing people that Perl is good for more than CGIs and quick-n-dirty system administration hacks. We don't need to throw fuel on that fire by "nicheing" ourselves right at the start. --Dks
Fwd: Renaming grep
Drat, thought I was sending this to the list: Begin forwarded message: On Nov 17, 2005, at 8:31 PM, Ilmari Vacklin wrote: Hi all, I think that grep should be renamed to something English and more, well, semantic. 'Filter' comes to mind as a suggestion. I realise there's a lot of cultural background (from Unix and Perl 5) that favours 'grep', but I think it's more important to name the language elements consistently (the right kind of consistency, I hope). 'sift' is the same number of characters as 'grep'. It's something of a bikeshed to me whether this rename is implemented or not, though. --Dks
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote: > > On Friday, June 13, 2003, at 10:26 PM, David Storrs wrote: > > >my $a = 'foo'; > >my Int $b = $a; # legal; $b is now 0; is there a warning? > >my $c = $b; # is $c 0, or 'foo'? > > 0, I think. Or specifically, C. So then conversion from Scalar to Int is not lossless, and (by extension) conversions from Scalar to any other LargeCapPrimitive are presumably not lossless either. > (I've been operating under the > assumption that an "untyped scalar" doesn't _remove_ the type of > something, it just can store values of _any_ type, and is by default > much more generous about autoconverting them for you, so that you could > use $c as an Int, int, Num, num, Str, str, etc., without warning or > error... but internally, it's actually still storing the value as an > C, because that's what you assigned to it.) Seems reasonable. Although I would assume that it would store and pull the value from an Int slot, then create a new value of the "converted to" type, and use that. > >my Str $d = $a; # no loss > >my $a = $d; # no effective change in $a > >my $e = $b; # what is $d? > > $d? Still a Str, I would think. And $e would be Int 0, same as $c I obviously had either a typo or a braino on the last line there. I have no idea what I was trying to ask. > > What value does $f end up with? (My vote would be '7'.) > > My understanding is that properties go with the values, (just like > traits go with the variables), so I would expect $f to be C<7 but > false>. So if a value is C, it stays C until you > say otherwise. A better example of what I was driving at would be this: my $a = 'foo' but purple; my Int $b = $a; In other words: I've just created an untyped Scalar. This Scalar is (presumably in it's Str slot) storing a string value which happens to have a property set on it (i.e., C
Re: printf-like formatting in interpolated strings
On Mon, Jun 16, 2003 at 11:37:06AM -0700, Michael Lazzaro wrote: > [...] > But there is broad support for the idea that the somewhat elderly > printf syntax is a PITA, and that printf, in general, should be > completely unnecessary since we already *have* interpolated strings, > fer pete's sake. A PITA, yes, but a darned powerful *and concise* PITA. > Is it possible that > > "The value of x is " > > is in fact a cleaner, more elegant syntax than: Quite honestly, I'd like to do better. One of the things that makes regexen so powerful is their concision; they pack a tremendous amount of meaning into every character and yet, for the most part, they aren't that hard to understand. I'd like to see the same for output rules. The vast majority of output rules will probably be on the order of: "make this an integer and left-pad with 0s to make sure there are at least 2 digits". I'd much rather write: "The value of x is \F02d$($x)" than "The value of x is $($x as integer but formatted()" > Or, if we have "output rules" just like we have "input rules", could > something quite complex be expressed simply as: > > "You have <$x as MoneyFormat>" I like this better; a good compromise between concision and readability (although the later poster's suggestion of 'MoneyFormat($x)' was even better, IMO). You still need to define MoneyFormat somewhere, however; I hope that you will be able to do that with nice concise formatting codes. --Dks
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Mon, Jun 16, 2003 at 11:47:35AM -0700, Austin Hastings wrote:
>
> Although it occurs to me that there might be such a thing as "Int
> properties" and "Str properties", and maybe the conversion propagates
> the appropriate ones.
>
> That is:
>
> my $a = "foo" but $purple ;
> $a but= false;
> $a but= prime;
> $a but= charset("UTF8");
> $a but= encoding("text/utf8");
>
> my Int $b = $a;
>
> At this point, $b would be C<0 but all(false, prime)>.
>
> =Austin
Yeek. That gives me the screaming willies. Let's either have it
preserve all the properties or none, but please don't make me remember
a big list of which properties exist for which types...and oh, btw,
did I happen to overload/modify that? Did any of the modules I'm
using? Where do user defined properties (if those still exist) fit
in?
--Dks
Re: As I am a New one.
On Mon, Jun 23, 2003 at 03:13:23PM +0100, sitaram wrote: > Hi, > I am a new one Perl. > I want a book which gives the Knowledge about perl. > I learned up to some extent using the online books. > I want a book which is tells me about functions(system,Built in) in brief. > Can U send the URL for such a Book. > > I am waiting for your reply. > > Thanks and Regards >Sitaram Sitaram, This list is intended to help define the syntax/grammar/etc of Perl 6, the next iteration of Perl. As such, it's not really the right place for your question. The place to direct questions like this, and all other beginner questions, would probably be [EMAIL PROTECTED] (the people on the list are extremely knowledgeable and helpful): However, some good pointers for you: Programming Perl (also known as "The Camel Book") is the definitive book: http://www.oreilly.com/catalog/pperl3/ Learning Perl (also known as "The Llama Book") is probably the best-known introductory book: http://www.oreilly.com/catalog/lperl3/ Welcome to Perl! --Dks
Re: This week's summary
On Tue, Jun 24, 2003 at 06:14:52AM -0700, Sean O'Rourke wrote: > On Tue, 24 Jun 2003, Leopold Toetsch wrote: > > > > [...] Nobody answered, if we need another > > Sub class implementing the old invoke/ret scheme ... > > I'd say "no". P6C is now compiling to an obsolete architecture. > While we should all step back and be impressed at how well Intel has > maintained backward compatibility in the x86, there's no particular > reason we should do so ourselves. Rather, someone (me) needs to port > P6C to the new machine. /me shows ignorance yet again. For those of us who are not hardware types...what is "the new machine"? The Itanium? Does that really have enough market penetration at this point to be a worthy target? Or is the idea that, by the time Parrot is finished, it WILL have massive market penetration? > > > Piers Cawley <[EMAIL PROTECTED]> wrote: > > > Whee! My first anniversary! > > > > Congrats and thanks for your great summaries. > > Seconded. Thirded. Although the doings of the internals list fascinate me, they are usually totally over my head, so I long ago unsub'd. It's great to be able to follow along via the summaries. --Dks
Re: This week's summary
On Tue, Jun 24, 2003 at 04:04:29PM +0100, Andrew Wilson wrote: > On Tue, Jun 24, 2003 at 07:58:32AM -0700, David Storrs wrote: > > /me shows ignorance yet again. > > > > For those of us who are not hardware types...what is "the new > > machine"? The Itanium? Does that really have enough market > > The machine they're talking about is parrot. A virtual machine, but a > machine none the less. The "new machine" is the new calling conventions > recently implemented. > > andrew Ah. Of course; I got confused by the x86 references and took them too literally. Thanks for setting me straight. --Dks
Re: Aliasing an array slice
Thinking about it, I'd rather see lvalue slices become a nicer version of C. my @start = (0..5); my @a = @start; @a[1..3] = qw/ a b c d e /; print @a; # 0 a b c d e 4 5 # Similarly: @a = @start; my $r_slice = [EMAIL PROTECTED]; @$r_slice = qw/ a b c d e /; print @a; # 0 a b c d e 4 5 # Note that it does NOT modify in rvalue context print reverse @$r_slice; # e d c b a print @a; # 0 a b c d e 4 5 # To modify, do this: @$r_slice = reverse @$r_slice; print @a; # 0 e d c b a 4 5 As far as what happens when you modify the array to which the slice points--treat it like any other reference. If you undef an array to which you are holding a reference, the reference is suddenly reffing a null array. If you undef an array slice to which you are holding a reference, your slice ref is now reffing undef. @a = @start; $r_slice = [EMAIL PROTECTED]; print @a; # 0 1 2 3 4 5 print @$r_slice; # 0 1 2 3 shift @a; # (*) print @a; # 1 2 3 4 5 print @$r_slice; # 1 2 3 (*) There should probably be a suppressable warning emitted here, something like: "Warning: slice reference being modified" or "Warning: slice reference such-and-such included this element; ref modified" If slices DO get this functionality, it would be nice to add a method whereby we could retrieve the min/max keys (for an array) or the set of keys (for a hash) which they are currently reffing. --Dks
Re: Aliasing an array slice
On Tue, Jul 08, 2003 at 05:52:04PM -0700, Austin Hastings wrote: > > --- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote: > > Am I now thinking clearly? > > > I don't think so. > > If you've created two separate arrays that happen to start with related > values, then the changes to the first won't affect the second. > > If splice overwrites the values instead of dropping and then replacing > them, it's going to produce some strange behavior. What kind of strange behavior? Can you give an example? > I think that for example: > > my @a is Array of int; > my $r_slice is Array of int; > > # ... as before ... > > should behave as expected, and "expected" in this case means > copy-on-assign. Could you elaborate on this? >OTOH, if you said C<$r_slice := @a ...> then you'd be > binding, not copying, and the one-change-affects-both behavior is in > effect. > > =Austin You also wouldn't be using a slice, you'd be using a reference to the array. Or was the ellipsis supposed to indicate the slice indices? --Dks
Re: Aliasing an array slice
On Fri, Jul 18, 2003 at 06:05:52PM -0400, Benjamin Goldberg wrote: > What would happen if I used 1,2,3 instead of 1..3? Would it do the same > thing? I would think so. > I wanna know what happens if I do: > >@a[0,2,4] = qw/ a b c d e /; Yup, you're right, I didn't consider non-contiguous ranges in my original proposal. Stupid of me. After considering it more thoroughly, I guess this isn't a good idea. Here are some of the cases that it would need to cover (obviously, punting on some of these is an option). Single finite contiguous list (1,2,3) Single finite noncontiguous list with pattern (2,4,6) Single finite noncontiguous list without pattern (2,4,6,13) Single finite contiguous range (1..3) Single finite noncontiguous range(1..10 :by 2) Multiple finite contiguous lists - that resolve to a contiguous list ((1,2,3),(4,5,6)) - that do not resolve to a contiguous list ((1,2,3),(7,8,9)) Multiple finite noncontiguous lists with pattern ((2,4,6),(9,12,15)) - that resolve to a contiguous list if reordered ((2,4,6),(1,2,3)) # reordering is almost certainly a bad idea Multiple finite noncontiguous lists without pattern ((2,4,6,13), (77,100,203)) Multiple finite contiguous ranges ((1..3),(7..9)) Multiple finite noncontiguous ranges ((1..10 :by 2), (20..50 :by 7)) Infinite ranges (1..Inf) or (7..Inf :by 8) Mixed cases - ((2,4,6),(99..200)) - ((2,4,6),(20..50 :by7)) Overlapping cases - ( (1,2,3,4), (3,4,5,6) ) It's a shame, because I think it would make a really nice convenience feature. I will say that I like the solution proposed earlier (sorry, I forget by whom) that the C<...> in 5...10 would mean "this is a splice slice". Btw, I don't remember what the syntax for "range, step by N" was, so my version probably isn't right. --Dks
Re: The Perl 6 Summary -- preprocessors
On Mon, Jul 21, 2003 at 12:19:11PM -0700, Austin Hastings wrote: > Likewise: > > my $fh = open " > $fh =~ / = Grammars::Languages::Runoff::tbl(input_method >= Grammars::Language::Runoff::eqn(input_method > = IO::Gunzip)))>/; Very cool. Assuming this ran successfully, what would the match object contain? Or, more specifically, how would you get the pieces out? Using $1, $2 etc would get cumbersome...is there an easier way? --Dks
Re: Next Apocalypse
On Mon, Sep 15, 2003 at 11:49:52AM -0400, Gordon Henriksen wrote:
> Austin Hastings wrote:
>
> > Given that threads are present, and given the continuation based
> > nature of the interpreter, I assume that code blocks can be closured.
> > So why not allocate JITed methods on the heap and manage them as first
> > class closures, so that the stackref will hold them until the stack
> > exits?
>
>
> Austin,
>
> That's a fine and dandy way to do some things, like progressive
> optimization ala HotSpot. (e.g., "Oh! I've been called 10,000 times.
> Maybe you should bother to run a peephole analyzer over me?") But when
> an assumption made by the already-executing routine is actually
> violated, it causes incorrect behavior. Here's an example:
>
> class My::PluginBase;
>
> method say_hi() {
> # Default implementation.
> print "Hello, world.\n";
> }
>
>
> package main;
>
> load_plugin($filepath) { ... }
>
> my $plugin is My::PluginBase;
> $plugin = load_plugin($ARGV[0]);
> $plugin.SayHi();
>
> Now, while it would obviously seem a bad idea to you, it would be
> reasonable for perl to initially optimize the method call
> $plugin.say_hi() to the function call My::PluginBase::say_hi($plugin).
> But when load_plugin loads a subclass of My::PluginBase from the file
> specified in $ARGV[0], then that assumption is violated. Now, the
> optimization has to be backed out, or the program will never call the
> subclass's say_hi. Letting the GC clean up the old version of main when
> the notification is received isn't enough--the existing stack frame must
> actually be rewritten to use the newly-compiled version.
This discussion seems to contain two separate problems, and I'm not
always sure which one is being addressed. The components I see are:
1) Detecting when the assumptions have been violated and the code has
to be changed; and,
2) Actually making the change after we know that we need to.
I have at least a vague idea of why #1 would be difficult. As to
#2...assuming that the original source is available (or can be
recovered), then regenerating the expression does not seem difficult.
Or am I missing something?
--Dks
Re: Alternately named arguments
On Fri, Oct 24, 2003 at 12:57:18AM -0600, Luke Palmer wrote:
> Presuming you can do:
>
> (who => $name, why => $reason) := (why => $because, who => "me");
>
> (from A6)
>
> Does that imply that you can do:
>
> sub routine (name => $nombre, date => $fecha) {...}
>
> Anyway, I just realized that this is finally an elegant way to do
> multiple, unordered return values:
>
> (name => $name, id => $id) := getinfo();
>
> (Or, in this precise case:)
>
> (+$name, +$id) := getinfo();
Just confirming something...if you did this:
($name, $id) := &getinfo();
I think you would end up storing an alias to the getinfo() sub in $name, and
undef in $id. Is that correct?
What would happen if you did this?
(+$name, +$id) := &getinfo();
I would expect a compile time error, because you can't bind a sub
alias to a scalar that is being forced into numeric context.
--Dks
Re: Roles and Mix-ins?
On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote: > On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote: > : For one, one role's methods don't silently override another's. Instead, > : you get, er, role conflict and you have to disambiguate yourself. How do you disambiguate? > : For > : two, you can attach new roles to an object at runtime (I don't know if > : you can do this with mixins, actually). > > Yes, you can. The mixin creates a new singleton class every time > you do it, derived from the previous class. My current thinking is > that run-time roles work a little differently. You get a singleton > class for the object the first time you apply a property, so that each > object's properties remain distinct. However, subsequent properties > re-use the existing singleton class, and do the same role-conflict > checks at run time that "does" would do in the class definition > at compile time. Furthermore, the singleton class is not really > derived from the original class, but just presents a different view > of the same class, so that, from the viewpoint of the object, every > role has the same standing, and run-time roles aren't privileged > above compile-time roles, as they would be if the singleton class > were really derived from the original class. In a sense, the object > thinks it's recomposing the original class, but it's slightly wrong. After reading this several times, I _think_ I understand. Let me check: imagine that the original class is a text buffer going from 0-99. We have two roles (A and B), each of length 100. Objects of various types can then see different segments of the buffer (i.e., different methods/properties/whatever), as follows: TypeCan see --- Class 1-100 A 101-199 B 200-299 Class+A 1-100,101-199 Class+B 1-100,200-299 Class+A+B 1-100,101-199,200-299 Is that right? Dave
run-once code
Given this code:
if ( some_expensive_lookup_function() >= $MAX_RECORDS ) {
mark_that_we_have_reached_max_records();
return;
}
After I enter that block once, I never want to evaluate the condition
again--I want the code to completely disappear from the bytecode (or,
at least, be jumped around). How would I do that in Perl 6?
(I recall seeing something about how to make assertions drop out, but
I want to be able to do this at run-time, not compile-time.)
--Dks
Re: run-once code
On Tue, Jan 13, 2004 at 10:16:48PM -0700, Luke Palmer wrote:
> sub mark_that_we_have_reached_max_records() {
> $max_reached = 1;
> }
>
> if !$max_reached && some_expensive_lookup_function() > $MAX_RECORDS {
> mark_that_we_have_reached_max_records();
> return;
> }
>
> That's a new feature we're adding called "conditional code removal",
> sometimes known as "short circuiting" :-)
Well, not what I asked (the block is not jumped around, just
shortcircuited) and doesn't really address the principle (i.e., how to
manipulate the bytecode at runtime) I was trying to grok, but ok.
[...]
> This could well be something the optimizer does, but assuming otherwise,
> optimized currying could be to our benefit.
>
> sub do_the_loop($x, $seen) {
> while $x --> 0 {
> if $seen || cheap_condition() {
> something();
> }
> last if !$seen && other_cheap_condition();
> }
> return $x;
> }
>
> &do_the_loop.assuming(seen => 1).(
> &do_the_loop.assuming(seen => 0).(100_000));
>
> If curries are subject to a short constant-folding pass, this should
> easily give us the effect we want.
Had to study this for a bit to assure myself it all worked, but cool!
This is exactly what I was looking for. Thanks.
> > (I recall seeing something about how to make assertions drop out, but
> > I want to be able to do this at run-time, not compile-time.)
>
> As uri said, who can tell the difference?
Point.
--Dks
Re: run-once code
On Wed, Jan 14, 2004 at 10:59:52AM -0500, Melvin Smith wrote: > I think Perl6 will allow a hint like so: > > my int $max_reached; > > The important thing is that $max_reached is used simply as a conditional, > and you don't pass it to a routine or otherwise use it in a way to cause it > to be promoted to a PMC What uses would cause it to be promoted to a PMC? --Dks
Re: run-once code
On Wed, Jan 14, 2004 at 11:57:05AM +, Richard Nuttall wrote:
> How about
>
> $test = sub
> {
> if ( some_expensive_lookup_function() >= $MAX_RECORDS )
>
> mark_that_we_have_reached_max_records();
>
>$test = sub{};
> };
>
> Then call &$test() as needed;
Neat. I wouldn't have thought of that; thank you.
--Dks
Re: backticks
On Wed, Apr 14, 2004 at 10:06:23PM +0200, Juerd wrote:
>
> If on your keyboard ` is in a worse place than {}, I'd like to know
> where it is.
>
> Juerd
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
Please put me down as strongly against this idea because:
1) ` looks like it should be a bracketing operator
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
4) This argument has not been made strongly enough to make me want to
give up one of the few remaining single character operators
(remaining, anyway, if @Larry decides that ` should get an
independent existence as a unary operator).
5) I use `` in short utility scripts all the time, and would hate to
lose it. To anyone who says that that is dangerous and should be
discouraged--my machine, my code, my problem. (And I work for
myself, so I am the only one who will be maintaining it.)
Actually, what I'd like to know is when it was decided that %hash{key}
meant %hash{key()}?? Was it in one of the Apocalypses? I missed that
and would like to go back and read the reason for it, since I suspect
that, given a single-term expression in a hash subscript, it is far
more likely to be a literal than a function call. It seems that that
is really the source of the entire 'problem' that this thread
addresses.
--Dks
Re: backticks
On Thu, Apr 15, 2004 at 11:45:27AM +0200, Juerd wrote:
> David Storrs skribis 2004-04-14 22:39 (-0700):
> > Very top row, one space right of the F12 key. Extremely awkward.
> > (This is a US keyboard on a Dell Inspiron 5100 laptop.)
>
> That is inconvenient.
Yup.
> > 1) ` looks like it should be a bracketing operator
>
> I think you means circumfix/balanced operator.
If you prefer those terms, sure.
> > 2) In some fonts, ` is hard to see.
> > 3) In some fonts, ` is hard to disambiguate from ' if you can see it.
>
> In some fonts, the difference between () and {} is hard to see.
> In some fonts, the difference between 1, l and I is hard to see.
> In some fonts, the difference between 0 and O is hard to see.
> In some fonts, the , is hard to see.
> In some fonts, " and '' look exactly the same.
All true.
> Don't use those fonts when programming, period. Use a fixed width font.
> No fixed width font that I have ever seen makes ` hard to see.
I am currently using a fixed width font to read this message. ` is
hard to see.
> > 4) This argument has not been made strongly enough (...)
>
> I'm not here to do anything weakly, strongly or forcefully.
s/strongly/convincingly/
> > 5) I use `` in short utility scripts all the time, and would hate to
> > lose it. To anyone who says that that is dangerous and should be
> > discouraged--my machine, my code, my problem. (And I work for
> > myself, so I am the only one who will be maintaining it.)
>
> As said in several messages in this thread before, `` does not have to
> go to support %hash`key. %hash`key has already been succesfully
> implemented in perl 5.8.3 and does not harm `` there at all.
You point is granted. However, mine still stands.
--Dks
Re: backticks
Folks, this discussion seems to be spinning. All the points, on both sides, have been made and are being repeated with only slight variation. We've all made our cases--why don't we drop the issue for a while and let Larry ruminate? I think we can all agree that he will give the idea a fair hearing and make a good decision...and I know that I'll be glad if, tomorrow, I *don't* have 30 mails in my box about backticks. :> --Dks
Re: Apocalypse 12
On Fri, Apr 16, 2004 at 05:30:01PM -0700, chromatic wrote: > Perl.com has just made A12 available: > > http://www.perl.com/pub/a/2004/04/16/a12.html > > Warning -- 20 pages, the first of which is a table of contents. > > Enjoy, > -- c It's here, it's here, it's he!! *Ahem* Sorry. Will now go off and read quietly. --Dks
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
On Tue, Jun 08, 2004 at 01:08:13PM -, Ingo Blechschmidt wrote:
> Hello,
>
> quoting Apocalypse 6:
> > You may ask a subroutine to wrap itself up in another subroutine in
> > place, so that calls to the original are intercepted and interpreted by
> > the wrapper, even if access is only through the reference:
> >
> > $id = $subref.wrap({
> > # preprocessing here
> > call;
> > # postprocessing here
> > }
> [...]
> > The $id is useful for removing a particular wrapper:
> >
> >$subref.unwrap($id);
Hmmm. What happens when I do this?:
$id1 = $subref.wrap({ });
$id2 = $subref.wrap({ });
$id3 = $subref.wrap({ });
$id4 = $subref.wrap({ });
$subref.unwrap($id3);
First off, is this even valid?
Second, what does it do under the hood? Does it need to tear off
wrappers 1 and 2 before tearing off #3? Does it need to recompile
wrappers 1 and 2? What kind of speed hit am I looking at?
--Dks
Re: FW: Periodic Table of the Operators
On Sun, Jun 13, 2004 at 03:40:27AM +0200, Pedro Larroy wrote: > What advantages have to use characters not in standard keyboards? Isn't > it a little scary? Well, what do you consider a 'standard' keyboard? The zip operator/Yen sign probably appears on most keyboards in Japan, but on very few in the US. My US keyboard gives me no convenient way to type a 'u with umlaut' character, but I'm sure that my friend Roland, who lives in Switzerland, has no such limitation. Like it or not, Unicode is the way of the future. Life really and truly will be easier once that becomes the default assumption; keyboard makers will start putting thought into how to provide easy access to normally-unused-in-this-locale characters, software will have to make it easy to work with foreign character sets, your terminal will not give you grief about displaying foreign characters, etc. But it's kind of a chicken-and-egg problem. If the characters are never used, we don't need to worry about them--except when we do. So, by making them more commonly used, we help bring about the day when we don't need to worry about them. And if you aren't ready to worry about them yet, I believe they all have ASCII equivalents (e.g., >>, <<, and zip). All the best, --Dks
Re: definitions of truth
On Thu, Jun 24, 2004 at 12:43:30PM -0700, Scott Bronson wrote: > > So, in summary, though "0"==false appears to work, it leads to a number > of strange boundary conditions and, therefore, bugs. It's hard for new > programmers to grasp and even old hacks are still sometimes tripped up > by it. It just feels inconsistent. That's why I'd love to see this > straightened out for Perl6. Interestingly, the very first use of the properties system that I remember seeing on this list was "0 but true". Although no one explicitly said so, it seems to me that the entire idea of properties was created to deal with this problem...which it doesn't do particularly well, since you still have to remember to tag the property on. As it turns out, properties are (at least apparently, until we have a significant Perl6 codebase) very useful for other things. FWIW, I also don't particularly like dealing with the edge cases that "0" causes. Unfortunately, I don't have a good solution. --Dks
Re: if, loop, and lexical scope
On Sun, Jun 27, 2004 at 03:16:11PM -0600, Luke Palmer wrote: > > But anyway, if you still want to be old school about it, then you'll end > up not caring about the scope of your $i. Really you won't. And you'll > be happy that it was kept around for you once you decide you want to > know the value of $i for which the loop terminated. > > Luke Personally, I consider the new state of affairs to be a gift from G--...er...Larry (ah, what's the difference?). It always annoyed me to have to declared my vars outside the control structure when I often needed them afterwards. Thank you, Larry. --Dks
Re: undo()?
On Tue, Jun 29, 2004 at 05:31:29PM -0600, Luke Palmer wrote: > Oh no! Someone doesn't understand continuations! How could this > happen?! :-) > > You need two things to bring the state of the process back to an earlier > state: undo and continuations. People say continuations are like time > traveling; I like to put it this way: > > Say you're in the kitchen in front of the refrigerator, thinking about a > sandwitch. You take a continuation right there and stick it in your > pocket. Then you get some turkey and bread out of the refrigerator and > make yourself a sandwitch, which is now sitting on the counter. You > invoke the continuation in your pocket, and you find yourself standing > in front of the refrigerator again, thinking about a sandwitch. But > fortunately, there's a sandwitch on the counter, and all the materials > used to make it are gone. So you eat it. :-) Urf. Okay, put me on the list as "someone who thought he understood continuations at least somewhat but obviously didn't have a clue." I was under the impression that a continuation was the entire state of the program at that point and that, when invoked, it overwrites the current state with the saved one. Therefore, if you invoke a continuation, you are resetting everything to the when it was when the continuation was taken. So external changes (the fact that you wrote to a file) will remain, but internal changes (the fact that you assigned 7 to $foo) will be undone. I'm not sure how some of the edge cases (where things are partially internal and partially external) are supposed to work out, for example: $dbh = connect_to_db_and_prepare_fetch_call(); # save continuation here close_connection_to_db($dbh); # invoke saved continuation here $dbh->fetch_row(); # DB has closed connection so this fails. Needless to say, I have never worked with continuations myself, just studied them very briefly in college (a long time ago). > A continuation doesn't save data. It's just a closure that closes over > the execution stack (and any lexicals associated with it; thus the "I > want a sandwitch" thought). If things change between the taking and > invoking of the continuation, those things remain changed after > invoking. 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. :< 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? --Dks
Re: if not C<,> then what?
On Thu, Jul 01, 2004 at 04:14:37PM -0700, Jonathan Lang wrote:
> Juerd wrote:
>
> If you're really enamoured with the infix operator syntax, consider this
> possibility:
>
> sub infix:-> ($before, $after) {
> $before; # is this line redundant?
> return $after;
> }
> print $a -> $b -> $c; # prints $c
>
> where C[->] is read as "followed by". You could even set up a
> right-to-left version, C[<-], but why bother?
You could do this, but you'd be overriding the current meaning of
C<< -> >> as "pointy sub".
You could also use, 'before':
# Recipe for (un)holy water that will irk the altar's god.
step_on_altar();
drop_water($_) before pray() for @water_potions;
OOC, can you define an operator that is made up of alphanumerics, or
only punctuation? e.g., is this legal?
sub infix:before ( $before, $after ){ ... }
--Dks
Re: C C and lazyness
On Sat, Jul 03, 2004 at 01:02:34AM -0600, Luke Palmer wrote:
> But indeed there are cases where it is a problem:
>
> my $x = 2;
> sub mklist () {
> return map { 2 * $_ } 0..10;
> }
>
> my @list = mklist;
> say @list[0..4]; # 0 2 4 6 8
> $x = 1;
> say @list; # 0 2 4 6 8 5 6 7 8 9 10
>
> Which is assuredly different from what would happen if it were evaluated
> non-lazily.
Did you mean the body of mklist to be:
return map { 2 * $x } 0..10;
# Note:^^
Or am I just confused?
--Dks
Re: fast question
On Tue, Jul 06, 2004 at 06:39:07PM -0600, Luke Palmer wrote:
> Matija Papec writes:
> >
> > Would there be a way to still use simple unquoted hash keys like in old
> > days ($hash{MYKEY})?
>
> Of course there's a way to do it. This is one of those decisions that I
> was against for the longest time, until one day something clicked and it
> made sense.
Out of curiosity, can you articulate what clicked? This one still
doesn't make sense to me, and I'd like to get it.
> You might do it something like this:
>
> macro postcircumfix:{} ($base, $subscript)
> is parsed( / $?subscript := (\w+) /)
> {
> return { $base.{"$subscript"} }
> }
I don't recall seeing postcircumfix before, nor can I find it in
A6...did I miss something?
Are there others, aside from these: ?
prefix: a unary prefix operator
infix: a binary infix operator
postfix:a binary suffix operator
circumfix: a bracketing operator
--Dks
Re: push with lazy lists
On Wed, Jul 14, 2004 at 07:40:33AM +0200, Ph. Marek wrote: > > To repeat Dave and myself - if > @x = 1 .. Inf; > then > rand(@x) > should be Inf, and so > print $x[rand(@x)]; > should give Inf, as the infinite element of @x is Inf. Does it even make sense to take the Infiniteth element of an array?...after all, array indices are integers, and Inf is not an integer. If we allow it, should we also allow people to take the NaNth element of an array? How about the 'foobar'th element? What happens if I take the Infiniteth element of a finite list? I think I would prefer if using Inf as an array index resulted in a trappable error. --Dks
Re: :)
On Sat, Jul 17, 2004 at 06:23:50PM -0400, Austin Hastings wrote: > > On Saturday, 17 July, 2004 01:53 Sat, Jul 17, 2004, Juerd wrote: > > > > Do we have a :) operator yet? > > It's an adverbial modifier on the core expression type. Does > nothing, but it acts as a line terminator when nothing but > whitespace separates it from EOL. Please tell me you're serious. --Dks
Re: Why do users need FileHandles?
On Sun, Jul 18, 2004 at 05:36:58PM -0700, Dave Whipp wrote:
> truncate Vs append would be infered from usage (assign => truncate). One
> might be able to infer read Vs write in a similar way -- open the file based
> on the first access; re-open it (behind the scenes) if we write it after
> reading it.
You might run into issues if the user starts doing seeks before
writing...although maybe not, since that just means that we need to
(behind the scenes) remember the current location of the seek pointer
when re-opening.
Exclusivity issue: when it re-opens, should it lock before opening?
Race condition: what if something deletes the file between the moment
that perl closes the file and the moment that it re-opens it? Is
there a cross-platform way to do an atomic reopen?
FWIW, although I'm not sure it will work in practice, I really like
this idea of eliminating FileHandles as a user-level object.
> my Str $text is file("foo.txt") does no_follow_symlink does no_create;
>
> Do we have an antonym for C?
How about 'no'?
my Str $text is file("foo.txt") no follow_symlink no create;
Other options (not all good):
without
not
dont
doesnt
--Dks
Re: Why do users need FileHandles?
On Sun, Jul 18, 2004 at 08:39:09PM -0500, Rod Adams wrote:
> Case 1:
> So I wanted to do a read/write scan, so I create my TextFile, start
> reading in data, so the file is opened for reading. Then, I come to the
> part where I want to update something, so I do a write command. Suddenly
> the file has to be closed, and then re-opened for read and write. And
> all my buffers, file pointers and the like are reset, (though curable
> with very careful planning), leaving me in a bad spot. Better if I could
> just declare the file open for read and write at open time.
>
> Case 2:
> I meant to use some critical data file in read-only mode, and accidently
> use a write command somewhere I didn't mean to, and silently just
> clobbered /etc/passwd. Better if I could have just opened the file read
> only, and trigger an error on the write command.
>
> What design philosophy would you envision TextFile taking to handle both
> these cases in a coherent fashion?
my $default is TextFile("/tmp/foo");
my $rw is TextFile("/tmp/foo")is rw;
my $ro is TextFile("/etc/passwd") is const;
$default will have the semantics that Dave has been
describing--initially opened read-only, then re-opened as r/w if you
write to it.
$rw is explicitly r/w. Attempts to write to it succeed, and do not
require an implicit re-open.
$ro is explicitly ro. Attempts to write to it fail, and do not
perform an implicit re-open.
Given the above code, here is some usage:
print $ro.readline(); # Prints first line
$ro = "boom!";# THROWS AN ERROR
(assume error was trapped somehow)
# Print file, inefficiently
print $default.readline for 1..$default.lines;
# Append a line
$rw .= "an additional line\n";
# New line is visible through $rw
print $rw.lines[-1]; # (*)
# last line not yet visible through $default because it was
# added by external handle--just like in a tail -f, we
# need to move file pointer manually
$default.seek(File.current_pos);
# Can't re-open for write mode, since another handle
# already has the write-lock. Throw error to that effect.
$default = "oops, this doesn't work";
(*) The .lines[-1] semantic is feasible if we are willing to tolerate
very slow performance (at least the first time; it could cache the
locations of $/ after scanning and dump the cache if $/ changes), the
fact that it wouldn't work on all files (/dev/null, /dev/zero, etc),
and a few other issues.
> I don't think anyone (read: Larry) has declared exactly what the
> capabilities of the default file handle object are yet. It seems me that
> you could very well get what you want.
True on both counts.
--Dks
Re: Why do users need FileHandles?
On Mon, Jul 19, 2004 at 03:37:12PM -0500, Rod Adams wrote: > I think part of the "mental jam" (at least with me), is that the > read/write, exclusive, etc, are very critical to the act of opening the > file, not only an after the fact restriction on what I can do later. If > I cannot open a file for writing (permissions, out of space, write > locked, etc), I want to know the instant I attempt to open it as such, > _not_ when I later attempt to write to it. Having all these features > available to open as arguements seems a much better idea to me. It's > "Open a file with these specifications", not "Open a file, and then > apply these specifications to it". > > I do admit there is merit to your abstraction system, but IMO, it > belongs in a library. > > -- Rod Adams First, why are they incompatible? Offer both, let TIMTOWTDI sort it out. Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. --Dks
Re: String interpolation
On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote:
> No Yes
> -- ---
> @foo@foo[1]
> %bar%bar{"a"} or %bar«a»
> $foo.bar$foo.bar()
> &foo &foo(1)
>
> In this worldview, $foo is an exception only because it doesn't naturally
> have a form that ends with some kind of bracket.
In an ideal universe, here's what I would like to see:
Scalars and things ending in brackets are interpolated. Things
starting with '@' are interpolated if there is an array of that name,
otherwise they are treated as literals.
$foo = 'apple';
%bar = ('a', 1, 'b', 2);
@foo = <>;
sub foo { my $param = shift // 7; return $param +2; }
# attached to object $baz which stringifies to '^object baz^'
method bar { return 'quux'; }
print "$foo"; # apple
print "\$foo"; # $foo
print "%bar"; # %bar
print "$baz.bar"; # ^object baz^.bar
print "$baz.bar()"; # quux
print "$baz\.bar()";# ^object baz^. with WARNING: no function bar()...
print "&foo"; # &foo
print "foo()"; # 9
print "&foo()"; # 9
print "&foo(1)";#
print "@foo[1]";# a
print "%bar{'a'}"; # 1
print "%bar«a»";# 1
print "@foo"; # a b c [1]
undef @foo;
print "@foo"; # @foo [2]
[1] Variable @foo exists, so it is interpolated. Separator character
might or might not be space, null string, whatever.
[2] Variable @foo does not exist, so is used as literal value,
possibly with warning. I don't know if there would be a difference
between these:
undef @foo
delete ::{'@foo'} # Perl5 syntax...still correct?
If there is, then probably the latter is required.
--
[EMAIL PROTECTED]
Re: Why do users need FileHandles?
On Sat, Jul 24, 2004 at 02:23:10PM -0700, Brent 'Dax' Royal-Gordon wrote:
> Jonadab the Unsightly One wrote:
>
> >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.
Definitely. On the other hand...I find myself wondering if we could
offer a pragma so that people can have the option if they want it.
For example:
#!/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.
Re: Why do users need FileHandles?
On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:
> On Sat, Jul 24, 2004 at 02:50:18PM -0700, David Storrs wrote:
> > #!/usr/bin/perl6
>
> #!/usr/bin/perl
I stated perl6 explicitly to be, well, explicit.
> > #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 Acme::Intraweb;
>
> > use SomeModule; #
> > use OtherModule;#
> > use Foo;# If these are not installed,
> > use Bar;# they will be auto-installed.
> > use Baz;#
> > use Jaz;#
> > }
>
>
> However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS
> has, so I'm not sure if it still works. Both are by Jos Boumans.
Urrmmm...ok, I'm sure I'm just being dense here, but I do not see your
point. Can you unpack it for me?
--Dks
Re: Why do users need FileHandles?
On Fri, Aug 13, 2004 at 10:53:02AM +0100, Nicholas Clark wrote: > On Wed, Aug 11, 2004 at 03:25:20PM -0700, David Storrs wrote: > > On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote: > > > > However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS > > > has, so I'm not sure if it still works. Both are by Jos Boumans. > > > > Urrmmm...ok, I'm sure I'm just being dense here, but I do not see your > > point. Can you unpack it for me? > > IIRC you said "it would be good if perl6 could do this" > > My point was that Jos wrote a module for perl5 that could do this last year. > However, I suspect if you attempt to install it from CPAN today it will > break, because it's not been updated to cope with changes to CPANPLUS, > upon which it depends. Ah. Thanks, that makes it more more clear. I'll look into Acme::Intraweb. --Dks
Re: Revision of A12's lookahead notions
On Tue, Aug 10, 2004 at 11:07:59AM -0700, Larry Wall wrote:
>
> 2) In the absence of evidence to the contrary, methods always
> assume they have *no* arguments. For methods:
>
> 2a) A method not followed by a left paren or colon has no
> arguments.
Just checking--whitespace doesn't count, right?
foo(1,2,3);# Func with 3 args
foo (1,2,3); # Same exact thing
When you say "*no* arguments", does that mean that they do not get
passed the implicit $self ref? (Or is that even relevant anymore?)
> 2b) As with multies, method declarations can have no effect on the
> parsing of methods. Unlike multis, the default is no arguments.
So, this doesn't work:
method foo($$$);
.foo 1,2,3; # WRONG!
> 2d) Given 2c, additional arguments may occur as adverbs
> whether or not there is an argument "pill":
"pill" == parenthesized arg list?
> 3) A bare {...} where an operator is expected always terminates the
> current list operator, and takes the precedence level back to statement
> level. That is, it pops all the implicit left parentheses of list
> operators with implicit right parentheses.
Is that a metasyntactic {...} or a literal y3 (yadda-yadda-yadda)
operator?
(Side note: This is my biggest problem with this operator--it makes
discussions about pseudo- and/or skeleton code highly ambiguous.)
> 3a) Note that an operator {...} cannot occur in the arguments of either
> a function or a method. Operator {...} is reserved for statement level
> control flow blocks.
> if blurk {...} {...}# 1st closure is arg, 2nd ifblock
> if blurk(1) {...} # closure is ifblock
> if blurk 1 {...} # closure is ifblock
> if .blurk {...} # closure is ifblock
> if .blurk {...} {...} # 1st is ifblock, 2nd is bare block?
Does that final question mark indicate uncertainty on your part about
how the language should be defined, or uncertainty on the parser's
part about what the code means?
> if .blurk 1 {...} # ILLEGAL
Just checking...this is illegal because 2c says that "[t]he only way
to pass arguments to a method is by an explicitly parenthesized list
or by adverb. Or by both." Correct? If the '1' wasn't there, then
you'd have a legal statement (as per example above).
> 3b) Term {...} cannot assume a comma after it if the next thing is
> a closure. Otherwise the first line under 3a breaks. The fifth
> line with a bare block is a bit problematic as a silent failure mode
> if the user expects the first block to be an argument to .blurk, which
> it isn't.
>
> 3c) Actually, despite the fact that I stated 3 in terms of
> precedence, as far as the parser is concerned 3 probably
> means that statement control things are parsed top down,
> and the bottom up expression parser simply stops when it hits
> an operator {...}.
>
> 4) Adverbs apply to the previous unparenthesized prefix, infix,
> or postfix operator, bypassing simple terms and other "pill"
> operators such as circumfix or postcircumfix.
>
> $a + $b :foo# applies to +
> $a + @b[2] :foo # applies to +
> $a + int($b) :foo # applies to int
> $a + (int($b)) :foo # applies to +
> @a.=sort:{ +$_ }# applies to .sort
> @a.sort(:quick):{ +$_ } # applies to .sort
> @a.sort:quick:{ +$_ } # both adverbs apply to .sort
Yoiks. This gives me the screaming willies. Couldn't we make it nice
and simple and say that adverbs must immediately follow (or
immediately precede, whichever you prefer, but pick one) their
operator?
$a +:foo $b # applies to +
$a +:foo @b[2] # applies to +
$a + int:foo($b)# applies to int
$a + (int($b)) :foo # WRONG!
@a.=sort:{ +$_ }# applies to .sort
@a.sort(:quick):{ +$_ } # applies to .sort
@a.sort:quick:{ +$_ } # both adverbs apply to .sort
Barring pathological cases where you pile up five or ten adverbs, this
seems like it reads clearer.
And while we're on the subject of making this simpler...there seem to
be a lot of cycles and contortions being devoted to making it possible
to leave the parens off of functions (and maybe method) calls. Is
this necessary? Is it really that big an advantage? Couldn't we just
make a nice, simple, easy-to-explain-and-remember rule that says "When
you call a func/meth, you always use (). Put whatever args you want
inside the ()." ??
Totally unambiguous to the human and the parser, easy to comprehend,
comfortable for people coming from basically any other language. And
it's only two characters.
--Dks
bidirectional iterators
There has been a lot of discussion in the other threads lately about
iterators. I was wondering if there will be an easy way to create a
bidirectional iterator? Toy example to show what I'm thinking:
for(1..10) {
next if /7/; # always skip 7
prev if 9 && !rand 3; # occasionally backup and redo 8
print;
}
More significant example:
class BigNum is Iterator:bi
{
has [EMAIL PROTECTED] is Iterator:bi;
...;
method postfix:*=($arg) {
my @temp is Iterator:bi;
my $carry = 0;
for ([EMAIL PROTECTED]:last_to_first) {
my $num = $_ * $arg + $carry;
my $val = $num % 10;
$carry = int( $num / 10 );
unshift @temp, $val; # efficient because it's a bi Iter
}
[EMAIL PROTECTED] = @temp;
}
};
Sometimes an iterator cannot be bidirectional--for example, reading
from STDIN--but that's fine; not all iterators need to be. And yes,
if I want a linked list, I can use a module off the 6PAN, or write it
myself, but that involves objects and methods. That's a lot of
conceptual overhead for something that may be quite simple.
--Dks
--
[EMAIL PROTECTED]
Re: Reverse .. operator
On Fri, Sep 03, 2004 at 08:09:23AM -0400, Joe Gottman wrote: > > > > -Original Message- > > From: Larry Wall [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 02, 2004 8:41 PM > > To: Perl6 > > Subject: Re: Reverse .. operator > > > > On Thu, Sep 02, 2004 at 08:34:22PM -0400, Joe Gottman wrote: > > : Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? [...] > > : @foo = reverse (1 ..5); > > : > > : but this has the major disadvantage that it cannot be evaluated lazily; > > : reverse has to see the entire list before it can emit the first element > > of > > : the reversed list. > > > > I don't see any reason why it can't be evaluated lazily. The .. produces > > a range object that gets shoved into the lazy list that gets bound to > > the slurp array of reverse(). If you pop that, there's no reason it > > couldn't go out and ask the end of the lazy list for its last element. > > Just have to make .. objects smart enough to deal off either end of > > the deck. > >I get it. One way to implement this would to give the .. object a > .reverse member iterator that lazily iterates from right to left, Hey look: bidirectional iterators. Cool. ;> --Dks
Re: Classes with several, mostly unused, attributes
On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote: I think that "slackness-on-demand" is a better policy than "strictness-on-demand", but that, again, is just my opinion Until now, the policy in Perl has always been that it is as slack and forgiving as possible, and you have to ask if you want it to be strict with you. I hope that doesn't change. --Dks
Re: Classes with several, mostly unused, attributes
On Dec 10, 2004, at 11:05 AM, Abhijit Mahabal wrote:
Consider a class (e.g., the hypothetical Geometry::Triangle) that can
have several attributes (side1, side2, side3, angle1, ang_bisector1,
side_bisector, altitude1 and so forth), most of which will not be
needed for most instances of Geometry::Triangle.
I know how this can be done in P5. Using the layout "Hash" things are
easy. How can P6 deal with this, without allocating too much memory to
things that'd never get used? The layout "P6Hash" could come to the
rescue, but there is still the issue of syntax:
what exactly does C do? IIRC, in the P6Opaque layout,
every instance of the class would have space the size of a PMC
allocated for it. This behavior is not needed for P6Hash, and it
should just leave attributes alone until they are assigned to (where
defaults are also "assigns").
In which case, maybe for that layout we can get away without declaring
all attributes, perhaps? (Since the declaration does nothing except
help the parser).
I was thinking whether we could do something like this:
class Triangle is layout does autovivify{
method calculate_bisectors { $.bisector1 = ...;
# $.bisector1 autovivifies
}
}
where it is an error without the autovivify, and only P6Hash supports
autovivification.
If it's an error without the autovivify and only P6Hash supports
autovivify, then isn't this redundant? Simply saying 'P6Hash' should
get me the autovivify behavior for free. (Incidentally that is 'should'
as in 'that is the way I think it would make sense for it to work in an
ideal universe' not 'should' as in 'based on the implementation, here
is the behavior I expect').
If, for some reason, I DON'T want that behavior, then I can pick
another layout or explicitly say 'does noautovivify'.
Incidentally, I just want to go on record as saying that the verbosity
of class declarations in P6 is really starting to skeeve me. I keep
reminding myself that these are the edge cases that are being
discussed, that you don't need all this stuff for the common case
(right?) that Perl 6 can be pretty much the same easy, succint, fun
language that I know and love, that sensible defaults will be chosen so
that in the common case the things I get automatically are the things I
wanted anyway. But, occasionally, I still find myself going
"eeew...Java."
Re: Classes with several, mostly unused, attributes
On Dec 15, 2004, at 6:11 PM, Abhijit Mahabal wrote: David Storrs wrote: On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote: I think that "slackness-on-demand" is a better policy than "strictness-on-demand", but that, again, is just my opinion Until now, the policy in Perl has always been that it is as slack and forgiving as possible, and you have to ask if you want it to be strict with you. I hope that doesn't change. --Dks There should be little reason to complain so long as it is drop-dead easy to turn on slackness. S01 says: # Perl 5 code is not strict by default, while Perl 6 code is. But it should be easy to relax with -e or maybe even a bare version number: perl -e '$x = 1' #!/usr/bin/perl -e $x = 1; #!/usr/bin/perl v6; $x = 1; Of course, you can counter that with "there should be little reason to complain so long as it is drop-dead easy to turn *strictness* on". But in either case, people are going to trip over this, expecting one(strictness/slacknesss) but getting the other. In one case (expecting slackness, but getting strictness from the compiler) it would be easier for the compiler to know that they have in fact tripped. --abhijit Obviously, however @Larry decide it should be, is the way it'll be and nothing I can say will change that. That said: this would suck. Badly. We should not be optimizing for the compiler's convenience, but for the programmer's. Although I can't prove it, I strongly suspect that the majority of times that someone sits down to do something with Perl, it's a quick one-liner or short script. Strictness just gets in the way for those. (And, for the record; I make my living writing Perl, mostly large programs, and I always use strict in those programs. I want strict. I like strict. Strict is good. I just don't want strict by default.) --Dks
Re: Possible syntax for code as comment
On Sat, Jan 08, 2005 at 12:48:32PM -0800, Ashley Winters wrote:
>
> sub canon( $subjet, $complement)
> -> $s = $subjet{$*Global}, $c = $complement
> {
> my @foo = ...;
> for @foo -> $bar; $remaining = @foo.elems {
> # $bar contains an element, $remaining contains the number of
> elements in @foo
> # or any expression I want, but it's block-scoped here
> }
> }
Out of curiosity, why are we all spelling 'subject' without a 'c'?
Or is 'subjet' a word I'm not familiar with? (Honest question.)
As to the meat of the proposal...I would rather that the aliasing was
done as part of the signature, not afterwards. Keep all the
information that pertains to this parameter in one location.
--Dks
--
[EMAIL PROTECTED]
Re: Dimension of slices; scalars versus 1-element arrays?
On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote: > @a[4; 0..5]; > a 1x6 array (probably correct)? Or a 6 array (probably not > correct)? For the ignorant among us (such as myself), what is a 6 array? Google and pdl.perl.org did not yield any immediate answers. --Dks -- [EMAIL PROTECTED]
Re: Making control variables local in a loop statement
On Thu, Jan 13, 2005 at 07:35:19PM -0500, Joe Gottman wrote:
>In Perl5, given code like
>
> for (my $n = 0; $n < 10; ++$n) {.}
>
> the control variable $n will be local to the for loop. In the equivalent
> Perl6 code
>loop my $n = 0; $n < 10; ++$n {.}
>
> $n will not be local to the loop but will instead persist until the end of
> enclosing block.
Actually, I consider this a good thing. There are lots of times when
I would LIKE my loop variable to persist and, in order to get that, I
need to do the following:
my $n;
for ($n=0; $n<10; ++$n) {...}
...do stuff with $n...
It's a minor ugliness, but it itches at me. Under the new Perl6
rules, I can easily have it either way.
{for (my $n=0; $n<10; ++$n) {...}} # Local to loop
for (my $n=0; $n<10; ++$n) {...}# Persistent
--Dks
Re: Making control variables local in a loop statement
On Fri, Jan 14, 2005 at 02:46:58PM -0500, Austin Hastings wrote:
> >rules, I can easily have it either way.
> >
> > {for (my $n=0; $n<10; ++$n) {...}} # Local to loop
> > for (my $n=0; $n<10; ++$n) {...}# Persistent
> >
> >--Dks
> >
> But there's no clean way to make some of them temporary and some
> persistent.
>
> This seems like a legitimate place for "saying what you intend", viz:
>
> for (my $n is longlasting = 0, $m = 1; ...) {...}
I see your point, but:
- at least in the kinds of programming I do, I rarely use more than
one loop variable (with the exception of nested loops, and even
there the second var is declared in the second loop line)
- even when I do, only rarely do I want some of them to persist and
some not
- if I do, I'm willing to suffer the minor ugliness of putting the
to-be-persistent ones outside the scope, rather than have to use a
property every time I want ANYTHING persistent.
- I would much prefer this:
my ($total, $last_seen, $had_errors) = (0)x3;
for ($my $i=0; $i < @elements; $i++) {...}
To this:
for (my $i=0,
$total=0 is longlasting,
$last_seen=0 is longlasting,
$had_errors=0 is longlasting;
$i < @elements;
$i++)
{
...
}
FWIW
--Dks
Re: S04
Given that Perl 6 won't support an actual do-while loop a la C++ (and
yes, I know that Perl5 didn't either), how would you accomplish that?
That is, I'd like to have a loop that runs once, then checks its
condition to see if it should repeat and continues to repeat as long
as the condition is true.
I don't think this works, but here's what I'm look for:
{
$foo = readline;
...do stuff with $foo...
} while ( $foo );
--Dks
Re: Pop a Hash?
On Wed, Feb 09, 2005 at 05:13:56AM -0600, Rod Adams wrote: > > Does > > ($k, $v) <== pop %hash; > or > ($k, $v) <== %hash.pop; > > make sense to anyone except me? It's clear to me. The only thing is that, right off the top of my head, I can't see where it would be used. Since the order in which the pairs were returned would be effectively random, you can't use this to remove and process a specific element. So, really, the only time it's useful is if you want to process all the elements in the hash--in which case, why not just use C< each >? --Dks -- [EMAIL PROTECTED]
thank you for clarification (was Re: S04)
On Thu, Feb 10, 2005 at 09:45:59AM -0800, Larry Wall wrote:
> That's spelled
>
> loop {
> $foo = readline;
> ...do stuff with $foo...
> } while ( $foo );
>
> these days.
>
> Larry
Cool, perfect. Thanks.
--Dks
--
[EMAIL PROTECTED]
Re: Pop a Hash?
On Fri, Feb 11, 2005 at 05:33:29PM -0800, Ashley Winters wrote: > On Thu, 10 Feb 2005 08:59:04 -0800, David Storrs <[EMAIL PROTECTED]> wrote: > > On Wed, Feb 09, 2005 at 05:13:56AM -0600, Rod Adams wrote: > > > > > > ($k, $v) <== pop %hash; > > > make sense to anyone except me? > > > > ... the only time it's useful is > > if you want to process all the elements in the hash--in which case, > > why not just use C< each >? > > That's true for the PerlHash implementation, but what about > OrderedHash? Or LookupQueue? Still seems like a useful trick. Good point. I'm glad you pointed that out, because it felt like this should be useful...glad to see it was just my imagination that was at fault. :> --Dks -- [EMAIL PROTECTED]
Pick's randomness (was Re: Fun with junctions (was Sets vs Junctions))
On Sat, Feb 12, 2005 at 06:39:01PM +1100, Damian Conway wrote: > pick - select at random from a list, array, or hash OOC, will there be a way to control where C gets its randomness from? (e.g. perl's builtin PRNG, /dev/random, egd, etc) --Dks -- [EMAIL PROTECTED]
Re: Pick's randomness (was Re: Fun with junctions (was Sets vs Junctions))
On Mon, Feb 14, 2005 at 10:43:21AM +1100, Damian Conway wrote:
> David Storrs OOC'd:
>
> >OOC, will there be a way to control where C gets its randomness
> >from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
>
> Sure:
>
> # Use RBR (Really Bad Randomness) algorithm...
> temp *rand (Num ?$max = 1) {
> return $max/2;
> }
>
> my $guess = @data.pick;
Ok, so it requires actually overriding the rand function and providing
your own implementation. I was hoping for something a bit more
automagical (probably involving a property or role, since they seem to
be the answer to everything these days), but this will work fine.
--Dks
--
[EMAIL PROTECTED]
Re: Fun with junctions (was Sets vs Junctions)
On Tue, Feb 15, 2005 at 11:06:51AM -0800, Larry Wall wrote: > > But what y'all are talking about above is the other end--the return > type. And maybe we need to enforce a newbie-friendly invariant on that > end as well. I suppose we could default to not accepting junctional > return values by default, and have a pragma to turn it on. Or perhaps > the problem isn't returning junctions per se, but storing them into > a variable that the user is thinking of as a simple scalar value. Pardon me while my brain autothreads: - But restrictions aimed at newbie-friendliness are a drag! People are only newbies for a little while, and they are intermediate-to-expert for a lifetime! Isn't the whole philosophy of Perl "we will trust that you know what you're doing and only enforce the B&D if you ask for it"? - Shut up, nitwit. Trust $Larry. Every time you have doubted his decisions in the past, he's been right and you've been wrong...or, at the very least, it has turned out to not be as bad as you first thought. --Dks -- [EMAIL PROTECTED]
Re: Fun with junctions (was Sets vs Junctions)
On Mon, Feb 21, 2005 at 11:01:45AM -0800, Larry Wall wrote:
>
> But rather than that, I suspect we'll see more use of constructs
> where the object to be mutated ends up being the topic, as in:
>
> some_complicated_lvalue() but= { .sortmyway(foo($_),bar($_)) }
>
> which would presumably do the same as
>
> my $noun is rw := some_complicated_lvalue();
> $noun = $noun but { .sortmyway(foo($_),bar($_)) };
>
> which presumably means something like
>
> my $noun is rw := some_complicated_lvalue();
> $noun = $noun.copy.=sortmyway(foo($noun),bar($noun));
>
> Larry
I assume that $noun.copy means that we are making a copy of the object
and changing the copy. That has memory and side-effect implications.
How would one do this as a mutation/in-place-edit, instead of a copy?
--Dks, who recognizes what "presumably means something like" means but
is curious anyway
Re: Config Variables (TRIVIAL FLUFF POST)
On Thu, Mar 03, 2005 at 04:09:26PM -0800, Larry Wall wrote: > On Thu, Mar 03, 2005 at 12:36:00PM -0800, Brian Ingerson wrote: > > : Thanks for the mind expanding reply. > > You're welcome. Next time don't eat blue sugar cubes from my frig. :-) "I know what you're thinking. 'Why, oh why, didn't I take the RED sugar cube?'" Sorry. --Dks
Re: Optional binding
On Sun, Mar 06, 2005 at 11:58:43PM -0800, Larry Wall wrote:
> On Sun, Mar 06, 2005 at 02:13:09AM -0700, Luke Palmer 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);
>
> I think it should say something like:
>
> Use of undefined value at foo line 2
> x = ; y = 1 2 3; z =
>
> Optional parameters are greedy, and @a means [EMAIL PROTECTED] in a scalar
> context.
>
> Larry
Urk. I, for one, will definitely find this surprising. I would have
expected:
x = ; $y = 1; z = 2 3
But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).
--Dks
--
[EMAIL PROTECTED]
Re: [RELEASE] Parrot 0.1.2 "Phoenix" Released!
On Sun, Mar 06, 2005 at 04:57:38PM +0100, Leopold Toetsch wrote: > On behalf of the Parrot team I'm proud to announce the release of > Parrot 0.1.2. First: Congratulations to everyone for this release! Second: What will it take before Parrot moves to a 0.2 (0.3, 0.4...) release? --Dks
Re: Comma in (sub) traits?
On Mon, Mar 07, 2005 at 03:43:19PM +0100, Aldo Calpini wrote:
> don't know if it helps, but I guess that you can also write it like
> this, if you prefer:
>
> sub greeting(Str $person) {
> returns Str;
> is export;
> "Hello, $person";
> }
>
> (this guess is based on something I recall having read in A12 about
> classes; if my guess is wrong, I'll be happy to stand corrected :-).
On reflection, I see why that probably works. I also pray that I
never have to maintain code that uses it, because it seems very
misleading. .
--Dks
--
[EMAIL PROTECTED]
Re: Optional binding
On Mon, Mar 07, 2005 at 05:36:08PM +0100, Aldo Calpini wrote:
> David Storrs wrote:
> >Urk. I, for one, will definitely find this surprising. I would have
> >expected:
> >
> > x = ; $y = 1; z = 2 3
>
> to obtain what you have expected, you need to explicitly treat the array
> as a list of values with the unary splat:
>
> foo($x, [EMAIL PROTECTED]);
>
> >But I suppose it's all a question of learning to love the Brave New
> >World in which arrays are actually objects (sort of).
>
> more to the point, arrays are automagically referenced in scalar context:
>
> @a = @b; # same as perl5
> $a = @b; # means $a = [EMAIL PROTECTED] in perl5
> $a = [EMAIL PROTECTED]; # means $a = @b in perl5 (more or less)
Yes, I know. That's what I meant by "...arrays are objects...(sort
of)." They are objects in the sense that they are sort of references
and sort of not and that they have behavior built into them
(e.g. C<.length>). They won't actually have a class (I don't
think...type Array is not the same as a hypothetical class Array,
right?), but otherwise they quack awfully much like an object.
> another thing that may surprise you (it still surprises me, somehow):
>
> sub bar($x, $y, $z) { ... }
> # ^ note x is scalar here!
>
> my @coords = (1.0, 3.0, 5.0);
> bar(@coords); # wrong
> # x => [EMAIL PROTECTED], y => undef, z => undef
>
> bar([EMAIL PROTECTED]); # ok
Yep, I am pretty sure that's going to trip me up endlessly for the
first 6 months or so.
To be perfectly honest, there are steadily more things I don't like
about the way Perl 6 is going, especially when it comes to signatures.
They are excessively verbose, they lead to (what I think is, and what
I suspect most Perl 5 programmers will think is) weird behavior like
that described above, and the type system feels like a straitjacket.
I know all these features are optional, but they WILL be used, which
means I have to know them so that I can maintain other people's code.
Essentially, it feels like we're turning our beautiful language into
something that has all the fun of Java but without Sun's marketing
budget.
But, every time I find myself thinking these things I take a deep
breath, put my faith in Larry, and assume that it will work out--I
really do have an amazing degree of faith in his ability to pull off
miracles. Hopefully, after I have a chance to play with the
production version of P6 for a while, all of these things that
currently seem like effluent will start to see like useful tools.
Fingers crossed,
--Dks
--
[EMAIL PROTECTED]
Re: Optional binding
On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
>
> In fact, we really haven't specified what happens when you say
>
> my Int @a is shape(3) := [1,2];
> my Int @b is shape(3) := [1,2,3,4];
>
[...]
> But I also have this nagging feeling that the user wouldn't have
> specified shape(3) unless they actually meant it. But I suspect
> that in the typical case, they really do want a 3-element vector,
> nothing more, nothing less.
I agree that this is undoubtedly what they meant. I wonder though, if
there is then any way to explicitly leave off an element. Can I do
this:
sub foo( Int @a is shape(3) ) { ... }
foo(1, 2, undef);
--Dks
--
[EMAIL PROTECTED]
Re: Optional binding
On Mon, Mar 07, 2005 at 05:15:14PM -0800, Larry Wall wrote: > On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote: > : Yes, I know. That's what I meant by "...arrays are objects...(sort > > No, they're real objects. (Though it's .elems rather than .length, since > we've banished the "l" word from our vocabulary.) Ah, ok. I've got to scrape up the tuits to go back and reread the A&Es. Actually, I guess they would have to be...can you apply a role to a bare type? my int does SelectOutputFile; # I would expect this to fail my Int does SelectOutputFile; # I would expect this to work > : But, every time I find myself thinking these things I take a deep > : breath, put my faith in Larry, and assume that it will work out--I > : really do have an amazing degree of faith in his ability to pull off > : miracles. Hopefully, after I have a chance to play with the > : production version of P6 for a while, all of these things that > : currently seem like effluent will start to see like useful tools. > > And I have put my faith in the Perl community, and assume it will work > out, because I have an amazing degree of faith in the ability of the > community to recognize the real effluent and avoid it. :-) I think I've just been very, very gently poked. :> For the record--just because I personally dislike these things doesn't make them bad, or even bad for the language. I didn't even say that they WERE effluent, just that right now they seem that way to me personally...and I'm trying to get past it. As I said, I'm confident it will all work out well in the end. > > : Fingers crossed, > >Niy ygsy ,sjra uy s ;py gsefre yp ytor/// > >:seet At first I thought I had annoyed you enough that you were attempting to summon an Elder God through my terminal. Then I realized that it works out to: But that makes it a lot harder to type... Larry Owie...stop making my head hurt! :> --Dks -- [EMAIL PROTECTED]
Re: Optional binding
On Mon, Mar 07, 2005 at 07:50:47PM -0800, Larry Wall wrote:
> On Mon, Mar 07, 2005 at 05:37:53PM -0800, David Storrs wrote:
> : On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
> : Is
> : there is then any way to explicitly leave off an element. Can I do
> : this:
> :
> : sub foo( Int @a is shape(3) ) { ... }
> : foo(1, 2, undef);
>
> That's illegal unless you either * the @a or [] the list.
Argh. My bad, I meant to * the @a. Ok, rewrite; is THIS legal?:
sub foo( Int [EMAIL PROTECTED] is shape(3) ) { ... }
foo(1, 2, undef);
The sense I'm trying to convey is:
"Here is my sub. It takes three ints."
"Here is me calling the sub. I am giving you only two ints and
explicitly telling you [by explicitly passing undef] that I meant
to do that so just take it and be quiet."
To put it another way...in perl5, a sub that was prototyped to take
three scalar args will throw an error when you pass only two but will
accept it if you pass two plus an explicit undef. On the other hand,
if it was prototyped to take an array there is no way to tell the
difference between an explicitly-passed undef and a too-short arg
list. How will P6 handle these two scenarios?
--Dks
finding the name of &$SUB ?
Is there a way to find the name of &?SUB ? It would be useful for error-logging and -reporting. --Dks
Re: some misc Perl 6 questions
On Tue, Mar 08, 2005 at 10:29:30PM -0800, Darren Duncan wrote: > [...] > > By using subtypes in this way, I could remove a lot of explicit input > checking code from my methods, which is great. Also, the "where > clause" is not being repeated for every argument or attribute or > variable declaration. (I like SQL domains for the same reasons.) That's very cool. I start to see the appeal of AOP. > 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. >[...] > Also, does my request sound like something that would be reasonable > to do, or a bad practice to avoid? FYI, in C++, the keyword 'friend' precisely describes the relationship you are discussing (and appears to be homologus to P6 'trusts'). There are good and bad things to be said about these relations but, IME, they are usually used because they have to be in order to achieve certain behavior, not because it is the cleanest or most appropriate way to build the model. Therefore, I would be very cautious about using 'trusts'. YMMV. --Dks -- [EMAIL PROTECTED]
Re: MMD as an object.
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
> There lingers the case of:
>
>use Foo; # from above, exports &bar is MMD::Random
>
>multi sub bar {...}
>
> Does this generate an error, since one could expect this particular &bar
> to be Manhattan? Or does it assume Random, since there's already a &bar
> in existence? In my head, it currently makes sense to say that the new
> &bar inherits the Random policy. Only something like:
This seems like action-at-a-distance to me; I use some random module,
define a couple of multis without realizing that they also exist in
the module, and am baffled as to why I don't get the dispatch behavior
I expect.
--Dks
Re: Adding linear interpolation to an array
> At 17:53 +0100 3/10/05, Thomas Sandlaß wrote: [request for clarification of 'covariant' and 'contravariant' usage] > >'Co' means together like in coproduction. And 'contra' is the opposite > >as in counterproductive. With instanciating parametric types the question > >arises how a subtype relation between instanciating types propagates > >to the template. E.g with Int <: Num, covariance would result in > >Array[Int] <: Array[Num]. Referential classes are actually quite difficult > >because upon write they are contravariant and covariant when read! > >So a third case of uncomparable types is needed as well, or it is the default > >if nothing else is specified. Thomas, I appreciate you attempting to explain this, but it remains clear as mud, at least to me. Could you please try again, using very short, very non-technical words and not assuming a mathematical or scientific background on the part of your reader? Something that would help: We could all look the words up in a dictionary, so we don't need a definition. What we need is a clarification, in simple terms, of what *you* mean by them, in this context. Thank you. --Dks
Re: MMD as an object.
On Thu, Mar 10, 2005 at 02:22:20PM -0600, Rod Adams wrote:
> David Storrs wrote:
> >On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
> >> use Foo; # from above, exports &bar is MMD::Random
> >> multi sub bar {...}
> >>
> >>Does this generate an error, since one could expect this particular &bar
> >>to be Manhattan? Or does it assume Random, since there's already a &bar
> >>in existence?
> >
> >This seems like action-at-a-distance to me;
> >
> Well, if you were not expecting Foo to export some &bar's, then you're
> in for a surprise regardless of dispatch when you call &bar in your code
> and one of Foo::bar gets called instead of one of yours, because it was
> a closer match.
>
> I would say that people should know what they are getting into when they
> C< use > something.
What I'm hearing you say here is "Yes, it's action-at-a-distance, but
it's your job to make sure it doesn't trip you up." The problem that
I see is that I may well be able to keep track of everything from the
modules I import, but what about the ones THEY import...and the ones
THEY import...and so on. In a medium-to-large software project, that
can get to be a lot of modules, very quickly.
--Dks
Re: lists in string context
On Sat, Mar 12, 2005 at 09:36:24PM +0100, Juerd wrote:
> Larry Wall skribis 2005-03-12 12:26 (-0800):
> > And arguably, the current structure of join is that the delimiter is
> > the invocant, so cat should be defined as
> > ''.join(@foo)
>
> This is what Python does. It does not make any sense to me, and I can't
> wrap my mind around it at all. Ruby-ish @foo.join('') seems more
> natural.
>
> Just like with how I prefer $fh.print($text) to $text.print($fh), I
> cannot explain WHY this is how my mind works.
I'm with you. In my opinion, it is weird to call a method against a
constant value; values aren't supposed to do things, they are supposed
to have things done to /them/. For similar reasons, it is only
slightly less weird to call a method on a variable when that variable
is simply a container for a constant value.
A variable that contains an object or "interface element" (e.g. a
filehandle), I can understand calling methods against that.
Ob flame retardant: I'm not saying that my opinion is necessarily
right, or the other way isn't valid. Just offering a thought on why
Juerd might have this feeling.
--Dks
Re: s/true/better name/
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > On Tue, Mar 15, 2005 at 10:51:57AM +0100, Juerd wrote: > : Autrijus suggested "indeed" or "id", of which I like "indeed" better, > : because I'd like to continue using "id" with databases. > > "id" is too heavily overloaded with identifiers and identities and such. > But "indeed" doesn't work right in context, "while indeed..." > > I'd go with either "istrue" or "so". "ok" is another possibility, > though that seems to connote definedness more than truth. It also breaks a huge percentage of the testing code that we would like to be able to automagically port from P5 to P6. --Dks -- [EMAIL PROTECTED]
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, Mar 16, 2005 at 12:00:28PM -0500, Aaron Sherman wrote:
>
> The one obvious thing to POD users is the replacement of <> with [] or
> {}. Why is this? Because < and > are used in un-balanced ways in a large
> number of situations, so they should not be the primary bracketing
> constructs.
Actually, I quite like <> as the bracketing characters. They are
visually distinctive, they connect well with their adjacent C/X/L/etc
without visually merging into it (compare L with L[foo]), and in
the circumstance that you want to bracket an unbalanced bracket, you
just double (triple, whatever) up and add some space:
C<< $x > $y >>
Looks pretty clear to me.
--Dks
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, Mar 16, 2005 at 01:30:04PM -0500, Aaron Sherman wrote:
> On Wed, 2005-03-16 at 12:25, David Storrs wrote:
>
> > I quite like <> as the bracketing characters. They are
> > visually distinctive, they connect well with their adjacent C/X/L/etc
> > without visually merging into it (compare L with L[foo]), and in
> > the circumstance that you want to bracket an unbalanced bracket, you
> > just double (triple, whatever) up and add some space:
> >
> > C<< $x > $y >>
> >
> > Looks pretty clear to me.
>
> You are confusing aesthetics with usability.
No, I am relating simplicity and consistency to usability. If it
costs two extra keystrokes, I'm cool with that.
> and noting could be simpler than:
>
> C[$x > $y] is about as B[easy] as it gets in [Perl]
C[$x[0] > $y] # hmmm...parser ok with that?
C[$x[0] > $] # hmmm...error, but what was intended: $y] or $]]?
C<< $x[0] > $y >> # parser's ok (so's the human)
C<< $x[0] > $ >> # oh, obviously $y was intended
> However, saving a couple of keystrokes and cleaning up the above text is
> inconsequential compared to
"...the power of the Force." Sorry, had to say it.
> the massive savings in terms of taking
> advantage of the legions of people who are learning Wiki syntax these
> days. Making POD *more* Wiki-like without sacrificing useful features of
> POD is invaluable in terms of tech writers and other
> non-Perl-programmers writing useful docs in POD!
Here's the real crux of your argument, and the real crux of my problem
with this approach. I don't like Wiki syntax; to me, it seems
arbitrary and non-unified. I use Wikis, I run one, I recognize their
usefulness. I just don't like them.
Here are some of the formatting rules for TWiki (the Wiki version I
use):
1) Elements of a bulleted list must match /^ {3}\* /
2) Elements of a numbered list must match /^ {3}1 /
3) Headings must match /^*\++/. Number of +s determines level
4) *bold*
5) /italic/
6) =fixed font=
7) put text to be rendered as-is here
What is the organizing priciple? What similarities do they have?
Quick, what level heading is this: + ? And this is just the
beginning...I didn't even get into the weird cases like ==bold fixed
font== and __bold italic__, which have no perceptible relation to
their component pieces (I would have expected */bold italics/*). Yes,
it's powerful and it can do useful things, but as soon as I stray from
the most basic stuff I find myself going back to the docs to look up
how it's done.
Contrast this to POD (I'm not trying for point-to-point equivalence):
1) All formatting starts with = in the first column.
2) Every POD command must have a blank line above and below it.
3) A list of any type starts with =over N and finishes with =back
4) List items are denoted with =item X where X is either * (bullets),
an int (numbered), or word/phrase. Use only one type per list.
5) Headings are denoted by =head1, =head2, etc
6) Formatting effects are done with X where X is one of:
B (bold), C (code), I (italics). You may also use
X<< text >> or X<<< text >>> if you have < or > in your text.
7) Text that is indented will be rendered as-is in fixed width font.
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.
I freely admit that the link syntax in POD is difficult to manage and
not as powerful as it could be.
--Dks
PS I'm subscribed to the list so feel free to just reply there; I
don't need a personal copy as well.
--
[EMAIL PROTECTED]
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, Mar 17, 2005 at 05:04:53PM -0500, Aaron Sherman wrote: > On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote: > > > The interesting thing to me is that all 3 syntaxes map over the same > > data model and thus are easily interchangable. > > It is, however, contrary to the spirit of POD for you or me to continue > much further down this road (see below). > > > Sam "mugwump" Vilain [...] > > is working on more formally defining the common model or "AST" that > > these dialects map to. > > My effort here was to try to PREVENT the proliferation (e.g. by Kwid and > POD butting heads and ending up in a stalemate). > > I'll continue only as far as is needed to propose this in full as an > example parser / converter, and then I'm going to stop. If Brian is correct about the fundamental interchangeability of these dialects (and I have no reason to think he isn't), may I suggest that the simple answer is to have a program which can translate from one dialect to another--just like we distribute pod2man, pod2html, and pod2text, we would now distribute pod2kwid and ajskwid2pod. --Dks -- [EMAIL PROTECTED]
Perl5->P6 convertor as refactoring tool
On Sat, Mar 26, 2005 at 10:13:54AM -0800, Larry Wall wrote: > The thing is that these MAD props are hung on whatever node is handy > at the time, [...]. That's the main reason for the first pass of > translator, to reattach the madprops at a more appropriate place in > the tree. > [...] > But with comments you'd like them > to travel with the code they're commenting, in cases where refactoring > moves code around. So, what I'm hearing you say is that you have just written the very very basic skeleton--maybe even just the backbone--of a Perl refactoring browser. Is that correct? Once you're done, could the community take this tool that you're producing and flesh it out into something that would allow for straightforward refactoring and reformatting of Perl code? --Dks
Re: Blocks, continuations and eval()
On Fri, Apr 08, 2005 at 05:03:11PM +0300, wolverian wrote: Hi wolverian, > one day a friend asked if Perl 5 had a REPL facility. > (Read-Eval-Print-Loop). I told him it has perl -de0, which is different > [...] > In Perl 6, the generic solution to fix this (if one wants to fix it) > seems, to me, to be to add a .eval method to objects that represent > scopes. I'm not sure if scopes are first class values in Perl 6. Are > they? How do you get the current scope as an object? Are scopes just > Code objects? I'm unclear on what you're looking for. Are you trying to get a way to do interactive coding in P6? Or the ability to "freeze" a scope and execute it later? Or something else? --Dks -- [EMAIL PROTECTED]
Re: Pugs 6.2.0 released.
On Wed, Apr 13, 2005 at 03:50:38AM +0800, Autrijus Tang wrote: > I am delighted to report that the first major milestone of Pugs, version > 6.2.0, has been released to CPAN: Autrijus and everyone else who has been working on Pugs, As someone who has been following the Perl6 lists for years, I'd like to say thank you very much for this work. You guys are great. --Dks (wishing he had the tuits to help :<) -- [EMAIL PROTECTED]
turning off warnings for a function's params?
I image we've all written logging code that looks something like this
(Perl5 syntax):
sub foo {
my ($x,$y) = @_;
note("Entering frobnitz(). params: '$x', '$y'");
...
}
This, of course, throws an 'uninitialized value in concatenation or
string' warning when your test suite does this:
is( foo(undef, undef), undef, "foo(undef, undef) gives undef" );
In a testing environment, I don't want to see this warning. In a
production environment, I do. Furthermore, when I want it gone, I
want it gone from every instance of C, without having to change
something in every location. I suppose I could change all my logging
calls to look like this:
{
if ( $DEBUG ) { no warnings 'uninitialized'; note(""); }
else { note(""); }
}
But that's really ugly, takes up a lot of space, is confusing, and is
redundant.
How would I best solve this problem in Perl6?
--Dks
--
[EMAIL PROTECTED]
Re: turning off warnings for a function's params?
On Mon, Apr 25, 2005 at 05:18:11AM -0600, Luke Palmer wrote:
> David Storrs writes:
> > sub foo {
> > my ($x,$y) = @_;
> > note("Entering frobnitz(). params: '$x', '$y'");
> > ...
> > }
> > This, of course, throws an 'uninitialized value in concatenation or
> > string' warning when your test suite does this:
> > is( foo(undef, undef), undef, "foo(undef, undef) gives undef" );
> > How would I best solve this problem in Perl6?
>
> Of course, no ordinary definition of a note() sub will work, since the
> concatenation happens before note is even touched.
Exactly; that's why I asked "how would I solve this", instead of "how
would I write note()".
> However, a macro could do it. It might go something like this:
>
> macro note(Perl::Expression $expr)
> is parsed(/$ := /)
> {
> $expr.compile(:warnings(0));
> }
>
> Luke
Cool. But that seems to turn off all warnings during the compilation
of the expression--I only want to get rid of the (expected)
'uninitialized' warning. Will there be a way to do finer-grained
control?
--Dks
--
[EMAIL PROTECTED]
Re: Junctions of classes, roles, etc.
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. --Dks
Re: Junctions of classes, roles, etc.
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
> On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
>
> >David Storrs <[EMAIL PROTECTED]> wrote:
> >>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.
> >>I'm quite willing to believe that there are [good results], but I'm not
> >>coming up with them.
> >What do you think this is?
> >
> > sub foo(Str | Int $bar) { ... }
>
> I believe you mean sub foo(Str^Int $bar){...} ( something that is Int or
> Str but not both). But that, too, just reduces the amount of code and is
> merely a shortcut for:
> multi sub(Str $bar){...}
> multi sub(Int $bar){...}
>
> 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.
Indeed, you're right on the money, Abhijit. Thanks for stating it so
well.
Let's move this away from simple types like Str and Int for a moment.
Tell me what this does:
class Tree {
method bark() { die "Cannot instantiate a Tree--it is abstract!" }
}
class Birch {
method bark() { return "White, papery" }
}
class Oak {
method bark() { return "Dark, heavy" }
}
class Dog {
method bark() { print "Woof, woof!"; return "bow wow" }
}
class AlienBeastie isa Tree isa Dog {}
class WhiteAlienBeastie isa Birch isa Dog {}
class HeavyAlienBeastie isa Oak isa Dog {}
sub Foo(Tree|Dog $x) { $x.bark() }
Ignore for the moment that this is stupid code--it's semantically and
(AFAIK) syntactically valid. So, what happens when I do each of these:
Foo( new AlienBeastie() );
Foo( new WhiteAlienBeastie() );
Foo( new HeavyAlienBeastie() );
??
--Dks
Re: Junctions of classes, roles, etc.
On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandlaß wrote:
> David Storrs wrote:
> >Let's move this away from simple types like Str and Int for a moment.
>
> If you consider them simple...
When compared to
"arbitrary-class-that-was-defined-by-
arbitrary-programmer-of-
arbitrary-and-unknown-skill-level"
then yes, I consider them to be extremely simple.
> >Tell me what this does:
> >
> >class Tree {
> > method bark() { die "Cannot instantiate a Tree--it is abstract!" }
> >}
> >class Birch {
> > method bark() { return "White, papery" }
> >}
> >class Oak {
> > method bark() { return "Dark, heavy" }
> >}
> >class Dog {
> > method bark() { print "Woof, woof!"; return "bow wow" }
> >}
>
> Four 'pure' classes so far.
Dog is not pure according to the definition of "pure class" that I
know (no side effects in any method, constructor, or subclass). Maybe
'pure class' means something else to you?
> >class AlienBeastie isa Tree isa Dog {}
>
> Here you get an error/warning of a composition time conflict between
> &Tree::bark and &Dog::bark.
So that I'm clear, is this your opinion/preference or is it based on
material from the SEAs? If the latter, could you point me to the
relevant passage?
> My preferred
> syntax for multiple inheritance is the junctive notation 'is Tree & Dog'
> for subclassing because it nicely allows for superclassing with
> 'is Tree | Dog'.
Again, so that I'm clear--this is your preference, and is not derived
from any authoritative source, correct?
> This might dispatch correctly for 'pure' Trees, Dogs etc.
> but not for your mixed classes above.
As I noted above, Dog is not 'pure' by the definition I know so I'm
not sure what to make of this statement.
--Dks
