IMHO type inference is the best way to get typing into Perl.
We don't lose any expressiveness or hurt backwards compatibility.
About the only thing we need to make visible are a few additional
pragmas to enable type inference warnings.
Steve Fink wrote:
> Types should be inferred whenever possibl
Steve Fink wrote:
> There are many possible goals for any typing-related stuff we do. I'd
> say the top three are:
>
> - compile-time warnings
>- definitely unsafe operations
>- probably unsafe operations
> - runtime storage optimization
> - runtime time optimization
Yes. The last two ar
John Tobey wrote:
> The Perl 5 (and older) behavior may preclude some optimizations.
I can't think of any optimizations @_ assignment precludes.
If we don't analyze dataflow to figure out if a sub modifies its
args, then we just assume it will.
Is this just a style issue? Why would you allow it
Nathan Wiger wrote:
> Because it has opportunity for bloat, I would suggest it should be in a
> pragma:
>
>use strict 'prototypes';
Bloat? What bloat? I don't want to *bloat* all my programs by sticking
a zillion pragmas in just to turn on all the features that makes Perl 6
different from Pe
Chaim Frenkel wrote:
> The Bytecode representation should be mutable and contain enough iformation
> for type/data flow analysis.
What do you mean by "mutable"? Wouldn't the dataflow analysis for a
given bytecode be immutable? Or do you mean the implementation should
be hackable?
> (Do you think
Damian Conway wrote:
> http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt
Curried operators might be a nice way of generalizing the switch
syntax. When we write:
switch ($x ==) {
1: "one";
2: "two";
3: "three";
}
That could be interpreted as currying the == operator
[Could we get the librarian to cc: the RFC owner and hide
replies from the announcement list?]
Perl6 RFC Librarian wrote:
> That is, the expression:
>
> $check = __ < 2 + __ * atan($pi/__) or die __;
>
> is equivalent to:
>
> $check = sub (;) {
> $_[0] < 2
Jonathan Scott Duff wrote:
> If implemented via source filters, $x < $y < $z would get translated
> to $x < $y && $y < $z, which, of course, short circuits. No need for
> "$y (but true)" (Although, we already have "0 but true" until someone
> submits an RFC to remove it ;-)
Why would we ever u
Perl6 RFC Librarian wrote:
> not because language design is a fun thing to do of an evening.
Huh? You mean I'm supposed to pretend to not enjoy myself? I keep
all my hair shirts at work, thanks.
> If that's the case, nobody wins if we bend the Perl language out of all
> recognition, because it w
Jeremy Howard wrote:
> Unless I'm missing something here, you're not filling in the args correctly.
> I think you mean:
>
> $check = sub (;) {
> @_==0 ? __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ? $_[0] < 2
Jonathan Scott Duff wrote:
> On Fri, Aug 04, 2000 at 10:52:24PM -0400, Ken Fox wrote:
> > Why would we ever use source filters when we're going to have a
> > beautiful extend-syntax macro system.
>
> Because source filters *are* that macro system. Why would we inv
Glenn Linderman wrote:
> For instance,
>
> if ( $v == @foo )
>
> is clearly testing the size of foo against the value of $v. But
>
> switch ( $v ) {
> case 1: { ... }
> case 2: { ... }
> case @foo { ... }
> }
>
> does not!
Then write the switch as:
switch ( __ ) {
ca
Glenn Linderman wrote:
> [currying] appears to be powerful, and a kind of like generic programming on
> the fly. I'd like to learn more: if someone would give a tutorial
> reference that would be helpful.
I'll try to find something. There's a bit of computer science snobbery
related to functiona
Jeremy Howard wrote:
> (..-1) == map -__ (1..);
That really confuses me. If the sequence (-4..-1) is (-4, -3,
-2, -1) then I don't see how your semantics are consistent. I'll
admit (reverse map -__ (1..)) is the same as (..-1) but reverse
on a stream is undefined. (It should be a run-time error
Dan Sugalski wrote:
> At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
> > uplevel 0, $Perl:Warnings=1;# Hit everyone
> > uplevel -1, $Perl:Warnings=0; # Hit my wrapper
> Yeah, I can see that. We're going to need a mechanism to hoist things to
> outer scope levels internally (f
Nathan Wiger wrote:
>$pw = getpwnam('nwiger');
>print "$pw"; # calls $pw->SCALAR, which prints 'nwiger'
>die "Bad group" unless $pw->gid == 100;
I'm ashamed that this feature would mess with my (bad?) habit of
re-writing "$pw" to just $pw on the assumption that whoever wrote
Perl6 RFC Librarian wrote:
> BiDirectional Support in PERL
I know nothing about bi-directional output. It doesn't seem
like Perl has any assumption of left-to-right at all. What's
the difference between right-to-left support in Perl and just
editing/using Perl in an xterm that does right-to-left?
Damian Conway wrote:
> That should of course have been:
>
> __ < 2 + __ * atan2($pi, __) or die __
Oh, yes, of course. Um, wait. Nope, I still don't follow. The
expression above curries to:
sub { $_[0] < 2 + $_[1] * atan2($pi, $_[2]) or die $_[3] }
But the expression
__ < 2 + __ * sin(__
Jeremy Howard wrote:
> It is proposed that Perl introduce a new prefix '_', which indicates a
> placeholder. This can be used either as '_identifier', which creates a named
> placeholder, or '__', which creates an anonymous placeholder.
This is a good idea, but it has a good chance of tripping up
Dan Sugalski wrote:
> But, if we toss refcounts, and split GC cleanup and
> end of scope actions anyway, we need to have a mechanism to hoist things
> out of the current scope.
Why say hoist when we can say return? I can think of several ways of
returning values that don't require the caller to a
[Sorry, spent too much time thinking in the editor and did not
see this before my reply.]
Mike Pastore wrote:
> - ^foo is the placeholder 'foo'
That already has perfectly good meaning: XOR with the function foo().
> Although, I suppose '&' would not work.
Why not? I think it would work great.
Mike Pastore wrote:
> Ken Fox wrote:
> > > Although, I suppose '&' would not work.
> >
> > Why not? I think it would work great.
>
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main rea
Jeremy Howard wrote:
> Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> allow named placeholders too. Although I don't see what this buys you.
Argument ordering. We might be constrained by the caller as to what order
the placeholders are passed in. Also, we want to make
"Bryan C. Warnock" wrote:
> It seems to me that whether something is CORE-worthy is really a
> decision for the internals team. Whether something should be a valid,
> meaningful construct in Perl, regardless of the implementation, is the
> focus of the language team.
The CORE of the Perl languag
Dan Sugalski wrote:
>$foo = 12;
>$bar = something();
>$bar = $foo;
>
> could work out to:
>
>$foo = $bar = 12;
>something();
If $foo is a lexical variable and it hasn't been aliased then
you might be able to do that optimization. The following is just
as good and safer:
$fo
Peter Scott wrote:
> Have often wanted a way to tell whether a scalar was a number
> way to get at the SvIOK and SvNOK results would be great.
SvIOK, SvNOK and "is a number" are not the same thing at all.
Often numbers are strings that just look like numbers. Perl doesn't
eagerly convert stuff i
John Porter wrote:
> Jeremy Howard wrote:
> > Yes, they're not identical. What I mean of course is:
> > (..-1) == reverse(map -__ (1..));
>
> WHAT? So the semantics of .. are magically different in the context
> of (..$n) so as to produce numbers in descending order?
Both of those expressions
Michael Fowler wrote:
> I would argue that you should be manipulating your data, or checking values,
> so that numbers and strings are sorted how you wish. The proposed isnum(),
> or way-to-determine-if-a-scalar-is-a-number would help. This should be an
> explicit check, though, because you have
> Higher order functions
This is a very nice proposal and I'd like to see it adopted. Since
many other RFCs are bound to assume this functionality, can we put
this one on the "fast track" approval process? ;)
- Ken
Dan Sugalski wrote:
> The number of different vtables needed to deal with this (along with
> the functions in those tables) is rather formidable, and it will tend
> to impact performance.
Hey! That sounds like an implementation topic... ;) (The internals
should be able to handle this if the langu
Bart Lateur wrote:
> On Tue, 08 Aug 2000 23:43:26 -0400, Ken Fox wrote:
> >(assuming min() is polymorphic):
> >
> > min($a, $b) eq $a
> >
> >Ugly, but minimal changes to the language.
>
> We could adopt a syntax similar to sort():
>
> $lo
Piers Cawley wrote:
>$ints_from = ^1 => sub {$ints_from->(^1+1)};
>$ints = $ints_from->(1);
I think pairs should use array range syntax ".." and be folded
into the array generator RFC (or at least referenced in that RFC).
In particular, using a pair in an array context should interpret
t
Dave Storrs wrote:
> On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> > BTW, if we define C to map keys of a hash to named place holders
> > in a curried expression, this might be a good thing:
> >
> > with %person {
> > print "Howdy, ", ^firstname, " ", ^lastname;
> > }
> >
Damian Conway wrote:
> sub sort (^&comparator, @list) {
> for (1..@list**3) {
> my ($i, $j) = (rand(@list), rand(@list));
> @list[$i,$j] = @list[$j,$i]
> unless $comparator->(a: $list[$i], b: $list[$j]);
>
"David L. Nicol" wrote:
> Ken Fox wrote:
> > IMHO, curries have nothing to do with this. All "with" really does is
> > create a dynamic scope from the contents of the hash and evaluate its
> > block in that scope.
...
> But that doesn't give us th
Dan Sugalski wrote:
> I expect we'd want to have some sort of heavy-duty regex optimizer, then,
> to detect common prefixes and subexpressions and suchlike things, otherwise
> we end up with a rather monstrous alternation sequence...
We need a regex merge function too -- then we could write macro
Nathan Wiger wrote:
> Your point is assuming that STDERR retains its weirdness, and does not
> become a simple scalar object ...
sub STDERR () { $STDERR }
or am I missing something?
> Making STDERR into $STDERR is all hinged on fast vtable stuff in core ...
Absolutely false. $STDERR does not d
Bart Lateur wrote:
> But isn't there going to be a large overhead, in populating such a
> "hash"?
If you need an ordered data structure the overhead would be lower
than using a hash.
> Doesn't the tree have to be reorganized every time you add a
> single new entry?
No. Sometimes you may have to
Branden wrote:
> Actually, with event loops and threading issues, probably things like
> the perl built-ins sleep and alarm won't ever be passed to the syscalls
> sleep(3) and alarm(3).
Sleep isn't usually a syscall -- it's often a library routine that sets
an alarm and blocks or uses some other
Bart Lateur wrote:
> What if we take the ordinary sleep() for the largest part of the
> sleeping time (no busy wait), and the 4 argument select for the
> remainder, i.e. subsecond?
You're trying to solve a problem that doesn't exist.
Sleep doesn't have the signal delivery problems that alarm has
Dan Sugalski wrote:
> At 11:57 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote:
> > On Wed, Jan 31, 2001 at 05:35:03PM -0500, Michael G Schwern wrote:
> > > grossly UNIX specific things like getpwnam's [can be pulled]
> >
> > But why? What is it going to buy you?
>
> Not that much. More than anything
Dan Sugalski wrote:
> At 02:04 PM 2/1/2001 -0500, Ken Fox wrote:
> >Isn't the trick to detect the necessary modules at compile time?
>
> Nope, no trick at all. The parser will have a list of functions--if it sees
> function X, it loads in module Y. (Possibly version Z) N
Dan Sugalski wrote:
> At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
> > Have a look at AnyLoader in CPAN.
>
> Looks pretty close to what's needed. Care to flesh it out (and streamline
> it where needed) to a PDD?
Isn't the trick to detect the necessary modules at compile time? Run-time
ca
Branden wrote:
> I actually don't understand how traversing a graph can be faster than
> incrementing/decrementing/testing for zero on a refcount.
There are two main reasons advanced garbage collectors are fast:
1. Cheap allocations. Most fast collectors have a one or two
instruction malloc
Branden wrote:
> Ken Fox wrote:
> > Some researchers have estimated that 90% or
> > more of all allocated data dies (becomes unreachable) before the
> > next collection. A ref count system has to work on every object,
> > but smarter collectors only work on 10% of the
Dan Sugalski wrote:
> At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > If I change the way some objects are used so
> > that I tend to create other objects instead of reusing the old ones, I'm
> > actually not degrading GC performance, since its work is proportional to
> > live data. Right?
>
> Cor
"David L. Nicol" wrote:
> # with POST
> sub find_first_line_matching_array($\@){
> open F, shift or die "could not open: $!";
> POST{close F};
> while(){
> foreach $w (@{$_[0]}){
>
Bart Lateur wrote:
> On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
> > 1. Cheap allocations. Most fast collectors have a one or two
> >instruction malloc. In C it looks like this:
> >
> > void *malloc(size) { void *obj = heap; heap += size; return obj; }
[Please be careful with attributions -- I didn't write any
of the quoted material...]
Russ Allbery wrote:
> >> sub test {
> >> my($foo, $bar, %baz);
> >> ...
> >> return \%baz;
> >> }
> That's a pretty fundamental aspect of the Perl language; I use that sort
Dave Mitchell <[EMAIL PROTECTED]> wrote:
> John Porter <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > I think closures are a lot harder (or at least subtler) than
> > > people think ...
> >
> > ... The scenario you gave seems rather far-fetched to me, in terms
> > of real-world program
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:38 PM 8/8/2001 +, Brian J. Kifiak wrote:
> > > Unfortunately all the references I have for alternatives really
> > > require what the Dragon Book teaches as a foundation.
> >
> > What are the references?
>
> ... Advanced Compiler Design & Implem
Michael G Schwern wrote:
> I can't think of any reason why this feature is useful anymore, and it
> can be a really confusing behavior, so what say we kill it in Perl 6?
I've always thought is was pretty useful for implementing generic
redirectors. I wrote a frame system that allows instances to
Michael G Schwern wrote:
> Any time you want to implicitly pass @_, you can just as easily
> *explicitly* pass it or use goto.
I never thought of using goto actually. "goto &$method;" actually
looks clearer than the code I'm using. (Although with re-directors
we want to minimize cost so the 10% p
Dave Mitchell wrote:
> The whole point is that closed variables *aren't* 'just local variables'.
> The inner $x's in the following 2 lines are vastly different:
>
> sub foo { my $x= ... { $x } }
> sub foo { my $x= ... sub { $x } }
You really need to learn what a closure is. There's a
Michael G Schwern wrote:
> If you *really* wanted to write an optimized redirector, you'd
> have the redirector eliminate itself.
That's not always appropriate. In my frame system, an instance
can over-ride its class method. An instance can also remove the
over-ride and return to using the class
Garrett Goebel wrote:
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > Okay, to humour me for a mo', what should the following 2 examples
> > output if Perl were doing the "right" thing?
> >
> > sub pr { print $_[0] || 'undef', "\n" }
> >
> > { my $x = 'X'; sub f { $F = sub {pr $x} }}
> > f();
[EMAIL PROTECTED] wrote:
> Dan, I don't immediately see how per object/class dispatch
> control helps to make multimethods pluggable.
The way to approach this problem is to profile
Class::MultiMethods and figure out (a) where the hot spots
are and (b) what core support would help eliminate those
Uri Guttman wrote:
[Re: use strict 'typing'; my $rex = new Dog; $rex.bark]
> then it should be a compile time error at the assignment to $rex
> and not later. you can't trace $rex at compile time to see what
> kind of object (if any) was assigned to it. so the illegal method
> call can't (easily)
Damian Conway wrote:
> Ken wrote:
>> The one thing I'm curious about is whether different syntactic
>> conventions affect the dispatcher or whether this is all just
>> sugar for a single dispatch.
>
> Multiple dispatch is certainly not (practically) implementable via single
> dispatch
"Bryan C. Warnock" wrote:
> I'm waiting for someone to say that in tri-state logic, '!<' != '>='
That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b".
In SQL this is "$a IS NULL or $a >= $b".
- Ken
"Bryan C. Warnock" wrote:
> {
> my $a = sub ($$) { code };
> gork($a);
> }
>
> sub gork {
> my ($a) = shift;
> $a->(@some_list); # <- Here
> }
>
> The reason prototypes aren't checked at "Here" is because there really
> isn't a way to know what the prototype was.
Um, that's not
I haven't seen details in an Apocalypse, but Damian's
Perl 6 overview has a bit about it. The Apocalypse
specifically mentions *compile-time* scope management,
but Damian is, uh, Damian. (DWIMery obviously. ;)
Is stuff like:
%MY::{'$lexical_var'} = \$other_var;
supposed to be a compile-time o
Damian Conway wrote:
> It would seem *very* odd to allow every symbol table *except*
> %MY:: to be accessed at run-time.
Well, yeah, that's true. How about we make it really
simple and don't allow any modifications at run-time to
any symbol table?
Somehow I get the feeling that "*very* odd" can'
Damian wrote:
> Dan wept:
>> I knew there was something bugging me about this.
>>
>> Allowing lexically scoped subs to spring into existence (and
>> variables, for that matter) will probably slow down sub and
>> variable access, since we can't safely resolve at compile time wh
Damian wrote:
> In other words, everything that Exporter does, only with lexical
> referents not package referents. This in turn gives us the ability to
> easily write proper lexically-scoped modules.
Great! Then we don't need run-time lexical symbol table
frobbing. A BEGIN block can muck with it
[EMAIL PROTECTED] wrote:
> Clearly caller() isn't what we want here, but I'm not
> quite sure what would be the correct incantation.
I've always assumed that a BEGIN block's caller() will
be the compiler. This makes it easy for the compiler to
lie about %MY:: and use the lexical scope being compi
Dan Sugalski wrote:
> ... you have to take into account the possibility that a
> variable outside your immediate scope (because it's been defined in an
> outer level of scope) might get replaced by a variable in some intermediate
> level, things get tricky.
Other things get "tricky" too. How abou
Dan Sugalski wrote:
> I think you're also overestimating the freakout factor.
Probably. I'm not really worried about surprising programmers
when they debug their code. Most of the time they've requested
the surprise and will at least have a tiny clue about what
happened.
I'm worried a little abo
Dave Mitchell wrote:
> Can anyone think of anything else?
You omitted the most important property of lexical variables:
[From perlsub.pod]
Unlike dynamic variables created by the C operator, lexical
variables declared with C are totally hidden from the outside
world, including any calle
Dan Sugalski wrote:
> At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
> >You wrote on perl6-internals:
> >
> >get_lex P1, $x # Find $x
> >get_type I0, P1 # Get $x's type
> >
> >[ loop using P1 and I0 ]
> >
> >That cod
Dan Sugalski wrote:
> On the other hand, if we put the address of the lexical's PMC into a
> register, it doesn't matter if someone messes with it, since they'll be
> messing with the same PMC, and thus every time we fetch its value we'll Do
> The Right Thing.
Hmm. Shouldn't re-binding affect onl
Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x itself.
So I should have said:
%MY::{'$x'} = $z;
That's pretty magical stuff isn't it? Sorry I used the wrong syntax.
I'm just taking it from yo
"Bryan C. Warnock" wrote:
> Generically speaking, modules aren't going to be running amok and making a
> mess of your current lexical scope - they'll be introducing, possibily
> repointing, and then possibly deleting specific symbols
How much do you want to pay for this feature? 10% slower code?
Garrett Goebel wrote:
> worried about the loss of data-hiding with Perl6's lexicals.
> Was that ever resolved?
Here in the 10-step Perl 6 program we don't talk about
resolution. We just learn to cope with change. ;)
There were two issues I had. As a Perl 6 user I felt
uncomfortable that Perl 6 i
Garrett Goebel wrote:
> Just does compile-time typing for $foo? Not inlining the constant?
You can't assume that the value associated with the symbol is
the same each time through the code, so how can it be inlined?
> I was thinking lowercase typed variables couldn't be rebound, because
> they w
Dave Storrs wrote:
> why didn't you have to write:
>
> rule ugly_c_comment {
>
/
>
\/ \* [ .*? ? ]*? \* \/
>
{ let $0 := " " }
>
/
> }
Think of the curly braces as the regex quotes. If "{" is the quote
then there's nothing spe
Uri Guttman wrote:
> but remember that whitespace is ignored as the /x mode is on
> all the time.
Whoops, yeah. For some reason I kept literal mode on when
reading the spaces between two literals.
The rules {foo bar} and {foobar} are the same, but some
very low level part of my brain is resisti
A question: Do rules matched in a { code } block set backtrack points for
the outer rule? For example, are these rules equivalent?
rule expr1 {
{ /@operators/ or fail }
}
rule expr2 {
@operators
}
And a comment: It would be nice to have procedural control over back-
tracking
Aaron Sherman wrote:
> rule { { /@operators/.commit(1) or fail } }
>
> The hypothetical commit() method being one that would take a number and
That would only be useful if the outer rule can backtrack into the
inner /@operators/ rule. Can it?
I agree with you that a commit method woul
Damian Conway wrote:
> rule expr1 {
> { m:cont/@operators/ or fail }
> }
>
> Backtracking would just step back over the rule as if it were atomic
> (or followed by a colon).
Ok, thanks. (The "followed by a colon" is just to explain the behavior,
right? It's illegal to follow a
Larry Wall wrote:
> On Fri, 30 Aug 2002, Ken Fox wrote:
> : Ok, thanks. (The "followed by a colon" is just to explain the behavior,
> : right? It's illegal to follow a code block with a colon, isn't it?)
>
> I don't see why it should be illegal--it cou
Larry Wall wrote:
> There's a famous book called "Golf is Not a Game of Perfect".
Well now I'm *totally* confused. I looked that up on Amazon
and it has something to do with clubs and grass and stuff. That's
completely different than what I thought golfing was. ;)
Seriously, though. I have a pos
Piers Cawley wrote:
> Unless I'm very much mistaken, the order of execution will
> look like:
>
> $2:=$1; $1:=$2;
You're not binding $2:=$1. You're binding $2 to the first
capture. By default $1 is also bound to the first capture.
Assuming that numbered variables aren't special, the orde
Simon Cozens wrote:
> [EMAIL PROTECTED] (Damian Conway) writes:
>
>>> %hash4 = ("Something", "mixing", pairs => and, "scalars");
>>
>>That's perfectly okay (except you forgot the quotes around the
>>and you have an odd number of elements initializing the hash).
>
> Urgh, no. Either a pair is a
Damian Conway wrote:
> No. It will be equivalent to:
>
> <[\x0a\x0d...]>
I don't think \n can be a character class because it
is a two character sequence on some systems. Apoc 5
said \n will be the same everywhere, so won't it be
something like
rule \n { \x0d \x0a | \x0d | \x0a }
Hmm.
The thing I'd like to do right now is turn on :w
for all rules. A Fortran grammar might want to turn
on :i for all rules.
Maybe add modifiers to the grammar declaration?
grammar Fortran :i { ... }
It would also be convenient to allow the :w
modifier to have lexically scoped behavior so a
gra
Damian Conway wrote:
> One possibility is that a modifier is
> implemented via a special class:
>
> my class Decomment is RULE::Modifier
>is invoked(:decomment) {
> method SETUP ($data, $rule) {
> ...
> }
> # etc.
>
Peter Haworth wrote:
> Also the different operators used (:= inside the rule, = inside the code)
> seems a bit confusing to me; I can't see that they're really doing anything
> different:
>
> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>
> Shouldn't they both use C< := > ?
Depen
David Wheeler wrote:
> Ah, yes, the same thing exists in Java. I remember, now.
I thought Java only has over loading?
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the o
Dan Sugalski wrote:
> At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>> So, just to clarify, does that mean that multi-dispatch is (by
>> definition)
>> a run-time thing, and overloading is (by def) a compile time thing?
>
> No. They can be both compile time things or runtime things, dependin
David Whipp wrote:
> But can I use a non-constant date?
You didn't show us the iso_date rule.
> Obviously we could put the onus on the module writer to write super-flexible
> rules/grammars. But will there be an easy way to force interpolative context
> onto this type of regex-valued subroutine
Damian Conway wrote:
> I would imagine that modifiers would be passed some
> kind of hierarchical representation of the rule
> they're modifying (i.e. a parse tree of it), and
> would be expected to manipulate that structure
> representation.
Excellent. Will there be an abstract syntax for tree
r
Damian Conway wrote:
> Because what you do with a hypothetical has to be reversible.
> And binding is far more cheaply reversible than assignment.
Why not leave it in the language spec then? If it's too
hard to implement, then the first release of Perl 6 can
leave it out. Someday somebody might c
Mr. Nobody wrote:
> /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/
>
> would actually become longer:
>
> /^(<[+-]>?)\d*(\.\d*)?(<[Ee]>(<[+-]>?\d+))?$/
Your first expression uses capturing parens, but the captures
don't bind anything useful, so you should probably compare
non-capturing versi
Damian Conway wrote:
> Though leaving optimization in the hands of the programmer
> is generally a Bad Idea.
That doesn't sound like a Perl slogan.
> It's also a matter of syntactic consistency. It has to be := for
> "inlined" bindings (i.e. rx/ $name:= /) because otherwise
> we make = meta (whi
Luke Palmer wrote:
> This requires infinite lookahead to parse. Nobody likes infinite
> lookahead grammars.
Perl already needs infinite lookahead. Anyways, most people
don't care whether a grammar is ambiguous or not -- if we did,
natural human languages would look very different.
People want
Luke Palmer wrote:
> On Thu, 12 Sep 2002, Ken Fox wrote:
> > Perl already needs infinite lookahead.
>
> Really? Where?
Indirect objects need infinite lookahead and they are
in the core language. Hyper operators may need lookahead.
Place holders may need lookahead. User def
Damian Conway wrote:
Larry Wall wrote:
That suggests to me that the circumlocution could be >>*<<.
A five character multiple symbol??? I guess that's the penalty for not
upgrading to something that can handle unicode.
Unless this is subtle humor, the Huffman encoding idea is getting
seriously
Austin Hastings wrote:
At this point, Meestaire ISO-phobic Amairecain Programmaire, you have
achieved keyboard parity with the average Swiss six-year-old child.
The question is not about being ISO-phobic or pro-English. **
The question is whether we want a pictographic language. I like
the siz
Austin Hastings wrote:
The << and >> ... are just as pictographic (or
not) as [ and ].
I'm not particularly fond of << or >> either. ;) Damian just
wrote that he prefers non-alphabetic operators to help
differentiate nouns and verbs. I find it helpful when people
explain their biases like that.
1 - 100 of 113 matches
Mail list logo
