Re: Syntax of using Perl5 modules?
You get all those possibilities whenever you install any new version of a module you get from someone else, regardless of a p5-p6 hop. In p6, when you say use Digest;, you are specifically asking for what p6 considers the latest version. In p5, it was first match on libpath. Except that within Perl 5, there is an general expectation that the same API will exist across multiple module versions. It is assumed that newer versions of a module will continue to work the same as older ones, with API breakages being a bad and rare thing. The 6 month long mod_perl Apache::-Apache2:: argument was over this very thing. There is a huge difference between an API version and a module (implementation) version. As far as I'm aware, there is no expectation that *every* module in Perl 6 that shares a name with a module in Perl 5 will merely be a re-implementation of the same API in Perl6. If I am expected to reimplement all my Perl 5 modules in Perl 6 without the opportunity to do a better job and take advantage of new Perl 6 API-related features, could someone please point my boot in the general direction of the ass of whoever came up with that idea. Adma K
RE: (OT) Re: Perl development server
Icelandic: laukur (Incidentally, none of you will ever guess how to correctly pronounce that.) Russian: luk (pronounced similar to English look). For some reason, Icelandic translation of onion is much closer to Russian than any other variants...
Re: Sets (was: Reductions, junctions, hashslices, and cribbage scoring)
On Thu, 26 May 2005, Patrick R. Michaud wrote: The continuing exchanges regarding junctions, and the ongoing tendency by newcomers to think of them and try to use them as sets, makes me feel that it might be worthwhile to define and publish a standard CSet class and operations sooner rather than later in Perl 6 development. This might reduce the tendency to confuse junctions I fully second that. You can search the archives for my own thoughts on the subject. Michele -- you'll see that it shouldn't be so. AND, the writting as usuall is fantastic incompetent. To illustrate, i quote: - Xah Lee trolling in clpmisc, perl bug File::Basename and Perl's nature
Re: Syntax of using Perl5 modules?
Adam Kennedy wrote: You get all those possibilities whenever you install any new version of a module you get from someone else, regardless of a p5-p6 hop. In p6, when you say use Digest;, you are specifically asking for what p6 considers the latest version. In p5, it was first match on libpath. Except that within Perl 5, there is an general expectation that the same API will exist across multiple module versions. It is assumed that newer versions of a module will continue to work the same as older ones, with API breakages being a bad and rare thing. The 6 month long mod_perl Apache::-Apache2:: argument was over this very thing. There is a huge difference between an API version and a module (implementation) version. As far as I'm aware, there is no expectation that *every* module in Perl 6 that shares a name with a module in Perl 5 will merely be a re-implementation of the same API in Perl6. If I am expected to reimplement all my Perl 5 modules in Perl 6 without the opportunity to do a better job and take advantage of new Perl 6 API-related features, could someone please point my boot in the general direction of the ass of whoever came up with that idea. soapbox Across all languages, libraries, modules, applications, operating systems, and most everything else in the computer world, I expect interoperability to remain mostly the same across minor version numbers, but anything goes when a new major version comes out. Now, I'm not terribly active in the CPAN arena, but I think it's short sighted to expect the API from version 1.1.5 to still be there in 2.7.1. This phenomenon is why it's fairly common to see the last minor version of the previous major version still around and available in many areas. Major changes in usage and syntax are what major version jumps are all about. /soapbox As an alternative, the URI field of the module version could be extended to have the API version mixed somehow, maybe cpan:JRANDOM#1.5.6. But that gets non-intuitive and ugly very quickly. Part of the p5 problem is that module upgrades were all or nothing. In p6, you'll be able to load both the old version and the new version, at the same time. Or just tell the old apps that you don't have time to fix to use versions 2.0.0, and the new apps to use version = 2.0.0. Another part of the problem with p5 is that while there was the ability to spec a version in a 'use' call, it was only a lower bound. You couldn't specify an upper bound as well, to tell people that you weren't ready for a new API/semantics. (To my knowledge, _nobody_ overrides the VERSION method) Personally, I would prefer having to track which major version number I'm using over the mess that's in CPAN, where it seems like the standard way to introduce a new API is to come up with a new name for the module that means the same thing. However, as I pointed out before, since in p5 there is no notion of an author URI, haveing that become the string 'perl5' makes sense, and could be matched against, both positively and negatively. -- Rod Adams
Method overloading, MMD/SMD
In Synopsis 13 MMD is discussed as the mechanism for overloading an operator. Many a times I would like to overload a method of a class. I just played around with this: http://svn.openfoundry.org/pugs/modules/Class-Events/lib/Class/Events.pm Notice how the Named event variation appends the role, adding some more specific signatures to familiar functions, to increase dwimmery. How do i get this to behave? Do I need to say all the methods that can ever be overloaded are multi? Or do I say that only the overloading ones are multi? If the first - how do I get a delegation to be multi? Does that rely on the delegation handler method? Also, is SMD not possibly representable in MMD? Is SMD a subset of MMD or a completely different system? Also on a side note, say I have two roles, both of which define the private attribute $.:horse. Do these attributes conflict, or does each role get it's own slot? What about MI/mixins? Grazie -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me tips over a cow: neeyah!! pgpY3osGEiO6Z.pgp Description: PGP signature
Re: (1,(2,3),4)[2]
Markus Laire wrote:
@m[0;1] is a multidim deref, referencing the 4.
Referencing the 2, I hope?
Doh!
Yes, the 2.
Really?
I consider this puzzling indicative that the (,) vs. [,] distinction
in Perl6 falls into the same category as e.g. starting the capture
variables at $1.
@m here has _single_ array-ref so
@m[0] returns that single array-ref - [[1,2],[3,4]]
@m[0;1] then returns array-ref [3,4]
@m[0;0] would return [1,2]
@m[0;0;1] would return 2
Yea, that's the---in my eyes unfortunate---preservation of
reference level depending on the left side of assignment.
Or stated the other way round, the auto-referencing when
the lhs is a $ variable. BTW, are lvalue subs handled the
same as $ vars here?
Could the ones who know it, enlighten me *why* it has to be so?
What does it buy the newbie, average, expert Perl6 programmer?
The answer that's how Perl5 did it is a good default, but
never hindered @Larry to change things.
Here are some speculations from me:
1) On one hand @a shall be a single handle to an array but
always writing a total slice, or flattener when you want
to replace the array as a whole is considered cumbersome
or redundant. Thus @a = 1 is basically a shortcut for
@a[] = 1 or [EMAIL PROTECTED] = 1. Note that for keeping some of the
existing values one has to use a non-total index/slice
like @a[42] = 1.
Question: With @a = (0,1,2,3,4,5), what does @a[2..4] = 7 mean?
@a == (0,1,7,5)? @a == (0,1,7,7,7,5)? I think it's the former,
and the latter actually is written @a[2..4] »=« 7.
How about: @a[1] = @b? Is that storing a ref to @b in @a at
position 1? Then @a[1] = 23 puts the 23 into @b at position 0?
So to get it back one has to use @a[1][0]?
2) Since a distinction between (,) and [,] for arrays and
( = , = ) and { = , = } for hashes is /syntactically/ possible
it is used to separate values from refs. But context spills
over from the lhs, though. I wouldn't unify these directly but
through the following typing:
(,) -- Eager (but not flattening nested Lazy stuff)
.. -- Lazy
= -- Pair
( = , = ) -- Eager of Pair
[] -- Array (this actually doesn't need the comma op)
{} -- Hash (actually Code, but evaluated immediately if
recognizeable at compile time)
3) The example in 1) might actually be wrong if @a = 1 sets
the size of the array. I see a tendency in perlkind to
have special cases like it's a number assigned to an array,
so the size changes. The assignment is smutten with these
special meanings because an imperative language is built
around it. E.g. ($x,$y) = (1,2) falls in this category as
well. In a purer setting it could be required to write
($x,$y) »=« (1,2) as it is for ($x,$y) »+« (1,2). Hmm,
then this is ultra-pure: @a[] »=« (1,2,3). Note that when @a
always denotes a single handle @a »=« (1,2,3) could be expanded
to (@a = 1, @a = 2, @a = 3) not (@a[0] = 1, @a[1] = 2, @a[2] = 3).
4) I guess not many want @a = \1 to be valid. But why not?
prefix:{'\'}:( Any $x : -- Ref of $x.type ) could build
an anonymous Ref of Int and then that is assigned to the
array on the left making it two-dimensional because of the
reference. Thus getting back the 1 needs one of the following
forms: @a[0][0], @a[0][], [EMAIL PROTECTED] or [EMAIL PROTECTED] The first
three forms
assume that postcircumfix:[ ] is supported by the Ref type.
I'm still arguing in favor of a---possibly strictly compiler enforced---
least upper bound typing of plain sigil expressions:
-- Code
$ -- Item (if that is the name now)
@ -- Array
% -- Hash
The strict type enforcement would prevent things like
@foo = sub (Int $x) { return $x * $x }
say @foo(13); # prints 169
OTOH without it, going almost sigilless would just be
my foo = 3;
my bar = HaloO;
if foo 2 { say bar }
my array is Array;
array[12] = 17;
My line of thought might actually be easier to understand if
you treat = as a normally dispatched infix operator without any
special significance. The two operators ::= and := are *not*
dispatched. They are macros or a direct part of the grammar.
::= is mostly syntactic sugar for a BEGIN block and := is basically
compiled to the engine level destructive assignment operation.
But this view might also be completely wrong.
Regards,
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
Juerd wrote:
From S02: Array and hash variable names in scalar context
automatically produce references.
Since [...] produces a scalar arrayref, we end up with an arrayref one
both sides of the =.
No.
There is no scalar context on the LHS of the assignment operator.
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
This argumentation breaks down as soon as you regard infix:{'='} as
an operator like many others. How do you derive context for the lhs
and rhs of infix:{'+'} or infix:{'*~*'}? From its invocant part of
the signature? With the sigil giving the default overrideable with the
'is context' param trait? Or does only the slurpy indicator * enforce
list context?
But then there might be a little bootstrapping problem with MMD if
both contexts are defined. How does one dispatch an Array then?
Junctively flattened and unflattened?
And another oddity is that the compiler has potentially to go back
and re-compile some code with invocations of ops if it later sees more
overloaded definitions of these ops that have other context traits in
their signature. It's much easier to just compile to MMD code and leave
the rest to the runtime dispatch. But this requires a self-contained
definition of the meaning of @a and [] as described by Rod.
--
TSa (Thomas Sandlaß)
Unicode Operators cheatsheet, please!
I would love to see a document (one per editor) that describes the Unicode characters in use and how to make them. The Set implementation in Pugs uses (at last count) 20 different Unicode characters as operators. While I'm sure these documents exist on the web somewhere, since P6 is the first time most of us will be using these operators, it'd be nice if P6 provided a nice cheatsheet for them. Thanks, Rob
Re: (1,(2,3),4)[2]
Juerd wrote:
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
What should hinder infix:{'='}:(Ref, Int: -- Int) to exist and be
usefull at least if the Ref is known to something that derefs it
and then finds the new referee? On the Perl6 language level references
are a means to share values. Don't mix that with the implementation
level references---which should be called pointers---that allow an
efficient implementation of handling heavyweight data.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-27 16:22 (+0200):
This argumentation breaks down as soon as you regard infix:{'='} as
an operator like many others.
Which we don't, making this discussion much easier for everyone.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-27 15:44 (+0200): Could the ones who know it, enlighten me *why* it has to be so? What does it buy the newbie, average, expert Perl6 programmer? The answer that's how Perl5 did it is a good default, but never hindered @Larry to change things. Because the alternative is to drop context. If we drop context, we have to use an array where we now use a list. And list automatically becomes an alias for array in our jargon. Also, arrays will then probably no longer have any referenceless version, and always be objects and thus references. Then we lose the point for having different sigils, and everything gets a dollar sign. The end result is very different from Perl, and can no longer be thought of even as derrived from Perl, in my opinion. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Declarations of constants
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
# Way 2
my MEANING_OF_LIVE = - () { 42 };
# or
sub MEANING_OF_LIVE () { 42 }
# Then one can use sigilless constants:
say MEANING_OF_LIVE;
# Way 3 (still possible?)
use constant MEANING_OF_LIVE = 42;
# Way 4 (evil?)
macro MEANING_OF_LIVE { 42 }
# Way 5 (overloading of the numification of Class -- evil)
Class does role {
method *prefix:+ (MEANING_OF_LIVE $class:) {
42;
}
}
class MEANING_OF_LIVE {}
say +MEANING_OF_LIVE;
# Please add more ways :)
--Ingo
--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon!|
Re: Declarations of constants
Ingo Blechschmidt wrote: # Please add more ways :) enum MEANING_OF_LIVE:(42); my MEANING_OF_LIVE = 42; # But might be considered evil sigilless mode -- TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
HaloO Juerd, you wrote: Because the alternative is to drop context. ... Then we lose the point for having different sigils, and everything gets a dollar sign. Isn't the strong type system adequate compensation? Especially when the sigils denote the level below which you can't go in untypedness or unspecificity? The two new list types Eager and Lazy nicely fit the jargon term. Actually you could e.g. apply them to complete files and view them as a list of lines if that suites a certain task. OTOH, some classes might like to travel in variables with the @ and % sigil. E.g. my @data is DatabaseTable; my %tree is StructuredDocument; -- TSa (Thomas Sandlaß)
Re: Declarations of constants
Hi, TSa (Thomas Sandla) wrote: my MEANING_OF_LIVE = 42; # But might be considered evil sigilless mode is that allowed (as 42 is a Num (or an Int), not a Code)? Do (most of) the basic types morph themselves into Codes, when needed? say 42();# 42? say Perl();# Perl? say [1,2,3].does(Code) # true? Or did you simply forget the braces around 42? :) --Ingo -- Linux, the choice of a GNU | Wer die Freiheit aufgibt, um Sicherheit zu generation on a dual AMD | gewinnen, der wird am Ende beides Athlon!| verlieren -- Benjamin Franklin
Re: Declarations of constants
Ingo Blechschmidt wrote:
is that allowed (as 42 is a Num (or an Int), not a Code)?
I don't know, but guess not.
Do (most of) the basic types morph themselves into Codes, when needed?
I don't consider it type morphing. If your examples parse
at all they will be dispatched as usual
say 42();# 42?
postfix:.( ):( Int :)
say Perl();# Perl?
postfix:.( ):( Str :)
say [1,2,3].does(Code) # true?
Depends on the type of [] which is Ref of Array or so.
But I think it should be false.
Or did you simply forget the braces around 42? :)
No, it was intented for seeing what the reactions will be :)
Just using foo as unsigiled variable. This might need
my foo is rw;
But then I presume you could say:
foo = 17;
if foo 8
{
@a[foo] = 8;
}
We could call that a codeless lvalue sub ;)
--
TSa (Thomas Sandla)
Re: Unicode Operators cheatsheet, please!
On Fri, May 27, 2005 at 10:29:39AM -0400, Rob Kinyon wrote: I would love to see a document (one per editor) that describes the Unicode characters in use and how to make them. The Set implementation in Pugs uses (at last count) 20 different Unicode characters as operators. Good idea. A modest start is at docs/quickref/unicode . -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Declarations of constants
Hi,
TSa (Thomas Sandla) wrote:
Ingo Blechschmidt wrote:
Or did you simply forget the braces around 42? :)
No, it was intented for seeing what the reactions will be :)
:)
Just using foo as unsigiled variable. This might need
my foo is rw;
I don't think this will DWYW, as firstly is rw is the default
on vars declared with my(), and secondly foo will be undef, not some
kind of Proxy object. To do what you want, you'd have to write (I
think):
my foo = new_codeless_lvalue_sub();
sub new_codeless_lvalue_sub {
my $var;
return {
new Proxy: FETCH = { $var }, STORE = - $new { $var = $new };
};
}
But then I presume you could say:
foo = 17;
if foo 8
{
@a[foo] = 8;
}
We could call that a codeless lvalue sub ;)
This indeed looks very slick! I wouldn't use it for normal vars, though.
--Ingo
--
Linux, the choice of a GNU | The next statement is not true.
generation on a dual AMD | The previous statement is true.
Athlon!|
Re: [S29] uniq
Luke Palmer wrote:
So I suppose that's my proposal. Allow, even encourage, overloading
of =:=, but only for value types. I've been thinking that we ought to
provide a standard role for making something a value type. Maybe it
would require definition of =:=.
I would like to propose something slightly different:
1) Let =:= be non-overloadable purely macro/grammar based
--- same could be applied to ::= and := I think
2) the implementation of =:= then checks type homogenity
as a precondition and calls the type specific EQUAL
submethod or some such
The rational is that type homogenity is a necessary condition
for identity and thus allows to return false when violated.
The EQUAL class/type submethod could be used as the default for
the == and eq operators as long as subtype homogenity for both
sides holds. Well, or the operator name is a parameter to the
parametric role:
role Identity[ eq_op:( ::?CLASS, ::?CLASS: -- bit ) = $::CLASS::EQUAL ]
does Identity[ ::?CLASS ] # F-bounded
{
...
}
which is implicitly forced into every class definition by virtue of
role Any does Identity;
In particular we have:
class Num does Identity[ infix:{'=='} ] {...}
class Str does Identity[ infix:{'eq'} ] {...}
To what exteent in canbe auto-generated with dispatching to
the respective methods of all elements defined into the class'
value environment, I can't say.
--
TSa (Thomas Sandlaß)
Transparent / Opaque references
When we heard that Larry didn't acutally want $$foo to infinitely dereference, some of us were overjoyed, and others severely disappointed. Both transparent dereferencing (infinite $$foo) and opaque dereferencing (one-level $$foo) have their uses, but they are definitely distinct. Instead of adding different syntax for each kind, I'll propose something different: two types of references: Opaque and transparent. Opaque references always need to be explicitly dereferenced (except for binding an array to an array reference, etc.). Transparent references always automatically dereference. The decision of what type of dereferencing will go on is left up to the reference taker. What I can't decide is which one \ will create, and how you will create the other kind. Also, I can't decide how to one-level dereference the transparent references so that you can change them. Luke
Default invocant of methods
Hi,
what is the default invocant of methods?
method blarb ($normal_param) {...}
# Same as
method blarb (Class | ::?CLASS $invocant: $normal_param) {...}
# or
method blarb (::?CLASS $invocant: $normal_param) {...}
# ?
I prefer the latter, as then one can't accidentally call a instance
method on the class -- i.e.
Foo.blarb # will die.
You can always specify Class as invocant, if you want to have a class
method.
Opinions?
--Ingo
--
Linux, the choice of a GNU | Elliptic paraboloids for sale.
generation on a dual AMD |
Athlon!|
Re: Transparent / Opaque references
Luke Palmer skribis 2005-05-27 20:59 (+):
Opaque references always need to be explicitly dereferenced (except
for binding an array to an array reference, etc.). Transparent
references always automatically dereference. The decision of what
type of dereferencing will go on is left up to the reference taker.
The way I see things, an opaque reference is a value, while a
transparent reference is a name. And thus we already have both.
The name $foo points to a container, and so does \bar. However, to get
at the container using $foo, you use simply $foo. To get at the
container using the reference to bar, you have to dereference explicitly
with another $.
To bind a name (and thus have a transparent reference), we can either
declare the name, creating the variable at that point, or use some other
means of creating the variable, and use := to bind it later.
There are named arrays, @foo, and anonymous arrays, [].
There are named hashes, %foo, and anonymous hashes, {}.
There are only anonymous pairs. You can't dereference a pair, or bind a
name to it.
What I can't decide is which one \ will create, and how you will
create the other kind. Also, I can't decide how to one-level
dereference the transparent references so that you can change them.
The only real problem with having only infix := for binding, is that you
can't easily use an alias (aka transparent reference) in a list. You can
have an array of aliases, but it's harder to have an array or hash in
which one element is an alias. Binding can be done explicitly:
%hash = { key = undef, foo = 'bar' };
%hashkey := $variable;
%hashkey = 5; # $variable is now 5 too
But there is no way to set the transparent reference (aka alias)
initially, because we lack a \-like syntax.
So I propose that := becomes a prefix operator as well as an infix one,
allowing:
%hash = { key = := $variable, foo = 'bar' };
%hashkey = 5; # $variable is now 5 too
(This almost makes \ want to be \=, and $foo \= $bar to be what we now
write as $foo = \$bar, and $foo = := $bar to be the same as $foo :=
$bar, and stacked :=s to be irrelevant... But let's not think about this
too much...)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Transparent / Opaque references
Juerd skribis 2005-05-28 1:15 (+0200):
There are named arrays, @foo, and anonymous arrays, [].
There are named hashes, %foo, and anonymous hashes, {}.
There are only anonymous pairs. You can't dereference a pair, or bind a
name to it.
I forgot an important one:
There are named scalars, $foo, and anonymous scalars, but they are
'literals', and read only, like 42.
There is no way to get an anonymous rw scalar, is there?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Transparent / Opaque references
On 5/27/05, Juerd [EMAIL PROTECTED] wrote:
There is no way to get an anonymous rw scalar, is there?
Can't the [] and {} syntaxes be considered aliases for new Array(...)
and new Hash(...)?
my $x := new int = 10; # looks like it should work
Ashley Winters
Re: comprehensive list of perl6 rule tokens
In regards to http://www.nntp.perl.org/group/perl.perl6.language/21120 which discusses character class syntax in Perl 6, I have some comments to make. First, I've been very interested in seeing proper set notation for char classes in Perl 5. I was pretty vocal about it during TPC in 2002, I think, and have since added some features that are in Perl 5 now that allow you to define your own Unicode properties with not only + and - and ! but as well. If we want to treat character classes as sets, then we should try to use notation that reads properly. I don't see how '+' and '|' are any different in this case: +Foo +Bar and Foo | Bar should produce the same results always. I suppose the + is helpful in distinguishing a character class assertion from any other, though. To *complement* a character class, I think the character ~ is appropriate. Intersection should be done with . Subtraction can be provided with -, although it's really just a shorthand: A - B is really A ~B... but I suppose huffman encoding tells us we should provide the - sign. Here are some examples, then: +alpha -vowelsall alphabetic characters except vowels +alpha ~vowels same thing [a..z] -[aeiou] all characters 'a' through 'z' minus vowels [a..z] ~[aeiou] same thing ~(X Y) | Z all characters not in X-and-Y, or in Z The last example shows ~ which is currently unclaimed as far as assertions go. Since I'd be advocating the removal of a unary - in character classes (to be replaced by ~), I think this would be ok. The allowance for a unary + in character classes has already been justified. For the people who are really going to use it, the notation won't be foreign. And I'd expect most people who'd use it would actually abstract a good portion of it away into their own property definitions, so that ~(X Y) | Z would actually just be +My_XYZ_Property which would be defined elsewhere. What say you? -- Jeff japhy Pinyan % How can we ever be the sold short or RPI Acacia Brother #734 % the cheated, we who for every service http://japhy.perlmonk.org/ % have long ago been overpaid? http://www.perlmonks.org/ %-- Meister Eckhart
