I've been working on, uh, let's call it a "Perl 6 emulator" recently,
and I've come unstuck about a few things.
I'm sure I'll think of some more questions, but here we go for now:
Should properties interpolate in regular expressions? (and/or strings) I
don't suppose they should, because we don't
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>I'm not entirely sure of that one--processing a full regex requires the
>perl interpreter, it's not all that modular. Though whether being able to
>yank out the RE engine and treat it as a standalone library is important
>enough to warrant being treat
Before people get their panties in a bunch, I'm not dissing Unicode. The point
that I am trying to make is that Unicode will probably never make everyone
happy. It WILL likely become widely accepted, and should offer the best
solution yet to integrating the major character sets into one.
> If the
On Wed, Jun 06, 2001 at 07:28:45AM -0400, NeonEdge wrote:
> If that was the goal, then they failed.
Oh, for heaven's sake, don't be silly. Our goal is to write Perl 6.
We haven't done that yet. That was our goal, so we failed?
--
"IT support will, from 1 October 2000, be provided by college and
Michael G Schwern wrote:
> It will have to go for strict classes. @ISA will have to be locked.
"strict classes"?
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> This definately can't work if $obj is of a class which is strongly
> typed.
"strongly typed class"?
> This can
At 06:59 PM 6/5/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 04:44 PM 6/5/2001 -0700, Larry Wall wrote:
>: >(Perl 5 extends it all the way to 64-bit values, represented in 13 bytes!)
>:
>: I know we can, but is it really a good idea? 32 bits is really stretching
>: it for character en
Russ Allbery writes:
: Yeah, but one of the guarantees of UTF-8 is:
:
:- The octet values FE and FF never appear.
:
: I can see that this property may not be that important, but it makes me
: feel like things that don't have this property aren't really UTF-8.
Which is one of the reasons I
Dan Sugalski writes:
: At 06:59 PM 6/5/2001 -0700, Larry Wall wrote:
: >Such large values would not typically be used for standard characters, but
: >as a means of embedding an inline chunk of non-character data, such as a
: >pointer, or a set of metadata bits.
:
: Ah. In that case, perhaps exten
Dan Sugalski wrote:
>
> I've been
> assuming that an Anything->Unicode translation will be lossless, but this
> makes me wonder whether that assumption is correct.
I seem to recall from reading articles on this issue that the issue is
encoding of arrangement: Even with an unlimited number of g
> So, to match $foo's colour against $bar, I'd say
>
> $bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
> Great, but how do I match $foo followed by any character followed by the
> literal "colour"?
$bar =~ /
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote:
>
>> So, to match $foo's colour against $bar, I'd say
>>
>> $bar =~ /$foo.colour/;
>
> No, you need the sub call parens as well:
>
> $bar =~ /$foo.colour()/;
Hm, I thought Larry said you would need to use
> >> So, to match $foo's colour against $bar, I'd say
> >>
> >> $bar =~ /$foo.colour/;
> >
> > No, you need the sub call parens as well:
> >
> > $bar =~ /$foo.colour()/;
>
> Hm, I thought Larry said you would need to use $() to interpolate
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote:
>
>> >> So, to match $foo's colour against $bar, I'd say
>> >>
>> >> $bar =~ /$foo.colour/;
>> >
>> > No, you need the sub call parens as well:
>> >
>> > $bar =~ /$foo.colour()/;
[EMAIL PROTECTED] writes:
:> What should $foo = (1,2,3) do now? Should it be the same as what
:> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
:> $foo = \@INC; does now.) Putting it another way: does a list in scalar
:> context turn into a reference, or
> But with the above you still have abiguity, for example what does this do
>
> $bar =~ /$foo.colour($xyz)/;
"Looks like a method call with parens, so *is* a method call with parens."
> I may be remembering about interpolation into strings as "$file.ext" is
> going t
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
>> But with the above you still have abiguity, for example what does this do
>>
>> $bar =~ /$foo.colour($xyz)/;
>
> "Looks like a method call with parens, so *is* a method call with parens."
>
>
>> I may
> > But it's not as *convenient* as "unadorned" interpolation.
>
> Sometimes convenient has to give way
Here we differ. I think the frequency of the
/$var.ident(whatever)/
pattern is likely to be low enough that method interpolation is a
better use for the syntax.
> > Exp
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
> But it's not as *convenient* as "unadorned" interpolation.
Disagree. "Adorning" a piece of syntax reminds the programmer that
something out of the ordinary is happening. It's a mental speed limit
sign - a traffic light, if you like
Russ Allbery wrote:
>
> a caseless character wouldn't show up in
> either IsLower or IsUpper.
maybe an IsCaseless is warrented -- or Is[Upper|Lower]
could return UNKNOWN instead of TRUE|FALSE, if the
extended boolean attributes allow transbinary truth values.
David L Nicol <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> a caseless character wouldn't show up in either IsLower or IsUpper.
> maybe an IsCaseless is warrented -- or Is[Upper|Lower] could return
> UNKNOWN instead of TRUE|FALSE, if the extended boolean attributes allow
> transbinary tru
On Wed, Jun 06, 2001 at 09:57:58AM -0400, NeonEdge wrote:
> Perl 6 cannot assume that Unicode is done.
Don't tell anyone, but it never did.
--
Thus spake the master programmer:
"After three days without programming, life becomes meaningless."
-- Geoffrey James, "The Tao
> Oh, for heaven's sake, don't be silly. Our goal is to write Perl 6.
> We haven't done that yet. That was our goal, so we failed?
Don't be ridiculous. With that as our goal, the ONLY way we could fail is to
NEVER write Perl 6. Unicode, on the other hand, was originally released for
public consum
On Wed, Jun 06, 2001 at 09:06:09AM -0400, NeonEdge wrote:
> > Oh, for heaven's sake, don't be silly. Our goal is to write Perl 6.
> > We haven't done that yet. That was our goal, so we failed?
>
> Don't be ridiculous. With that as our goal, the ONLY way we could fail is to
> NEVER write Perl 6.
David L. Nicol wrote:
> it isn't currently in 5.6.1's
>
> bool
> Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen)
>
> function (contrary to what John Porter said)
Huh? What did I say?::
--
John Porter
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thi
On Tue, 5 Jun 2001, Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote:
> > I cannot imagine running an enterprise critical application
>
> As a complete digression, can we please strike the term "enterprise"
> from the English lexicon? Completely r
Damian Conway wrote:
> I very much doubt Perl is going to become significantly more statically
> analyzable in general. Though static determinacy is obviously a
> desirable thing, there are plenty of other B&D
Bondage and Discipline?
> languages that offer it
> in abundance. And the dynamic pow
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
> print $a->{test2};
Oh, hrm. Shouldn't it be $a{test2}? That works too, at any rate.
Does that mean that arrow between variable and subscript is optional,
or should this be some kind of error? Or should it mean something else
alt
"Daniel S. Wilkerson" <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > No subroutine refs. No dynamic inheritance. No autoloading. No
> > dynamic method calls. No symbol table manipulation. No eval. No
> > automatic method generation. (That's off the top of my head).
>
> You don'
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Consider the following... Foo is a poster-child for a strict class.
> Everything is predeclared and typed. Its entire hierarchy is rock
> solid. Someone uses Foo in their script and calls Foo->bar. They
> also use Bar, a module you installed a lon
Since this thread made it into this week's Official Perl6 Summary,
here goes a defense of C as a shorthand for the thing that last
had C or C queried of it.
It (by which I mean C, isn't this fun) would be a side-effect of
non-autovivifying queries. It allows redundant descents into arbitrarily
> Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should
> I don't suppose they should, because we don't expect subroutines to.
> (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we ne
Thanks *very* much for your answers; I still have a lot of work left
to do, it seems. But I'm still a little confused:
On Thu, Jun 07, 2001 at 06:08:23AM +1000, Damian Conway wrote:
>> Should properties interpolate in regular expressions? (and/or strings)
> Do you mean property look-ups via t
On Wed, Jun 06, 2001 at 02:20:25PM -0500, David L. Nicol wrote:
> this is a confusing hack that might not save any cycles.
Please don't try defending "it" or "$^d" in terms of efficiency;
any variable that Perl has to keep track of magically takes a
performance hit. Remember $`, $', and $&?
--
Graham Barr <[EMAIL PROTECTED]>:
>On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
>> [EMAIL PROTECTED] writes:
>> :> What should $foo = (1,2,3) do now? Should it be the same as what
>> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
>> :> $foo =
Damian Conway wrote:
> $ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
Me wrote:
>
> > [strict typing]
> >
> > Not a negative, but realize that many people find it
> > of less value than the annoyances it brings with it
> > (myself included)
>
> Michael, I don't know which is more impressive; the
> fact that use of a strictly typed language implies that
> a copy of
Me wrote:
> I.Found your notion of a "sealed off namespace"
> intriguing. I have no idea what it meant just yet;
> I'm going to go read and think about it now.
I'll pitch some syntax:
# prevent modification to %reflexive:: like so:
package reflexive is closed;
# allow i
Me wrote:
>
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
>
> Right?
it is already detectable. from perldoc perlref:
Perl will raise an except
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote:
> On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
> > Can someone post a few ? I am open to what are the pros/cons
> > but right now my mind is thinking " Whats the benefit of making
> > $a=(1,2,3); be the same as $a=[1,2,3
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> :> What should $foo = (1,2,3) do now? Should it be the same as what
> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
> :> $foo = \@INC; does now.) Putting it another
On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
> Can someone post a few ? I am open to what are the pros/cons
> but right now my mind is thinking " Whats the benefit of making
> $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something
> different, ie what it does in perl5"
Simon Cozens wrote:
> Please don't try defending "it" or "$^d" in terms of efficiency;
> any variable that Perl has to keep track of magically takes a
> performance hit. Remember $`, $', and $&?
No, this datum is already known by defined() and exists() all I
am suggesting is a name for the Perl
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> Damian Conway wrote:
> > $ref.{a}can be $ref{a}
> which can also be
> $ref.a
Dereferencing a hashref is the same as accessing a property?
I hope not.
--
Did you know that 1 barn yard atmosphere = 9.
On Wed, Jun 06, 2001 at 07:21:19PM -0500, David L. Nicol wrote:
> No, this datum is already known by defined() and exists() all I
> am suggesting is a name for the Perl API name for it.
Sorry, I didn't read your original post thoroughly enough; yes,
one for defined and exists would be feasible,
> [strict typing]
>
> Not a negative, but realize that many people find it
> of less value than the annoyances it brings with it
> (myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor un
46 matches
Mail list logo
