Re: Re-thinking file test operations

[Paul Hodges]

--- On Thu, 7/9/09, Moritz Lenz  wrote:
> . . .
> Somehow the current file test syntax, 'filename' ~~ :e, looks like a not
> well-though-out translation of Perl 5's syntax, -e 'filename'.
> Apart from totally feeling wrong to me,

Dunno about totally. I'm still trying to get a P6 mindset, but there's a lot to 
be said (evidenced by how much has been said) for having an "old-fashioned" and 
more familiar way to do it. 

I'm underinformed, so I won't waste everyone's time on internals I haven't 
checked.

> 3) I haven't look too closely at the list of proposed Perl 6 file test
> operators, but Perl 5 has 29 of them. The idea of having 29 single
> letter methods in class Str doesn't make me all that happy.

This doesn't sound ideal, but I don't panic over it. Wrap them in the class and 
you get some benefits. Personally, I don't mind losing some Huffmen 
convenience, though; I've seldom used most of them, and even for the ones I use 
most I don't mind having a more descriptive name that makes me hit a few extra 
keys. I just want to be able to accomplish whatever it is that I need to do.

> So I collected other ideas, both in my brain and in #perl6.
> Some of them are:
> 
> $str.f.exists# Str.f returns an "interpret this object
> $str.f.size  # as a file name" object
> 
> $str.File.e  # same, different names
> $str.stat.exists # again
> 
> stat($str, :e)# let multi dispatch handle it for us

I'd prefer $str.File.exists; I'm not crazy about $str.f.whatever. 

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.



  

Re: Logo considerations

[Paul Hodges]

--- On Tue, 3/24/09, jason switzer  wrote:

> Basically, the perl community has largely adopted TIMTOWTDI

So how about a "Tim the Toady"? :)

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.





  

Re: Logo considerations

[Paul Hodges]

--- On Tue, 3/24/09, John Macdonald  wrote:

> The graphene logo inspires me to suggest that a carbon
> ring be used as the logo for Parrot...
 
A carbon ring also has the advantages that it's regognizable as a very small 
logo, even as just a favicon.ico, and can be reasonably if stylistically 
represented in simple ASCII art. You can even put a tail off the top to look 
like 6-ish, or if you have real art skills, superimpose a Pearl into the 
hexagon with a little "VI" (both a Roman numeral and a vague homage to the text 
editor of it's UNIX roots).

Yes, lots of inside jokes, but that's part of the community thing


===
Hodges' Rule of Thumb: Never expect reasonable behavior from anything with a 
thumb.

Re: how to write literals of some Perl 6 types?

[Paul Hodges]

(full quote below)
> As Duncan said, the real question is what’s the point of having
> Bit when we also have both Int and Blob. I think none.

I can't find anything in the existing synopses about Blobs.
Probably looking in the wrong place, sorry. 

Blobs can handle arbitrary numbers of bits?
If so, I agree, a Bit type may be superfluous, since you could compose one 
easily enough.

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


--- On Fri, 12/5/08, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:

> From: Aristotle Pagaltzis <[EMAIL PROTECTED]>
> Subject: Re: how to write literals of some Perl 6 types?
> To: perl6-language@perl.org
> Date: Friday, December 5, 2008, 7:42 AM
> * TSa <[EMAIL PROTECTED]> [2008-12-03 09:30]:
> > And I want to pose the question if we really need two types
> > Bool and Bit.
> 
> I think so. Binary OR and logical OR are different beasts.
> 
> As Duncan said, the real question is what’s the point of having
> Bit when we also have both Int and Blob. I think none.
> 
> Regards,
> -- 
> Aristotle Pagaltzis // 

[OT] Re: [svn:perl6-synopsis] r14501 - doc/trunk/design/syn

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Besides $^_ is just uglier than anything else I've seen today...

lol -- I thought of it as a rather cute peeking-wink with a cauliflower
ear, but that's probably much more cutesiness than we want to encourage
in our language design.

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: what should be the default extension?

[Paul Hodges]

A small tangent that might be relevant -- what's the current convention
for, say, putting several related "packages" in the same file?

In p5, I might write a great Foo.pm that loads Foo::Loader.pm and
Foo::Parser.pm and Foo::Object.pm; I'd usually drop them into seperate
files and have one load the rest, so I could just use Foo; and get on
with my code, but that does add some maintenance that could be skipped
if loading the one file automatically grabbed all the relevant parts.
Plusses and minuses there If the Foo:Widget and Foo:Gadget are only
of use with the something in Foo proper, maybe it would be reasonable
to toss them into the same file, though.

Looking at this proposal made me wonder if there were any value in
maybe tossing them all into one file, since that's how they'd usually
be used, but that if I just really had a use for a Foo::Parser and
didn't want any of the rest, maybe I could still
   use Foo::Parser in Foo.pm;

That could load just the one section from whatever file it found in a
usual search for Foo. I really can't see that it's anything very
urgent, but maybe someone sees a use for that? It would have the
possible advantage of making the more common case be easier, and the
rarer, exceptional case be the one that takes the extra work. Even so,
I'm just not sure it's worth the work it might take to build it in.

All in all, I'm still thinking in p5, so I'd still probably do it the
old way. =o)

--- Trey Harris <[EMAIL PROTECTED]> wrote:

> In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
> 
> > May I suggest the following extension to the 'use ' pragma, viz.
> > use  in
>  > constrained by local system>
> 
> Oh please, no.
> 
> The entire point of the wording currently in the synopsis is so that
> we 
> can have platform-independent location of libraries.  The "name
> mangling 
> capability" hypothesized lets the same C get the requested
> resource, 
> regardless of the file (or database location!) where the resource is 
> actually located on the platform running Perl.
> 
> Your proposal would force us to have platform-dependent locations,
> and 
> hence platform-dependent programs.  Do you really want to see dozens
> of 
> switches like
> 
>given $?OS {
>   when m:i:/win/ { use Foo in WinFoo.pm }
>   when m:i:/nix/ { use Foo in UnixLikeFoo.pm }
>}
> 
> at the top of programs?
> 
> > The broken operating system, or rather family of systems (and I
> converted 
> > away from them about three years ago), still is used by 90% of
> users. In 
> > practice, it does matter what happens in that environment.
> 
> Yes--but better for implementators to make that decision than for
> each and 
> every Perl programmer (most of whom will have no experience with most
> OS's 
> Perl runs on, so will be making such decisions blind!) to make them 
> separately (and differently).
> 
> > But also consider, whatever operating system is in use, it has to
> know how by 
> > default to handle a file - interpret it as a script, run it as a
> native 
> > executable, pipe it to an editor or renderer etc. That information
> has to be 
> > associated with the file in some way. One operating system uses
> name 
> > extensions, another looks at the first line for a #! etc.
> >
> > Personally, I find it useful to have a visible clue in the name
> (via an 
> > extension) as to the content of the file. This seems to me more
> widespread 
> > than just an OS requirement, as otherwise why have *.tar *.tar.gz
> *.pdf *.doc 
> > *.png etc or even .* for hidden files in unix?
> 
> The .tar, etc., are typically named for transport, where you may need
> to 
> know the filetype without having the benefit of its contents for 
> examination.  *.pdf and *.doc are filetypes that did not exist until
> after 
> Windows did, and so the required-extension behavior ossified.  The .*
> 
> convention merely came about because it was a convenient kludge put
> into 
> ls for the purpose.
> 
> By way of illustration,
> % mv foo.png foo.jpg
> does not convert the file's image type.  If it did (or if it refused
> to do 
> the move) you'd have an argument there.
> 
> > If it doesnt matter - as far as perl6 is concerned - how the module
> is named 
> > (see Larry Wall's response regarding unicode and case-sensitivity),
> then the 
> > extensions too are irrelevant, no? So if I choose to call my perl6
> scripts 
> > *.p6 it should not matter? Other than for the sake of tradition or
> conformity 
> > with the tribe's sense of propriety :)
> 
> Sure, knock yourself out.  Call it ".perl6" if you like, or 
> ".niftynewlanguagethatisn'tquitecompatiblewith.pl" (except those
> violate 
> eight.3 rules).
> 
> > And that brings me to another question. Should it matter what the
> name of the 
> > file is? For modules in perl5 as far as I can discern, the name of
> the module 
> > in the file name has to conform with the package name inside the
> script. I 
> > have found this default behaviour annoying at times.
> 

Re: Multiline comments in Perl6

[Paul Hodges]

--- Jonathan Lang <[EMAIL PROTECTED]> wrote:

> Paul Hodges wrote:
> > http://perl6.org/doc/design/syn/S02.html still says:
> >  "Intra-line comments will not be supported in standard Perl"
> 
> This is wrong, since S02 also defines intra-line comments, under
> "Whitespace and Comments".  It calls them 'embedded comments'.  You
> don't need a 'use' statement.

So I found something worth fixing? =o]

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: Multiline comments in Perl6

[Paul Hodges]

I love this list. I wish I had more of value to contribute. =o]
But for those of you who don't want to read a long blather, this is
mostly opinion, hopefully sans soapbox. Feel free to skip to the end.

> What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years?  It's not
> like @Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.

I agree 100%. In fact, I've been guilty of this myself, but the point
is valid...and I think the  was a nice touch. Still, we do want
to keep polling the user base, if hopefully with a minimum of spam. As
long as we don't lose the forum under a deluge of whining and
me-too-isms, I think it's good to get the occasional, abbreviated
re-airing of old issues. For example, I missed this one the first dozen
times through

I don't like having to think about whitespace so much, but I'll get
used to that. Virtually every language uses significant whitespace, and
though P6 seems to be more saturated with *relevant* whitespace issues,
as a rule of thumb I have been bluntly impressed with what the @Larry
have been accomplishing. I'll learn, I'll deal, and I'll be happy for
the toys they let me buy with those quirks, lol

But for my meager $.02 in the matter

http://perl6.org/doc/design/syn/S02.html still says:
 "Intra-line comments will not be supported in standard Perl"

I obviously missed something again here. Could someone clue me in?
Isn't that what this thread is talking about with #{...}? 
I assume it's a module-based construct, like most everything else?

Line comments and POD are fine, but I have (on occasion) missed being
able to use embedded comments. I'm glad they'll be available now, but I
doubt I'd add a use() to get them most of the time -- just personal
preference; I'd rather save the line of code, lol. I don't personally
even mind having to deal with the whitespace rule, though it does feel
pretty wierd to me.

I think the bracketing construct is a cool concept. Start with a
hashmark and follow it with a bracketing construct, and it comments
everything in the bracket but I have to say just for the
accumulation of weight on the issue that it's going to really take some
time for me to get used to thinking of comments as ending with just a
bracket, especially since I'll have to trace back to the matching
structure to make sure it's the right bracket.

Syntactically, I know @Larry's a lot smarter than I am, so I defer, but
could we start thinking now, as a community, in terms of standards for
this? I mean, correct me if I'm wrong, but didn't most of us follow the
general convention of making filehandle names capitalized in P5? Perl
didn't care, but it's a courtesy we observed for ourselves and the
inheritors of our code. Of course, I usually used a scratchpad variable
instead.

So I'll probably tend to use some standard set of brackets and "flag"
characters just for my own benefit. On that note, I do have a couple of
actual questions. =o)

Is there any restriction of the whitespace *inside* the comment?
And is / a valid bracketer? Is there any problem with something like:

   @x = #/* here's an embedded comment */ 1..99;

or should I stick to things like

   $x = #<-- comment  --> 1;
   $x = #{   comment   #} 1;
   $x = #(   comment   +) 1;
   $x = #[   comment  =o] 1;

Or will any of these not work?

I suppose there's always #{/* foo */}
Or when all else fails, just move the comment to a line of it's own, or
a block of POD. ;o]

Thanks for your patience and your input,
Paul

--- "Mark J. Reed" <[EMAIL PROTECTED]> wrote:

> Whitespace is significant in many places.  Even in some of the
> corners of Perl 5.  Perl 6 has a different set of rules, and it
> will take some getting used to, but the rules are designed to
> let you do things as naturally as possible.
> This, for instance, works fine:
> 
> my @values =
> # (1,2,3)   # older values, don't use
> (4,5,6);
> 
> If I were suddenly granted the magical ability to impose my will upon
> the design of Perl 6 and change anything I wanted, the multi-line
> comments leading-whitespace exception would not make the top 5.
> 
> What's with the sudden influx of people swooping in at the
> last minute and attacking design decisions that were made, with much
> angst and public debate, over the span of months and years?  It's not
> like @Larry are doing things based on whim; if they were, Perl6 would
> have been done 2+ years ago.
 



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: Bite-sized Tasks for the Interested (was Re: Standards bearers)

