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
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.
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
[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 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;
> $
--- 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: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.
--- 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 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
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
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:
> 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
--- 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
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"
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
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
[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:
> % 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
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
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
[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
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
--- 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
> []
> >
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)
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 $().
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]
>
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
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
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
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
30 matches
Mail list logo
