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
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:
Edwin Steiner [EMAIL PROTECTED] writes:
The rule could be like:
\\F printf_format_without_percent funny_character_expression
After-afterthought:
We know: Everything between the \F and the next funny character is the
format specifier. This allows extensions to the printf-specifiers:
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,
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]
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 $().
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)
{
--- 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
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
[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
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
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
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
[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
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
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, CInt
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,
--- 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;
--- 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
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
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
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
--- 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
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
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;
[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
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
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.
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
29 matches
Mail list logo