[Paul Hodges]

Sounds like a good plan to me.
It's one of those bite-sized tasks that will grow with time, but will
make the overall process move along. Feel free to tag me offlist for
help, too.

--- ispyhumanfly <[EMAIL PROTECTED]> wrote:

> chromatic wrote:
> > On Tuesday 11 December 2007 09:20:22 Paul Hodges wrote:
> >
> >   
> >> But on this general note, is there any current organization or
> location
> >> where small problems are being parcelled out? I'd love to help,
> but my
> >> time is as limited as everyone's If I could get small bites of
> work
> >> to do, maybe I could contribute something useful.
> >>
> >> Anyone requesting one black-box module or function at a time? Or
> am I
> >> pipe dreaming?
> >> 
> >
> > I used to publish a Pugs and a Parrot task of the week in the
> Perl.com 
> > newsletter, but there didn't seem to be much uptake and so it
> slowly 
> > dissolved.
> >
> > It might be nice to have a small list of bite-sized tasks for the
> interested 
> > linked off of dev.perl.org/perl6 and the various project pages.  I
> know 
> > there's a Perl 6 wiki around here somewhere, so in theory all we
> need is 
> > someone to prune the page regularly and poke various projects
> asking for a 
> > couple of small tasks for the uninitiated.
> >
> > -- c
> >
> >   
> I realize now I sent a post directly to chromatic regarding this
> issue, 
> but I've developed an idea using an existing technology that could 
> really help for organizing something like this.  www.hiveminder.com
> is a 
> task/to-do list organizer application written using Jifty.  It's
> created 
> and mainted by the Best Practical team.  I would be willing to
> maintain 
> a group on hiveminder and people interested in getting involved can 
> create accounts and have tasks assigned to them.  These tasks could 
> easily be tracked and monitored in an organized fashion with rss
> feeds 
> available for viewing by say; perl.org?  Just an idea...
> 
> -- 
> _ispy++ >> [EMAIL PROTECTED] :: use Perl;
> 
> 


===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: Standards bearers (was "Re: xml and perl 6")

[Paul Hodges]

It also helps that you consistently make incisive observations and
contributions to conversations, even if they are a little tart
sometimes. :)

But on this general note, is there any current organization or location
where small problems are being parcelled out? I'd love to help, but my
time is as limited as everyone's If I could get small bites of work
to do, maybe I could contribute something useful.

Anyone requesting one black-box module or function at a time? Or am I
pipe dreaming?

--- chromatic <[EMAIL PROTECTED]> wrote:

> On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote:
> 
> >  I download pugs and parrot from
> > SVN repositories, written tests - one of which still hangs the
> > compilation of pugs. Indeed the test I wrote for pugs concerned the
> > ability of pugs to use existing CPAN modules. I have tried parrot
> with
> > SDL and the tests fail. My aim was to write a P6 GUI module so that
> from
> > the start it would be easy for P6 users to generate UI interfaces
> easily.
> 
> If you send me or the Parrot list the Parrot test results, I will do
> my best 
> to fix them.
> 
> > Unfortunately, despite my eagerness, I am not a professional
> programmer
> > with the time or the skill to fix the problems. Where I can
> contribute
> > is to express a view about how P6 might best be developed.
> 
> Hey, I'm a trained musician and sometimes novelist who develops
> software on 
> the side, and the primary reasons @Larry absorbed me are that:
> 
> 1) I transcribe conversations faster than anyone else on the team
> 2) I had a working keycard to O'Reilly's Tarsier meeting room in
> Sebastopol
> 
> and the reason I keep working on this stuff is:
> 
> 3) I'm some combination of too stubborn or too stupid not to keep
> working on 
> it
> 
> All it takes to make a contribution is a fraction of my stupid or my
> stubborn 
> plus some spare time.
> 
> -- c
> 



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: Standards bearers (was "Re: xml and perl 6")

[Paul Hodges]

duh. I'll learn to finish reading all the posts before adding my own
*someday*.

--- Darren Duncan <[EMAIL PROTECTED]> wrote:

> At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote:
> >Darren Duncan wrote:
> >>At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote:
> >>>Equally, Something to replace CGI or DBI will be essential to the 
> >>>uptake of P6. I would far prefer to have a skilled and resourceful
> 
> >>>professional, such as yourself or Damian Conway write these 
> >>>modules than leave it to enthusiastic amateurs such as myself.
> >>
> >>I for one can assert that both of these are being produced right 
> >>now. Also that neither is part of the Perl 6 kernal, though the 
> >>kernal may enhanced over time to better support them. -- Darren 
> >>Duncan
> >
> >A great relief. Fantastic.
> >
> >Where should I be looking to see what is happening. Is there some 
> >form of coordination of this module writing activity?
> 
> Look in the ext/ subdirectory of Pugs version control to start with, 
> as it contains a bunch of Perl 6 modules in various stages of 
> completion, some doing http or web stuff, and some doing database 
> stuff.
> 
> One place to look for some coordination is on the perl6-users list. 
> They were discussing a CGI replacement awhile ago, and Juerd made a 
> proposal plus some example code, which became HTTP/ and Web/ under 
> ext/.
> 
> On various DBI lists there was some talk about DBI-2, which it ended 
> up will have a foundation written for Parrot with bindings for Perl 
> and other languages.
> 
> There is also a mod_parrot project.
> 
> There is also my Muldis DB project, a version of which is written in 
> Perl 6, and which is being built rigorously.
> 
> These efforts are all separate from each other, as per CPAN module 
> development in general, and there is no one coordination point of all
> 
> of it.
> 
> But the work is still getting done nonetheless.
> 
> As for standards, well those tend to be defacto.  Whichever of these 
> projects get functional and used will likely set the pace for what 
> comes next, which may include forming the basis for more formal 
> standards.
> 
> -- Darren Duncan
> 



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

[OT][SPAM] Re: Pair notation for number radix

[Paul Hodges]

This is another great example of why I love this list. :o]

I live in GA, so far out in the boonies that I can't get cable or
broadband at *all* except for by satellite. I've stopped trying to
explain what I do, because I start saying things like this, and they
glaze and visibly regret it, lol

Now I just tell them my official job title is "computer monkey".
That works pretty well. :)

But so that this post isn't (hopefully) entirely hot air, 
 How does this sort of adverbial typecasting relate back to compile
time typing? The old my Dog $spot thing?

There seems to be a significant relationship, but I can't wrap my head
around where the underlying mechanics might be usefully applied.



--- Ryan Richter <[EMAIL PROTECTED]> wrote:

> On Tue, Dec 04, 2007 at 07:39:16AM -0800, Larry Wall wrote:
> > On Sun, Oct 07, 2007 at 03:01:06PM -0600, David Green wrote:
> > > What happened to the suggestion of using ` to designate units?
> > 
> > It's kinda caught between two other notions.  On the one hand,
> > we're trying to reserve ` for user definition, in part because it's
> > so difficult to tell from ' in many fonts so we're avoiding it for
> > standard usage.  On the other hand, it's not clear that units
> aren't
> > generally just simple multiplication by a scaling factor: 1*in,
> where
> > 1*in == 2.54*cm, for instance.  Units could also be viewed as type
> > conversion, which would give us kg(1) and 1.kg as conversion forms
> > in current Perl 6.  Since 1.kg is essentially using the units as a
> > postfix, presumably the 1kg form could also work on literals, just
> as
> > we currently allow 1i to convert 1 to i via the postfix:
> operator.
> > (And I suppose there's a sense in which 10e-2 is specifying the
> > scaling factor of the left side explicitly.)
> > 
> > In any case, though, if we treated them as type names rather than
> > just methods, we'd probably want to require predeclaration of unit
> > names since a type name like "kg" or "in" or "fortnight" could
> easily
> > collide with a user-defined routine.  Or maybe they still want some
> > special sigil-ish mark to stay in their own namespace.  Dunno.  I
> don't
> > think we have to solve that for 6.0.0 in any case, especially if we
> > require predeclaration of which unit names are wanted, in which
> case
> > there might just be a units pragma that can pull in selections of
> > the predefined units:
> > 
> > use units :cgs, :nasa, <μfortnight gibibyte>;
> > my newton $thrust = 42.lbf;
> > 
> > But with a sigilish mark we could just pull in all the units from
> > /usr/share/units.dat, I suppose.
> 
> I don't know if I ever mentioned it on the mailing list, but a while
> back I did some work on a units module that uses units.dat
> (examples/rules/unitsdat-grammar.pm in the pugs repo).  I think
> that a simple postfix syntax (e.g.) doesn't give you the ability to
> specify the kind of composite units that are common in scientific
> applications where units are heavily used (e.g. Gauss per square root
> Hertz).  Those kind of units also rule out simple type-based units,
> e.g.
> having roles for length, mass, etc. - you can't do a role to the -7/3
> power.  I settled on a syntax that allows a mini-language similar to
> units(1):
> 
> 9.8.:as
> $field_noise.:as
> 
> But someone may be able to come up with something better.  My
> implementation does unit type-checking at runtime, but compile-time
> checking would be much nicer where possible.  It would also be cool
> to
> be able to define roles that can represent themselves in several
> different units:
> 
> role Photon does NumUnit { ??? }
> my Photon $p .=new( energy => 42.:as );
> say "energy is $p.:as zeptojoules";
> say "wavelength is $p.:as Å";
> say "frequency is $p.:as THz";
> 
> -ryan
> 



  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: xml and perl 6

[Paul Hodges]

--- Alex Kapranoff <[EMAIL PROTECTED]> wrote:
> Â ×òâ, 29/11/2007 â 07:18 +0100, James Fuller ïèøåò:
> > On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> > > > I do not nec. agree with 'a particular grammer is not' part
> > > > of the core ... if that grammar is so common to every problem
> > > > (like regex is) then why not include it?
> > >
> > > Because it's not necessary for getting and installing other
> > > extension modules.
> > >
> > > The criterion for including a module in the core is "Is this
> > > necessary to get and install other modules?" not "Why not
> > > include this module?"
> > 
> > I read this statement as saying that perl's core main purpose is to
> > enable extension versus be a useful programing language ?

You say that as if they were somehow mutually exclusive.
It's accomplishing one via the other.

> > feels like we are externalizing what I would call build artifacts
> > of a language  e.g. a distro of Perl 6 should be easy to adopt
> > and easy to use immediately . I would like to see some basic
> > level of XML support in this distro.
> > 
> > I understand that there can be different distros customized to
> > certain problem domains, but as explained I see XML as common to
> > all those problem domains.
> 
> But is it? I'm sure you can easily find lots of people using Perl
> professionally without any need of an XML parser/processor. Just like
> database or web libraries. Why do you consider XML something
> essential without also insisting on all the other technologies
> people use in Perl?

I've been using Perl for ten years, and I've used tons of CGI and DBI
and even a good bit of ACME, but I've never needed XML at all. Not
everyone does things the way you do, and I'm glad I didn't have to
spend out very limited disk space on features we didn't need.

Yeah, disk is cheap now, but don't assume everyone has the same
resources, needs, or red tape you have.

Paul


  

Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

Re: Micro-articles on Perl 6 Operators

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 18, 2007 at 07:41:54PM -0700, Paul Hodges wrote:
> :  while length($ruler) < $len;  # till there's enough
> 
> There is no length function anymore.

duh. I knew that. Still thinking in v5.
Thanks, Larry.


   

Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, 
photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC

Re: Micro-articles on Perl 6 Operators

[Paul Hodges]

Looks good . . . but how short do we want them?
For the non-Perl audience, I think it might be worth mentioning the
 (to us) obvious automatic context manipulations. e.g.,

 ~ is "stitching" strings, and will make strings out of its arguments
if it can -- it's not adding, but has the same precedence, so:
  $x =  1 ~  2  + 3;  # 15: is "12" + 3, string coerced to number

maybe even add
  $y = (1 ~  2) + 3;  # 15: same as above, but explicit
  $z =  1 ~ (2  + 3); # 15: 1 ~ 5, numbers coerced to strings
though I think that adds up to a bit too much clutter.
 
Or have I gone too long without sleep? It looks funny
  
