Re: overloading the variable declaration process
Stevan Little wrote: > Yes, that is correct, because: > > Dog.isa(Dog) # true > $spot.isa(Dog) # true > ^Dog.isa(Dog) # false > > In fact ^Dog isa MetaClass (or Class whatever you want to call it). > > At least that is how I see/understand it. OK. To help me get a better idea about what's going on here, what sorts of attributes and methods would ^Dog have? -- Jonathan "Dataweaver" Lang
Re: overloading the variable declaration process
On 2/8/06, Jonathan Lang <[EMAIL PROTECTED]> wrote: > Consider "my Dog $spot". From the Perl6-to-English Dictionary: > Dog: a dog. > $spot: the dog that is named Spot. > ^Dog: the concept of a dog. > > Am I understanding things correctly? > > If so, here's what I'd expect: a dog can bark, or Spot can bark; but > the concept of a dog cannot bark: > can Dog "bark"; # answer: yes > can $spot "bark"; # answer: yes > can ^Dog "bark"; # answer: no Yes, that is correct, because: Dog.isa(Dog) # true $spot.isa(Dog) # true ^Dog.isa(Dog) # false In fact ^Dog isa MetaClass (or Class whatever you want to call it). At least that is how I see/understand it. Stevan
Re: The definition of 'say'
At 21:30 +0100 2/8/06, Juerd wrote: >Larry Wall skribis 2006-02-08 8:38 (-0800): > > It would be nice to have other data points In the Macintosh world: 1) say is a reserved word in AppleScript that sends text to a speaker (with windings and a cone). 2) We are forever mucking with $/ and $\ set to different values. One for reading someone else's file and the other for writing something the Macintosh way. (It's better in OS neXt.) And everywhere: 3) There are two more 16 bit line ends in unicode that may or may not ever be really used. -- Applescript syntax is like English spelling: Roughly, but not thoroughly, thought through.
Re: Smart match table
-- Original message --
From: Luke Palmer <[EMAIL PROTECTED]>
> On 2/7/06, Robin Houston <[EMAIL PROTECTED]> wrote:
> > Any undef undefinedmatch if !defined $a
> > Any Regex pattern matchmatch if $a =~ /$b/
> > Code() Code()results are equalmatch if $a->() eq $b->()
> > Any Code()simple closure truth match if $b->() (ignoring $a)
> > Num numish[!] numeric equality match if $a == $b
> > Any Str string equality match if $a eq $b
> > Any Num numeric equality match if $a == $b
> >
> > which retains commutativity in all cases. Of course it's
> > different in Perl 6, because the "dotted entries" like
> > .[number] and .method need to behave non-commutatively.
> > But is it really necessary for coderefs?
>
> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists. The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
>
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
>
> And then the interpretation of ~~ is determined by its right-hand side.
>
> Luke
Also ermemebr that a very common user of ~~ is the implisit use in a when
conditional inside a given block, which is an inheirently assymeterical (thus
non-communitive) situation.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: overloading the variable declaration process
Consider "my Dog $spot". From the Perl6-to-English Dictionary: Dog: a dog. $spot: the dog that is named Spot. ^Dog: the concept of a dog. Am I understanding things correctly? If so, here's what I'd expect: a dog can bark, or Spot can bark; but the concept of a dog cannot bark: can Dog "bark"; # answer: yes can $spot "bark"; # answer: yes can ^Dog "bark"; # answer: no -- Jonathan "Dataweaver" Lang
Re: Smart match table
Luke wrote:
> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists. The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
>
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
>
> And then the interpretation of ~~ is determined by its right-hand side.
Heavens, I hope not!
The whole point of ~~ is that it's dispatched multimorphically, *not*
polymorphically. So you get the most appropriate matching behaviour
for the *combination* of arguments.
And I've always imagined that it's commutative for the same reason ==
and eq are communative: because that's the only thing that makes
sense. When you're comparing two apples (or an apple and a
handgrenade), it shouldn't matter which of the two is in your left
hand, and which is in your right.
Damian
Re: Smart match table
On 2/7/06, Robin Houston <[EMAIL PROTECTED]> wrote:
> Any undef undefinedmatch if !defined $a
> Any Regex pattern matchmatch if $a =~ /$b/
> Code() Code()results are equalmatch if $a->() eq $b->()
> Any Code()simple closure truth match if $b->() (ignoring $a)
> Num numish[!] numeric equality match if $a == $b
> Any Str string equality match if $a eq $b
> Any Num numeric equality match if $a == $b
>
> which retains commutativity in all cases. Of course it's
> different in Perl 6, because the "dotted entries" like
> .[number] and .method need to behave non-commutatively.
> But is it really necessary for coderefs?
My interpretation (which may be totally off, as I don't have any
confirmation that anybody else is thinking the same way I am) is that
the synopsis is wrong, and commutivity of ~~ is a happy coincidence
wherever it exists. The way I've been thinking about ~~ is just as
the following object-oriented sugar:
role Pattern {
method match(Any $x) {...}
}
sub infix:<~~> (Any $x, Pattern $y) {
$y.match($x);
}
And then the interpretation of ~~ is determined by its right-hand side.
Luke
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote: > Does this imply that we should think up this process? Go ahead. > If I propose a concrete plan for the implementation of Perl 6 in a > layered fashion it will probably be even more overlooked. > > I have no authority, and this is not something I can do on my own. If other people find it valuable, that's all the authority you need. The last time someone tried to set forth a complete specification in a particular order was the Perl 6 documentation project. That didn't work then. I have doubts that specifying a complete compiler and toolchain without at least some trial and error will work, but I could be wrong. Maybe the right place to start is to gather a list of all of the questions you need to have answered and all of the features people want, and then try to unify them into a Perl 6-ish whole. -- c
Re: The definition of 'say'
Larry Wall skribis 2006-02-08 8:38 (-0800):
> It would be nice to have other data points
I associate "say" with to-human communication, and there, I don't
generally have records. Without records, no ORS.
However, while I think that &say should not be
&print.assuming(:ors("\n")), it shouldn't be print + \n either.
Instead, I think the format should be configurable, defaulting to
suffixing \n, but configurable to have another suffix, and possibly a
prefix even. For example, I may very well like a "* %s\n"-like output,
or when dealing with HTML, "%s".
Of course, I could just override &say. But I think making it
configurable and documenting the difference between say and print as a
difference in final recipient (human versus computer) may make more
sense.
In any case, &say being print + \n as the default is IMO a better plan
than having it default to any ORS, even if that ORS happens to be \n.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: The definition of 'say'
On 2/8/06, Larry Wall wrote: > From: Damian Conway <[EMAIL PROTECTED]> > I've now been using C (via Perl6::Say) for some time -- testing our collective intuition on this -- and it turns out that b. isn't the least surprising. At least, not to me. In fact, I am regularly (and annoyingly) > re-surprised every time $\ overrides what I was sure was going to be newline. The question basically boils down to how you think about "say". I guess I think of "say" as "print + \n" too... because that's how everyone explains it. If we told everyone it meant "print + ORS", I think it would be less surprising. Of course, I hardly ever set a record separator, and I'm not sure what Damian was doing that led him to want to set one and to use 'say' at the same time. What's the difference between an ORS and a newline anyway? The purpose of a newline is typically to provide a visual separation... hm. Maybe we should take a step back: 'say' and ORS's are both a kind of shortcut to save you from typing everything out explicitly in every print statement. What if 'print' never added anything to its output, and 'say' always added the field and record separators? The default ORS should then be \n. Instead of turning the separators on and off (as in P5), you would switch between using 'print' and 'say'. (You might also make an argument that the default OFS should be a space or a tab, but I think OFS="" and ORS="\n" are probably what most people want most of the time. That certainly fits my typical uses of 'print' and 'say'.) -David "say what?" Green
Re: The definition of 'say'
One more data point?
I might want a newline or I might want an ORS. The former, say()
gives me. The latter, print() provides.
I cannot imagine ever wanting a mixture of those, and if I ever do,
I expect I'll prefer to say what I mean:
# modulo syntax:
{ temp ORS //= "\n"; print @args } # b
print @args, "\n"; # c
{ temp ORS ~= "\n"; print @args } # d
In the common case, I think I'll have one or the other, and no
surprises, if you please. Option a.
Eirik
--
Habit is a cable; we weave a thread of it each day,
and at last we cannot break it.
--Horace Mann
Re: The definition of 'say'
On Wed, Feb 08, 2006 at 08:38:32AM -0800, Larry Wall wrote: > The question basically boils down to how you think about "say". > Damian's argument is that, if people are like him, they will learn > it as "print plus newline" rather than as "emit a whole record". > I'm inclined to think that people do in fact learn one feature in > terms of other features like that, rather than treating "say" as a > different primitive. > > It would be nice to have other data points, though, since I think > even Damian will admit that Damian's brain doesn't work like everyone > else's brain. Just as another data point, I too have been thinking of "say" as "print + newline". -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: The definition of 'say'
IMHO, people who set $/ are, by definition, saying that they expect lines to terminate with something other than a newline; they should expect 'say' to conform to their wishes. I don't like the notion of perl second-guessing the programmer's intentions here; "Do what I mean, not what I say" only carries so far. That said, I very rarely set $/, so this aspect of 'say' doesn't really affect me. -- Jonathan Lang
Re: overloading the variable declaration process
On Tue, Feb 07, 2006 at 07:32:18PM -0500, Stevan Little wrote:
: On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
: > Stevan~
: >
: > I am going to assume that you intended to reply to perl 6 language,
: > and thus will include your post in its entirety in my response.
:
: Yes, sorry... I missed the "reply to all" button on the gmail UI by a
: few pixels I guess. Thank you for forwarding.
:
: > Now that everyone is on the same page, I will go about responding
: >
:
: # snip some code
:
: > >
: > > class Pipe::Stem {
: > >has $composed_of;
: > >has $color;
: > >has $length;
: > >has $filter = bool::false;
: > > }
: >
: > so far I am mostly with you, except one question. Does bool::false;> just provide a default?
:
: Yes, that is a default value. I assume that most Pipe smokers don't
: like filters in their pipes, I might be wrong on that one because I am
: not a pipe smoker :)
:
: > > You would then model the different pipes you sell;
: > >
: > > class MagrittePipe {
: > > has $stem = Pipe::Stem.new(
: > > :composed_of,
: > > :color,
: > > :length
: > > );
: > > has $bowl = Pipe::Bowl.new(
: > > :composed_of,
: > > :color,
: > > :size
: > > );
: > > }
: > >
: > > Now, you might say, why not make the MagrittePipe an instance of Pipe,
: > > and give the Pipe class a few more attributes, like a name. Well, if
: > > you did that then you couldn't subclass it of course.
: >
: > Actually, I was going to ask why not make MagrittePipe inherit from Pipe.
:
: Ooops, forgot that part it should infact inherit from Pipe. And of
: course you can do that dynamically with the metamodel ;)
:
: > > Well, using introspection, it becomes very simple to discover various
: > > qualities about your inventory, enough to probably even autogenerate
: > > the HTML pages for your online-web store (powered by Perl 6 of
: > > course). And lets not forget the uber-cool Perl 6 Object Database
: > > which you are using to store your real-time inventory in (all
: > > metamodel powered of course). And of course if you want, you can use
: > > the DistributedObjectProxy metaclass which will automatically make
: > > your objects distributed so that your door-to-door Pipe saleforce can
: > > update your inventory in real time from their cellphones. And your R&D
: > > department can use the built-in (but as yet unspeced) logic
: > > programming features of Perl 6 to mine your customer information from
: > > your (previously mentioend) object database and genetically "grow"
: > > new, more desireable Pipe products (which is easy to do since your
: > > metaclasses are programatically composable (and no I don't mean eval
: > > $code)).
: >
: > I think you mis-understand me. I do not question the value of a
: > powerful meta-model. Quite the contrary I want to see Perl 6 have a
: > meta-model more powerful and accessible then CLOS. I see it as a
: > necessity for a language that plans to truely scale in the future.
: >
: > What I do question is the usefullness of having bare class names
: > represent these "prototype objects". I just don't really understand
: > what they are for or do.
:
: Well, to be totally honest, I think only Larry truely understands
: their usage, but to the best of my understanding they are intented to
: serve a number of roles;
:
: (Larry, please correct me if I am wrong here)
:
: - to allow for introspection of the class.
:
: After all ^Foo.can() is really just a series of method calls to the
: Foo metaobject. And besides ^Foo.meta.can() is 5 more characters to
: type!!
:
: - provide an invocant for "class" methods.
:
: Larry does not like the class-method/instance-method distinction (in
: fact it seems he doesn't even like the class/instance distinction
: either), and has declared that a "class method" is really just a
: method of the class which does not access any instance attributes.
: Well, this complicates the type signature of the invocant, and we need
: an invocant that the type-checker can check.
:
: In Perl 5, classes were just package names which were just strings.
: This will not work in Perl 6 in the presence of a reasonably decent
: type checker, the class needs to be *something*. Now Larry has also
: declared that he does not like the idea of a "class object", I think
: this is because that means that a properly typed method signature for
: a class method would look like this:
:
: class Foo {
: method foo (Class $class:) {
: say "I am a class method, and proud of it";
: }
: }
:
: According to the signature, this method takes any Class instance as an
: invocant. Well
: thats just not right because it should only accept the Class instance
: which represents the Foo class. But we can't (at least I dont think we
: can) be that
Re: The definition of 'say'
On Tue, Feb 07, 2006 at 06:38:14PM +, Robin Houston wrote:
: Late last year I implemented a few Perl 6 features in Perl 5.
: A couple of things have emerged that may be relevant to the
: Perl 6 design. Certainly they're things that I'm curious about.
: I'll send the other one in a separate message to keep the
: threads apart: this message is about 'say'.
:
: The definition of 'say' is very simple:
:
: say
:
: is exactly equivalent to
:
: print , "\n"
:
: and that's just the way it works in Perl 5.9.3. In fact,
: that's how it's compiled. A few people on p5p have expressed
: some disquiet that
:
: say "foo";
:
: will print the string "foo$,\n$\". I'm inclined to agree that
: this seems sensible only when $, and $\ are both empty, as
: they are by default.
:
: I'm not sure what the Perl 6 analogues are of $, and $\. I've
: heard that $\ is a per-filehandle setting. Is there any analogue
: of $,? Presumably there is.
Yes, native Perl 6 will attach such things to the filehandle objects,
though the p5-to-p6 translator will have to emulate them somehow...
: In short, I'm curious as to why say is defined as it is, rather
: than, for example, to be the equivalent of the Perl 5 code
:
: { local $\ = "\n"; print }
:
: I've searched the archives of this list, but failed to turn
: up anything relevant.
You're searching the wrong archives. :-) Here's something from the
@Larry's archives--Damian first brought this up almost two years ago,
and I don't think he'll mind me forwarding the last message in that
thread:
> From [EMAIL PROTECTED] Sun Jan 23 14:31:50 2005
> Message-ID: <[EMAIL PROTECTED]>
> Date: Mon, 24 Jan 2005 09:31:36 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
> To: Perl 6 Design Team <[EMAIL PROTECTED]>
> Subject: Revisiting an old decision (after extensive play-testing)
> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
> PROTECTED]> <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Length: 2404
> Lines: 56
>
> Some time back, we were discussing the C function, and its interaction
> with a filehandle's ORS:
>
> > On Fri, Mar 26, 2004 at 01:01:28PM +1100, Damian Conway wrote:
> > : So, how (if at all) does C interact with the filehandle's output
> > : record separator? Does it:
> > :
> > : a. Temporarily set the filehandle's ORS to newline and call C?
> > : (i.e. just append: "\n")
> > :
> > : b. Temporarily set the filehandle's ORS to newline unless that ORS is
> > : already defined as something else and call C?
> > : (i.e. append: $fh.outsep // "\n")
> > :
> > : c. Append a newline and call C, which then appends the
> > :filehandle's ORS?
> > : (i.e. append: "\n" ~ $fh.outsep)
> > :
> > :
> > : d. Append the filehandle's ORS, then a newline, and output directly?
> > : (i.e. append: $fh.outsep ~ $fh)
> > :
> > :
> > : Personally, I think a. or b. would probably be the least surprising.
> >
> > I think b. seems likeliest to do what they want. Of course, it doesn't
> > actually have to be implemented in terms of print.
>
> I've now been using C (via Perl6::Say) for some time -- testing our
> collective intuition on this -- and it turns out that b. isn't the least
> surprising. At least, not to me. In fact, I am regularly (and annoyingly)
> re-surprised every time $\ overrides what I was sure was going to be newline.
>
> I've realised that this is because I constantly abstract C in terms of
> C. Specifically, as "print plus a newline".
>
> But the b. semantics constantly thwart that unconscious abstraction, giving
> me
> instead "print plus *sometimes* a newline, but sometimes not".
> That's because, if $\ is set, C devolves to exactly C (which also
> seems somehow "wasteful").
>
> I have the definite sense that C is going to be one of the most-used
> features of Perl 6 (it's certainly the one I use most so far), so I'd
> strongly
> suggest that we revisit its semantics to make them less surprising.
>
> In particular, I think the simplest, most useful, and most predictable
> semantics are actually those suggested in alternative c. above. That is, I
> think the following equivalence should hold exactly:
>
> say @args <> print @args, "\n"
>
> That's definitely how I find myself thinking about C when I'm not
> actually...err...thinking about C, so I think that's what might fit
> hacker brains most naturally.
>
> Damian
The question basically boils down to how you think about "say".
Damian's argument is that, if people are like him, they will learn
it as "print plus newline" rather than as "emit a whole record".
I'm inclined to think that people do in fact learn one feature in
terms of other features like that, rather than treating "say" as a
different primitive.
It would be nice to h
Re: overloading the variable declaration process
Stevan~ On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote: > > > After all Foo is just a specific instance of the class Class. > > Shhh... class objects don't exist ... I was never here,... I will I > count to three and when I snap my fingers you will awaken and will > have forgotten all about class Class. > > 1 ... 2 ... 3 ... *snap* ... What!?!? Where was I? Oh, yeah. As I was saying, I think we just take C++'s object system exactly. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: A proposition for streamlining Perl 6 development
Yuval Kogman wrote: > What I do think is that there is something in the middle of these > two big questions, and they are: > > * How will the Perl 6 compiler be designed (parts, etc) That... was what Pugs Apocrypha was meant to contain, with PA02 being a design overview, and PA03 onward documenting the various parts with their interfaces. But English is not my forte (by far), and the last time you and I worked toward it, it resulted in a jargon-filled document largely inaccessible to a casual participant. So that needs to be fixed. I'll be in Tel Aviv in 5 days (thank $deity), and I'd be very willing to work with you on this before the Hackathon starts. Audrey signature.asc Description: OpenPGP digital signature
Re: A proposition for streamlining Perl 6 development
I'd like to have a crack at rephrasing this, since everyone but stevan seems to be getting the wrong impression. Perl 6 has some hard to answer questions. The questions the community has answered so far are: * How the VM will work/look * What the syntax/feature requirements are If we ignore pugs for a second. These are though questions to answer, and I have no criticism whatsoever that they took long to answer. Development speed is *NOT* what this post was about. What I do think is that there is something in the middle of these two big questions, and they are: * How will the Perl 6 compiler be designed (parts, etc) * What are the definitions of some of the standard features mentioned in the Synopses ( S29 is a good start, but we need more than the standard perlfunc) If we let Perl 6 continue to grow organically we will have answers to these questions, but we will likely invest lots of effort in trial and error. I think that some of these questions can be answered based on some up front design, thinking, and decision making, thus helping us direct our trial and error efforts towards a more defined goal. Furthermore, I think this has important implications on the quality of the implementation of the Perl 6 compiler and standard library, and that we should start worrying about that too. The second (much larger) part of the post contains a sort of draft, if you will, of what I think can be a good start towards trying to answer these questions. Thanks -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /methinks long and hard, and runs away: neeyah!!! pgpHSuE6cygmL.pgp Description: PGP signature
