Juerd wrote:
But will they also see "foo" ~ $bar as something different from
"foo$bar"?
They ought to, since the two are different in Perl 5.
For example:
my @bar = 'bar';
print "[EMAIL PROTECTED]";
print "foo[" . @bar . "]baz\n";
And what context does "foo{ $bar }" use?
Strin
Damian Conway skribis 2005-09-24 8:31 (+1000):
> >In my opinion, making the string value in interpolation different from
> >the value in Str context is madness.
> It's dwimmery.
It's dwymmery, or dwdmmery indeed. Not at all what I mean, am likely to
mean, or will ever mean.
> Which often looks l
Damian Conway skribis 2005-09-24 8:31 (+1000):
> They ought to, since the two are different in Perl 5.
> For example:
> my @bar = 'bar';
> print "[EMAIL PROTECTED]";
> print "foo[" . @bar . "]baz\n";
This does not compare stringification to interpolation. It compares
scalarification t
On Sun, Sep 25, 2005 at 12:52:08PM +0200, Juerd wrote:
> Hackers on this list, what do you think?
I think separating the two is extremely confusing. I do not see any uses
for it, but maybe I am not thinking hard enough.
--
wolverian
signature.asc
Description: Digital signature
On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote:
> Damian Conway skribis 2005-09-24 8:31 (+1000):
> > >In my opinion, making the string value in interpolation different from
> > >the value in Str context is madness.
> > It's dwimmery.
>
> It's dwymmery, or dwdmmery indeed. Not at all what I m
Hi,
Suppose I'm writing a file browser, with a pane on the left to
display the filesystem hierarchy, and a frame on the right to
preview the file.
Suppose I have a convenience function, preview_file which takes a
path and returns a value that the frame display view knows to
render.
Let's define
In order to support continuable exception generators, here is a
style guide for exception values, and an observation on what
exceptions should support at the language level:
* Exceptions should preserve data
All exceptions should contain as much of the original data that
caused them...
With Luke
On Sun, Sep 25, 2005 at 18:11:22 +0300, Yuval Kogman wrote:
> In order to support continuable exception generators, here is a
> style guide for exception values, and an observation on what
> exceptions should support at the language level:
And more...
* Exception strings are for humans
Humans ne
To ease the understanding of exactly how this might work, assume
that perl 6 is really all continuation passing style under the
surface (parrot is ;-).
use fatal;
my $x = do_bar();
do_foo();
sub do_bar {
fail "bah";
}
The way CPS works is r
Hmm... Making up these subjects is fun =)
Anywho...
Since type inferrencing is going to make into Perl 6, and
allomorphism is very richly supported by the type system, i'm
wondering on the nature of the optionality...
What excatly do the users get to control? Are functions with '-->'
rich type s
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I propose a new model - each exception has a continuation that
> allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of "use fatal", it makes a lot more sense.
Something comes to mind:
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote:
> > Damian Conway skribis 2005-09-24 8:31 (+1000):
> > > >In my opinion, making the string value in interpolation different from
> > > >the value in Str context is madness.
> > > It's dwimmer
On 9/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> [...]
> Exactly which exception is continued?
> [...]
Named restarts in Common Lisp appear to try to solve a related
problem, if I'm skimming this thread correctly. :-) (see [1]).
Michael
[1]
http://www.supelec.fr/docs/cltl/clm/node312.html#SE
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Hmm... Making up these subjects is fun =)
Very interesting. :)
> Under strict type inferrencing, i'd expect this to be a compile time
> error:
>
> my $dog = Dog.new;
>
> if ($condition) {
> my Cat $c = $dog;
>
On 9/25/05, Ashley Winters <[EMAIL PROTECTED]> wrote:
> On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > Under strict type inferrencing, i'd expect this to be a compile time
> > error:
I quoted but didn't read close enough. You DID say strict type
inferencing. Never mind. :)
Ashley Winters
On Sun, Sep 25, 2005 at 10:59:38 -0700, Ashley Winters wrote:
> The Stringification of a UnixEpochTimestamp should probably be the
> same as its Integerization -- 12345678900. However, the Interpolation
> of it should be the locale-specific POSIX-style datetime string.
Why? What value does the st
On Sun, Sep 25, 2005 at 11:32:54 -0600, Luke Palmer wrote:
> Exactly which exception is continued?
...
> This comes up again with open(). So it's somewhere in between.
> Where?
For the open() example I don't have a solution but I know in what
direction to throw it: the same thing that makes croa
On Sun, Sep 25, 2005 at 11:24:05 -0700, Ashley Winters wrote:
> I can't accept that. While you can infer that $dog will be a Dog at
> that line of code, it isn't being enforced, which means no
> compile-time error. $dog is allowed to store any kind of data, and you
> only know what methods exist in
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 25, 2005 at 10:59:38 -0700, Ashley Winters wrote:
>
> > The Stringification of a UnixEpochTimestamp should probably be the
> > same as its Integerization -- 12345678900. However, the Interpolation
> > of it should be the locale-speci
Yuval Kogman skribis 2005-09-25 21:34 (+0300):
> > if $color.as(Str) eq '#FF00FF' and "$color" eq "magenta" {
> > $Ashley++;
> > }
> $color.hex_triplet; # no alpha
> $color.name; # if we have one... or we can try to make one up (#ff0033 is
> bluish red ;-)
We can do better than equivalence test
Ashley Winters skribis 2005-09-25 12:26 (-0700):
> It's not a Date, it's a UnixEpochTimestamp.
That is precisely the flaw. Are you honestly likely to have that class?
If you really need an unix epoch timestamp, wouldn't you just use a very
simple integer for that? Because that's what it *is*, b
On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> We can do better than equivalence testing for colors. Instead, try to
> match. Surely a *smart* match operator really is smart?
>
> $color ~~ '#FF00FF'
>==
> $color ~~ 'magenta'
>==
> $color ~~ [ 255, 0, 255 ]
Hmm.
* wolverian ([EMAIL PROTECTED]) [050925 11:57]:
> On Sun, Sep 25, 2005 at 12:52:08PM +0200, Juerd wrote:
> > Hackers on this list, what do you think?
>
> I think separating the two is extremely confusing. I do not see any uses
> for it, but maybe I am not thinking hard enough.
Of course, having
Mark Overmeer skribis 2005-09-25 17:28 (+0200):
> Stringification/Numification should be used to let an object play its
> natural role within the program.
Agreed, but...
> For instance, some "Temperature" object producing 273 when compared to
> the melting point of water.
That's for numeric cont
Whenever possible, object should have useful numeric and string
representations. These are generally lossy, but this is not a problem, because
a scalar stays a scalar even after being used in a certain context, and the
object isn't lost.
When a protocol or data format that already has a string for
In a private conversation with Larry this afternoon, he said that by
default "$foo" and ~$foo and $foo.as(Str) all give the same result
(assuming scalar context, etc.). And that "@foo[]" and [EMAIL PROTECTED] and
@foo.as(Str) are the same as join(' ', @foo) where join is effectively:
sub join
On 9/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> > We can do better than equivalence testing for colors. Instead, try to
> > match. Surely a *smart* match operator really is smart?
> >
> > $color ~~ '#FF00FF'
> >==
> > $color ~~
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > In order to enforce that level of compile-time type safely, you should
> > need to declare my Dog $dog, or stick a pragma up top:
>
> That's the point of my question - why? What do I lose by
> inferrencing?
Nothing that I see. I recant my arg
On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> Whenever possible, object should have useful numeric and string
> representations. These are generally lossy, but this is not a problem, because
> a scalar stays a scalar even after being used in a certain context, and the
> object isn't lost.
Sounds
29 matches
Mail list logo