The point is that we want these articles to play up both the old
"perlishness" that's retained for those fearful of change, and give a
good feel of what "perlishness" is all about to those used to C and
Java...or CoBOL and ForTran. We also want shell programmers to see that
the convenience factor of quick scripting is still there, but with
Perl's ramped-up capabilities -- it beats the hell out of ksh and awk,
after all, but isn't really so much harder to learn and use, either at
the low or the high end.

Maybe we should add a "Making the easy things easy, and the hard things
possible" tagline to all these articles. :)

Also -- is it out of the scope of these to have each perhaps present a
basic problem and a use of the operator to solve it? I think the zip
article does that, and the example helped, but this one seems like a
small but faintly operator-spicy example would help, even if a little
contrived.

  sub page_ruler ( uint8 $len = 80 ) { # take int, max 256, default 80
  my $ruler = '';  # declares a buffer
  my $digit = 0;   # starts with 0
  $ruler ~= $digit++ % 10  # appends next digit
 while length($ruler) < $len;  # till there's enough
  return $ruler;   # and returns the string
  }
  my $r = page_ruler(25); # 0123456789012345678901234

Again, PLEASE double-check my probably goofy syntax. 

Paul

--- Adriano Ferreira <[EMAIL PROTECTED]> wrote:

> On 9/18/07, Paul Hodges <[EMAIL PROTECTED]> wrote:
> >
> > --- Adriano Ferreira <[EMAIL PROTECTED]> wrote:
> > [[snips here and at end]]
> > > > . . . I have one suggestion: you might want to mention
> > > > the roundrobin function in the article on the zip function
> since
> > > > the two are very closely related.
> > >
> > > Thanks, Joe and Alberto.
> > >
> > > Even though the roundrobin is very closely related to zip, I
> think
> > > that mentioning it and giving an explanation would add length and
> > > detail to the article. I already sacrificed the trick with (@x,
> *) to
> > > extend a list and the @@() for multidimensional context, which
> are
> > > fine but too much for this piece of text.
> >
> > It would certainly add length, but you could minimize the addition
> of
> > detail by using them as hooks. Maybe embed them in a special
> section...
> > e.g.,
> >
> > 
> > For the Gearheads
> >
> >   We won't bore you with excess details, but for more info on the
> trick
> >   with (@x, *) to extend a list and the @@() for multidimensional
> >   context, c.f. .
> > 
> 
> I am thinking about such hooks and good ways to do that. More on that
> later.
> 
> > Sorry, not sure where to link off the top of my head, but if anyone
> > thinks it's a good idea I'll look it up on request.
> >
> > > Well, it's kind of hard to keep these articles small and
> interesting.
> > > Maybe this stuff can find their way in later articles.
> >
> > Personally, I'm a bit behind on my P6, but I think this is a good
> idea.
> >
> > I'd be happy to contribute something, and though my time is short
> like
> > everyone's these days, please feel free to contact me here or
> offline
> > with requests or suggestions. If you like, I could even try to
> > ghost-write an article or three. I'll go look over the list and see
> if
> > there's anything I feel competent to work with (but feel free to
> tell
> > I'm a schmuck and I shouldn't bother if I don't post more. =o)
> 
> I salute every bit of help. I am trying to organize the production
> and
> will hopefully provide more details soon. By now, I think that I can
> handle suggestions and corrections to the articles. The next one is
> here:
> 
> http://ferreira.nfshost.com/perl6/stitching6.html
> 


===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


  

Check out the hottest 2008 models today at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html

Re: Micro-articles on Perl 6 Operators

[Paul Hodges]

--- Adriano Ferreira <[EMAIL PROTECTED]> wrote:
[[snips here and at end]]
> > . . . I have one suggestion: you might want to mention
> > the roundrobin function in the article on the zip function since
> > the two are very closely related.
> 
> Thanks, Joe and Alberto.
> 
> Even though the roundrobin is very closely related to zip, I think
> that mentioning it and giving an explanation would add length and
> detail to the article. I already sacrificed the trick with (@x, *) to
> extend a list and the @@() for multidimensional context, which are
> fine but too much for this piece of text.

It would certainly add length, but you could minimize the addition of
detail by using them as hooks. Maybe embed them in a special section...
e.g., 


For the Gearheads

  We won't bore you with excess details, but for more info on the trick
  with (@x, *) to extend a list and the @@() for multidimensional
  context, c.f. .


Sorry, not sure where to link off the top of my head, but if anyone
thinks it's a good idea I'll look it up on request.

> Well, it's kind of hard to keep these articles small and interesting.
> Maybe this stuff can find their way in later articles.

Personally, I'm a bit behind on my P6, but I think this is a good idea.

I'd be happy to contribute something, and though my time is short like
everyone's these days, please feel free to contact me here or offline
with requests or suggestions. If you like, I could even try to
ghost-write an article or three. I'll go look over the list and see if
there's anything I feel competent to work with (but feel free to tell
I'm a schmuck and I shouldn't bother if I don't post more. =o)

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


   

Be a better Heartthrob. Get better relationship answers from someone who knows. 
Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

Re: Web Module (Was: Perl6 new features)

[Paul Hodges]

How about a Bundle::Common?
Streamline both the core and the inclusion of the most commonly used
modules? The core does include the CPAN module, right?

Personally, I *prefer* grabbing what I need piecemeal, but I understand
making it easy if possible

--- Luke Palmer <[EMAIL PROTECTED]> wrote:

> On 6/25/07, Peter Scott <[EMAIL PROTECTED]> wrote:
> > I will just voice my support for putting best-of-breed modules for
> very
> > common tasks (CGI, DBI for sure) in the core.
> 
> Of course, then you get the disadvantage that most users will see new
> versions of those modules as often (or seldom, as it were) as perl
> itself.
> 
> Luke
> 


===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


   

Choose the right car based on your needs.  Check out Yahoo! Autos new Car 
Finder tool.
http://autos.yahoo.com/carfinder/

Re: Is Perl 6 too late? (an aside)

[Paul Hodges]

It's a valid aside to note that, while people know what singular and
plural are, few people use or even refer much to the Greek use of a
special intermediary (the dual) when there were exectly two of
something...but the basic mindest of dichotomy is a fundament of the
language. (c.f. the men/de construct so basic to the language).

Perl is like that. There are a lot of little corner cases that are
distinctly Perl, things unlikely to be seen elsewhere, and sometimes
hardly ever even used in Perl but the mindset that is Perl is a
beautiful thing, and that's still there. 

Besides, if you don't get the aesthetics of the Schwartzian Transform,
then you should probably be using python or java anyway, hm?

Let's let Perl be Perl. It's a new Perl, but it's still a pearl. =o)

*Paul

--- Larry Wall <[EMAIL PROTECTED]> wrote:

> On Mon, May 14, 2007 at 02:21:47PM -0400, Ryan Richter wrote:
> : In Perl 6, the & sigil is used to distinguish between
> : 
> : foo bar
> : 
> : which calls bar and passes the return value to foo, and
> : 
> : foo &bar
> : 
> : which passes bar as a Code object to foo.
> 
> In other words, the sigil is consistently a noun marker in Perl 6,
> even when a sigil is used on a verb.  In Perl 6, where sigils
> distinguish nouns not only from verbs, but also from adjectives (if
> you count types as adjectival).  With a glance you can tell which
> are the nouns and which are the types here:
> 
> multi CatDog sub make_catdog (Cat $cat, Dog $dog) {...}
> multi CatDog sub make_catdog (Cat Dog $catdog) {...}
> 
> While Gabor is correct that in Perl 5 removing the sigils from verbs
> made some verbal collisions happen that otherwise wouldn't have, in
> Perl 6 we've mostly fixed that by essentially getting rid of most
> reserved words, and making even the builtin functions participate
> as normal multis and methods.  For that reason, and because verbs
> linguistically tend to be disambiguated by the nouns fed to them as
> argements, verbs don't need to be conjugated nearly as badly as nouns
> need to be declined.  A lot of nouns typically don't have arguments
> to disambiguate them with, at least until you start subscripting
> them,
> and we don't do multiple dispatch on subscripts.
> 
> As for the original complaint, we long ago decided to ignore people
> who
> are prejudiced against languages that mark nouns.  Greek wouldn't be
> Greek if you couldn't decline your nouns.  (In my estimation, it's
> the conjugated verbs that make Greek so difficult to learn, really.
> On the other hand, once you learn them they're very expressive in
> tense and aspect.  It's all tradeoffs.)
> 
> Larry
> 



 

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: S04 - forbidden coding-style

[Paul Hodges]

I know, shoot me -- but just so we've discussed it and put it to bed,
maybe :if or _if or fi?




--- Aaron Crane <[EMAIL PROTECTED]> wrote:

> Larry Wall writes:
> > Maybe we should just make statement modifiers uppercase and burn
> out
> > everyone's eye sockets. :)
> 
> I like statement modifiers, and I want them to continue to exist in
> Perl 6.
> But it seems to me that a lot of the most awkward decisions about
> Perl 6
> syntax are awkward precisely because
> 
>   EXPR
>  if EXPR;
>   BLOCK
> 
> and
> 
>   EXPR;
>   if EXPR BLOCK
> 
> are so similar.
> 
> Bearing that in mind, would the eye-socket-burning
> 
>   return $foo
>   IF $something;
> 
> really be so bad?
> 
> Alternatively, perhaps it's possible to find some other morphological
> or
> syntactic device to distinguish statement_modifier: from
> statement_control:, for both humans and the compiler.  One option
> might
> be to require an extra token (a postfix complementizer?) before a
> statement
> modifier.  Maybe something like this:
> 
>   return $foo
>   --- if $something;
> 
> -- 
> Aaron Crane
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Can foo("123") dispatch to foo(Int) (was: Mutil Method Questions)

[Paul Hodges]

so back to foo("bar"). What's the default behavior? String doesn't Num,
does it? though is does convert if the value is good 

Does that mean foo("123") should or should not dispatch to foo(Int)?
Or even foo(Num), for that matter Oy, I could see some headaches
around setting these rules in mind, lol What's the DWIMmiest
behavior hear?

I assume foo(1) would dispatch to foo(Int) rather than foo(Num), as the
most restrictive fit, and I could see how that could blow up in my
face. Is there some basic compile time warning (and a way to tell it
"shut up, I know what I'm doing") that says "hey, these are
suspiciously close signatures, are you sure this is what you wanted?"

Is the difference that foo("123") can be easily converted to foo(123)
without data loss, whereas foo("bar") to foo(0) cannot?

--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
> > And what about other types?
> > e.g. if String can't ever be "best candidate" for Int,
> > then does that mean that neither can Int ever be "best candidate"
> > for Num, because they are different types?
> 
> Well, I think Num and Int *aren't* different types because as far as
> duck typing goes, Num does Int.  I wouldn't expect that String does
> Int though (at least not without some help :).
> 
> The way I see it, the types specified in the signature are like
> constraints.   When you say
> 
> sub foo (Num) { ... }
> 
> the signature says that "only an item that can perform the Num role
> may fit in this slot". When perl tries to match Capture to Signature,
> it checks the type of each argument in the Capture against the 
> "does list" for each parameter in the Signature.  If the argument
> type appears in the "does list" of the Signature, then it's a match
> and all is well.  Otherwise it's an error.  Since "Num does Int",
> a call such as C succeeds.
> 
> At least that's my vague interpretation of this aspect of perl6 at
> this moment.  :-)


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Synchronized / Thread syntax in Perl 6

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 03, 2006 at 03:51:45PM -0700, Paul Hodges wrote:
> :  { no threads;
> :print @_.»();
> :  }
> 
> It seems a bit odd to use a construct for its syntactic sugar value
> but take away its semantics...
> 
> If you just need ordering, this (or something like it) should
> serialize it:
> 
>print $_.() for @_;
> 
> Larry

LOL -- and "d'oh".
Apologies, not enough sleep. 
I stand corrupted. :o]

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Synchronized / Thread syntax in Perl 6

[Paul Hodges]

--- Ashley Winters <[EMAIL PROTECTED]> wrote:
> On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote:
> >
> >  my @answer = map { async { &_() } } @jobs;
> 
> That still seems too explicit. I thought we had hyperoperators to
> implictly parallelize for us:
> 
> my @answer = @jobs.»();
> 
> Which would run them in parallel automatically, if possible.

Snazzy bit of syntactic shenanigans, that...and slick, if we're in that
mode, but just to clarify, I *will* still be able to know whether or
not something's going to thread? Or will it matter?

