>> And, if this is so, then isn't it impossible to have useful
>> stricture about variable properties, because any given
>> reference to a property might be instead a value property
>> unknown to the compiler?
>
> Yes.
So:
You can't have (variable or value) property strictur
> So, is it right to say that one can't use stricture to avoid
> use of mistyped user defined value attached properties?
> (Perhaps with the exception of references to a value
> property in the same lexical scope as assignments of
> that value?)
>
> And, if this is so, then i
>> Consider the code:
>>
>> my $foo = 1 is Found;
>> &bar($foo);
>>
>> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>>
>> Does the value of $baz have the Found property?
>
> Yes.
>
>> If so, does the compiler know that?
>
> No. Because i
> Consider the code:
>
> my $foo = 1 is Found;
> &bar($foo);
>
> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>
> Does the value of $baz have the Found property?
Yes.
> If so, does the compiler know that?
No. Because it only has the property at
Larry Wall <[EMAIL PROTECTED]> writes:
> Russ Allbery writes:
>> Particularly since extending UTF-8 to more than 31 bits requires
>> breaking some of the guarantees that UTF-8 makes, unless I'm missing
>> how you're encoding the first byte so as not to give it a value of
>> 0xFE.
> The UTF-16 BO
> On Tue, Jun 05, 2001 at 04:38:24PM -0500, 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?
>
> Can't you hear the
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 encoding, and 64 seems rather excessive.
Such large
>> Question 2:
>>
>> 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 could certainly warn you
Consider the code:
my $foo = 1
Russ Allbery writes:
: Particularly since extending UTF-8 to more
: than 31 bits requires breaking some of the guarantees that UTF-8 makes,
: unless I'm missing how you're encoding the first byte so as not to give it
: a value of 0xFE.
The UTF-16 BOMs, 0xFEFF and 0xFFFE, both turn out to be illeg
> 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.
It could certainly warn you, but it can't object fatally since there's
always the p
At 07:40 AM 6/5/2001 -0700, Dave Storrs wrote:
>On Tue, 5 Jun 2001, Dave Mitchell wrote:
>
> > dispatch loop. I'd much rather have a 'regex start' opcode which
> > calls a separate dispath loop function, and which then interprets any
> > further ops in the bytestream as regex ops. That way we doub
At 04:44 PM 6/5/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Have they changed that again? Last I checked, UTF-8 was capped at 4 bytes,
>: but that's in the Unicode 3.0 standard.
>
>Doesn't really matter where they install the artificial cap, because
>for philosophical reasons Perl is go
On Tue, Jun 05, 2001 at 04:44:46PM -0700, Russ Allbery wrote:
> NeonEdge <[EMAIL PROTECTED]> writes:
>
> > This is evident in the "Musical Symbols" and even "Byzantine Musical
> > Symbols". Are these character sets more important than the actual
> > language character sets being denied to the ot
On Tue, Jun 05, 2001 at 04:44:46PM -0700, Russ Allbery wrote:
> In the meantime, the normally-encountered working character set of modern
> Asian languages has been in Unicode from the beginning, and currently the
> older and rarer characters and the characters used these days only in
> proper nam
Russ Allbery <[EMAIL PROTECTED]> writes:
> That's probably unnecessary; I really don't expect them to ever use all
> 31 bytes that the IETF-standardized version of UTF-8 supports.
31 bits, rather. *sigh*
But given that, modulo some debate over CJKV, we're getting into *really*
obscure stuff al
Larry Wall <[EMAIL PROTECTED]> writes:
> Doesn't really matter where they install the artificial cap, because for
> philosophical reasons Perl is gonna support larger values anyway. It's
> just that 4 bytes of UTF-8 happens to be large enough to represent
> anything UTF-16 can represent with sur
Dan Sugalski writes:
: Have they changed that again? Last I checked, UTF-8 was capped at 4 bytes,
: but that's in the Unicode 3.0 standard.
Doesn't really matter where they install the artificial cap, because
for philosophical reasons Perl is gonna support larger values anyway.
It's just that 4
NeonEdge <[EMAIL PROTECTED]> writes:
> This is evident in the "Musical Symbols" and even "Byzantine Musical
> Symbols". Are these character sets more important than the actual
> language character sets being denied to the other countries? Are musical
> and mathematical symbols even a language at
The problem as I see it, is not that the mechanism can't handle the languages,
it is that the Latin/Gothic countries chose first, and gave what's left to the
Oriental countries.
This is evident in the "Musical Symbols" and even "Byzantine Musical Symbols".
Are these character sets more important
On Tue, Jun 05, 2001 at 11:14:29PM +0100, Michael G Schwern wrote:
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> I'm probably using the wrong terms.
>
> This definately can't work if $obj is of a class which is strongly
> typed.
You would do that in Java by using reflection.
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, Jun 05, 2001 at 03:27:03PM -0700, Russ Allbery wrote:
>> Caseless characters should be guaranteed unchanged by conversion to
>> upper or lower case, IMO.
> I think Bryan's asking more about \p{IsUpper} than uc().
Ahh... well, Unicode classifies
On Tue, Jun 05, 2001 at 03:27:03PM -0700, Russ Allbery wrote:
> Caseless characters should be guaranteed unchanged by conversion to upper
> or lower case, IMO.
I think Bryan's asking more about \p{IsUpper} than uc().
--
Henry, I'm a Regent Master of the Ancient and Venerable House of Congregati
On Tuesday 05 June 2001 05:49 pm, Simon Cozens wrote:
> YES. Definitely. Same Unicode character, same thing. You wanted something
> else, use a different Unicode character.
I don't understand. There *is* only one character. I can't choose another.
Take 0x0648, for instance. It's both waw, th
On Tue, Jun 05, 2001 at 04:38:24PM -0500, 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?
Can't you hear the low roar from the strong-
On Tue, Jun 05, 2001 at 03:29:02PM -0700, Daniel S. Wilkerson wrote:
> It would be interesting for someone to measure that, however I doubt that it
> is so.
Oh, and look at what just showed up in my mailbox!
- Forwarded message from Tony Bowden <[EMAIL PROTECTED]> -
I think we should st
On Tue, Jun 05, 2001 at 05:49:30PM -0400, John Porter wrote:
> > By preventing lots of little gotchas, you free the mind to pay attention
> > to what it is doing rather than the most minute details of how to do
> > it. This is a quite powerful effect.
>
> Interesting you should mention this.
> I
At 03:21 PM 6/5/2001 -0700, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > At 12:40 PM 6/5/2001 -0700, Russ Allbery wrote:
>
> >> (As an aside, UTF-8 also is not an X-byte encoding; UTF-8 is a variable
> >> byte encoding, with each character taking up anywhere from one to six
>
Bryan C Warnock <[EMAIL PROTECTED]> writes:
> Some additional stuff to ponder over, and maybe Unicode addresses these
> - I haven't been able to read *all* the Unicode stuff yet. (And, yes,
> Simon, you will see me in class.)
> Some languages don't have upper or lower case. Are tests and
> tra
John Porter wrote:
> Daniel S. Wilkerson wrote:
> > It is doubtful we shall have compilers that can tell you for example,
> > that you used the wrong algorithm.
>
> Right. I think that's what Schwern was getting at, when he said
> > > > > Type checking is nice, but its just one class of error-ch
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 12:40 PM 6/5/2001 -0700, Russ Allbery wrote:
>> (As an aside, UTF-8 also is not an X-byte encoding; UTF-8 is a variable
>> byte encoding, with each character taking up anywhere from one to six
>> bytes in the encoded form depending on where in Unicode
On Tue, Jun 05, 2001 at 02:39:33PM -0700, Daniel S. Wilkerson wrote:
> Thank you, that's what I thought it might be. This can be done at
> compile time with a two-stage compilation. The first one writes the
> code that the second compiles. Then the checking can be done during
> the second stage
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 redundant and drives me up the
wall. Almost as bad as "eco
Daniel S. Wilkerson wrote:
> It is doubtful we shall have compilers that can tell you for example,
> that you used the wrong algorithm.
Right. I think that's what Schwern was getting at, when he said
> > > > Type checking is nice, but its just one class of error-checking.
> By preventing lots
On Tue, Jun 05, 2001 at 05:39:36PM -0400, Bryan C . Warnock wrote:
> Some languages don't have upper or lower case. Are tests and translations
> on caseless characters true or false? (Or undefined?)
I'd say undefined.
> Should the same Unicode character, when used in two different languages
At 02:39 PM 6/5/2001 -0700, Daniel S. Wilkerson wrote:
>Thank you, that's what I thought it might be. This can be done at compile
>time with a two-stage
>compilation. The first one writes the code that the second
>compiles. Then the checking can be
>done during the second stage.
Not when the
I apologize. I royally screwed up my original post.
I had meant to ask two minor specific yes/no answer
type questions about properties and stricture, that
were mutually unrelated. Instead I asked one major
open ended one.
In the hope that I haven't completely blown any
chance of getting answers
On Tuesday 05 June 2001 03:24 pm, Dan Sugalski wrote:
> > > The second objection is again related to character versus glyph
> > > issues: since Chinese,
> >
> >I think this problem =~ locale. For any unicode character, you can not
> >properly tell its lower case or upper case without considering
Daniel S. Wilkerson wrote:
> If you call a method in Java, you can see right there which method you are
> calling.
> You can then lexically follow the inheritance tree and find out exactly
> what code really is called, what its signature is, and what it returns.
> Nothing dynamic is involved.
Pre
Thank you, that's what I thought it might be. This can be done at compile time with a
two-stage
compilation. The first one writes the code that the second compiles. Then the
checking can be
done during the second stage.
Daniel
Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 01:42:38PM
I flatter myself that I understand your point. It is doubtful we shall
have compilers that can tell you for example, that you used the wrong
algorithm.
However, perhaps I did not express my point as well as I could have. I
include the quote from Whitehead again, along with some others.
"By rel
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote:
> Someone please tell me what automatic method generation is exactly.
package Foo;
sub AUTOLOAD {
my $method = $AUTOLOAD;
eval "sub $method { warn qq/Please do not call this method again.\n/ }"
goto &$method;
}
--
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote:
> Someone please tell me what automatic method generation is exactly.
Its the generation of large numbers of similar methods which would
otherwise be really tedious to write out by hand, such as accessor
methods. Without this,
On Tue, Jun 05, 2001 at 03:31:24PM -0500, David L. Nicol wrote:
> Graham Barr wrote:
>
> > I think there are a lot of benefits to the re engine not to be
> > separate from the core perl ops.
>
>
> So does it start with a split(//,$bound_thing) or does it use
> substr(...) with explicit offsets?
If you call a method in Java, you can see right there which method you are
calling. You can then lexically follow the inheritance tree and find out exactly
what code really is called, what its signature is, and what it returns. Nothing
dynamic is involved.
One might ask for other featues, but I
Daniel S. Wilkerson wrote:
> Michael G Schwern wrote:
> > Type checking is nice, but its just one class of error-checking.
> > Doesn't do squat for basic logic errors, for example.
>
> No, it does.
I think you're missing what ought to be an obvious point:
No amount of (sane) typing will allow y
> I would like to see some sort of "use really_strict" pragma which would
> disable at compile time the kinds of things you mentioned:
Yes, the point is to make this possible, not required. I thought Perl was
supposed to make "hard things possible." This is easy in Java and its not
even possibl
Daniel S. Wilkerson wrote:
> I can't imagine any way in which one can consider Perl typing to be "strong".
> When you know the type of a variable, you are supposed to have confidence
> that when you see a statement
> a - lexically locally (without looking around elsewhere) and
> b - at compile tim
Michael G Schwern [mailto:[EMAIL PROTECTED]] wrote:
> Of course, there's problems of order of definition. What happens if
> Bar.pm is loaded before Foo? Dunno.
simple sematics can be defined. If we see a declaration:
package Foo is encapulated;
then we throw an error if the namespace, Foo,
Graham Barr wrote:
> I think there are a lot of benefits to the re engine not to be
> separate from the core perl ops.
So does it start with a split(//,$bound_thing) or does it use
substr(...) with explicit offsets?
Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote:
> > But in the end, I'm most concerned that my code is correct. Having
> > the compiler check everything it can possibly check for me is really
> > a requirement for that. Compile time type checking
On Tue, Jun 05, 2001 at 01:05:45PM -0700, Daniel S. Wilkerson wrote:
> 2 - You can't make a user defined type, like classes in Java, that
> are compile time checked.
Well, you can sort of: Attribute::Types. But that's not what John is
talking about.
--
Michael G. Schwern <[EMAIL PROTECTED]
On Tue, Jun 05, 2001 at 02:37:11PM -0500, Garrett Goebel wrote:
> > Before anyone gets the wrong idea, I don't think the solution is a
> > drastic scaling back in Perl's flexibility. I just don't know what
> > the solution is yet. Maybe it should be possible for a class to
> > completely seal of
I can't imagine any way in which one can consider Perl typing to be "strong".
When you know the type of a variable, you are supposed to have confidence that
when you see a statement
a - lexically locally (without looking around elsewhere) and
b - at compile time
you know exactly what the statement
At 12:40 PM 6/5/2001 -0700, Russ Allbery wrote:
>Bart Lateur <[EMAIL PROTECTED]> writes:
> > UTF-8 is NOT limited to 16 bits (3 bytes).
>
>That's an odd definition of byte you have there. :)
Maybe it's RAD50. :) Still, it may take 3 bytes to represent in UTF-8 a
character that takes 2 bytes in
Bart Lateur <[EMAIL PROTECTED]> writes:
> On 05 Jun 2001 11:07:11 -0700, Russ Allbery wrote:
>> Particularly since part of his contention is that 16 bits isn't enough,
>> and I think all the widely used national character sets are no more
>> than 16 bits, aren't they?
> It's not really important
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
>
> Before anyone gets the wrong idea, I don't think the solution is a
> drastic scaling back in Perl's flexibility. I just don't know what
> the solution is yet. Maybe it should be possible for a class to
> completely seal off its namespace to
On Tue, Jun 05, 2001 at 02:42:01PM -0400, John Porter wrote:
> > You don't want to try holding up prototypes and dereference checks to
> > Java's typing system and try to claim its in the same league, or even
> > the same sport.
>
> As I said before, it boils down to the fact that perl's notion of
At 11:18 AM 6/5/2001 -0700, Hong Zhang wrote:
> > Firstly, the JIS standard defines, along with the ordering and
> > enumeration of its characters, their glyph shape. Unicode, on the other
> > hand does not. This means that as far as Unicode is concerned, there is
> > literally no distinction be
On Tue, Jun 05, 2001 at 09:16:05PM +0200, Bart Lateur wrote:
> Unicode "text" files
No such animal. Unicode's a character repertoire, not an encoding.
See you at my Unicode tutorial at TPC? :)
--
buf[hdr[0]] = 0;/* unbelievably lazy ken (twit) */ - Andrew Hume
On 05 Jun 2001 11:07:11 -0700, Russ Allbery wrote:
>Particularly since part of his contention is that 16 bits isn't enough,
>and I think all the widely used national character sets are no more than
>16 bits, aren't they?
It's not really important.
UTF-8 is NOT limited to 16 bits (3 bytes). With
Michael G Schwern wrote:
> > % perl -e '$r=\%h; print @$r'
> > Not an ARRAY reference at -e line 1.
>
> This isn't type-checking (semantical arguments > /dev/null),
Heed your own redirection, eh?
> its more like basic syntax.
No, it's not. If it were, then it would be caught at
compile time.
At 07:29 PM 6/5/01 +0100, Michael G Schwern wrote:
>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 lo
On Tue, Jun 05, 2001 at 12:46:52PM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > Prototypes don't work on methods. And I wouldn't hold them up as
> > being anything but a mediocre hack. Its not really type checking.
>
> It's not just prototypes.
>
> % perl -e '$r=\%h; print @$r'
> N
On Tue, Jun 05, 2001 at 07:33:55AM -0700, Dave Storrs wrote:
> (By 'strictly', I think you mean 'all methods (etc) are declared
> explicitly in code, not generated by AUTOLOAD, etc'. If I'm not
> understanding you correctly, please correct me.)
Yeah, pretty much. I put together a proof-of
> Firstly, the JIS standard defines, along with the ordering and
> enumeration of its characters, their glyph shape. Unicode, on the other
> hand does not. This means that as far as Unicode is concerned, there is
> literally no distinction between two distinct shapes and hence no way to
> specify
On Mon, Jun 04, 2001 at 06:04:10PM -0700, Larry Wall wrote:
> Well, other languages have explored that option, and I think that makes
> for an unnatural interface. If you think of regexes as part of a
> larger language, you really want them to be as incestuous as possible,
> just as any other par
Dan Sugalski <[EMAIL PROTECTED]> writes:
> It does bring up a deeper issue, however. Unicode is, at the moment,
> apparently inadequate to represent at least some part of the asian
> languages. Are the encodings currently in use less inadequate? I've been
> assuming that an Anything->Unicode tran
> Courtesy of Slashdot,
> http://www.hastingsresearch.com/net/04-unicode-limitations.shtml
>
> I'm not sure if this is an issue for us or not, as we're generally
> language-neutral, and I don't see any technical issues with any of the
> UTF-* encodings having headroom problems.
I think the au
On Tue, Jun 05, 2001 at 01:31:38PM -0400, Dan Sugalski wrote:
> The other issue it actively brought up was the complaint about having to
> share glyphs amongst several languages, which didn't strike me as all that
> big a deal either, except perhaps as a matter of national pride and/or easy
> id
On Tue, Jun 05, 2001 at 12:49:41PM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > If there's a class which isn't strictly defined anywhere in
> > your hierarchy, no go.
>
> For robust, mission-critical software, that can hardly
> be called a negative.
Not a negative, but realize that m
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things: firstly, we can make Perl 6 ops as lightweight as we like.
>
> Second, Rub
At 06:22 PM 6/5/2001 +0100, Simon Cozens wrote:
>On Tue, Jun 05, 2001 at 10:17:08AM -0700, Russ Allbery wrote:
> > Is it just me, or does this entire article reduce not to "Unicode doesn't
> > work" but "Unicode should assign more characters"?
>
>Yes. And Unicode has assigned more characters; it's
On Tue, 29 May 2001 18:25:45 +0100 (BST), Dave Mitchell wrote:
>diffs:
>
>-"K&R" style for indenting control constructs
>+"K&R" style for indenting control constructs: ie the closing C<}> should
>+line up with the opening C etc.
On Wed, 30 May 2001 10:37:06 -0400, Dan Sugalski wrote:
>I realize
On Tue, Jun 05, 2001 at 10:17:08AM -0700, Russ Allbery wrote:
> Is it just me, or does this entire article reduce not to "Unicode doesn't
> work" but "Unicode should assign more characters"?
Yes. And Unicode has assigned more characters; it's factually challenged.
--
And it should be the law: I
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Courtesy of Slashdot,
> http://www.hastingsresearch.com/net/04-unicode-limitations.shtml
Is it just me, or does this entire article reduce not to "Unicode doesn't
work" but "Unicode should assign more characters"?
The presentation initially made me thi
Michael G Schwern wrote:
> If there's a class which isn't strictly defined anywhere in
> your hierarchy, no go.
For robust, mission-critical software, that can hardly
be called a negative.
> Of course, it probably only works with strict functional languages,
> which is very unPerlish.
It could
Michael G Schwern wrote:
> Prototypes don't work on methods. And I wouldn't hold them up as
> being anything but a mediocre hack. Its not really type checking.
It's not just prototypes.
% perl -e '$r=\%h; print @$r'
Not an ARRAY reference at -e line 1.
Of course, that's a run-time check, but
On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote:
> But in the end, I'm most concerned that my code is correct. Having
> the compiler check everything it can possibly check for me is really
> a requirement for that. Compile time type checking of method
> signatures is really h
On Tue, Jun 05, 2001 at 11:51:53AM -0400, John Porter wrote:
> Perl has strong typing; it just has a different notion of
> what a "type" is. The "types" in Perl are SCALAR, ARRAY,
> HASH, CODE, and a few others. Watch:
>
> % perl -e 'sub foo(\@){} foo %h'
> Type of arg 1 to main::foo must be ar
> I would like to be able to use Perl for serious large-scale
> industrial-strength object-oriented projects, but the lack of strong
> compile-time type checking really prevents it, unfortunately.
Industrial-strength, as Chip says, is great, but also dangerous for pets
and small children.
Courtesy of Slashdot,
http://www.hastingsresearch.com/net/04-unicode-limitations.shtml
I'm not sure if this is an issue for us or not, as we're generally
language-neutral, and I don't see any technical issues with any of the
UTF-* encodings having headroom problems.
It does argue for abstract
Perl has strong typing; it just has a different notion of
what a "type" is. The "types" in Perl are SCALAR, ARRAY,
HASH, CODE, and a few others. Watch:
% perl -e 'sub foo(\@){} foo %h'
Type of arg 1 to main::foo must be array (not hash deref) at -e line 1, at EOF
Execution of -e aborted due to
I would like to suggest that this is one of the major advantages that Java
has over Perl. Getting things to "work" quickly in Perl is great. I like
that very much about Perl. But in the end, I'm most concerned that my code
is correct. Having the compiler check everything it can possibly check
As some of you may have noticed from the YAPC schedule[1], I'll be hosting
the "Perl Apprenticeship Hour" next week.
I'm STILL looking for brief descriptions of projects that are
looking for some help, including:
* documentation* tools
* tutorials* bugfixes
* modules *
On Tue, 5 Jun 2001, Dave Mitchell wrote:
> dispatch loop. I'd much rather have a 'regex start' opcode which
> calls a separate dispath loop function, and which then interprets any
> further ops in the bytestream as regex ops. That way we double the number
> of 8-bit ops, and can have all the re
On Tue, 5 Jun 2001 [EMAIL PROTECTED] wrote:
> So I'd say no, Perl can't know at compile-time if your method is
> declared or not. Only in certain restricted cases, such as if you
> don't inherit from anything, or if *all* your parent classes are
> declared strictly.
(By 'strictly', I
On Tue, 5 Jun 2001, Hugo wrote:
> I'd also like to see a specification for indentation when breaking long
> lines.
Fwiw, the style that I prefer is:
someFunc( really_long_param_1,
(long_parm2 || parm3),
really_long_other_param
Simon Cozens <[EMAIL PROTECTED]> opined:
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things: firstly, we can make Perl 6 ops as
David Grove <[EMAIL PROTECTED]> writes:
>> Perl is far more practical than experimental.
> Not at the moment. That's the problem.
Pretty much everything proposed, even in the wildest RFCs during the
brainstorming phase, was still stuff that's been done elsewhere by other
languages. That's the
On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> This is the bit that scares me about unifying perl ops and regex ops:
> can we really unify them without taking a performance hit?
Coupl'a things: firstly, we can make Perl 6 ops as lightweight as we like.
Second, Ruby uses a giant
Larry Wall <[EMAIL PROTECTED]> wrote:
> It may certainly be valuable to (not) think of it that way, but just
> don't be surprised if the regex folks come along and borrow a lot of
> your opcodes to make things that look like (in C):
>
>while (s < send && isdigit(*s)) s++;
This is the bit th
On Mon, Jun 04, 2001 at 06:49:28PM -0500, Me wrote:
> 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?
>
> Should there be a strict mode that warns if a
> method na
92 matches
Mail list logo
