[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 addressin
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 specifica
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
--- 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 locat
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 Money
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
--- 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:
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.
--- 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 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;
> $
[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 l
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
> mo
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
> disp
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 ana
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 lik
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.)
ru
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
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
> []
> >
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 s
[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 natt
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 "pri
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 type
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
30 matches
Mail list logo
