Re: printf-like formatting in interpolated strings
[EMAIL PROTECTED] (Edwin Steiner) writes: >Description: This list is for discussing user-visible changes to >the language. > > It's somewhat unnerving to post on topic and (hopefully) politely and I think your post was spot on; the only problem I had with it is that I felt it was addressing a problem at too low a level. This could be because I'm a grouchy old-timer, and I carry over a Perl 5 design principle that says that changes should be made in as general a way as possible. I *want* to solve the sprintf-interpolation problem, but I think it's possible to get too bound-up in syntax and miss more generic ways of solving the same problem. A quick review of the early archives of this list might serve to exhibit the phenomenon. :) I also think it's possible to get bogged down in low-level details right now, when the same energy could be used to, say, hash out the MMD "big issue" that Ziggy mentioned earlier today. I think all that needs to happen at this stage is that we realise that a nicer way to do formatting in strings would be good, we look at whether or not it can be done (decently, for *someone*'s definition of decent ;) with the tools we already have proposed, and if not, flag it as something to come back to when we need to hammer out the details. > get a cold (less on topic) reply from someone with "warm feelings". On > the other hand the sharks might miss the occasional bite... Unfortunately, it cuts both ways; this is the second post in a row you've ended with an unnecessary barb. I know I'm no saint as far as that's concerned, but I also know it doesn't necessary endear people to your point of view. -- Facts do not cease to exist because they are ignored. -- Aldous Huxley
Re: printf-like formatting in interpolated strings
Simon Cozens <[EMAIL PROTECTED]> writes: > it was addressing a problem at too low a level. This could be because I'm a > grouchy old-timer, and I carry over a Perl 5 design principle that says that > changes should be made in as general a way as possible. It's a very good principle, I think. One (tiny) generalization I could think of was to pass everything between the \F and the funny character as an argument to a method call on the value. This method then stringifies the value. The default method just does sprintf or something similar. I see that it would probably be better to pass something like a general "stringification context" to the value, which could contain eg. language info. > Ziggy mentioned earlier today. I think all that needs to happen at this stage > is that we realise that a nicer way to do formatting in strings > would be good, I'm content if this will be revisited (hopefully by someone with better overview than mine). It just should not be ignored. > Unfortunately, it cuts both ways; this is the second post in a row you've > ended with an unnecessary barb. I know I'm no saint as far as that's > concerned, but I also know it doesn't necessary endear people to your point of > view. Look, no barb --> :) -Edwin
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote: > > On Friday, June 13, 2003, at 10:26 PM, David Storrs wrote: > > >my $a = 'foo'; > >my Int $b = $a; # legal; $b is now 0; is there a warning? > >my $c = $b; # is $c 0, or 'foo'? > > 0, I think. Or specifically, C. So then conversion from Scalar to Int is not lossless, and (by extension) conversions from Scalar to any other LargeCapPrimitive are presumably not lossless either. > (I've been operating under the > assumption that an "untyped scalar" doesn't _remove_ the type of > something, it just can store values of _any_ type, and is by default > much more generous about autoconverting them for you, so that you could > use $c as an Int, int, Num, num, Str, str, etc., without warning or > error... but internally, it's actually still storing the value as an > C, because that's what you assigned to it.) Seems reasonable. Although I would assume that it would store and pull the value from an Int slot, then create a new value of the "converted to" type, and use that. > >my Str $d = $a; # no loss > >my $a = $d; # no effective change in $a > >my $e = $b; # what is $d? > > $d? Still a Str, I would think. And $e would be Int 0, same as $c I obviously had either a typo or a braino on the last line there. I have no idea what I was trying to ask. > > What value does $f end up with? (My vote would be '7'.) > > My understanding is that properties go with the values, (just like > traits go with the variables), so I would expect $f to be C<7 but > false>. So if a value is C, it stays C until you > say otherwise. A better example of what I was driving at would be this: my $a = 'foo' but purple; my Int $b = $a; In other words: I've just created an untyped Scalar. This Scalar is (presumably in it's Str slot) storing a string value which happens to have a property set on it (i.e., C
Re: printf-like formatting in interpolated strings
On Monday, June 16, 2003, at 10:39 AM, Edwin Steiner wrote: I'm content if this will be revisited (hopefully by someone with better overview than mine). It just should not be ignored. Oh, it definitely won't be ignored. :-) It's come up several times before -- try searching for "stringification", IIRC -- and has always sortof fizzled because the higher-ups were never quite ready for it yet. And there's some primitive type and type conversion questions that are still unclear -- until those are fleshed out, the stringification proposals have been a bit "stuck". But there is broad support for the idea that the somewhat elderly printf syntax is a PITA, and that printf, in general, should be completely unnecessary since we already *have* interpolated strings, fer pete's sake. If you really want to make your brain hurt, consider this: stringification can be thought of, obliquely, as the "inverse" of regexes. One puts strings together, the other takes them apart. And Perl6 introduces shiny, clean-looking rule syntax: /here is a / Oooh, pretty. So if I were in an evil mood, which I almost always am, I'd ask: what's the inverse of a rule? Is it possible that interpolated strings could benefit from the same angle-bracket syntax? __Is it possible that there are "output rules" just like there are "input rules"?__ So what would "The value of x is " mean, from the interpolation end of things? _Could_ it mean something? Is it possible that "The value of x is " is in fact a cleaner, more elegant syntax than: "The value of x is $(expr but formatted(...))" Or, if we have "output rules" just like we have "input rules", could something quite complex be expressed simply as: "You have <$x as MoneyFormat>" having previously defined your MoneyFormat "formatting rule" in some other location? MikeL
Re: Type Conversion Matrix, Pragmas (TAKE 4)
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote:
> >
> > On Friday, June 13, 2003, at 10:26 PM, David Storrs wrote:
> >
> > >my $a = 'foo';
> > >my Int $b = $a;# legal; $b is now 0; is there a warning?
> > >my $c = $b;# is $c 0, or 'foo'?
> >
> > 0, I think. Or specifically, C.
>
> So then conversion from Scalar to Int is not lossless, and
> (by extension) conversions from Scalar to any other LargeCapPrimitive
> are presumably not lossless either.
Not *guaranteed* lossless. Indeed, how could they be?
I suppose you could construct your scalar as:
my $a = "foo";
my Int $b = $a;
$b == 0 but Scalar("foo");
such that you may reconstruct the Scalarness. But that seems like
trouble waiting to happen -- propagating the value means that
eventually someone calls C and gets "foo" instead of "0".
Unless operator semantics strip extended-value-attributes, so that $b
== 0 but Scalar("foo") while C<$c = $b + 1> == 1 but Scalar("1");
Frankly, I prefer to regard Scalar->Int as a narrowing conversion and
accept the lossage.
>
> > (I've been operating under the
> > assumption that an "untyped scalar" doesn't _remove_ the type of
> > something, it just can store values of _any_ type, and is by
> default
> > much more generous about autoconverting them for you, so that you
> could
> > use $c as an Int, int, Num, num, Str, str, etc., without warning or
>
> > error... but internally, it's actually still storing the value as
> an
> > C, because that's what you assigned to it.)
>
> Seems reasonable.
>
> Although I would assume that it would store and pull the
> value from an Int slot, then create a new value of the "converted to"
> type, and use that.
This goes back to Damian's point some months ago that function call
arguments are pass-by-reference and the limitations that imposes on
automatic conversion/coercion.
In essence, because we say:
sub foo(Int $arg) {...}
foo($a);
The parameter to foo has to be type compatible with Int, or the
compiler will have to automatically instantiate a temp and convert in
one or more directions. Currently, I believe the pendulum has swung
towards "must be type compatible or you get an error."
> A better example of what I was driving at would be this:
>
>my $a = 'foo' but purple;
>my Int $b = $a;
>
> In other words: I've just created an untyped Scalar. This Scalar is
> (presumably in it's Str slot) storing a string value which happens
> to have a property set on it (i.e., C this Str to an Int. String values get converted when assigned to
> Ints. Are we converting and assigning THE IDENTICAL VALUE or are we
> creating a new value (whose value, in a numeric context, is
> considered equivalent) and assigning that? In the first case, I
> would expect that the property would be preserved. In the latter
> case, I would expect it NOT to be preserved.
My preference is:
$temp = "foo";
$temp.setProperty(purple);
$a = $temp;
$temp = Str_to_Int($a); # 0, no property.
$b = $temp;
Although it occurs to me that there might be such a thing as "Int
properties" and "Str properties", and maybe the conversion propagates
the appropriate ones.
That is:
my $a = "foo" but $purple ;
$a but= false;
$a but= prime;
$a but= charset("UTF8");
$a but= encoding("text/utf8");
my Int $b = $a;
At this point, $b would be C<0 but all(false, prime)>.
=Austin
Re: printf-like formatting in interpolated strings
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > Or, if we have "output rules" just like we have "input rules", could > something quite complex be expressed simply as: > > "You have <$x as MoneyFormat>" > > having previously defined your MoneyFormat "formatting rule" in some > other location? "You have ", no? =Austin
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Monday, June 16, 2003, at 11:04 AM, David Storrs wrote: On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote: (I've been operating under the assumption that an "untyped scalar" doesn't _remove_ the type of something, it just can store values of _any_ type, and is by default much more generous about autoconverting them for you, so that you could use $c as an Int, int, Num, num, Str, str, etc., without warning or error... but internally, it's actually still storing the value as an C, because that's what you assigned to it.) Seems reasonable. Although I would assume that it would store and pull the value from an Int slot, then create a new value of the "converted to" type, and use that. Yeah, I would think so. A better example of what I was driving at would be this: my $a = 'foo' but purple; my Int $b = $a; In other words: I've just created an untyped Scalar. This Scalar is (presumably in it's Str slot) storing a string value which happens to have a property set on it (i.e., CI am almost positive that the assignment would perform a copy/clone of the original value, but would preserve the properties while doing so. So if we try to assign C<'foo' but purple> to the Int $b, it: - clones a new Scalar C<'foo' but purple>, but... - identifies the copied C<'foo' but purple> as being a Scalar, not an Int, so... - converts the copied C to an Int, resulting in C - assigns C to $b. ... or something like that. But I would expect that the property _would_ be preserved... my gut feeling is that otherwise, they'd be _way_ to easy to accidentally lose, yes? OT afterthought: In the past, whenever we've gotten embroiled in one of these thorny, knotty issues, @Larry has pulled a stunningly beautiful, elegant rabbit out of their hats. And when I thought that, I had this vision of a single quantum rabbit simultaneously coming out of multiple hats with widely divergent spatial coordinates Yeah. What I wouldn't give for a quantum bunny, right about now. It's not even that type conversion is a particularly difficult issue, it's just so *very* all-encompassing that it's got to be done precisely, because it chains through everything else about the language... what happens when calling subroutines, what happens in the multimethod dispatcher, what simple lines of code do or don't give big honkin' errors, etc... MikeL
Re: printf-like formatting in interpolated strings
On Monday, June 16, 2003, at 11:49 AM, Austin Hastings wrote: --- Michael Lazzaro <[EMAIL PROTECTED]> wrote: Or, if we have "output rules" just like we have "input rules", could something quite complex be expressed simply as: "You have <$x as MoneyFormat>" having previously defined your MoneyFormat "formatting rule" in some other location? "You have ", no? Yeah. Though I'd actually hope both forms were acceptable, personally. I really like the visual karma of the first, representing a "type or format conversion", more than the second, representing the "creation of a formatted object" -- though in practice the two notions are of course identical. :-) MikeL
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030615 Welcome to the last Perl 6 Summary of my first year of summarizing. If I were a better writer (or if I weren't listening with half an ear to Damian telling YAPC about Perl 6 in case anything's changed) then this summary might well be a summary of the last year in Perl 6. But I'm not, so it won't. Instead, I'm going to try and keep it short (summaries generally take me about 8 hours on an average day, and I really don't want to lose 8 hours of YAPC thank you very much). It's getting predictable I know, but we'll start with the internals list again... Class instantiation and creation Dan continued slouching towards full OO and outlined the issues involved with setting up classes and asked for people's opinions. People offered them. http://xrl.us/jou Writing Language Debuggers Clinton Pierce wanted to know how to go about writing language level debuggers in Parrot. (This man is unstoppable I tell you.) He offered some example code to show what he was trying to do. Benjamin Goldberg had a style suggestion for the code, but nobody had much to say about Clint's particular issue. http://xrl.us/jov Converting Parrot to continuation passing style A lot of this week's effort was involved in getting support for the Continuation passing style function calling into Parrot. Jonathan Sillito posted a patch. This lead to a certain amount of confusion about what needs to be stashed in the continuation and a certain amount of bemusement about the implications of caller saves rather than callee saves (in a nutshell, a calling context only has to save those registers that *it* cares about; it doesn't have to worry about saving any other registers, because its callers will already have saved them if they cared.) Dan ended up rewriting the calling conventions PDD to take into account some of the confusion revealed. I think the upshot of this is that the Parrot core now has everything we need to support the documented continuation passing calling conventions. But I could be wrong. http://xrl.us/jow http://xrl.us/jox Segfaulting IMCC for fun and profit Clint Pierce's BASIC implementation efforts continue to be one of the most effective bug hunting (in code and/or docs) efforts the Parrot team has. This time, Clint managed to segfault IMCC by trying to declare nested ".subs" using the wrong sorts of names. Leo Tötsch explained how to fix the problem. It seems that fixing IMCC to stop it segfaulting on this issue is hard, since the segfault happens at runtime. http://xrl.us/joy Passing the time Clint's BASIC can now place chess! Not very well, but we're in 'dogs dancing' territory here. Bravo Clint! There was applause. http://xrl.us/joz Meanwhile in Damian's YAPC address... New DISPATCH method Last week Ziggy worried about multimethod dispatch not being good enough. This week at YAPC, Damian announced DISPATCH, a scary magic subroutine which allows you to define your own dispatch rules. Essentially it gets called before the built in dispatch rules, beyond that, I know nothing. Sorry, no link for this. Meanwhile in perl6-language Ziggy's obsoleted thread Last week I mentioned that Adam Turoff had worried a little about multimethod dispatch, and wanted to know if it would be possible to override the dispatch system in an easy way. This week, he outlines the sorts of things he might want to do. See above for the resolution. Details don't exist just yet, but we'll get there. http://xrl.us/jo2 Type Conversion Matrix, Pragmas (Take 4) Michael Lazzaro posted the latest version of his Type Conversion Matrix and asked for comments and hopefully definitive answers. There was a small about of discussion... http://xrl.us/jo3 Returning from a nested call Whilst idly 'longing for the cleansing joy [of] Perl', Dave Storrs wondered how/whether he could write a method that would return from its caller. Answer: Yes, use "leave". http://xrl.us/jo4 printf like formatting in interpolated strings Edward Steiner wondered about having some way to to printf like formatting of numbers in interpolated strings. Luke Palmer (who just told me he's embarrassed about something I wrote about something he said last week, but I'd forgotten it) came up with a cool looking suggestion in response. http://xrl.us/jo5 Acknowledgements, Announcements and Apologies Well, that wraps up my first year of summary writing. Thanks to everyone for reading, it's been fun. I have one announcement to make: As of next week, there will be no obligatory reference to Leon Brocard -- I'm getting bored of it, you all must have been bored with it for months... If you've appreciated this sum
Re: printf-like formatting in interpolated strings
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > On Monday, June 16, 2003, at 11:49 AM, Austin Hastings wrote: > > --- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > > >> Or, if we have "output rules" just like we have "input rules", > could > >> something quite complex be expressed simply as: > >> > >> "You have <$x as MoneyFormat>" > >> > >> having previously defined your MoneyFormat "formatting rule" in > some > >> other location? > > > > "You have ", no? > > Yeah. Though I'd actually hope both forms were acceptable, > personally. > I really like the visual karma of the first, representing a "type > or > format conversion", more than the second, representing the "creation > of > a formatted object" -- though in practice the two notions are of > course > identical. :-) > Boggle. I was thinking that the C keyword was reserved for type transformation, while was already well-defined for passing arguments to rules. I'd much rather call a sub than create a temp object and then call a method. =Austin
Re: printf-like formatting in interpolated strings
On Mon, Jun 16, 2003 at 11:37:06AM -0700, Michael Lazzaro wrote: > [...] > But there is broad support for the idea that the somewhat elderly > printf syntax is a PITA, and that printf, in general, should be > completely unnecessary since we already *have* interpolated strings, > fer pete's sake. A PITA, yes, but a darned powerful *and concise* PITA. > Is it possible that > > "The value of x is " > > is in fact a cleaner, more elegant syntax than: Quite honestly, I'd like to do better. One of the things that makes regexen so powerful is their concision; they pack a tremendous amount of meaning into every character and yet, for the most part, they aren't that hard to understand. I'd like to see the same for output rules. The vast majority of output rules will probably be on the order of: "make this an integer and left-pad with 0s to make sure there are at least 2 digits". I'd much rather write: "The value of x is \F02d$($x)" than "The value of x is $($x as integer but formatted()" > Or, if we have "output rules" just like we have "input rules", could > something quite complex be expressed simply as: > > "You have <$x as MoneyFormat>" I like this better; a good compromise between concision and readability (although the later poster's suggestion of 'MoneyFormat($x)' was even better, IMO). You still need to define MoneyFormat somewhere, however; I hope that you will be able to do that with nice concise formatting codes. --Dks
Re: printf-like formatting in interpolated strings
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2003 at 11:37:06AM -0700, Michael Lazzaro wrote:
> > [...]
> > But there is broad support for the idea that the somewhat elderly
> > printf syntax is a PITA, and that printf, in general, should be
> > completely unnecessary since we already *have* interpolated
> strings,
> > fer pete's sake.
>
> A PITA, yes, but a darned powerful *and concise* PITA.
>
>
> > Is it possible that
> >
> > "The value of x is "
> >
> > is in fact a cleaner, more elegant syntax than:
>
> Quite honestly, I'd like to do better. One of the things that makes
> regexen so powerful is their concision; they pack a tremendous amount
> of meaning into every character and yet, for the most part, they
> aren't that hard to understand. I'd like to see the same for output
> rules. The vast majority of output rules will probably be on the
> order of: "make this an integer and left-pad with 0s to make sure
> there are at least 2 digits". I'd much rather write:
>
> "The value of x is \F02d$($x)"
>
> than
>
> "The value of x is $($x as integer but
> formatted()"
>
>
> > Or, if we have "output rules" just like we have "input rules",
> could
> > something quite complex be expressed simply as:
> >
> > "You have <$x as MoneyFormat>"
>
> I like this better; a good compromise between concision and
> readability (although the later poster's suggestion of
> 'MoneyFormat($x)' was even better, IMO).
>
> You still need to define MoneyFormat somewhere, however; I hope that
> you will be able to do that with nice concise formatting codes.
Not sure I care about that -- the good ones will wind up in core+, or
barely outside, just like useful helper functions.
I do like one other aspect of printf codes, however -- they are
independent of data, or at least they're REALLY late bound. Remember
the signature for printf:
int printf(format_string, ...)
Being able to code a Grammar used for proactive generation of output
makes P6 a real programm(ar)ing language, possibly the first such. :-)
But saying
rule MoneyFormat {
?
{1,3} ( {3})*
( {2})?
}
isn't the same as saying
emit MoneyFormat {
my $amt = shift;
my $out;
$amt = int($amt * 100);
$out = $decimal_delimiter _ ($amt % 100);
$amt /= 100;
while $amt > 999 {
$out = $thousands_delimiter _ ($amt % 1000) _ $out;
$amt /= 1000;
}
$out = $currency_sigil _ $amt _ $out;
return $out;
}
And as much as I hate to claim that any of the Apocalypsen are
incomplete, I wonder if maybe we need some more thought paid to the
"FORMAT" chapter -- replacing, or merging, formats with emit-rules
seems like an interesting project. (Although one that won't require
*much* in core- other than a standardized "anonymous stream" mechanism
that we've already talked over [inconclusively] once).
=Austin
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Mon, Jun 16, 2003 at 11:47:35AM -0700, Austin Hastings wrote:
>
> Although it occurs to me that there might be such a thing as "Int
> properties" and "Str properties", and maybe the conversion propagates
> the appropriate ones.
>
> That is:
>
> my $a = "foo" but $purple ;
> $a but= false;
> $a but= prime;
> $a but= charset("UTF8");
> $a but= encoding("text/utf8");
>
> my Int $b = $a;
>
> At this point, $b would be C<0 but all(false, prime)>.
>
> =Austin
Yeek. That gives me the screaming willies. Let's either have it
preserve all the properties or none, but please don't make me remember
a big list of which properties exist for which types...and oh, btw,
did I happen to overload/modify that? Did any of the modules I'm
using? Where do user defined properties (if those still exist) fit
in?
--Dks
Re: printf-like formatting in interpolated strings
[EMAIL PROTECTED] (Austin Hastings) writes: > replacing, or merging, formats with emit-rules > seems like an interesting project. I dunno, I think it fires my "change for the sake of change" alarm bells. So far we're already throwing away thirty years of^W^W^W^W^W^Wrationalising one Unix little language; can't we leave another one alone, please - at least until 6.1? We don't have to fix the entire world immediately; fixing the majority of it is already taking quite long enough. :( -- Mohandas K. Gandhi often changed his mind publicly. An aide once asked him how he could so freely contradict this week what he had said just last week. The great man replied that it was because this week he knew better.
Re: printf-like formatting in interpolated strings
On Mon, Jun 16, 2003 at 05:48:58PM +0100, Simon Cozens wrote: > > But then I'm one of those freaks who likes the idea of keeping core Perl 6 > generic, extensible, clean and small, and letting all the clever stuff go > into extensions, a heretical position which is way out of favour with the > more influential listfolk, so feel free to ignore my opinion. FWIW I agree with you completely, and strongly. If it can be outside the core it should be, unless there's a very good reason why not. But I guess I'm far from being an influential listfolk these days... I console myself with a high level of trust in the core design team. Tim [wandering off into the sunset to ruminate on DBI issues...]
Re: printf-like formatting in interpolated strings
Perhaps someone could post a summary of how the issue has been tackled in other languages that support a similar concept. I've not seen one (but then I've not been paying attention, so forgive me if it's need done already, and perhaps point me to a url). Tim.
Re: Dispatching, Multimethods and the like
In <[EMAIL PROTECTED]> Adam Turoff wrote:
> Damian just got finished his YAPC opening talk, and managed to allude
> to dispatching and autoloading.
>
> As it *appears* today, regular dispatching and multimethod dispatching
> are going to be wired into the langauge (as appropriate). Runtime
> dispatch behavior will continue to be supported, including things like
> AUTOLOADER and the like.
>
> As of January, the thinking is sub DISPATCH {} will handle runtime
> dispatching behaviors, including autoloading, but easily accomodating
> value-based dispatching, AOP style pre/post methods, and whatnot.
>
> Unfortunately, Damian said that the design team isn't saying much
> about this, because the semantics aren't quite worked out yet,
> especially with the interaction between autoloading and other dynamic
> dispatching behaviors.
>
> Yes, this is a *big* issue.
It definitely is.
I can't speak for Perl 6 the language, but I can speak for Parrot, so I
can tell you what semantics will be available (though not necessarily
exposed) to the compiler.
For methods, each object is ultimately responsible for deciding what to
do when a method is called. Since objects generally share a class-wide
vtable, the classes are mostly responsible for dispatch. The dispatch
method can, if it wants, do *anything*. However, as some degree of
predictability is nice, the current plan is that classes will:
1) Look for the method in the class or parent. If found, it's
dispatched to. (This method may be defined as a multimethod in the class,
in which case MMD is used to determine which method of the set *in the
class only* is used)
2) Look for an AUTOLOAD method in the class or parent. If found, we
dispatch to it.
3) Look for a MMD version of the method outside of any class. If found,
do MMD
Core engine support will be in for this, since we don't want everyone to
have to bother writing code for it all. Duplicate code. Bleah. We'll
also provide method caches so we have some hope of not being horribly
slow.
By default, the system and class MMD will do class-based dispatching
only, deciding on which method to call based on the types of the
parameters. Both the class MMD method *and* the system MMD method may be
overridden if someone wants to install their own MMD scheme, though
overriding system-wide MMD stuff is always a dodgy thing. (Though no
more than any other overridden systemwide thing, I expect)
Will perl 6 support this? Dunno. Will it call for a different scheme? It
well might. Can a language completely skip the MMD stuff? It can if it
chooses, yes. What name will the dispatch sub be? Beats the heck out of
me, but then that's syntax and I don't do syntax. :)
Re: printf-like formatting in interpolated strings
Luke Palmer <[EMAIL PROTECTED]> writes:
> As far as the syntax, the () and {} don't make a lot of sense with
> regard to the rest of the language. We could either utilize the
> string/numeric context distinction that already exists in {} and []
> for subscripting, or we could always use () in analog to $().
My idea was to make it like the scoped \L{ } of Apocalypse 2.
The \L also says something about formatting and the { } creates a
scope, which "stays" in the interpolated string.
You are right about the (), however, because there should be a
more visible marker (probably a sigil) when the syntax changes from
to .
> I'd like to have that dollar in there somewhere, actually.
>
> "The value in hex is \Fx$( expression )."
The problem is calculated format (I forgot to mention this):
"The value in the chosen format is \F$format$( expression )."
The compiler cannot know, if $format contains the whole format
specifier or just a part (or nothing) so it does not know if it should
take $( expression ) as part of the format or as the formatee ;).
With my proposed syntax the first '(' outside any nesting constructs
would clearly mark the beginning of the formatee.
One option would be to only allow
\\F \{ \}
so this would work and the dollar is there:
"You wanted to see it like that: \F$format\Q{$that}"
"You have \F${digits}d{$cent}."
...which is less than beautiful (should not be common, though).
Also the formatee would always be converted to a string before
formatting (also see conclusion below).
> Or something. That is kinda clunky, though. Maybe just a
> stringification adverb, albeit verbose (but more versatile):
>
> "The value in hex is $( expression where format('x') )"
>
> No, I actually think that should be a property. In fact, one that has
> been discussed before:
>
> "The value in hex is $( expression but formatted('x') )"
>
> That's actually my favorite so far.
So the value should 'carry' its own format...This makes sense in some
cases, in other cases it does not (Though you always could override
with another C.)
The syntax is clean, but even longer than with sprintf:
"The value in hex is $( expression but formatted('x') )"
"The value in hex is $( sprintf '%x',expression )"
Why not allow both (\F with {} and C)? If we disallow
interpolated formats on the \F it introduces minimal complexity into
the parser and compiler. The only price to pay would be the \F
itself.
Disallowing interpolated formats on \F has the additional advantage of
making the {} unnecessary in the most common cases (also removing the
'force to string').
The best of both worlds:
sub foo(int $x,int $y)
{
# print "fooing $x with $y\n" if $debug;
# change it to hex format temporarily
print "fooing \Fx$x with \Fx$y\n" if $debug;
}
$msg = "The value of \$y is $( $y but formatted($chosen_format || '0d') )."
-Edwin
Re: printf-like formatting in interpolated strings
Edwin Steiner <[EMAIL PROTECTED]> writes:
> Disallowing interpolated formats on \F has the additional advantage of
> making the {} unnecessary in the most common cases (also removing the
> 'force to string').
As an afterthought: This suggests getting rid of the {} entirely.
The rule could be like:
\\F
so
"The value in hex is \Fx$value."
"The value in hex is \Fx%lookup{$key}."
"The value in hex is \Fx$(calculate($x,5))."
would both be ok. For more complex formatting you use C or
C.
I really like that. (It's perlish, too, don't you think?)
-Edwin
Re: printf-like formatting in interpolated strings
Edwin Steiner <[EMAIL PROTECTED]> writes:
> The rule could be like:
>
> \\F
After-afterthought:
We know: Everything between the \F and the next funny character is the
format specifier. This allows extensions to the printf-specifiers:
(These extension and more could also be used in C.)
rule format_specifier {
('-' | ' ') ? ? ('.' )? ?
|
? ? ('.' )? ?
}
rule fill_character {
'-' |
}
rule fill_character_no_minus {
> ( <[EMAIL PROTECTED] ]> | )
}
(Hope I got that right.)
If there is no specified, just do the alignment and
filling on the value (which is converted to string before that).
Examples:
$x = 3;
" \F6$x" --> 3
" \F-6$x" --> 3
" \F06$x" --> 03
" \F*6$x" --> *3
" \F-*6$x" --> 3*
" \F\$6$x" --> $3 (yes, it's ugly)
" \F\-6$x" --> -3
" \F -6$x" --> -3 (looks better without the backslash, I think)
" \F--6$x" --> 3-
"\F*20$()" eq ('*' x 20)(don't want to propose special syntax instead of $())
Another possible extension: If there is a specified,
followed by an 'x' and , interpret it as x
and don't expect the :
"\F*x20" eq ('*' x 20)
...quite irregular though.
-Edwin
Dispatching, Multimethods and the like
Damian just got finished his YAPC opening talk, and managed to allude
to dispatching and autoloading.
As it *appears* today, regular dispatching and multimethod dispatching
are going to be wired into the langauge (as appropriate). Runtime
dispatch behavior will continue to be supported, including things like
AUTOLOADER and the like.
As of January, the thinking is sub DISPATCH {} will handle runtime
dispatching behaviors, including autoloading, but easily accomodating
value-based dispatching, AOP style pre/post methods, and whatnot.
Unfortunately, Damian said that the design team isn't saying much about
this, because the semantics aren't quite worked out yet, especially with
the interaction between autoloading and other dynamic dispatching
behaviors.
Yes, this is a *big* issue.
Z.
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
Re: printf-like formatting in interpolated strings
Luke Palmer writes:
>
> As far as the syntax, the () and {} don't make a lot of sense with
> regard to the rest of the language. We could either utilize the
> string/numeric context distinction that already exists in {} and []
> for subscripting, or we could always use () in analog to $().
>
> I'd like to have that dollar in there somewhere, actually.
>
> "The value in hex is \Fx$( expression )."
>
> Or something. That is kinda clunky, though. Maybe just a
> stringification adverb, albeit verbose (but more versatile):
>
> "The value in hex is $( expression where format('x') )"
>
> No, I actually think that should be a property. In fact, one that has
> been discussed before:
>
> "The value in hex is $( expression but formatted('x') )"
>
> That's actually my favorite so far.
>
> > -Edwin
> Luke
maybe the analogy with quotelike expressions in p6 could be usefull
so that "$" inside string are (sort of ) quotelike operators.
this is unambiguos if single ":" cannot be a beginning of variable
name.
"value is $:3int( $value ) or $:5.3float( $value )"
but maybe cleaner way is to have a predefined function which can be
passed modifyers
"value is \F:3int[ $value ] or \F:5.3float[ $value ]"
or just
"value is \F[as=>'3int', $value ] or \F[as=>'5.3float', $value ]"
arcadi
Re: an idle question: returning from a nested call
David Storrs <[EMAIL PROTECTED]> writes:
> 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]).
Something in Damian's talk this morning reminded me that:
void Ficp400::SaveRow(long p_row) {
when row_is_deleted { }
...
}
Will do a magic return. I do wonder if it'll simply return from
SaveRow, or from the innermost enclosing C
--
Piers
Re: printf-like formatting in interpolated strings
--- arcadi shehter <[EMAIL PROTECTED]> wrote:
> Luke Palmer writes:
>
> >
> > As far as the syntax, the () and {} don't make a lot of sense with
> > regard to the rest of the language. We could either utilize the
> > string/numeric context distinction that already exists in {} and
> []
> > for subscripting, or we could always use () in analog to $().
> >
> > I'd like to have that dollar in there somewhere, actually.
> >
> > "The value in hex is \Fx$( expression )."
> >
> > Or something. That is kinda clunky, though. Maybe just a
> > stringification adverb, albeit verbose (but more versatile):
> >
> > "The value in hex is $( expression where format('x') )"
> >
> > No, I actually think that should be a property. In fact, one that
> has
> > been discussed before:
> >
> > "The value in hex is $( expression but formatted('x') )"
> >
> > That's actually my favorite so far.
> >
> but maybe cleaner way is to have a predefined function which can be
> passed modifyers
>
How about a pre- or user- defined function that just does sprintf?
"The values are $( sprintflike($format-string, @values))"
Now, if you want to talk about the cool amazing formatting syntax
you've conceived for sprintf replacement, that's fine. But I'm getting
that warm cozeny feeling that this is burning unnecessary listmips.
(Note: In the spirit of the "regex as generator" discussion of a few
months back, I'd love to hear about a rule [production?] based approach
to output formatting...)
=Austin
Re: printf-like formatting in interpolated strings
Austin Hastings <[EMAIL PROTECTED]> writes: > Now, if you want to talk about the cool amazing formatting syntax > you've conceived for sprintf replacement, that's fine. But I'm getting > that warm cozeny feeling that this is burning unnecessary listmips. Well, it's a bike shed. But it is a bike shed people use all the time. The world cannot be run by nuclear scientists alone. If you don't think it's worth talking about such things, install a mail filter which deletes all mails not containing the word 'paradigm'. -Edwin
Re: printf-like formatting in interpolated strings
[EMAIL PROTECTED] (Edwin Steiner) writes: > Well, it's a bike shed. Perhaps best not to have people expend lots of energy painting bike sheds until the nuclear reactor's anywhere near functional, though. I think the whole thing can be done, in whatever style people would like, using whatever natty syntax, by means of $( ), overloaded string constants, or, heaven forbid, a purpose-built grammar rule override for double-quoted strings. When we have any one of those things. And I would go so far as to say that since we have proposals for three different ways to allow people to do it precisely how they like, we don't need to discuss a way to do it in the core language. At least, certainly not yet. But then I'm one of those freaks who likes the idea of keeping core Perl 6 generic, extensible, clean and small, and letting all the clever stuff go into extensions, a heretical position which is way out of favour with the more influential listfolk, so feel free to ignore my opinion. > But it is a bike shed people use all the time. Agreed, I suppose. % grep printf cvs/modules/**/*pm | wc -l 15 % grep -v printf cvs/modules/**/*pm | wc -l 15360 Well, 0.1% agreed, anyway. -- Putting a square peg into a round hole can be worthwhile if you don't mind a few shavings. -- Larry Wall
Re: printf-like formatting in interpolated strings
On 2003-06-16 at 17:48:58, Simon Cozens wrote: > % grep printf cvs/modules/**/*pm | wc -l > 15 > % grep -v printf cvs/modules/**/*pm | wc -l > 15360 > > Well, 0.1% agreed, anyway. Now, now, that's hardly a fair comparison. Maybe if you grepped for lines that contain "print" but not "printf", or simply did a grep -l to count the number of modules that use printf at all anywhere . . . I think output formatting is a logical thing to have in the core. It was the first thing Perl was used for, after all. I don't think we need a special magical way of doing it inside an interpolation context, though. I think the less interpolation magic, the better, and there's already a lot which can go away once we have $( arbitrary expression ). I think $( sprintf ) is more than adequate. The sprintf syntax could perhaps stand to be shorter. It is unfortunate that Perl's string/number duality would make it at the very least awkward to adopt the Python/Ruby overloaded % operator, which I otherwise like. Perhaps we could, by analogy with uc() and lc(), introduce an sf() alias? -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Friday, June 13, 2003, at 10:26 PM, David Storrs wrote: On the subject of untyped scalars...what does it mean to say that the conversion is 'lossless'? For example: I've been using the word to mean that a conversion is "lossless" if, for a particular A-->B conversion, you can recreate the typed value A *completely* from B, including value, definedness, and properties. So if you can say A-->B-->A, and always get _exactly_ the same thing in A that you started with, for _any_ valid starting value of A, it's "lossless". Which is darn rare, looking at the matrix, because of range issues, etc. my $a = 'foo'; my Int $b = $a; # legal; $b is now 0; is there a warning? my $c = $b; # is $c 0, or 'foo'? 0, I think. Or specifically, C. (I've been operating under the assumption that an "untyped scalar" doesn't _remove_ the type of something, it just can store values of _any_ type, and is by default much more generous about autoconverting them for you, so that you could use $c as an Int, int, Num, num, Str, str, etc., without warning or error... but internally, it's actually still storing the value as an C, because that's what you assigned to it.) my Str $d = $a; # no loss my $a = $d; # no effective change in $a my $e = $b; # what is $d? $d? Still a Str, I would think. And $e would be Int 0, same as $c 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'.) My understanding is that properties go with the values, (just like traits go with the variables), so I would expect $f to be C<7 but false>. So if a value is C, it stays C until you say otherwise. Are any warnings emitted? Yeah, I dunno. I think we need somebody smart to tell us at this point. I have no idea how close or how far we are on our musings about pragmas and defaults... I sure hope somebody does. :-) MikeL
Re: printf-like formatting in interpolated strings
Simon Cozens <[EMAIL PROTECTED]> writes: > % grep printf cvs/modules/**/*pm | wc -l > 15 > % grep -v printf cvs/modules/**/*pm | wc -l > 15360 > > Well, 0.1% agreed, anyway. Could also mean the current printf syntax is not too popular. Reusable code is also less likely to use it than the day-to-day code one writes anew each time (being annoyed about printf). There should be guidelines about what postings are appreciated on perl6-language. I'd happily obey them. dev.perl.org says Description: This list is for discussing user-visible changes to the language. It's somewhat unnerving to post on topic and (hopefully) politely and get a cold (less on topic) reply from someone with "warm feelings". On the other hand the sharks might miss the occasional bite... regards -Edwin