Seems to me there will be times when I WANT a purely single-threaded
system, even if I'm using hyperops -- in fact, especially if I'm using
hyperops. Maybe we need a pragma to be able to step in and out as
needed?

 { no threads;
   print @_.»();
 }



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: Synchronized / Thread syntax in Perl 6

[Paul Hodges]

--- John Drago <[EMAIL PROTECTED]> wrote:
. . .
> >  class QueueRunner {
> >our sub process_queue(Code @jobs_in) {
> >  my @ans is serial;
> >  @ans.push map { async { &_() } } @jobs_in;
> >  @ans;
> >}
> >  }
> >  my @answer = QueueRunner.process_job_queue( @jobs );
> 
> Actually I think you did it just right.
> I think that horse is dead now.

LOL!! I'm flattered. =o)

> So, what about "serial" classes and methods?:
> 
> # Does marking this class "is serial" mean it's forced to be a
> singleton?

Hmm I wouldn't think so. You should still be able to spawn object
instances, but I'd say it scopes the lock to the whole class, so that
everything in that container is locked any time anything in the class
in accessed. It's a cheap way to make all shared resources queue up
nicely, if you just want a quick and dirty script instead of something
well streamlined. Kind of like locking at the DB or table level instead
of just the row, but there are times when that's what you need.

. . . 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: Synchronized / Thread syntax in Perl 6

[Paul Hodges]

--- John Drago <[EMAIL PROTECTED]> wrote:
> > You mean "is parallel" as a synonym for "is async"?
> 
> I think "is parallel" denotes something as usable by multiple threads
> simultaneously, "in parallel".
> "is serial" would denote that only one thread can use the $thing at a
> time, exclusively.

Are you saying both are asynchronous, but one specifies that a resource
should be locked rather than duplicated?

> . . .  
> > If $age has been passed to an asynchronous closure, it should be
> > marked as locked, and other threads trying to access it would have
> > to get a lock first. Yes, lots of overhead but that way if the
> > default is WAIT (which seems the smart default to me), the thread
> > waits until TakesForever() releases the resource.

In that light, responding to my own comment, you could infer that you
should lock anything passed by reference, and not worry about it if
passed by value unless you said "$age is locked" or "is serial" or
whatever, yes?

> > if we declare
> > 
> >  our method TakesForever ( int $num is serial ) is async but NOWAIT
> {
> >...
> >  }
> > 
> > or
> > 
> >  my $age = 27 but NOWAIT;
> > 
> > or
> > 
> >  TakesForever( $age but NOWAIT );
> > 
> > (or whatever) then I'd say it should just fail. I mean, isn't that
> kind
> > of the idea, to have that sort of flexibility?
> > 
> 
> Perhaps some more syntax-play is in order here.

lol -- yeah. :)
 
> One thing about threading with Perl5 is that it is easy to write a
> simple threaded program that is entirely opaque - unless you
> wrote the program yourself.
> 
> The program below gets a list of coderefs and executes each one, then
> returns the result.
> #
> (Using the threads.pm way...)
> package QueueRunner;
> 
> use strict;
> use threads;
> use threads::shared;
> 
> sub process_job_queue
> {
>   my ($s, @jobs_in) = @_;
>   my @results : shared = ();
>   my @workers = ();
> 
>   push @workers, async { push( @results, $_->() ) } foreach @jobs_in;
>   $_->join foreach @workers;
>   return @results;
> }# end process_job_queue()
> 
> # Elsewhere...
> package main;
> 
> my @answer = QueueRunner->process_job_queue( \&job1, \&job2, \&job3
> );
> 
> #
> And my attempt at the same, using Perl6: 
> #
> 
> class QueueRunner {
>   our sub process_job_queue( Code @jobs_in ) returns List of Any {
> my Any @results is parallel;
> my Thread @workers = ();
> 
> for @jobs_in {
>   @workers.push( async { &_() } );
> }
> for @workers {
>   @results.push( $_.join() );
> }
> 
> return @results;
>   }# end process_job_queue()
> }# end QueueRunner
> 
> # Elsewhere...
> my @answer = QueueRunner.process_job_queue( @jobs );
> 
> #
> 
> I made absolutely no progress here.  It seems to me that it's no more
> obvious what's going on here than in the Perl5 version.  Any
> comments?
> 
> Regards,
> John Drago

Hm. If we're using *implicit* threads (which I thought was the point),
how about

 class QueueRunner {

   our sub process_queue(Code @jobs_in) {
 my @ans is serial;
 @ans.push map { async { &_() } } @jobs_in;

 @ans;
   }

 }# end QueueRunner

 # Elsewhere...
 my @answer = QueueRunner.process_job_queue( @jobs );

The point is that the call to async() is supposed to handle the thread
management for you, isn't it?

Though if that works, you could squish this example even more, to

 class QueueRunner {

   our sub process_queue(Code @jobs_in) {
   map { async { &_() } } @jobs_in;
   }

 }# end QueueRunner

 # Elsewhere...
 my @answer = QueueRunner.process_job_queue( @jobs );

and the issues of serialization are hidden in the map() call. For all
that

 my @answer = map { async { &_() } } @jobs;

though that gets away from the point.

Someone smack me if I'm drifting too far here?

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: Synchronized / Thread syntax in Perl 6

[Paul Hodges]

--- John Drago <[EMAIL PROTECTED]> wrote:
> James Mastros wrote:
> > I don't like the name synchronized -- it implies that multiple
> > things are happening at the same time, as in synchronized swiming,
> > which is exactly the opposite of what should be implied. 
> > "Serialized" would be a nice name, except it implies serializing
> > to a serial format, like disk. "Locked" is the best name I can
> > think of, and it frankly isn't that good -- it's so vauge as to
> > be able to mean almost anything.
> > . . . 
> 
> Agreed - maybe "is serial" instead, which suggests "is parallel"
> would be its implicit counterpart.

You mean "is parallel" as a synonym for "is async"? I actually like it
better, but that's just me.
 
> If we have a situation that looks like this:
> 
> our method TakesForever ( int $num is serial ) is async {
>   # Do something that takes a long time...then:
>   $num++;
>   # $num has not been changed by anything else that might
>   # have access to $num.
> }
> 
> my $age = 27;
> TakesForever( $age );
> $age += 20; # Fails somehow, because &TakesForever is working on $num

Hmm
Is "fails somehow" the default?
I was thinking the better default would be more like standard
threading.
If $age has been passed to an asynchronous closure, it should be marked
as locked, and other threads trying to access it would have to get a
lock first. Yes, lots of overhead but that way if the default is
WAIT (which seems the smart default to me), the thread waits until
TakesForever() releases the resource.

if we declare

 our method TakesForever ( int $num is serial ) is async but NOWAIT {
   ...
 }

or

 my $age = 27 but NOWAIT;

or

 TakesForever( $age but NOWAIT );

(or whatever) then I'd say it should just fail. I mean, isn't that kind
of the idea, to have that sort of flexibility?
 
> Maybe a better example is needed - this one is pretty contrived.

I dunno. It gets a point across.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Synchronized / Thread syntax in Perl 6

[Paul Hodges]

How about one of these?
==

 class Baz {
   has $.a is restricted;
   has $.b is controlled;
   has $.c is unique;
   has $.d is shared;
   has $.e is queued;
   has $.f is token;
   ...
 }

--- John Drago <[EMAIL PROTECTED]> wrote:

> I asked this via the Google Groups interface a few weeks ago, but I'm
> not sure if it made it here.
> I am asking again in case the question never made it onto the list.
> 
> Has the syntax for synchronized/threaded @things been worked out?
> For example:
> 
> class Foo is synchronized {
>   ...
> }
> 
> our method Bar is synchronized {
>   ...
> }
> 
> class Baz {
>   has $.Bux is synchronized;
> }
> 
> ...or is there some new, less Java-esque way to express "only one
> thread may access this thing at a time"?
> 
> 
> 
> 
> John Drago | VP Software Engineering
> [EMAIL PROTECTED] 
> www.precissystems.com 
> 
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: packages vs. classes

[Paul Hodges]

--- Stevan Little <[EMAIL PROTECTED]> wrote:

> On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote:
> > People can diverge completely with completely incompatible
> > metaclasses that don't .do those roles, the only side effect
> > of which being that people who write code for the standard
> > Perl 6 metamodel will be incompatible, and maybe some ways
> > of setting up the class won't work without another layer of
> > trickery. I *think* that's what you're getting at. Of course,
> > it shouldn't be prohibited just because it smells.
> 
> I am not sure I like this, incompatible metaclass issues are really
> really tricky and hard to debug (aka - smells *really* bad). And the
> system needed to support them really can bloat the metamodel
> internals in a nasty way. There are several papers out there on the
> subject, none of which IMO provide a satisfactory solution. The 
> problem then becomes compounded by introducing the Python and Ruby
> metamodels into the fray. Having a single compatability level made
> out of roles is not that much of a restriction really, and keeps
> much of the system interals clean and orderly. It also makes it
> much easier for use to add new metamodels from other languages by
> just by writing a layer to map to the core metamodel roles.


I'd say a more standard system is much better, so long as we leave a
standard set of hooks by which someone can insert a nonstandard setup.
A small API isn't a huge bloat, and is worth it, though I agree that a
full system might actually be counterproductive.

And by all that I've seen lately, the whole language is pretty
malleable that way; those who really want the nonstandard model can
take the small overhead hit of whatever internal shenanigans they need
to implement, and just about anything like that can be stuffed into a
module now, can't it?

So the upshot is, a standardized metamodel seems like the way to go to
me



And Congrats again, gramps. May your new little one be as loved as the
language you've also labored so much to guide to maturity. >;o]


Paul

"on est aisément dupé par ce qu'on aime" -- Molière (one is easily fooled by 
that which one loves)
"Increase in wisdom can be measured accurately by the corresponding decrease in 
anger." -- Friedrich Nietzsche
"There are trivial truths and there are great Truths. The opposite of a trival 
truth is obviously false.
 The opposite of a great Truth is also true."  -- Neils Bohr

"Real friends are those whom, when you must inconvenience them, are bothered 
less by it than you are." -- me. =o) 
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [svn:perl6-synopsis] r7784 - doc/trunk/design/syn

[Paul Hodges]

--- [EMAIL PROTECTED] wrote:
> . . .
> -Such an "eigenmethod" is delegated to C<.meta> just as method like
> . . .
> +Such an I is always delegated to C<.meta> just as

changing "eigenmethod" to I should also change "an"
to "a":

 +Such a I is always delegated to C<.meta> just as
   ^

Small thing, but someone will mention it eventually anyway.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: File.seek() interface

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Arguably, we could probably admit
> 
> $fh.pos = 10`bytes
> 
> for the case of seeking from the begining.  But I'd kind of like
> 
> $fh.pos = 10
> 
> to be considered an error.

It seems a logical extension also to say

  $fh.pos += 10`bytes

