Re: Circular dereference?
On May 4, 2005, at 2:38 PM, Thomas Sandlaß wrote: Aaron Sherman wrote: If we agree that the first say should print 7, then we must conclude that either we've changed the value of undef to 7, or we've created a circular reference. In my view of refs 7 is printed, indeed. But I've difficulty to understand what you mean with "the value of undef". Undefinedness to me is the absence of value. In Perl (5 and 6) there is actually a value, 'undef'. That value can be stored in variables, just like any other value. There is no real fundamental difference between '7', 'foo', and 'undef'...they are all values (although each has a slightly different set of meaningful operations). As a community, we have decided that 'undef' means something like "I don't know what this value is" and the perl engine enforces that, but there is nothing implicit about undef that requires it to mean that. I think we agree that references are a level of indirection. We also agree that variables are names that allow us to get at---and here I think our views diverge---a box, cell or container for values. So after resolving a name, we always have one level of indirection from the cell to the value. To me a referencial value is just such a thing without an entry in a namespace or symbol table. Not quite. *values* never have entries in a namespace or symbol table...e.g., there is no symbol table that stores 1,2,3...100, etc. You don't say "$x + number::integer::7" in order to add 7 to $x. A reference is a value, just like an integer or a string. It does not have a symbol table entry. It is, instead, stored in a container. Containers that have names are called "variables", containers that do not have names are (surprisingly enough) "anonymous". So, in Perl 5, "$x = [ 1 ];" creates a reference (a value) to an anonymous array (a nameless container) containing the literal number 1 (a value) and stores it in $x (a named container). So, if you want, you can say that $x is a single level of indirection to get to its value...but, in the example above, its value is [ 1 ], not 1. Therefore, you have another layer of indirection. The name doesn't tell you anything about how many layers of indirection you're going to get. And yes, Juerd and I have fundamentally different opinions of what has got identity. To me only values can be identical. Cells are an implementation vehicle to handle values. It depends on how you define "identity", I suppose. --Dks
Re: split /(..)*/, 1234567890
On May 12, 2005, at 11:59 AM, Autrijus Tang wrote:
On Thu, May 12, 2005 at 04:53:06PM +0200, "TSa (Thomas Sandlaï)"
wrote:
Autrijus Tang wrote:
pugs> split /(..)*/, 1234567890
('', '12', '34', '56', '78', '90')
Is this sane?
Why the empty string match at the start?
I don't know, I didn't invent that! :-)
$ perl -le 'print join ",", split /(..)/, 123'
,12,3
This makes sense when I think about what split is doing, but it is
surprising at first glance. Perhaps this should be included as an
example in the docs?
--Dks
Re: Argument Type Checking
On May 19, 2005, at 10:56 PM, Luke Palmer wrote: In general, you should probably be declaring your parameters with uppercase types, [...] Luke If so, wouldn't it make sense that 'int' is the boxed type (one less keystroke) and 'Int' is the special case? Optimize for the common case, and all that. Of course, it would go against the consensus of other languages. --Dks
Re: date and time formatting
On May 31, 2005, at 9:51 AM, Rob Kinyon wrote: On 5/31/05, Nathan Gray <[EMAIL PROTECTED]> wrote: As I am interested in human-readable dates and times, and having found no conclusive discussion on time formatting, I make my recommendation for a syntax (to start discussion, and allow for date formatting to be implemented in pugs): What's wrong with porting DateTime? Rob It's back to the old question of "what's in core?" Are dates and times something that are used in such a large proportion of programs that they deserve to be shipped in the basic grammar? Or perhaps in the basic set of packages? Perl 5 has an entire swath of modules designed to manipulate dates and times; this suggests that they are (A) commonly used and (B) something that people feel very strongly about the semantics of. --Dks
Re: date and time formatting
On May 31, 2005, at 1:16 PM, Rob Kinyon wrote:
What's wrong with porting DateTime?
It's back to the old question of "what's in core?" Are dates and
times something that are used in such a large proportion of programs
that they deserve to be shipped in the basic grammar? Or perhaps in
the basic set of packages?
Perl 5 has an entire swath of modules designed to manipulate dates
and times; this suggests that they are (A) commonly used and (B)
something that people feel very strongly about the semantics of.
Which still begs the question - why not port DateTime to P6? Why can't
installing a module provide new keywords?
Rob
In reverse order:
- No reason it can't. Nor did I imply otherwise.
- I didn't say we shouldn't port DateTime. My point was simply that,
based on the amount of date-related code on CPAN, this is an issue
that many people care about quite a bit. We would probably be well
served to consider it carefully and decide on what semantics we
really want. Maybe DateTime is exactly what everyone wants and all
we need to do is port it. On the other hand, there is something to
be said for Nathan's approach; isn't it worth discussing?
Personally, I've always found date handling to be difficult. The
various modules go a long way towards simplifying it, but they
require calling functions and methods, which forces one to think in a
low-level algorithmic style. It would be great if there was a more
intuitive time/date handling model built into the language...the kind
of quantum leap in power and intuitiveness that we got from the new
Rules engine (as opposed to the old regex engine).
Perhaps something like the typed operations that were discussed
recently:
my ($launch_date = now() + 6 weeks) but time(9am);
say "We will launch on a $lauch_date.day_of_week, at
$launch_date.time_of_day.";
say "This gives us " . $launch_date but hours . " hours,
including weekends and evenings.";
# outstanding_tickets() returns user-written ticket objects;
created() returns a time object representing
# creation time. The objects stringify to their report.
say "Remaining issues, oldest first:";
say "\t $_" for sort { $a.creation().age <=> $b.creation().age }
outstanding_tickets();
# Prints 'Meetings are...is Sunday, June 19.;
say "Meetings are the third Sunday of each month. The first
June meeting is " .
(month(6).days(0))[2] but format(/,
/);
The above examples are just noodlings and are not well thought out,
but hopefully they point in the right direction.
--Dks
Re: date and time formatting
On May 31, 2005, at 2:22 PM, Rob Kinyon wrote: my ($launch_date = now() + 6 weeks) but time(9am); Sure. $launch_date is of type DateTime. It will numify to the seconds-since-the-epoch, stringify to some date string, and provide all the neat-o-keen methods you want it to have. Works for me. Frankly, I think we're in violent agreement here. Sounds like it. I don't really care if it's built in or comes in a module. I do think that date manipulation is common enough that, if it's in a module, the module should come in the "basic set". I met a guy once who made his living doing Java programming. I asked him what he liked about Java and he said "Nothing. I hate it. I only do it because it pays." He then went on to list the reasons he hated it--high on the list was that Java is not good at date manipulation. Personally, I've done so little Java that I can't really speak to the accuracy of his statements, but the message has stuck with me--date manipulation is important, and needs to be got right. To put it another way--it's one of those hard things that Perl 6 is trying to make easy. --Dks
Re: new mailing list: perl6-general?
On Jun 15, 2005, at 3:33 PM, Patrick R. Michaud wrote: And here they are... this is just a draft -- feel free to flame/edit/ tear it apart liberally. These are also written assuming we don't create a perl6-general list (but it shouldn't be hard to adapt them should one be created). Well, I'd suggest the following. (Anything not mentioned stays as you wrote it.) perl6-language This is the "theory of" list. Discussion of the design of the perl6 language, and its desired (or unwanted) feature list. If you have patches and/or suggestions for improving the Perl 6 design documents (Apocalypses, Synopses, etc.), send them here. perl6-howto This is the "practice of" list. Come here to ask "How do I...", "What does XYZ mean?", or "Why doesn't this work?" Novices are especially welcome. (Note: I envision this list being much like beginners@perl.org, but I never liked that name because it seems like it would drive away those who have a question but do not consider themselves beginners. On the other hand, maybe it's more important to explicitly welcome novices. I could go either way: maybe the above list should be 'perl6-beginners')
Re: ./method
On Jun 17, 2005, at 10:42 PM, John Siracusa wrote: But the truth is that / really does look file-path-y to me, and just plain old ugly. I think at least two other people had similar reactions (Martin Kuehl and Carl Franks). David Storrs, reporting to show solidarity, sir(acusa)! Maybe .:: has even more detractors, I dunno. All I know is that I dislike ./ and I'm trying to come up with an alternative. What say you all? Too many dots in .::? Surely ./ isn't as good as it gets... I'm not fond of .:: because I don't think it's sufficiently visually distinct from .:. I don't have a better suggestion...but that's mostly because I dislike this entire concept of secondary sigils. I already get to have the "Perl is line noise!" conversation _way_ too often...I don't feel that we need to give the trolls more ammunition. For that matter, I'm a Perl zealot and /I/ think they're ugly and obfuscatory. For what it's all worth, I suppose. --Dks
Re: ./method
On Jun 18, 2005, at 9:24 PM, Damian Conway wrote: chromatic wrote: I find it ugly enough that I plan to name my invocants explicitly. ...which should be construed as a *feature* of the current syntax. ;-) Damian In that case, why do we have this feature? Seriously. Are default invocants really such a good idea? At least, do they need to be there in 6.0.0? Do they need to be supported in the core engine, or could they be pushed out to a module? I guess that as long as we're arguing the color, we might as well argue the location of the bikeshed. All that said, I still agree with John... './' does not look like method call syntax to me. But, whatever. I suppose I'll get used to this, along with all the other things that have given me the heebie- jeebies so far. :/ --Dks
Re: Everything is an object.
On Tue, Dec 17, 2002 at 09:54:12AM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Dave Storrs) writes: > > Just so I'm clear, are you saying that you think L2R is a bad idea, > > and should not be supported? Or just that it has not yet been > > demonstrated that this is a good idea? > > I think supporting two distinct syntaces, one being a mirror image of > the other, is a bad idea. I honestly don't understand why not...can you explain it to me? So long as, within any given statement, it is clear which syntax is being used, what's the problem? Perl has always been famous for supporting the kitchen sink and letting you choose which faucet you want to turn on--e.g., we have OO style, imperative style, and a pretty full language built into the regexen. --Dks
Re: Everything is an object.
On Tue, Dec 17, 2002 at 09:49:42AM -0500, Dan Sugalski wrote: > At 5:45 PM -0800 12/16/02, Dave Storrs wrote: > >Just so I'm clear, are you saying that you think L2R is a bad idea, > >and should not be supported? Or just that it has not yet been > >demonstrated that this is a good idea? > > I think it's a good idea, and that it should *not* be supported. Um...I'm sorry, I really don't understand that, could you explain it to me? If it's a good idea, why shouldn't we support it? --Dks
Re: Everything is an object.
On Tue, Dec 17, 2002 at 09:54:52AM -0800, Michael Lazzaro wrote:
> Umm... I think some of these recent messages have had typos between L2R
> and R2L. (?) In that people seem to have been arguing against
> themselves. (??) I'll try using --> and <--.
Just to make sure I'm not one of those people, I'll clarify my terms:
I am calling this L2R:
@b = @a --> sort --> map { $_++ } --> grep { $_ > 0 };
I don't care about the syntax at all, I just made up something that
seemed moderately clear to me. In point of fact, I hope we DON'T use
the above syntax, or anything else where you are required to have an
operator between each element of the pipeline.
I am calling this R2L:
@b = grep { $_ > 0 } map { $_++ } sort @a;
Note that this is just Perl5 code.
> We _must_ (for some value of "must" that is real close to being a 100%
> drop-dead requirement) support --> (L2R), in the form of
>
>@a.grep( {...} )
>.map( {...} )
> .sort;
>
> i.e. however else we do it, array processing functions _MUST_ exist as
> methods of Array. That may not be the preferred spelling, or anything
> close to attractive, but it would be simply pathetic for it not to
> exist.
Well, I generally agree with you, but with an important nit: they
shouldn't be members of Array, they should be members of Collection,
Array's base class. Otherwise, what if I define an UnorderedMultiSet class and I want
to grep over it?
Ok, let me play Devil's Advocate (*) for a moment. Why do we need
this? Why should these names be locked up in the Array class? What
if I want to grep a list, or if I want to define some kind of class
for which it is meaningful to grep an instance...perhaps an
UnorderedMultiSet class. If these functions are locked up in Array, I
will need to either derive my UnorderedMultiSet from Array
(inappropriate), use an Array internally (perhaps inconvenient), or
redefined the methods myself (wasteful).
> have to be in _addition_ to the above, not _instead_ of. We can add
> the Perl5-style:
>
> @out = sort map {...} grep {...} @a;
>
> if we want to, but I don't think it should be given a free ride in
> Perl6. It's not regular (not like anything else in the language),
> sucks up those names as globally reserved (as opposed to merely methods
> of arrays), implies more possible wacky behaviors of curlies, and
> cannot credibly be tortured into being OO upon @a.
Hmmm...I don't suppose that, with implicit promotion to Array, we can
get out of this with the indirect object notation, can we? I'm not
sure what it looks like this week, but perhaps we could make a minor
requirement change (e.g., need a comma on the methods and a trailing :
on the @a) and shoehorn it into something like this:
@out = sort map {...}, grep {...}, @a:;
--Dks
Re: Everything is an object.
On Tue, Dec 17, 2002 at 02:51:04PM -0500, Dan Sugalski wrote:
> At 9:54 AM -0800 12/17/02, Michael Lazzaro wrote:
> >We _must_ (for some value of "must" that is real close to being a
> >100% drop-dead requirement) support --> (L2R), in the form of
> >
> > @a.grep( {...} )
> > .map( {...} )
> > .sort;
>
> Those are simple method calls, so there's no reason we shouldn't
> support them, though they will *only* work if each returns an actual
> array, rather than a list.
Question on this: for me, one of the trickiest things when teaching
Perl5 has always been explaining the difference between an array and a
list, when you need one versus the other, why they aren't precisely
the same, and where the differences are.
What exactly are the advantages of having both in Perl6? Is it
possible that we could put them together and have only one or the
other without losing anything (that we aren't willing to lose)?
>@b = (*@a, *@b, foobar()) grep {} map {} sort {};
>
> That can't work as methods of the list, unless we're wildly
> redefining how lists work, which I don't think we're going to do.
I don't know enough to see why this is a problem. Can you explain it?
> *That's* the sort of way, the L2R way, that I'd argue against.
> Shifting directions in mid-stream is, well, really tough for us old
> codgers.
Mid-stream in terms of the work that's been done on Parrot or in terms
of your programming experience? i.e., are you saying that it would
require major redesign and recoding on the existing engine, or that it
would be hard to get used to having it in the language?
> function calls. To forbid
>
> @b = sort {} map {} grep {} @a;
>
> is the same as forbidding
>
> @b = sort({}, map({}, grep({}, @a)));
>
> which I think would be... unwise. As would chopping sort/map/grep and
> friends from the language entirely. One of the hallmarks of perl is
> its richness, and I think losing that would be ill-advised.
Indeed.
--Dks
Re: "my int( 1..31 ) $var" ?
On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > --- Smylers <[EMAIL PROTECTED]> wrote: > > junction should be sufficient: > > > > print "date" if $var == any(1 .. 31); > > Superpositions in the core? You're kidding, right? > > What's wrong with "if 1 <= $var <= 31"? My understanding was that junctions were most definitely in the core. As to what's wrong with the example you give...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Wed, Jan 08, 2003 at 08:31:51AM -0800, Austin Hastings wrote:
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > @out = @a ~> grep {...} ~> map {...} ~> sort;
> > ...
> > @out <~ sort <~ map {...} <~ grep {...} <~ @a;
For the record, I think this is great.
> Brilliant! Keep pushing this. Finally, I'll be able to get investor
> backing for my USB foot-pedal shift-key device.
http://www.tuxedo.org/~esr/jargon/html/entry/double-bucky.html
--Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
(/dks attempts to pour water.)
Damian Conway <[EMAIL PROTECTED]> wrote:
> > And even if we do have both functional and methodical versions, this:
> >
> > @out <~ sort <~ map {...} <~ grep {...} <~ @a;
> >
> > is still clearer in its intent than:
> >
> > @out = sort map {...} grep {...} @a;
Mr. Nobody wrote:
> I find the normal function call and assignment far more readable than using
> some weird ugly operator.
Ok, but "weird" and "ugly" are personal opinions--that is, they are a
question of aesthetics, not language design, and aesthetics varies
from person to person. A lot of other people (myself included), seem
to find the ~> operator to be kinda cool. Is this a case where we
could just agree that TIMTOWTDI?
> > And the squiggly version is also reversible, for those who are more
> > comfortable with reading left-to-right.
> >
> > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
>
> That's going to be just plain confusing. Arguments to functions are supposed
> to be on the right.
Don't think of it as a function call then. Think of it as a pipeline,
where data flows in the direction of the arrows.
> And what's up with using them for assignment? That's
> making them even more overcomplicated and ugly. Do you care about readability
> at all? It seems to me that ~> and <~ have no use except making perl 6 uglier
> and more complicated than it already is. They're completely unnecessary.
Now don't hold back on account of social niceties like not wanting to
cloud the issue with emotion or low-level ad hominem attacks. Tell us
what you _really_ think. :>
--Dks
Re: Variable Types Vs Value Types
On Wed, Jan 08, 2003 at 05:59:14PM +0800, Damian Conway wrote: > > my Array @array := SpecialArray.new; > > > > Should the value in @array act like an Array or a SpecialArray? Most > > people would say SpecialArray, because a SpecialArray ISA Array. > > Weell...*I'd* say that @array should act like an Array (that is, you should > only be able to call the methods specified by the Array class), except that > any method calls should be polymorphically resolved to invoke the > equivalent SpecialArray methods. > > But maybe that's just saying the same thing. Is there a linguist in the house? Will an English major do? If SpecialArray extends the interface of Array, then these two statements are not the same; the first statement gives you all of SpecialArray's functionality while the second statement gives you only a subset. --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Sun, Jan 12, 2003 at 11:50:14AM +, Richard J Cox wrote: > > U+21DC "Leftwards Squiggle Arrow" and U+21DE "Rightwards Squiggle Arrow" would > seem to fit the bill rather well maybe the ascii <~ and ~> are merely > aliases of the true symbols? If we go this route, I would suggest that we use U+219C (Leftwards Wave Arrow) and U+219D (Rightwards Wave Arrow). Not only are they closer to the potential ASCII aliases, but (IMHO) they are more attractive. (Although, of course, both parts of the above may not apply, since the arrows are allowed to be represented differently in different fonts.) To see what the Unicode Consortium thinks they look like: http://www.unicode.org/charts/PDF/U2190.pdf --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote: > On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote: > > The headers I received make no mention of character set - does your mailer > > mark the message in any way? If not, then STMP will assume it's good old > > 7 bit ASCII > > Thus we are back to using uuencode :-) Which, actually, might not be a bad thing. It will give Unicode a boost by forcing people to become more aware of this issue. To a large extent, the software industry as a whole is driven by what makes the lives of programmers easier--as a simple example, programming editors are written by and for programmers, who use them to write other programs. If editors become Unicode by default (both input and output) then the other programs will start to become Unicode by default. Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: > At 7:13 AM -0800 1/17/03, David Storrs wrote: > >Do we at least all agree that it would be a good thing if Unicode were > >the default character set for everything, everywhere? That is, > >editors, xterms, keyboards, etc? > > No. No, we don't. Could you explain why not? I'd like to be able to easily exchange mail and scripts with people in other countries. --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 17, 2003 at 12:19:01PM -0500, Dan Sugalski wrote: > At 8:08 AM -0800 1/17/03, David Storrs wrote: > >On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: > >> At 7:13 AM -0800 1/17/03, David Storrs wrote: > >> > > >> >Do we at least all agree that it would be a good thing if Unicode were > >> >the default character set for everything, everywhere? That is, > >> >editors, xterms, keyboards, etc? > >> > >> No. No, we don't. > > > >Could you explain why not? > > Because it makes life significantly harder for everyone on the planet > who already has a perfectly fine local system. > > What you're asking for is a massive software, hardware, and data > conversion project, with all the work being done by all the world > that doesn't use straight ASCII. Given that covers a good 80% of the > world, well... seems just the tiniest bit arrogant to me. Actually, that's *not* what I'm asking for. It would appear that either my question was not clearly written, or that people didn't read it very careful before jumping to conclusions. I didn't say "Let's start doing the conversion." I didn't say "Let's force everyone else to do the conversion." What I said was "Do we agree that this would be a good thing?" To me it seems like a good thing. All I wanted to know was if there were issues I wasn't thinking of. > Very few people need to deal with inter-language data exchange. The > vast majority of data is kept in the native language of the operator > of the system, with most of the remainder in 7-bit ASCII, which fits > in everyone's local character set anyway. > > Unicode is like XML. It's the least-bad solution we have for general > data interchange. We just don't often *need* general data interchange. Even if, for the sake of argument, we grant that this is the case right now (and, given the number of messed-up characters I get in my email every day, I do *not* grant it), it is becoming less and less the case every day. In 10 or 20 years, I believe it will be not just common but expected to have projects (programming and otherwise) that consist of people scattered all over the world, constantly passing their data around. To paraphrase your comment above, Unicode may be a pain, but it is the least bad solution we have. --Dks
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 11:03:43AM -0800, Michael Lazzaro wrote: > > And note that as pretty as -> is, we couldn't have <- for piping > because it would conflict rather strongly things like > > if ($a<-5)# (negative five, or pipelike?) Pipelike. Longest token rule. --Dks
TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: > Paul Johnson wrote: > > > Well, I'll be pretty interested to discover what cause is deemed more > > deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, > > right? > > True. But I suspect that TPF's position is that, to many people, Perl 6 is > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or > Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of > a hundred other projects on which their job depends on a daily basis. > > Supporting those efforts is important too, and TPF has only limited resources. Correct me if I'm wrong, but isn't the one thing that all those projects have in common...well...Perl? And isn't Larry the guy to whom we owe the existence of Perl? I'm not fortunate enough to be using Perl in my job, but I'm still more than happy to pony up for a donation, purely from gratitude. This is something along the lines of the applied research vs basic research question. What Larry is doing pretty much amounts to basic research that will help all of these other projects in the long run. --Dks
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
> $a = sub ($a, $b) { ... }
> $x = -> ($y, $z) { ... }
>
> The pointy-arrow doesn't buy anything here.
IMHO, it's actually a loss. I have yet to come up with any mnemonic
for "pointy arrow means sub" that will actually stick in my brain.
Every time I see this construct, I have to stop in my tracks and
mentally flip through the reference manual.
> But in a for loop:
>
> for 1,2,3,4 { ... }
> for 1,2,3,4 -> ($a,$b) {...}
>
> its cuteness works because the brain sees it as a piping operator (even
> though its not).
Agreed.
[snip]
> And then we can replace the ~> with ->:
>
> for 1,2,3,4
> -> sub ($a, $b) { $a+$b }
> -> sub ($a) { $a**2 }
> -> { $^foo - 1 }
> -> print;
>
> And this begs the question: what exactly does the C contribute to
> the semantics of the pipeline? What would C (in void context)
> do differently?
One potential answer: make 'map' be lazy by default and 'for' be
nonlazy (energetic? active? ADHD?). My logic in suggesting it this
way around is that, to me, 'for' seems to operate more on a whole
list, while 'map' is intended to operate on elements one after
another. Like so:
for (1,2,3) { print } # "I want to call print for this whole list"
map { print } (1,2,3) # "Map the 'print' function over the elements
# of this list"
--Dks
Re: Arrays, lists, referencing
Some random musings, for what they're worth...
1) The fact that we've had this long thread about arrays and shows
that they are confusing. How could we change the
functionality/eliminate the differences so as to simplify things?
2) It seems that the functionality of lists is a proper subset of the
functionality of arrays. If this is the case and I'm not just
missing something, we might want to at least consider some way to
eliminate lists as a separate data type.
2a) What would be the costs (performance and otherwise) of eliminating
lists and just having people use anonymous array composers where
they would normally use a list? How much more expensive is it to
allocate an array on the heap than an equivalent list on the
stack?
3) More interesting than eliminating lists would be to distinguish
them...to give them a "special power" of their own. My suggestion
would be to make lists behave as a shortcut for mapping over their
elements. Therefore:
(@a, @b, @c).pop();
# same as @{[@a, @b, @c]}.map({pop})
%z = (@a, @b, @c).{$_[0] => $_};
# same as @z = @{[@a, @b, @c]}.map({$_[0] => $_});
4) Also spiffy would be if we could make lists auto-hyper their
elements:
@a = (1, 2, 3) + 7;
# same as @a = (1, 2, 3) >>+<< 7;
# might need to be @a = (1, 2, 3).+ 7;
Ok, I will now sit back and listen to reasons why this is a bad
idea. :>
--Dks
Re: Arrays, lists, referencing
On Fri, Feb 14, 2003 at 10:10:09PM -0700, Luke Palmer wrote:
> > Date: Fri, 14 Feb 2003 12:38:59 -0800
> > From: David Storrs <[EMAIL PROTECTED]>
> >
> > Some random musings, for what they're worth...
> >
> > 1) The fact that we've had this long thread about arrays and shows
> >that they are confusing. How could we change the
> >functionality/eliminate the differences so as to simplify things?
>
> It seems that what we need to do is come up with a simple
> explanation/analogy that describes each. In our minds as it stands,
> it indeed is confusing.
Fair enough, and probably the best course. I just want to bring up an
alternative, so that we don't all get "trapped in the box." After
all, the point of a greenfield rewrite is that you can question
things. :>
> > 2) It seems that the functionality of lists is a proper subset of the
> >functionality of arrays. If this is the case and I'm not just
> >missing something, we might want to at least consider some way to
> >eliminate lists as a separate data type.
> >
> > 2a) What would be the costs (performance and otherwise) of eliminating
> > lists and just having people use anonymous array composers where
> > they would normally use a list? How much more expensive is it to
> > allocate an array on the heap than an equivalent list on the
> > stack?
>
> This has been previously discussed in another guise. The distinction
> between lists and arrays is important, and I think it is necessary to
> have both in the language.
>
> If we don't have lists, what does unary * do? Right now, it flattens
> an array into a I, which is why you can use it to fill in
> multiple arguments in a parameter I. Without them, we have to
> make special cases for all these behaviors, which surely isn't a good
> idea.
Good point. But, I'm still not clear on what functionality lists have
that arrays don't. If the abilities of a list are a subset of those
of an array, why not make parameters lists be parameter arrays instead?
< idea type="wildly blue sky" >
What if functions/methods did not take parameter C? What if,
instead, they took parameter B?
Could you modify them at runtime? Might there be some way to get
access to the function/method's body at runtime and rewrite it so as
to make it aware of your new parameter?
This might be a very bad idea...it could lead to ugly, nasty
spaghetti hacks everywhere. On the other hand...code that modifies
code is a powerful technique. You could use this to optimize code
while it was running, without having to reload the entire program
and lose state. I know it's possible, in P5, to replace a
function/method by assigning a code ref to the package symbol table,
but there is no way (that I know of) to actually retrieve the code
that generated the current version of a particular method, rewrite
it, eval it, and then reinsert it into the stash.
Ok, I'll come back to earth now.
< /idea >
> Also, don't worry about implementation. That's p6i's job.
Fair enough. :>
> > 3) More interesting than eliminating lists would be to distinguish
> >them...to give them a "special power" of their own. My suggestion
> >would be to make lists behave as a shortcut for mapping over their
> >elements. Therefore:
> >
> > (@a, @b, @c).pop();
> > # same as @{[@a, @b, @c]}.map({pop})
> >
> > %z = (@a, @b, @c).{$_[0] => $_};
> > # same as @z = @{[@a, @b, @c]}.map({$_[0] => $_});
>
> This is an interesting concept... although, we already have vector
> syntax. Is it really worth it to make implicit what was already clear
> explicitly? The real question is, if they don't auto-vector, what
> I this do:
>
> @a = (4, 1, 2) + 7;
>
> @a could be (9) or (10), maybe even (\(4,1,2)+7), but hopefully not.
I can see five possible courses here:
1) We decide that my suggestion is a bad one and do nothing with it.
That's fine; I am not wedded to it, I just thought it was an
interesting idea that I wanted to raise.
2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
found it incredibly non-intuitive. I'd really like to get away
from this, even if it means that this expression is a fatal error
"Can't add scalar to list".
3) (4, 1, 2) + 7 returns (10), by adding 7 to the length of the list.
This makes lists look even more like arrays, and doesn't really add
any new power to the language.
4) (4, 1, 2) + 7 returns (11, 8, 9). This is a convenient shorthand
for the vector syntax, IMO.
5) (4, 1, 2) + 7 returns (1
Re: Arrays, lists, referencing
On Wed, Feb 19, 2003 at 09:51:12AM +1100, Deborah Ariel Pickett wrote:
> That said, I don't know of anything that the C comma operator can do
> that you couldn't equivalently do with a Perl5 C statement:
>
> foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
Or just a Boolean:
foo() or (warn("blah") && next; );
--Dks
A6 questions
Greetings all,
Ok, it took me several days to get through A6, and I'm not caught up
on all the mail yet (though I've tried to skim so I don't repeat
someone else's question). I'm left with a bunch of questions; can
anyone answer the following:
==QUESTION
- Page 8 says "In some languages, all methods are multimethods." I
believe that Java is one of these. Is that right and what are some
others? (This is really just curiousity.)
==/
==QUESTION
- Given the following code, what is called by $ride.current_speed()?
class Vehicle {
my $speed;
method current_speed() { return $speed; }
method set_speed($n) { $speed = $n; }
}
class Car {
submethod current_speed() {
print SUPER.current_speed();
return SUPER.current_speed();
}
}
class A6 { }
my $ride = new A6;# Perl with German engineering???
$ride.set_speed(60); # Calls Vehicle.set_speed()
print $ride.current_speed(); # Calls what?
[NB: an A6 is a type of car made by Audi; I couldn't resist.]
==/
==QUESTION
- On page 9, on the section concerning Rules, we see the following
quote:
"They [rules and methods] share the same namespace, and a rule
really is just a method with a funny syntax."
If that's so, why does there need to be a distinction between them?
Wouldn't it be better to use up as little mind-space as possible,
and reduce the required syntax set, by eliminating rules as a
separate type?
==/
==QUESTION
- Also on page 9, concerning macros:
"...while a macro's name may be installed in either a package
or a lexical scope, its syntactic effect can only be lexical,
from the point of declaration (or importation) to the end of
the current lexical scope."
Does that mean that I cannot define a bunch of commonly-used macros
in a single file and then use them in different files?
==/
QUESTION
- SUPER:: is mentioned on page 9. Was this an analogy, or a
demonstration of intention to keep it?
==/
QUESTION
- re: operator overloading, from page 11:
"...you may specify exactly where the parse rule is
interpolated with a special ... marker, which is considered
part of the name: macro circumfix:(*...*)"
If the ... is part of the name, then C has a
different name than C. What does that
mean in practical terms? Can I call them separately? If so, how do
I specify which one I want?
==/
QUESTION
- Regarding <== and ==>:
list(@foo, how => 'scrambled' <== 1,2,3)
I had to read this a bunch of times before it started to make any
sense. What is happening here is that the 1,2,3 to the right of <==
constructs a list, and the list(...) constructs a list of everything
inside it. So a list is made of the 1,2,3, and that list is then
appended (via the pipe) to the list being built by the list(...). Is
that correct? And doesn't it meant that the <== is redundant and
obfuscatory?
Don't get me wrong--I LIKE the idea of piping operators, and I'm glad
they're here. I just want to make sure I understood what was going on
in this instance, and had't missed something.
==/
--Dks
- End forwarded message -
Re: A6 questions
On Sun, Mar 16, 2003 at 10:08:41PM -0500, Chris Dutton wrote:
> On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
>
> > ==QUESTION
> > - Page 8 says "In some languages, all methods are multimethods." I
> > believe that Java is one of these. Is that right and what are some
> > others? (This is really just curiousity.)
> > ==/
>
> Doesn't C++ work this way? Also I believe Pike allows overloading of
> methods by default.
Nope. C++ will only dispatch on the type of the first argument (the
implicitly-passed argument which becomes the "this" pointer).
> > ==QUESTION
> > - Given the following code, what is called by $ride.current_speed()?
> >
> > class Vehicle {
> > my $speed;
> > method current_speed() { return $speed; }
> > method set_speed($n) { $speed = $n; }
> > }
> >
> > class Car {
> > submethod current_speed() {
> > print SUPER.current_speed();
> > return SUPER.current_speed();
> > }
> > }
> >
> > class A6 { }
> >
> > my $ride = new A6;# Perl with German engineering???
> > $ride.set_speed(60); # Calls Vehicle.set_speed()
> > print $ride.current_speed(); # Calls what?
>
> Unless this is more complicated than I think, Car's current_speed() is
> called.
I should have included the relevant quote (which I can't find right
now). This was a question specifically related to submethods. If I
understand correctly, submethods allow you to declare a method in a
base class, and override it in a derived class such that the
overidden submethod is not visible from classes derived from there on
down. So, if I'm right about this, calling $ride.current_speed() will
actually call Vehicle's method, because Car's is not visible (being a
submethod).
> That said, a minor nitpick is that you'd want something more like
>
> class Vehicle { ... }
> class Car is Vehicle { ... }
> class A6 is Car { ... }
D'oh! Yes, of course.
--Dks
Re: A6 questions
On Mon, Mar 17, 2003 at 10:56:51AM -0700, Luke Palmer wrote:
> Assuming the obvious inheritance, Vehicle.set_speed() would be called.
Ok good, that's what I thought. Thanks.
> No. Rules fit better in a grammar than subs, and help the psychology
> of people in various ways. For instance:
>
> multi subst(Str $str: Rule $match, Code $repl) { ... }
>
> Helps people to know that $match should be a regex. Helps the
> compiler, too.
>
> Also, it looks nicer:
>
> sub identifier {m{ <[\w]-[\d]> \w+ }}
> rule identifier { <[\w]-[\d]> \w }
I personally don't see a lot of difference between those two, but I'll
go with you on the "helps people know that $match should be a regex"
point. Good enough.
> > QUESTION
> > - SUPER:: is mentioned on page 9. Was this an analogy, or a
> > demonstration of intention to keep it?
> > ==/
>
> I think there was intention to keep it. It's a useful thing, you
> know.
Yes, indeed; I knew there would be SOMETHING that would fill this role
in P6. I just wanted to know if it would actually be the same token
with the same semantics, or if Larry had some plan to totally
hyperrenoberate how inheritance works and superclasses are accessed
(which he well may...we'll need to see A12, I suppose).
> > QUESTION
> > - Regarding <== and ==>:
>
> I'm not too happy with the semantics of ==> and <==, but they might
> grow on me... we'll see. Anyway, yes it is redundant. Just as
> postfix C is redundant with C. It's still a useful thing to
> have, in terms of readability.
>
> And like most things in Perl, it can also be obfuscatory, given the
> proper guise.
Good enough. I wasn't slamming the operator in total--I think it's
fine. I simply found this particular usage a bit awkward.
OTOH, I think this is wonderfully clear:
@data ==> map {} ==> sort {} ==> map {} ==> print;
--Dks
Funding the design team
On Sat, Mar 15, 2003 at 05:32:39PM -0500, James Mastros wrote: > On 03/14/2003 3:22 PM, Dan Sugalski wrote: > > That means that TPF's "perl development grant" fund is fine to donate > > to, and if there's only enough cash for one grantee, and Larry's the > > best candidate, that's keen. Setting up a "Fund Larry Wall" fund is > > where things get much less easy. > [it's not a problem if] there was both a "perl > development fund", and a "perl6 development fund". Then people who > wanted to see things like DBI and mod_perl get funded could give to the > first, and people who wanted to see Larry, you (Dan), Damian, and the > gang get funded (or, unfornatly, some subset thereof, depending on how Such a fund would be the ideal but, until it is set up, there is a very easy way to fund the design team: Folks, give us your address (or a PO box, or something), where we can send checks. The checks won't be tax deductible, but are we really doing this for the tax deduction? --Dks
grab-bag questions (was Re: A6 questions)
Piers, Apologies...I actually put them into one mail deliberately, because I didn't want to burn more mindspace than necessary...people could skim all my questions at once, answer those they were interested in, and be done. I didn't think about how this would impact the summaries. In future, I'll split questions as you request. --Dks On Mon, Mar 24, 2003 at 04:00:38PM +, Piers Cawley wrote: > David Storrs <[EMAIL PROTECTED]> writes: > > Greetings all, > > > > Ok, it took me several days to get through A6, and I'm not caught up > > on all the mail yet (though I've tried to skim so I don't repeat > > someone else's question). I'm left with a bunch of questions; can > > anyone answer the following: > > [ list of 7 thematically unrelated questions, sharing only the fact > that they were sparked by the same Apocalypse ] > > Okay, I almost put this into the summary, but it's really something > internal to the list: > > Please, I'm begging you, when you have a bunch of questions about an > apocalypse which are otherwise only tangentially related, break the > list up into multiple posts. This thread is not the only offender by > far, but summarizing the responses to such a list is a complete > nightmare; I have to jump back and forth between posts, trying to > separate out the substrands so as to present something coherent. Or, I > just get pissed off with the whole affair and fail to do a good job of > summarizing. Also, if you split the questions up into multiple posts, > you have the opportunity to help me (and all other readers) still > further by coming up with meaningful subject lines for each > question. Trust me, a subject line of 'is static?' is way more useful > to the reader than 'A6 Questions' or 'Apoc 5 - some issues'. Also, if > you avoid 'grab bag' posts, you'll probably see more attention given > to your individual questions. > > Make my life easier, go on, you know you all want to. > > -- > Piers
Re: A6: Named vs. Variadic Parameters
On Wed, Mar 19, 2003 at 12:19:20PM -0800, Michael Lazzaro wrote: > I think newbies are going to unquestionably try and put the parameters > in the same order as they expect to see the eventual arguments, and be > durn confused it doesn't work -- I know I would. [...] > Dunno. I'm just one datapoint, but I strongly see the difference > between (1) and (2) as being a *huge* newbie trap. Well, I guess I'm another datapoint then. Although I don't consider myself a wizard by any means, I've been programming Perl for a long time and I'm very comfortable with it. I've read A6 a couple of times and been following the discussions on the list. And, despite all those advantages, I _still_ don't really grok the proposed signature stuff (it gets a little clearer every time I read it, but it's still awfully muddy). I hadn't even recognized the trap that we are discussing until this thread came up. I think people just coming to Perl are going to be extremely baffled and frustrated by the signature syntax and semantics. This is going to promote one of two reactions: they will leave and go to Python/Ruby/whatever, or they will never use signatures. I'm still waiting for the Exegesis...I recognize that the Apocalpsi are hard simply because they are definitive and must cover every edge case. Possibly, with some day-to-day examples and down-to-earth tutorial materials available, all of this will become simple; that has happened for me before with prior Apocalpsi. However, even if it ends up being clarified by the Exegesis, the signature syntax/semantics ARE complex. In order to justify that complexity, they need to provide a tremendous advantage; I'm simply not sure that the advantages they provide are worth the complexity. In order to make it worthwhile (IMO), it would need to be very easy to use, which would imply at least the following: 1) There are both long and short forms of the zone markers. E.g: sub foo($x, $y, ?$z, *a);or sub foo(pos($x, $y), opt($z), slurp(@a)); (I'm pretty sure this is already planned.) 2) Once the params and their nature have been determined, it should be possible to use the function with the arguments in the same order as the declaration: E.g.: sub bar(pos($a, $b), slurp(@x), named($key)); bar($a, $b, 1,2,3, key => 'jack'); I understand what I'm asking here...the slurpy array must somehow know to "stop", which is somewhat opposed to the idea of "slurping". I would be perfectly happy if it were a compile-time error to declare the slurpy array anywhere other than last, and to declare positional arguments anywhere other than first. I guess what I'd really like is to see the concept of 'zones' taken to its logical extreme; specify the order in which the zones must appear, and then have a marker that denotes the transition, as opposed to labelling every parameter. Therefore (violating the rule about the colon for a moment): sub foobar( $x, $y, $z, # required positionals go here o: $a, $b, $c, # optional positionals go here n: $d, $e, $f, # named go here h: %h, # slurpy hash here s: $s, # slurpy scalar here a: @a # slurpy array here ); mygrep( Block &code, a: @list ); init_screen( n: $color, $height, $width, h: %control_values); etc... --Dks
Incorporting "WhatIf"
I recently discovered a CPAN module called WhatIf (http://search.cpan.org/author/SIMONW/Whatif-1.01/). This module has the ability to provide rollback functionality for arbitrary code. I don't really understand continuations yet (although I'm reading up on them), so perhaps they would allow this to be done trivially. However, I think it would be very cool to roll this module into the core language and provide the keyword support in core. Is this feasible? What would the overhead costs be? --Dks
Re: A6: Named vs. Variadic Parameters
On Wed, Apr 02, 2003 at 12:18:47PM -0800, Paul wrote: > I think Larry's accomodating everybody, here. > Those of us who want to play with the tinkertoys will probably enjoy > the whole box, even the little widgets that take us a while to > identify. Agreed. But I'd like to keep the identification time as short as possible by clearly labelling everything. > > David Storrs <[EMAIL PROTECTED]> wrote: > > [re: current sig syntax] > > In order to make it worthwhile (IMO), it would need to be very easy > > to use, which would imply at least the following: > > > > 1) There are both long and short forms of the zone markers. > >E.g: sub foo($x, $y, ?$z, *a);or > > sub foo(pos($x, $y), opt($z), slurp(@a)); Actually, looking back, this should have been two things: 1a) There are both long and short forms of the zone markers. (E.g., "?" and "optional"). 1b) There should be a way to write it such that you don't have to label every parameter individually. Instead, you should be able to collect the params in a particular zone together and say "These all belong to this zone". The example above does that: sub foo(pos($u, $v, $w, $x, $y), opt($z, $zz), slurp(@a)); I believe that the method which is currently proposed for long-form declarations use properties: sub foo( $u is positional, $v is positional, $w is positional, $x is positional, $y is positional, $z is optional, $zz is optional, @a is slurpy ); I'd really like to be able to save some typing here (and yes, I could just do it with a slurpy array/hash). I don't remember if properties are distributive, but if they are not, it would be a great feature to add (much like 'my' is distributive in P5). So, if people don't like my original proposed syntax, we could just use distributed properties, as Paul suggested: > sub foobar( ($x, $y, $z) is positional, > ($a, $b, $c) is optional, > ($d, $e, $f) is named, > (%h, $s, @a) is slurpificatious (This is something I would propose in general, incidentally, not just for signatures. But it's so useful and so obvious that Larry must have already thought of it, so I'll shut up now.) > Could [the signature zones] then be reordered [after being > explicitly labelled as above]? Well, it depends on what you're willing to give up. To me, it is important to ensure that the declaration of the function is good documentation on the correct order in which to specify the parameters. Therefore, I would say that no, they cannot be reordered. The zones should have a fixed order of occurrence and it should not be possible to permute that order (although it is, of course, feasible to leave out a portion). > Will it be possible to multi-declare traits like that? Not sure how you mean multi-declare...are you talking about the distributing of a property? > And even once the declared types are clear, what does that say about > the required order of accepted args? At a minimum, the order in which they appear in the declaration must be correct. If there are other, additionally acceptable ways to order them, that's probably ok. But the order in the declaration must be a valid way to call the function. --Dks
Re: A6: Named vs. Variadic Parameters
On Fri, Apr 04, 2003 at 10:40:49AM -0800, Larry Wall wrote: > Yes, though it's usually been mentioned with respect to things like: > > my ($a,$b,$c) is constant = abc(); > > However, I would personally go with the prefix zone macros before using > distributed traits, just to get the zone info out front. Ok, cool. As long as I have both of these options, I'm happy. > Perl 6 is designed to allow cultural experimentation. You may > reclassify any part of Perl 6 as a bike shed, and try to persuade > other people to accept your taste in color schemes. Survival of the > prettiest, and all that... Well, I admit that this issue is less important than many others (e.g., the threads thread). However, it all started when MikeL pointed out that some function signatures mean that the function can't be called with the params in the same order as they were declared. To me, this violates the Principle of Least Surprise, which makes it at least a small step up from a bike shed. But, as I said, the macros option and the distributed properties option both exist, so that will solve half the problem. The other half would be fixed simply by declaring the zone order to be fixed. --Dks
Re: Compile-time binding
On Wed, May 28, 2003 at 04:41:36AM -0600, Luke Palmer wrote: > I was reading about Haskell, and realized that I don't know what ::= > is supposed to mean (don't ask what that has to do with Haskell :-). > I know it's compile-time binding, but... what's compile-time binding? > > Could someone who knows enlighten me, please? > > Luke Well, perhaps I'm mistaken, but I had understood it to mean simply that the binding between variables and/or methods is established at compile time, not at runtime. Specifically: - Named variables have their addresses hardcoded during compilation - Global variables given offset from start of global data area - Local variables given offset from top of stack - Object variables given offset from start of object data - Normal function and method calls are hardcoded during compilation - Normal functions have specific starting address in object file - Object methods have specific starting address in object file - Compiler is able to determine which function matches each call (The above shamelessly cribbed from: http://www.cs.sbcc.net/~shouk/polyhi/tsld005.htm, because it's 9:34 AM and my brain doesn't wake up for at least another half hour.) -Dks
Re: Compile-time binding
On Wed, May 28, 2003 at 06:35:31AM -0700, David Storrs wrote: > On Wed, May 28, 2003 at 04:41:36AM -0600, Luke Palmer wrote: > > I know it's compile-time binding, but... what's compile-time binding? > > Luke > > Well, perhaps I'm mistaken, but I had understood it to mean simply > [...] > > - Named variables have their addresses hardcoded during compilation > - Global variables given offset from start of global data area > - Local variables given offset from top of stack > - Object variables given offset from start of object data > - Normal function and method calls are hardcoded during compilation > - Normal functions have specific starting address in object file > - Object methods have specific starting address in object file > - Compiler is able to determine which function matches each call > > (The above shamelessly cribbed from: > http://www.cs.sbcc.net/~shouk/polyhi/tsld005.htm, because it's 9:34 AM > and my brain doesn't wake up for at least another half hour.) (Responding to my own post) I suppose I should explicitly state that P6 will probably implement things a little differently from the details described above (e.g., I don't know that we will have one-and-only one global data area), but the above describes the general concept. --Dks
an idle question: returning from a nested call
So, as I sweat here in the salt mines of C++, longing for the
cleansing joy that Perl(5 or 6, I'd even take 4) is, I find myself
with the following problem:
Frequently, I find myself writing stuff like this:
void Ficp400::SaveRow(long p_row)
{
// if p_row is marked as deleted, return
if (GetStatus(row) & FLX_ROW_DELETE) { return; }
...
}
As a general rule, I don't like comments. When I see a comment, I
want to turn it into a function name. So, I keep wanting to be able
to write the above code like so:
void Ficp400::SaveRow(long p_row)
{
Return_If_Is_Deleted(p_row);
...
}
Now, in C++ (or P6, FTM), I could make this work via a macro, but
that's ugly. In P6, I could make it work by passing the current
continuation down to Return_If_Is_Deleted and call the continuation if
the row is in fact deleted, but that will require an extra param. Is
there a way to make it work as written? I'm thinking maybe the
C object would have something that would allow me to jump to
the right point (i.e., caller[2]).
Just an idle thought,
--Dks
Re: an idle question: returning from a nested call
On Thu, Jun 12, 2003 at 03:12:32PM -0700, Austin Hastings wrote:
>
> sub Ficp400::SaveRow(Int $p_row)
> {
> return if IsDeleted($p_row);
> }
*laugh* Well, yes, there is always the obvious way. I had wanted
something that would be reusable between multiple function, though
(sorry, should have said that explicitly).
I guess I got too caught up in the specific example; what I was really
curious about is if there was a way to skip up the stack on return.
And the answer, I see, is yes. Thanks for pointing me at C.
Yeesh. Looks like I need to go back and reread A6 for a third time.
I obviously didn't understand it well enough.
--Dks
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Tue, Jun 10, 2003 at 12:04:14PM -0700, Michael Lazzaro wrote:
> J: (scalar junctive to typed scalar)
>
> A scalar junctive, e.g. an "untyped" scalar, can always be silently
> used as and/or converted to a more specific primitive type. This will
> quite frequently result in the loss of information; for example, saying:
>
> my $a = 'foo';
> my int $b = $a;# $b is now C<0>
>
> works, but silently sets $b to 0, because the numeric value of C<'foo'>
> is C<0 but true>.
On the subject of untyped scalars...what does it mean to say that the
conversion is 'lossless'? For example:
my $a = 'foo';
my Int $b = $a; # legal; $b is now 0; is there a warning?
my $c = $b; # is $c 0, or 'foo'?
my Str $d = $a; # no loss
my $a = $d; # no effective change in $a
my $e = $b; # what is $d?
In the above, I would expect that $c is 0 and
my $a = 7 but false;
my Str $b = $e; # ???
What value does $f end up with? (My vote would be '7'.)
Does it have any properties?
Are any warnings emitted?
>
> (iv) Pragma-Controlled Conversions
>
>Given the above, and given the fact that our general answer to
> everything is to Use A Pragma ;-), we have the following tentative list
> of needed pragmas. For each possibility, we need to be able to declare
> that a given implicit type conversion will be silently allowed, will
> result in a warning, or will result in an exception.
>
> A (very) rough proposed pragma form, for the sake of argument, is:
>
> use strict conversions; # all on (exceptions)
> no strict conversions; # all off
>
> use strict conversions allow => << cv1 cv2 ... >>; # selected
> conversions are allowed
> use strict conversions warn => << cv1 cv2 ... >>; # selected
> conversions give warnings
> use strict conversions fail => << cv1 cv2 ... >>; # selected
> conversions give exceptions
Seems generally, but I'd like to see this be organized into
hierarchies, like Perl 5 (recent versions) warnings: the Numeric
group would control every form of numeric conversion, the
Truncation subgroup would control everything in the Numeric group
that could end up truncating data (e.g. int -> short), etc.
> S: (string to numeric)
My vote for default: C
> F: (float to int)
My vote for default: C
> N: (numeric range)
My vote for default: C
I also suggest adding an extra pragma:
use rangechecking warn => << Int_to_int >>;
use rangechecking warn => << Num_to_num >>;
use rangechecking fail => << Int_to_int >>;
use rangechecking fail => << Num_to_num >>;
This lets you trade speed for safety on a lexically-scoped basis.
> (vi) Conversions of User Defined Types/Classes
>
>It may be useful to allow the same level of pragma-based control for
> user-defined types and classes. For example, a given class Foo may
> wish to be "silently" convertable to an C. One proposed syntax to
> declare the method of coercion/conversion might be:
>
> class Foo {
> ...
>
> to int {...} # or C?
> }
>
> However, users of such a class could adjust the warning level of the
> given conversion using the alternate syntax given above (v):
>
> use strict conversions warn { Foo => int };
Adding to the 'hierarchical pragmas' idea that I mentioned above...how
about a 'to_int' group, which controlled any type (user defined or
system) that was attempted to convert itself to an int? The
extensions are obvious.
--Dks
Re: printf-like formatting in interpolated strings
On Mon, Jun 16, 2003 at 02:09:43PM +0200, Edwin Steiner wrote:
> Edwin Steiner <[EMAIL PROTECTED]> writes:
>
> We know: Everything between the \F and the next funny character is the
> format specifier. This allows extensions to the printf-specifiers:
Cool, Perlish, scary.
> Examples:
> [snip]
> " \F\$6$x" --> $3 (yes, it's ugly)
> [snip]
> "\F*20$()" eq ('*' x 20)[...]
The Obfuscated Perl Contest people will LOVE this.
--Dks
