On Tue, Aug 23, 2005 at 10:11:37AM -0700, Larry Wall wrote:
> setting up the proxy hash. It's possible that COW hashes can be made
> to work efficiently. We'll need to copy hashes if we want to modify
> them to pass to subfunctions, just as when you change your environment
> it doesn't affect yo
On Wed, Aug 24, 2005 at 10:12:39AM -0700, Chip Salzenberg wrote:
> On Wed, Aug 24, 2005 at 08:38:39AM -0400, John Macdonald wrote:
> > When calling a function, I would like to be able to have a
> > mixture of named and positional arguments. The named argument
> > acts as a tab into the argument lis
I've been trying to thing about how to make this read right without too
much line noise. I think Lukes keyword approach ("named") is on the
right track.
If we want named params at both start and end, then its bound to be a
bit confusing. But perhaps we can say that they're always at the end --
On Wed, Aug 24, 2005 at 08:38:39AM -0400, John Macdonald wrote:
> When calling a function, I would like to be able to have a
> mixture of named and positional arguments. The named argument
> acts as a tab into the argument list and subsequent unnamed
> arguments continue on.
I see a main point of
On Wed, 24 Aug 2005, Damian Conway wrote:
> Larry wrote:
>
> > Plus I still think it's a really bad idea to allow intermixing of
> > positionals and named. We could allow named at the beginning or end
> > but still keep a constraint that all positionals must occur together
> > in one zone.
>
> If
I don't think this example reads very clearly. Visually you have to parse
until you see the next => and then back track one word to figure out the key.
> move( from=> $x, $y, delta=> $up, $right );
Personally I'd write that as either
move(from => [$x, $y], delta => [$up, $right]);
OR as
WRT to PIL and compilation and all that, I think it's time to think
about how the linker might look.
As I see it the compilation chain with the user typing this in the
prompt:
perl6 foo.pl
perl6 is a compiled perl 6 script that takes an input file, and
compiles it, and then passes the co
On Wed, Aug 24, 2005 at 04:27:03PM +1000, Damian Conway wrote:
> Larry wrote:
>
> >Plus I still think it's a really bad idea to allow intermixing of
> >positionals and named. We could allow named at the beginning or end
> >but still keep a constraint that all positionals must occur together
> >in
On Tue, Aug 23, 2005 at 16:32:37 -0700, Larry Wall wrote:
> Hmm, well, I don't think >>&op<< is valid syntax, but you did say
> "semantics", so I can't criticize that part. :-)
What is >><<, btw?
Is it
&circumfix:{'>>','<<'} (Code &op --> Code); # takes some code, returns
a listop
or
Larry wrote:
Or we could have a different operator that coerces like == and eq, only
via .snap:
if [1,2,3] equals [1,2,3] { say "true" } else { say "false" }
(Actual name negotiable, of course). The advantage of the latter approach
is that you can say
@foo >>equals<< @bar
and th
Larry mused:
On the other hand, I'm not all that attached to colon itself.
I *am*!!!
If, as proposed elsewhere, we get rid of the %Foo:: notation in favor of
some Foo<> variant, then trailing :: becomes available (ignoring ??/::
for the moment), and
new Dog:: tail => 'long'
almost mak
11 matches
Mail list logo