as shorthand for 

  $fh.pos = $fh.cur + 10`bytes

Likewise for -=

But then that begs the questions of *= (not too nuts), /= (same),
%= (great for fixed length records?) and the predictable other host of
operators.

Am I reaching?

Paul





Sell on Yahoo! Auctions – no fees. Bid on great items.  
http://auctions.yahoo.com/

Re: junctions as indicies

[Paul Hodges]

--- David Christensen <[EMAIL PROTECTED]> wrote:
> I'm looking in S09, and reading about junctions.  It seems to me
> that if we have a junction $j which we use to index into an array
> or a hash, it should DWIM and return a junction of the corresponding
> values.
> 
> @ar=[1..10];
> %hash=(a=>1,b=>4,c=>7);
> 
> $j=1|2|3;
> $k="a"|"c";
> 
> $u = @ar[$j];   # 2|3|4
> $v = %hash{$k}; # 1|7
> 
> Does this make sense to others?
> 
> David

Maybe, but I don't like returning junctures in those cases unless you
*explicitly* ask for it. I'd rather the default be the arbitrary lists
returned, or whatever fits the context. How about

 @ar=[a..z];
 %hash=(a=>1,b=>4,c=>7);

 $j=1|2|3;
 $k="a"|"c";

 @u  = @ar[$j];# (b..d)
 %u  = @ar[$j].kv; # (1=>'b',2=>'c',3=>'d')
 $u  = @ar[$j];# \(b..d)
 $ju = juncture @ar[$j];   # 'b'|'c'|'d'

 @v  = %hash{$k};  # (1,7)
 %v  = %hash{$k}.kv;   # (a=>1,c=>7) 
 $v  = %hash{$k};  # \(1,7)
 $jv = juncture %hash{$k}; # 1|7

Am I way off base here?

 



__ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
. . .  
> <-[a..z]>
> 
> should be allowed/encouraged/required.  It greatly improves the
> readability in my estimation.  The only problem with requiring .. is
> that people *will* write <[a-z]> out of habit, and we would probably
> have to outlaw the - form for many years before everyone would get
> used to the .. form.  So maybe we allow - but warn if not
> backslashed.

In general, I think this is a great idea, but what exactly do you mean
by "warn if not backslashed"? That I'd get a warning *any* time I use a
dash in a character class? I guess I can live with that.



__ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 15, 2005 at 11:28:31AM -0500, Rod Adams wrote:
> : David Wheeler wrote:
> : 
> : >But the first person to write <[a...]> gets what's comin' to 'em.
> : 
> : Is that nothing (since '.' lt 'a'), or everything after 'a'?
> 
> Might as well make it everything after 'a' for consistency.  One
> could also view the last dot as a special version of the ordinary
> "any" dot, and read it "a to whatever".
> 
> Larry

I think that if we're looking for consistency, the default should be to
read it as "a and everything after it". If someone wants "a to
whatever", they should write it <[a..\.]> since it's a pretty odd
fringe case.




__ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

Re: Classes with several, mostly unused, attributes

[Paul Hodges]

--- David Storrs <[EMAIL PROTECTED]> wrote:
> . . . .
> Obviously, however @Larry decide it should be, is the way it'll be
> and nothing I can say will change that.

Au contraire -- that's what this list is for.
State your opinion, man! :)

> That said:  this would suck.  Badly.
> We should not be optimizing for the compiler's convenience, but for
> the programmer's.

I'm pretty sure that's the case so far. The @Larry are trying to do as
much of the for as possible while minimally reducing the latter,
though, and that's also good.

> 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.)

For the record likewise, I also make my living writing perl scripts,
and the huge preponderance of them fall into one of two major
categories:
1) tools which use one or more of our in-house libraries such as
modules to parse a particular file layout, or
2) little 5 or 10 line utility scripts that handle a frequently needed
niche. (Or maybe that correct wierd behavior by reimplementing our
strange version of head)

That said, it's the strange and usually VERY old script that doesn't
start with

  use strict;
  use warnings;

In fact, one of those little utility scripts is explicitly for that: it
opens a file and puts things like those pragma and a stamp for who
started it when and when at the top. (Mostly it just edits itself into
a new file. :)

I for one (minority or not) would like strictures unless otherwise
requested, though I think the last I heard was the right approach --
strict by default in modules and classes, but not in simple scripts.

Doesn't that handle it?

PH

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Time to change the (perl 6) guard! [OT]

[Paul Hodges]

--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> . . . .
> Of the qualities you listed for Pumpking:
> 
> "Look, I already told you! I deal with the goddamn customers so the
> engineers don't have to! I have people skills! I am good at dealing
> with people! Can't you understand that? What the hell is wrong with
> you people?"
> 
> =Austin

lol -- for the few of us who might not get that, it's a beautiful
reference to "Office Space". Watch the movie -- you may live there. ;o]





__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: definitions of truth

[Paul Hodges]

--- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Paul Hodges wrote:
> > --- Spider Boardman <[EMAIL PROTECTED]> wrote:
> >>You need ord() for character/grapheme/byte/whatever testing that's
> >>equivalent to what C does.  Since C doesn't really have strings,
> >>and Perl does, this is just one of those differences between the
> >>languages where (essentially, and perhaps abusing some linguistics
> >>theory and terminology) you've run into a 'false cognate'.
> > 
> > lol -- C doesn't have strings, but Perl does?
> 
> He's absolutely correct.
> [snip]

lol remind me not to get so abstract when trying to make a point
(especially when sleepy and disorganized) on a board for programmers.
:)

Right, ok, agreed. I knew what he meant when I said it, and played
Devil's Advocate to make a point which got lost in translation, and
wasn't that important in the first place. 

Good night, all. :)

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: definitions of truth

[Paul Hodges]

--- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> Paul Hodges wrote:
> 
> > Do note that I realize I can check it. It's just that for no reason
> > I can quite define, my C background wants a null byte to be FALSE
> > without any special chicanery on my part when checking. I can live
> > with the fact it isn't going to be, it just seems odd to me.
> 
> If that seems odd to you, the implications of Perl's being an
> expression-based rather than a statement-based language will
> probably give you nightmares (strange nightmares about void
> context...)

lol -- strangely enough, I like that. ;o)

> >>I believe, from the way you asked your question, that you don't
> >>havethe right mental map to make it comfortable.  As I see it,
> >>at least, with respect to what you're asking about testing, Perl
> >>has strings and integers, but not 'characters'.
> > 
> > Perl has scalars, and they can be any of the above.
> 
> No.  A Perl scalar can't store a character per se.  It can store
> the ordinal value of the character as a number, or it can store a
> string of length one, but neither of those is the same thing as
> storing a character directly...

Ok, I'll give you that. And that's largely the reason for the true
null. I know. In the above statement I was actually thinking about
splitting strings into characters, but your point is absolutely
correct. I stand corrupted. I mean corrected. :)

> >>Consider this test in Perl:
> >>if "\0" {...}
> >>Its equivalent in C is this:
> >>if ("") ...
> 
> That can't be right.  If anything it's got the two languages
> flipped, but that's still not quite right either.  Apples and
> orange leotards.

lol 

> > But it isn't. The perl is passing a zero -- just a fairly obscure
> > one.
> 
> No, "\0" isn't zero.  It may become zero if you translate it from
> certain character sets (e.g. ASCII) to its numeric collating code
> (and this is what ord does, but ord is not one of the more
> frequently-used builtins, because that's just not something you
> need to do very much in Perl; 90% of the times I've seen ord used
> were in deliberatly obfuscated code), but otherwise it's a character,
> not a number.  Under more normal conditions it would numerify to
> zero only for the same reason "C" would also numerify to zero.

Sorry, I was thinking in C, where every data bit is a number. A
character in C is just a very small number, one byte wide. A null is a
zero; a '0' is a 48. In perl, there's an entire hat full of magic
swinging around under every scalar, which is, again, why it surprised
me that null wasn't assumed to be false when it was a single byte in a
boolean context. (Hm...I'm starting to sound a little redundant here, I
think) 

> > I just thought that the special value of an ASCII 0 fit well
> > into that ~arbitrary~ set, just as the special value of an ASCII
> > 48 does. It's just a mindset, as several folk have said, but hey,
> > I'd be ok if 0 was true because it wasn't the explicit boolean 
> > value of FALSEthough I'm REALLY glad Perl doesn't do that. :) 
> 
> Lisp does this -- anything that's not nil is effectively true (err,
> t). It works for lisp, but it wouldn't play nicely in Perl due to
> some other differences.

No comment. :)

> > lol -- C doesn't have strings, but Perl does?
> 
> As a fundamental data type, he meant.  C doesn't have strings in the
> same sense that Perl doesn't have characters.  Some languages have
> both, you know, and so the character A is not the same thing as the
> string "A" and would be stored in a variable with a different type. 
> (I'm thinking here of Pascal.) A C variable can store a character
> directly, such that afterward the answer to "what is in this
> variable" is "such and such a character".  In Perl the answer would
> be "a string". Going the other way around, Perl can store "Hello,
> World" in a scalar, and if you then ask the question, "What's in
> $hello ?" the answer is "The string 'Hello, World'", whereas, in C
> the answer would really be "A pointer to a character".

I know, and I apologize for the roundabout. It wasn't that I didn't
know what he meant, but rather that I was demonstrating a different
mindset. I won't say again something about my expectations, because I
think that poor horse has been beaten enough.

My point is merely about the principle of least surprise, and
apparently I'm in the

Re: definitions of truth

[Paul Hodges]

--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Hodges) writes:
> > Do note that I realize I can check it. It's just that for no reason
> > I can quite define, my C background wants a null byte to be FALSE
> > without any special chicanery on my part when checking. I can live
> > with the fact it isn't going to be, it just seems odd to me.
> 
> Has this problem ever bitten you in Perl coding so far?

Only the once. Once I realized that a null byte was boolean true (and
passed that info around the office, to many confused looks and remarks
about it) then I knew thereafter, and coded accordingly. But yes, I
wrote a program that was parsing data, and if the null had been false
as expected, I'd've been happier. As it was I just had to rethink the
logic a bit, but it was still disconcerting.

> I don't think I've ever seen a bug in code that turned out to be
> because of "0.0" being true, either; I'm sure someone can find an
> example, but it's extremely rare.

No argument -- but I think I've done that as well. :)



__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: definitions of truth

[Paul Hodges]

--- Spider Boardman <[EMAIL PROTECTED]> wrote:
> At some point in history, Paul Hodges wrote (in part):
> ph> So a null byte is still Boolean true.  Ugh, yarf, ack, etc.
> 
> No.  And it never has been (at least in my world view). 

A valid point, though I reply:

   my $x = "\0";
   print "true" if $x;


> However, asking that question explains some things. 
> See below for more.
> 
> ph> But as long as I know -- easy enough to check explicitly.

Do note that I realize I can check it. It's just that for no reason I
can quite define, my C background wants a null byte to be FALSE without
any special chicanery on my part when checking. I can live with the
fact it isn't going to be, it just seems odd to me.
 
> ph> But just tell me thisam I the only guy who thinks this
> ph> *feels* wierd? Understanding the reason doesn't make it any
> ph> more ~comfortable~.
> 
> I believe, from the way you asked your question, that you don't have
> the right mental map to make it comfortable.  As I see it, at least,
> with respect to what you're asking about testing, Perl has strings
> and integers, but not 'characters'.

Perl has scalars, and they can be any of the above.

> (And see another p6l thread about graphemes and language-dependence
> and bytes, etc., for why that's a Good Thing(TM).)

Read it till I got a headache. :)

> For example, take this test in C:
>   if ('\0') ...
> It corresponds to this in Perl:
>   if ord "\0" {...}

Not exactly. In C, the only thing the if() is testing is whether or not
the value is a zero. Anything else is true. The Perl ord is checking
for the numeric value of the first byte of the given string, and then
the if() is testing to see whether the result that got passed back was
either 0 or '0' or '' or undef, with anything else being true. I just
thought it felt natural (at least to me) for "\0" to have been in that
list, though I can live with it either way.

> Consider this test in Perl:
>   if "\0" {...}
> Its equivalent in C is this:
>   if ("") ...

No, because the Perl is passing back the actual zero value null byte,
whereas the C is passing back the address pointer of the location in
memory where the enpty string literal was stored. If it were the above
situation, I'd say "Ok!" and shut up -- which I may do anyway. :)

But it isn't. The perl is passing a zero -- just a fairly obscure one.

It's still received as a scalar, which is not a number, and so is
treated as a string. It's length is one instead on zero, so it isn't
perl's '', and it isn't character ASCII 48, so it isn't '0', and it
isn't a number, so it isn't 0, and it is defined, so it isn't undef,
and so since all these things have been counted out, it isn't any of
the known FALSE values, so it must be true.

But to me, the fact that Perl will let you use 0 or '0' is great. The
fact that '' is a valid string that is still false is great. The fact
that all these are defined and still false is great.

I just thought that the special value of an ASCII 0 fit well into that
~arbitrary~ set, just as the special value of an ASCII 48 does. It's
just a mindset, as several folk have said, but hey, I'd be ok if 0 was
true because it wasn't the explicit boolean value of FALSEthough
I'm REALLY glad Perl doesn't do that. :) 

> You need ord() for character/grapheme/byte/whatever testing that's
> equivalent to what C does.  Since C doesn't really have strings, and
> Perl does, this is just one of those differences between the
> languages where (essentially, and perhaps abusing some linguistics
> theory and terminology) you've run into a 'false cognate'.

lol -- C doesn't have strings, but Perl does?
Ok, that's a bad case of perspectivitis.
A string is just not as neatly packaged in C, but in either I can take
the string "coordinates" and extract "ordinate" from it with a function
call. If I'm using offset and length for both, then the sentinel null
byte that C usually uses to denote a string isn't even relevant, though
once again, I much prefer Perl's way of doing things.

Yes, Perl's strings are cleaner and more prettily wrapped, because they
are an interpretive subset of scalars and the way they're defined. Perl
was written in C, and uses the same internal bits at some point.

But yes, if by 'false cognate' you mean I've taken a point of view that
doesn't mesh with the commonly accepted norm, then I'm apparently
guilty, and will accept the answer that a null byte in a default scalar
context

Re: definitions of truth

[Paul Hodges]

--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Paul Hodges writes:
> > So, in P6:
> > 
> >   if 0 { print "0\n"; } # I assume this won't print.
> >   if '0'   { print "'0'\n";   } # I assume this won't print.
> >   if ''{ print "''\n";} # I assume this won't print.
> >   if undef { print "undef\n"; } # I assume this won't print.
> > 
> > But my question is, will this:
> > 
> >   if "\0" { print null\n"; } # Is this going to print, or not?
> 
> As far as things are currently defined, yes, it will print.  And your
> syntax is perfect... well, maybe not:
> 
> if undef { print "undef\n"; }
> 
> Might be interpreted as:
> 
> if undef( { print "undef\n"; } ) # syntax error, expecting {
> 
> But close enough anyway.

Maybe I should have been more specific:

  if undef() { whatever(); }

But it's a moot point, since only a moron would test what he knowks the
answer to -- unless it's one of those wierd cases, and then he could
just use 0 instead..
 
So, putting it back into the context of real things.

> If you must check for a null byte, it's as simple as:
> 
> unless $chr { print "0, '', or '0' }
> unless ord $chr { print "null byte" }

So a null byte is still Boolean true.
Ugh, yarf, ack, etc.

But as long as I know -- easy enough to check explicitly.

But just tell me thisam I the only guy who thinks this *feels*
wierd? Understanding the reason doesn't make it any more ~comfortable~.

Paul



__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 

Re: definitions of truth

[Paul Hodges]

I seemed to have opened a can of worms, lol
But did anybody see the one that had something to do with my question
crawling around? (I've obviously missed a couple of messages. They're
probably hanging out down at the router in the cyberspace equivelent of
teenagers ogling girls on the street corner smoking cigs.)

So, in P6:

  if 0 { print "0\n"; } # I assume this won't print.
  if '0'   { print "'0'\n";   } # I assume this won't print.
  if ''{ print "''\n";} # I assume this won't print.
  if undef { print "undef\n"; } # I assume this won't print.

But my question is, will this:

  if "\0" { print null\n"; } # Is this going to print, or not?

And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well? 
=o)

Paul

--- "Hodges, Paul" <[EMAIL PROTECTED]> wrote:
> 
> Every now and then I have this discussion with people at work that
> involve Perl's ideas of boolean truth. I usually break it down like
> this:
> 
> In Perl5, the following values are FALSE: undef, '0', 0, and ''.
>  
> Anything not in that list is considered TRUE in a boolean context.
> That means that Perl5 has some notions of truth that confuse some
> folk. I mean, I can understand "00" being true, even if it seems a
> little odd to me personally, but "\0"??? How is a single null byte
> *true*?
> 
> Okay, so it's binary data. So is "0" and 0, if you look at it that
> way. I realize the internal representations are different, but the
> programmer shouldn't have to care about that. I just figure that if
> my bit of $data contains one byte, and I'm checking that $data for
> boolean truth, I'd expect a null to be false, as would ba-zillions of
> C programmers (from which backgroud I came). I know we aren't trying
> so hard to imitate C behavior anymore, but still, doesn't this
> violate the principle of least surprise?
> 
> So my question is this, with apology for the ramble
> aside from P6's other changes, is a single null byte of binary data
> still going to register as TRUE, or will it now be what seems to me
> the more sensible FALSE?
> 
> Paul




__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: enums and bitenums

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 13, 2003 at 07:16:21AM -0800, Paul Hodges wrote:
> :   $Spot = $visitor.nephew ?? $nicedog :: $meandog;
> : 
> : Which brings up a small side note: that's a successfully applied
> : boolean context for $visitor.nephew, right?
> 
> Yes, but $visitor.nephew is no longer .does(nephew) in my current
> view. You have to say
> 
> $Spot = $visitor ~~ nephew ?? $nicedog :: $meandog;
> 
> if nephew is to do any kind of implicit subtype matching.  You can
> also be explicit with .does(), of course.

I knew that, lol -- but again, that's why I lurk here. I'm trying keep
my habits chasing the curve of whatever's being worked out.

> : So what exactly does it mean to have a "typed reference"? $meandog
> : still a Dog, just using an AttackDog role, right? So it's type is
> : Dog&AttackDog? Inheritance thinking starts crowding in here and
> : blurring my understanding of what's going on.
> 
> There are going to be some limits on what you can do.  We don't have
> enough parallel universes to allow all uses of all junction types--in
> the absence of quantum computing the combinatorics are not in our
> favor...

Amen, brutha. Accordingly, do we have an idea what it actually means to
add a type to something? I mean, I get that we could say

  print "yup" if $Spot ~~ AttackDog;

but is there still

  print ref $Spot;

and if so what does it print???

> : Obviously I'm not awake yet, but maybe these rambles will be useful
> : to somebody?
> 
> As a example of the problem with defaults, if nothing else.  :-)

lol -- hey, if I can be a bad example, at least my life has *some*
purpose. :)

> : My workplace considers refactoring to be reinventing the wheel.
> : Just add another motor and axle over here!! sheesh, lol
> 
> With multis you can be refactoring while you're also adding motors
> and axles.   :-)

oooOoohh.. Hey! I *LOVE* that! >:op



__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: enums and bitenums

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 12, 2003 at 03:10:30PM -0800, Paul Hodges wrote:
> : Ok, wait a sec. Does that mean different references to the same
> : critter can have differing sets of aspects?
> : 
> : my Dog $Spot;
> : my $doggie = Dog.new();
> : my $meandog  = \$doggie.as(AttackDog);
> : my $nicedog  = \$doggie.as(LapDog);

Forgive me, I'm trying to get accustomed to the new syntax, so let me
rewrite

> : if $me.away {
> : if $visitor.nephew {
> :$Spot = $nicedog; 
> : } else {
> :$Spot = $meandog; 
> : }
> : }

as

  $Spot = $visitor.nephew ?? $nicedog :: $meandog;

Which brings up a small side note: that's a successfully applied
boolean context for $visitor.nephew, right?

> : Now, if I'm away and someone show up, I presume that if it's my
> : nephew then $Spot.seeVisitor() will invoke the LapDog role's .wag()
> : method, but otherwise I expect it to invoke the AttackDog role's
> : .Bark() method. I realize there are other ways to get here
> : but would this *work*???
> 
> We might be able to make it work, though as you say, there are other
> ways to get there, and the chances are that at least one of them will
> be a better way.

lol -- yeah. This is the kind of code I find six months after writing
it and wonder what sort of delerium I was suffering that day. 

So what exactly does it mean to have a "typed reference"? $meandog
still a Dog, just using an AttackDog role, right? So it's type is
Dog&AttackDog? Inheritance thinking starts crowding in here and
blurring my understanding of what's going on.

> Certainly when the Dog object's class is composed, it
> will have to do something about the conflicting .seeVisitor methods
> in the two roles. 

Ah! The class has to reconcile the roles used to build it.
That would cause the same conflict between AttackDog.Bark() and
LapDog.Bark(), if each had one, but that certainly falls back to a
matter of design, and that there are better ways to build it.

I wish I had generated a better example, but for the sake of
consistency, I'll work with what we've already got, so how about
predefining defaults to resolve known conflicts?

   class Dog does LapDog {...};
   Dog.bark is default(LapDog); # I lowercased .bark() here
   class Dog does AttackDog;

   my Dog $Spot = Dog.new();
   $Spot.bark(); # yip, yip
   $Spot.AttackDog.bark();   # sick 'em!

I just noticed I had uppercased my method(s), and it was annoying me.
Anyway, that syntax looks really freaky to me. I can look at it and
know what it was *meant* to do, but how would it be implemented?
  
  Dog.bark but= LapDog;

didn't look any better, though. :(
Obviously I'm not awake yet, but maybe these rambles will be useful to
somebody?

> It might well be better to encode that choice as
> part of the dog's state rather than in the references to it. 

I'd say that was almost guaranteed to be the better way to go in
practice. I've just seen too many cases where I was handed poorly
designed legacy code and expected to hack it into some new
functionality, "oh and we need that by three today?" 

My workplace considers refactoring to be reinventing the wheel. Just
add another motor and axle over here!! sheesh, lol

> On the other hand, it might just fall out of our implementation
> that it does the right thing with typed references, if the method
> dispatch to the conflicting methods in the Dog class can have access
> to the reference types to break ties.

And since the type of the ref could be Dog&LapDog&AttackDog&Pet, that
should work. :)

> : And btw, just a refresher on this "assigning a ref" thing -- would
> : the syntax have to change at *all*?
> 
> Dunno.  I don't see anything obviously wrong with it, but then I
> never could see very well...

Yeah, right. :)

> Larry

Paul

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: enums and bitenums

[Paul Hodges]

Larry said:
> The interesting question to me is what
> 
> $ref = \$foo.as(Color);
> 
> returns.  It looks like a typed reference to me, but it's still
> a reference to the object in $foo, or can behave as one somehow.
> I don't think it should generate a reference to the bare role,
> because roles aren't intended to be first class objects (though
> you can force them to be, I think).  Roles are supposed to
> encapsulate abstractions without implying objecthood.  I think
> roles are a little bit like quarks--they're fine in theory, but
> it's scary to have loose ones floating around.

Ok, wait a sec. Does that mean different references to the same critter
can have differing sets of aspects?

my Dog $Spot;
my $doggie = Dog.new();
my $meandog  = \$doggie.as(AttackDog);
my $nicedog  = \$doggie.as(LapDog);
if $me.away {
if $visitor.nephew {
   $Spot = $nicedog; 
} else {
   $Spot = $meandog; 
}
}

Now, if I'm away and someone show up, I presume that if it's my nephew
then $Spot.seeVisitor() will invoke the LapDog role's .wag() method,
but otherwise I expect it to invoke the AttackDog role's .Bark()
method. I realize there are other ways to get here but would this
*work*???

And btw, just a refresher on this "assigning a ref" thing -- would the
syntax have to change at *all*?


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: roles (Was: enums and bitenums)

[Paul Hodges]

--- Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Incidently, I think I've caught on to _one_ of the concepts in the
> upcoming object-orientation proposal: linguistically, there's a triad
> of "basic verbs" - namely "be", "do", and "have".  If I'm following
> things properly, one could think of an object's properties as things
> that it has, its methods as things that it does, and its roles as
> things that it is. 

Beautiful. This has a lot of potential, although some of it is
potential to twist young minds. It makes me want to add commas
where commas should not be. 

  my Dog $Spot is Pet, will { Sit() }, has @.fleas;

See what I mean? :op
But seriously, how much of that actually is valid?I doubt @.fleas will
fly (no pun intended, honest).



__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: Properties -- distributive, predeclared, post-applied....??

[Paul Hodges]

--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hodges, Paul writes:
> > How about
> > 
> >   use Baz; # assume object type
> >   my property foo;
> >   my @bar of Baz is false but foo; # maybe not what you meant?
> 
> Definitely not what you meant.  Fortunately, the compiler will teach
> you a thing or two about it:  C is not a trait.  

Duh. I knew I'd do something simple/stupid like that. :)
But you get the idea.

> But indeed foo would apply to @bar itself, rather then to any element
> that goes into @bar later.
> 
> > If you apply a trait like false to an array, I expect it to apply
> to the
> > "array instance object" itself and not the content, so that 
> >   push @bar, Baz.new();
> >   if @bar{ print "stuff"; } else { print "empty"; } 
> >   if @bar[0] { print " oops"; } else { print " ok";   } 
> > would print "empty oops" instead of "stuff ok". 
> >
> > I'd *like* to be able to predeclare a trait or property to be
> distributed
> > across any values placed in this array, but only this array.
> > For example, it would be nice if I could have the default
> > aspects of false and foo be applied to any Baz that gets stuck
> > into @bar, but obviously this isn't the syntax to do it. I could
> > make Baz's new() do it, but I don't want *ALL* Baz objects to be
> > false and foo...just the ones in @bar. So, what I need is
> > something more like
> > 
> >   my @bar of Baz;
> >   @bar.STORE.wrap { my $r = call; return $r >>but=<< (false,foo); }
> 
> Something likely more like:
> 
> my role property_wrap[Property [EMAIL PROTECTED] {
> method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> }
> @bar but= property_wrap[false, foo];

...square brackets?
...roles can have methods? duh, they'd have took
...but, *square* brackets???

And C< but [EMAIL PROTECTED] > looks like "but" is distributive.
I think that's good, but not what I inferred from your last note on the
topic.

> With emphasis on "something".  (Extrapolating wildly the little bit I
> know about roles and making up some semantics, such as C [EMAIL PROTECTED]>).

lol -- oh, ok. :)
But it's *good* BS.

> As for just declaring it, um... why would you want to do that?
> I could see making the array default to some value with a trait,
> which is trivially:
> 
> my @bar is default(undef but foo);
> 
> But automatically marking every value that ever goes into the
> array... I don't see the utility.

Nothing that couldn't be done in a dozen other ways, but this is one
way that I like. It's perhaps a slightly contrived situation, but one I
hope might shed some light on the semantics so that I can learn to use
them when they're a better solution that the kludges I so often end up
with.

In other words, there's always the possibility of doing it another way.
Any object-oriented code functionality could be replicated by purely
functional code, but sometimes you'd end up having to design entire
paradigms to replace some of the functionalities. It's just a mindset
issue, though I will readily confess that my mind is usually set at
wierd angles.

Usually I end up keeping track of some feature by putting all things
with this feature into THIS array and all things like that into THAT
array or some such parallel silliness. It works, and is faster than
practically any object code on our poor old nag of a workhorse server,
but then if I have to know which stack something came from when I send
it to a sub I have to include another argument. There are LOTS of
alternate ways to mark things, but I like this one.

> > But I'm not sure C<$r >>but=<< (false,foo)> works, and I really
> > wanted to figure out a way to do it all in the declaration. Maybe
> > it could be
> > 
> >   my @bar of Baz will do STORE.wrap { call >>but=<< (false,foo); }
> 
> Yeah, that's definitely not right.  C works as follows:
> 
> :w  will  
> 
> It's really just a shorthand for C, so you don't have to put
> parens around the block.

But subs in A6 have a "will do", though I presume the do is optional?

Hmmstill aware that this isn't a sub declaration,

  my @bar of Baz will init { 
 .STORE.wrap { call >>but=<< (false,foo); }
  }

I still like the idea that call could set itself up as an lvalue.
~smirk~

So is it possible that this is a valid way to declare a container with
modified methods all at once?

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: >>OP<< [was: Re: Properties] [OT]

[Paul Hodges]

--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Hodges) writes:
> > I am not seeing unicode.
> 
> Don't worry because, and I honestly don't mean this disparagingly -
> by the time Perl 6 is ready for prime-time, you will. Larry got this
one
> right.

lol -- I think you're right.
And don't worry -- I don't take offense easily.
When you're as bone-headed as me, you can't afford to. :)




__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: >>OP<< [was: Re: Properties] [OT]

[Paul Hodges]

> And as far as I know, << and >> are exactly equivalent to æ?? and æ??
> in all cases.

lol I get the idea, but I foresee these unicode bits as becoming an
occasional sharp spot in my metaphorical seat of consciousness. :)

I am not seeing unicode.


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: >>OP<< [was: Re: Properties]

[Paul Hodges]

--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> > Didn't know "is" would do that. Good to know!
> > And in my meager defense, I did reference MikeL's operator
> > synopsis as of 3/25/03, which said ^[op] might be a synonym
> > for <<>> or >><< (Sorry, no fancy chars here. :)
> 
> Hey, that was *March*!  ;-)  The fossil records from that time are 
> fragmentary, at best.

lol... and I've been a little out of the loop lately, too.

> I don't think I ever saw any further reference to the ^[op] syntax 
> staying alive; I assume that means it's dead.  Last I heard, which
> was admittedly around the same time frame, we'd have the
> non-Unicode-using >>op<<, and a Unicode synonym »op«, and that's it.

I think I saw a few of those in passing. Been a while. :)

> There were also vaguely threatening proposals to have <> and
> >>op<< do slightly different things.  I assume that is also dead,
> and that <> is (typically) a syntax error.

Which is probably a good idea. We have any/all/one/none, and not
*everything* needs a punctuation-type version. I'd actually rather
*not* have alternate versions of those, unless they do something
different, like they way "or" has a lower precedence than "||".
Likewise, if we're going to use <<>> as P6's version of P5's qw//, then
never mind the complexity of making the parser able to figure out that
a given case of <<+>> means I've deleted all other items from the list,
rather than wanting a distributive addition Yes, I could figure it
out, but there are currently enough contextually dependent items in the
language that the importance of that one doesn't strike me as 'core'
necessary, if you know what I mean. :o)

> If anyone in the know knows otherwise, plz verify for Piers' summary 
> and the future fossil record.
> MikeL

Could we get a synopsis posted somewhere?
Maybe something that inticates the current state of this particular onion?

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

With apologies, I'm already seeing blunders. *sigh*

>   my Baz @ray = ( Baz.new() );

No reason to type that. Should be

  my @ray = ( Baz.new() );



__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

> : And "exportation"???
> 
> Exportation is just aliasing some name inside a scope to somewhere
> outside the scope.  Importatation is the same operation from the
> viewpoint of the importing scope.

I just wasn't thinking clearly when you said it the first time.

> Perl 5 didn't allow exportation of lexicals because typeglobs only
> dealt with package variables, not lexical variables.  In Perl 6
> we'll be able to alias both lexicals and package variables.  That
> implies that a lexically scoped name can be exported, whether it
> refers to a variable or something else like a property.

So a role defined in one module can be scoped lexically so as not to
trample another module's namespace, and the use()'er of that module can
elect whether ot not to export that role into his own space for
implicit use on other objects. Accordingly, if Foo implements a zippy
property, and Bar does as well, and both are polite enough about it to
make then the equivelent of EXPORT_OK, then I can say

  use Foo 'zippy';
  use Bar;
  use Baz;

  my Baz @ray = ( Baz.new() );
  $ray[0] but= zippy;

But just for the sake of clear understanding, suppose I pushed onto
@ray a whole passle of Foos and Bars and Bazzes. All the Foos and
Bazzes could use Foo's zippy. If I say

  push @ray, Bar.new();
  $ray[-1].zippy = "woohoo!";

then Bar's zippy would be used by default, right?
Now the hard question.

  my $tst = Baz.new();

How do I set a zippy property on $tst explicitly using Bar's zippy?
Is that possible? Baz has no zippy, so I'd have to use "but", right?
How about

  $tst but= Bar.zippy;  # is zippy a class property?  
  $tst but= Bar::zippy; # is zippy a class method? do I need a & ??

Or is this even possible?  

> : . . . .
> : Don't you just love the way the Greek "polymorphism" just
> : comfortably sidles up to the literal Latin "ad hoc"? :)
> : . . . .
> 
> Well, I didn't make up that particular term.  It's right out of the
> OO faq.

Oh, I know. I didn't mean to imply there was anything wrong with it.
It just struck me as funny. I have a classics degree, and I have to
take it out and walk it every now and the. :)
 
> : What I mean is (I guess) that there should only be one $o.bar, and
> : it sounds like you're saying that's not the case. Please fix my
> : bleeding brain on this one?
> 
> It means if there are two conflicting definitions of the same name,
> it's considered ambiguous where both versions of name are visible. 
> Otherwise, the name means the property that is in scope, and you
> can't see the "other" property that happens to have the same name
> elsewhere.  In other words, any time you say property "bar", it's
> really a shorthand for a longer name that may include a package name
> or lexical scope.  The aliasing of the short name to the actual name
> has to be unambiguous or it's illegal.
> 
> Larry

Ok. "it's illegal" was what I was looking for. :)


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

> : but it confuses me. Does that mean you're leaning more toward
> : allowing undeclared properties, or just that you're still trying
> : to give both sides of the argument thorough consideration?
> 
> I'm not doing either of those things...  :-)

Yayy! :)

> : Just for my vote, I want to be able to declare new properties, but
> : would rather not be able to accidentally set $o.ture.
> 
> That's how it works.

Ok. So are we sticking with the

  our property *foo;

syntax?

And does that mean property is a type? ~smirk~

> :   if $me.flying {
> :  $me.drunk = "scotch";  # inebriation source
> :  $me.dunk  = true;  # I do when I can
> :  $scotch.dunk  = "fig newton";  # the only acceptable value!
> :  $newton.dunk  = true;  # only way I eat 'em
> :  $scotch.drunk = true;  # oops, it's all gone :(
> :   }
> : . . . .
> 
> None of those are legal if the object doesn't have the property yet.
> Only C has the power to add roles at run time.

Which works as well for objects of class Foo as for undef. Ok.
But it only works if the property/role being added is one the compiler
already knows, in which case it just "promotes" the object to a new
pseudo-class with the new property. Yes?

> . . . .
> : That's beautiful, and very sensible. Where can I read up on roles a
> : little more?
> 
> Well, it's not nearly as general as we're making it, but the
> inspiration for it comes in part from the "Traits" paper:
> 
> http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf

This box isn't well configured, so I forwarded this to work. I'll see
it Monday.
 
> Basically, I'm attempting to take their concept and unify it with
> properties, interfaces, generics, aspects, and mixins.  Among other
> things...

You have a talent for designing Swiss Army Knives. :)
 
> : But I thought properties *were* attributes, basically
> 
> We're using "attributes" to mean instance variables defined by the
> class.  Properties used to be considered something else, but now this
> role-playing I'm talking about makes them more like real attributes
> that happen to be added at run time.  Except it doesn't modify any
> named class to do so, but only the anonymous class associated with
> the object in question.  (And if there isn't an anonymous class yet,
> it generates one.)

Wrapper-classes?
 
> : Hrmm. So properties are "object" attributes unrelated to class?
> 
> Unrelated to the original named class.

On that note, just for curiosity -- does undef have a class?

> . . . .
> :   our property *zippy;
> : 
> : would probably be a bit foolish, since there can be only one such,
> : and trying to redeclare it by loading two modules with that in them
> : would crash, but wouldn't storing the context of a property by like
> : recursively giving the properties some properties of their own? Is
> : that a can of worms we really want to open?
> 
> I don't see what the problem is.  Once anyone has declared *zippy,
> everyone has a global zippy, and it's the same global zippy
> everywhere.  You only get separate zippys if in more than one place
> you say things like:
> 
> our property zippy;
> my property zippy;

I was just saying that the compiler would bail if you said

  module Foo { our property *zippy; }
  module Bar { our property *zippy; }

( Hmm... I think I need to reread the rule on semicolons. :)
 
> Either of those declarations may be exported, however, in which case
> the importing modules shares the zippy, just as it would share an
> exported variable.

Ok, exported as in the Exporter module.

> . . . .
> : All I've seen on interfaces is a few lines in passing. Anyone got a
> : reference where I can RTFM and thin the spam to the list? :)
> 
> Don't have a doc, but see Java for an example.  Basically it's a
> clunky way of sneaking a little bit of multiple inheritance into a
> language that only supports single inheritance.
> 
> Larry


Ok, if Java interfaces will do as an example/template, I understand,
and I *LIKE* it. In fact, I like it much better than Java (but then, I
always have. ;o)

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

--- Paul Hodges <[EMAIL PROTECTED]> wrote:
>   print "foo" is $x;

With deeply sincere apologies, that should have been

  print "foo" if $x;


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
> : hmm... lexical propertiesI've read the rest of the message,
> : and I see how this could be a problem. Just to be clear on it,
> : what exactly would it mean for a property or trait to be lexical?
> : If a value or container with that aspect gets passed out of that
> : scope, what happens?
> 
> It would mean that that aspect becomes unnameable, even if a
> different lexical name looks like it.  (But note that exportation
> can cause two distinct lexical scopes to share the same name.)

To quote a better man than me, "ow, me noggin."
Do you mean unreference-able by name?
And "exportation"???

> : Wouldn't an object efectively provide a virtual "scope" of its own?
> 
> Depends on what you mean by effective.  There's a sense in which the
> object knows nothing about the properties that are going to be bound
> to it someday, or whether there might be two conflicting properties
> of the same name.  There is the danger of ad hoc polymorphism.

Don't you just love the way the Greek "polymorphism" just comfortably
sidles up to the literal Latin "ad hoc"? :)  Almost makes me feel like
I was back in college, staying up way too late talking about the nature
of reality, except that this is both more "concrete", if you will, and
usually more confusing, lol.

What I mean is (I guess) that there should only be one $o.bar, and it
sounds like you're saying that's not the case. Please fix my bleeding
brain on this one?

> : Maybe the syntax looks something like this:
> : 
> :   class Foo has Scalar bar is rw = undef; # suplies a default
> 
> Well, it's "does" to incorporate a role, but again, you generally
> wouldn't apply a property to a class at compile time.

You say "again". :)
As a general apology to anyone besides me who might be inconvenienced
by it, my mail is on a bounce or three before I get it, and may go out
as strangely, so I suspect you recieved my second message before my
first. You certainly responded to that one first.
 
> : That would allow you to add the property to the class with a
> : default value at compile time, wouldn't it? Then you could modify
> : objects:
> : 
> :   my $o = Foo.new;
> :   $o.foo but= "stuff";
> 
> That'd be adding an anonymous property to the foo attributes.  You
> want:
> 
>   $o but= foo("stuff");

Ah! Okie.

> : It would also make it inherently class scoped, and would fail to
> : compile if someone in another module had already declared a
> : property bar. Right?
> 
> You don't want properties inherently class scoped.  Except when you
> do.

Right. I'm with you.

> : > Or maybe we can tag property names with the scope in which
> : > they're declared somehow.
> : 
> : o. That's hairy, isn't it?
> : Yes, I think it would be useful...but what's the upshot? The value
> : of $o.foo is dependent on scope? Hmm My first reaction was to
> : frown and shudder, but maybe that's short-sighted. Any lexical
> : variable's value is always dependent on scope.
> : 
> :   our $foo = 1;
> :   { my $foo = 2;
> : print $foo; # 2
> :   } 
> :   print $foo; # 1
> : 
> : I'm just not sure how I like the idea of that applying to
> : properties.
> : 
> :   our $o = Foo.new();
> :   $o.foo but= "global?";
> :   dostuff::with($o); # module scope, different value?
> : 
> : Wouldn't that utterly mangle the principle of least surprise?
> 
> The principle of least surprise is also utterly mangled by accidental
> polymorphism.  We can prevent that by complaining when we detect the
> attempt to declare or import two different properties of the same
> name.
> 
> Larry

Which does make better sense. :)


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2003 at 09:13:32AM -0800, Paul Hodges wrote:
> : --- Smylers <[EMAIL PROTECTED]> wrote:
> : > Larry Wall writes:
> : > 
> : > > : if $x.foo { print "$x has property foo" }
> : > > : $x.bar = 1;   # Or $x = $x but bar
> : > > 
> : > > Or maybe the .bar notation is only for rvalues, and to create a
> : > > property you have to say:
> : > > 
> : > > $x but= bar;
> : > 
> : > I think that would be an unPerlish restriction; people who know
> : > how to read a property would also expect to be able to set it in
> : > the same way.
> : 
> : I'd think that would depend on the current status of strictures.
> : Assuming no strictures at all, I'd rather expect Perl to autovivify
> : properties much the way hash elements are created when you assign a
> : value to a previously nonexistant key, but that's exactly the
> : reason I *NEVER* leave strictures *or* warnings off, even in short
> : little one-shot programs. If it's complex enough to save to a file,
> : it's worth adding a couple of "use" statements to make sure I don't
> : do something carelessly stupid.
> 
> I don't feel any great need to de-stricture this in non-strict
> scopes. I think people who want hash semantics can use hashes.  :-)

lol -- good. :)
I'm all for there being more than one way to do it, and for not playing
Code Police (God knows I'd do my share of time in the BigHouse...), but
I have to agree with you on this one.

> : And if I try to set $o.bar when there's no bar property predefined
> : on class Foo of which $o is a member, does that mean this singular
> : object gets this new property,
> 
> Yes, in fact it gets a new anonymous class that is derived from its
> current class.

Ah -- implicit adoption by the new foster parent. That's kind of neat,
but it confuses me. Does that mean you're leaning more toward allowing
undeclared properties, or just that you're still trying to give both
sides of the argument thorough consideration?

Just for my vote, I want to be able to declare new properties, but
would rather not be able to accidentally set $o.ture.

> : or does Perl have to redesign class Foo on the
> : fly, and suddenly distribute a bar property across all Foo object
> : extant?
> 
> No, the whole point of properties is that they cut across class
> lines.
> It doesn't matter whether you're flying first class or coach, you
> might acquire the property "drunk" at run time.

The adoption mentioned above handles this, but even though properties
cut across class lines, I want to avoid those silly boo-boos.
While

  if $me.flying {
 $me.drunk = "scotch";  # inebriation source
 $me.dunk  = true;  # I do when I can
 $scotch.dunk  = "fig newton";  # the only acceptable value!
 $newton.dunk  = true;  # only way I eat 'em
 $scotch.drunk = true;  # oops, it's all gone :(
  }

might be all well-and-good, I don't want my $newton to be able to be
set $newton.drunk = true by accident because in all that
pseudo-repetitive code I mistyped and the compiler let me get away with
it. Code bits like this are common enough that I want every bit of
assistance I can get. 

I'd rather be able to add the .dunk and .drunk properties to classes in
which they are appropriate, even after the fact of the class
definition, but I definitely don't want that to make it possible to
drink my $newtons, nor get them inebriated.

Am I too far over the edge here?

> : Does it imply a scalar type from your supplied value of 1? What
> : if you later try to "push $o.bar, 2"? Ugh.
> 
> If we allowed undeclared properties, it'd have to assume scalars. 

Okie.

> But if we require declaration of properties as a kind of role,
> then the role declaration could declare whatever data structure
> it wants.  In fact, a role can declare multiple attributes, which
> implies that we could conceivably have complex struct-like
> properties:
> 
> return undef but error(ENOMAKESENSE, "What the heck?", 42);
> 
> Under the hash view of properties, that has to be a scalar reference
> to an object, but under the role view, it can merely be a set of
> components of the undef object without a separate scalar existence.
> 
> Q: Mr. Undef, are you an error object?
> A: No, but I play one on TV.

That's beautiful, and very sensible. Where can I read up on roles a
little more?
 
> : Accordingly, I'd expect Perl to stick out it's tongue, cross it's
> : arms, and refuse to play with me if I tried to set a property of
> : whic

Re: Properties

[Paul Hodges]

--- Smylers <[EMAIL PROTECTED]> wrote:
> Larry Wall writes:
> 
> > : if $x.foo { print "$x has property foo" }
> > : $x.bar = 1;   # Or $x = $x but bar
> > 
> > Or maybe the .bar notation is only for rvalues, and to create a
> > property you have to say:
> > 
> > $x but= bar;
> 
> I think that would be an unPerlish restriction; people who know
> how to read a property would also expect to be able to set it in
> the same way.

I'd think that would depend on the current status of strictures.
Assuming no strictures at all, I'd rather expect Perl to autovivify
properties much the way hash elements are created when you assign a
value to a previously nonexistant key, but that's exactly the reason I
*NEVER* leave strictures *or* warnings off, even in short little
one-shot programs. If it's complex enough to save to a file, it's worth
adding a couple of "use" statements to make sure I don't do something
carelessly stupid.

And if I try to set $o.bar when there's no bar property predefined on
class Foo of which $o is a member, does that mean this singular object
gets this new property, or does Perl have to redesign class Foo on the
fly, and suddenly distribute a bar property across all Foo object
extant? Does it imply a scalar type from your supplied value of 1? What
if you later try to "push $o.bar, 2"? Ugh.

Accordingly, I'd expect Perl to stick out it's tongue, cross it's arms,
and refuse to play with me if I tried to set a property of which it was
not previously aware. Personally, I'm a little scared of how this would
work without strictures on. The DWIMmyness we expect from Perl would
beat the dickens out of any possible optimization, though that's going
to happen a lot with unstrictured code anyway

On the other hand, properties are probably best scoped to a class, and
a class definition is almost always best placed in a class file, which
has strictures on by default. Again, I recommend some syntax
class-scoped and compile-timed to declare properties, such as

  class Foo has Array bar is rw = undef;

> > ... as long as we limit the .bar notation to rvalues or to
> > lvalues on already-created properties.  And in fact, we may
> > be limiting the creation of properties to predeclared names,
> 
> That sounds like a much better solution.

Agreed.

> And thanks for taking the time to answer Luke's questions so fully.
> Smylers

Ditto. :)

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
> : --- Larry Wall <[EMAIL PROTECTED]> wrote:
> : > ... in fact, we may be limiting the creation of properties
> : > to predeclared names, so that even
> : > 
> : > return 0 but ture;
> : > 
> : > can be caught at compile time.
> : 
> : Excellent, so long as we can define new properties explicitly.
> : At the moment, I draw a complete blank on how to do that.
> : 
> : Somebody drop me an example?
> 
> Well, it hasn't been defined yet.  Likely there will be some syntax
> 
> my property foo;
> 
> that is shorthand for something vaguely resembling
> 
> my role foo is property {
>   has $.foo is rw;
> }

That's cool. You might even consider making declarable properties a
little *less* convenient, though Of course, I bet you *have*
considered it, lol.

> However, universal properties like "true" and "tainted" are likely to
> be declared implicitly everywhere:
> 
> property *true;
> property *tainted;
> 
> Less common properties are likely to be imported into a lexical
> scope.

hmm... lexical propertiesI've read the rest of the message, and I
see how this could be a problem. Just to be clear on it, what exactly
would it mean for a property or trait to be lexical? If a value or
container with that aspect gets passed out of that scope, what happens?
 
Wouldn't an object efectively provide a virtual "scope" of its own?

> So you'd likely only declare properties that you use entirely by
> yourself, or that you intend to export.  If you really want to mess
> everyone up, though, you could certainly declare things like:
> 
> property *ture;

And I can certainly see someone doing just that.
False laziness, false impatience, false hubris :)

> Actually, there's something to be said for declaring all property
> names as globals, since they cut across object classes, and you
> wouldn't want to add two different properties of the same name to
> a given object.

Agreed.
Maybe the syntax looks something like this:

  class Foo has Scalar bar is rw = undef; # suplies a default value;

That would allow you to add the property to the class with a default
value at compile time, wouldn't it? Then you could modify objects:

  my $o = Foo.new;
  $o.foo but= "stuff";

It would also make it inherently class scoped, and would fail to
compile if someone in another module had already declared a property
bar. Right?

> Or maybe we can tag property names with the scope in which they're
> declared somehow.

o. That's hairy, isn't it?
Yes, I think it would be useful...but what's the upshot? The value of
$o.foo is dependent on scope? Hmm My first reaction was to frown
and shudder, but maybe that's short-sighted. Any lexical variable's
value is always dependent on scope.

  our $foo = 1;
  { my $foo = 2;
print $foo; # 2
  } 
  print $foo; # 1

I'm just not sure how I like the idea of that applying to properties.

  our $o = Foo.new();
  $o.foo but= "global?";
  dostuff::with($o); # module scope, different value?

Wouldn't that utterly mangle the principle of least surprise?

> Larry


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Properties

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> ... in fact, we may be limiting the creation of properties
> to predeclared names, so that even
> 
> return 0 but ture;
> 
> can be caught at compile time.

Excellent, so long as we can define new properties explicitly.
At the moment, I draw a complete blank on how to do that.

Somebody drop me an example?


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Autovivification (was Re: E6: assume nothing)

[Paul Hodges]

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2003 at 11:18:12AM +0200, Paul Johnson wrote:
> : By the way, I trust this will be addressed (if it hasn't been
> : already):
> : 
> : perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!"
> :  if exists $a{b}'
> : 
> : perlfunc says:
> : 
> : This surprising autovivification in what does not at first--or
> : even second--glance appear to be an lvalue context may be fixed
> : in a future release.
> 
> I sure hope so.  Perl 5 confuses reference contexts with lvalue
> contexts.  With the new vtable implementation of basic types, we
> ought to be able to substitute an "always undefined" array or hash
> vtable that can propagate non-existence outward in rvalue context.
> 
> Larry

This one doesn't *quite* make me as strongly prompted to chuckle and
say "Larry, you're an evil genius" as the comments on macros in another
thread, but it still gives me a warm fuzzy particularly because we
know Good Larry is in charge, and Evil Genius Larry just works in the
sweatshop to satisfy his need to beat the Gods of Cryptocontext at
their own game. 

TMTOWTDI applies likewise to DWIMming! :)

Also, I'm very sorry Larry -- I hit the wrong button backing up to edit
this, and sent you an empty message. :(