On Aug 24, 2005, at 7:42 PM, Andrew Rodland wrote:
On Wednesday 24 August 2005 04:26 pm, Amir Karger wrote:
Several people pointed out that I didn't perldoc -f system. Sorry!
Btw, even after reading the docs, I still don't understand why Perl
would pass a cd command to a piece of the shell tha
Leopold Toetsch wrote:
>
> Above Parrot interface function tries to locate Sub objects in the
> namespace of the invocant's class and in the MRO of it. When you go back
> to the PIR translation of your code there is e.g.
>
> class Foo:
> def g(self,y):
>
> I have translated this to:
>
> .
On Wednesday 24 August 2005 04:26 pm, Amir Karger wrote:
> Several people pointed out that I didn't perldoc -f system. Sorry!
> Btw, even after reading the docs, I still don't understand why Perl
> would pass a cd command to a piece of the shell that can't understand
> it. Granted, I shouldn't do
On 8/23/05, I wrote:
> I adopted the Zcode interpreter that leo posted in February.
>
> The only bad news is there's something wrong with my make test.
> I managed to narrow this down to a very
> weird Perl behavior I don't understand at all:
>
> testportal:~>mkdir z
> testportal:~>cd z
> testpo
On Wed, 24 Aug 2005, Sam Ruby wrote:
[huge cut]
> Below is from the sample that Leo provided.
>
> > # print foo.f(2)
> >
> > # emulate python find_name, which checks attributes too
> > push_eh m_nf
> > $P0 = foo."f"(2)
> > clear_eh
> > goto m_f
> > m_nf:
> > # getattri
On Aug 24, 2005, at 23:34, Sam Ruby wrote:
Leopold Toetsch wrote:
Note that you would then be caching the results of a curried function
call. This result depends not only on the method string, but also on
the particular object upon which it was invoked.
No the "inner" Parrot_find_method_
Leopold Toetsch wrote:
>
>> Note that you would then be caching the results of a curried function
>> call. This result depends not only on the method string, but also on
>> the particular object upon which it was invoked.
>
> No the "inner" Parrot_find_method_with_cache just caches the method fo
On Aug 24, 2005, at 19:45, Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby wrote:
The return value is a callable sub.
More precisely: a curried function call. This is an important
distinction; to see why, see below.
A callable sub may be of course a curried one - yes.
The interest
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 --
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Leopold Toetsch wrote:
>
>>> A stripped down PIR-only, pythonless translation is below.
>
>> (example: classes aren't global in Python),
>
> Yes, of course. The stripped down means essential the absence of any
> lexical handlings. But as you say,
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 Tue, Aug 23, 2005 at 05:09:26PM -0400, Amir Karger wrote:
> testportal:~/z>perl -we 'system("cd y")'
The right thing to do (tm) here is chdir("y"), but if 'cd' is just an
example and not the actual command, the right thing is system LIST form:
system command => @args;
--
wolverian
sign
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
Sam Ruby wrote:
Leopold Toetsch wrote:
A stripped down PIR-only, pythonless translation is below.
(example: classes aren't global in Python),
Yes, of course. The stripped down means essential the absence of any
lexical handlings. But as you say, this doesn't matter for these sub and
m
I agree this following would be cool.
However in the general case this type of code inference is HARD to do.
I believe that the optimizations you are looking for would require a
combination of type inference and graph reduction.
PyPy may be the eventual answer.
Don't get me wrong, I think it is gre
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
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Let me try again to move the discussion from subjective adjectives to
>> objective code. Consider:
>
> [ example code ]
>
>> If you run this, you will get 1,2,3.
>>
>> When called as a function, f will return the value of the second
>> parameter. W
Sam Ruby wrote:
Let me try again to move the discussion from subjective adjectives to
objective code. Consider:
[ example code ]
If you run this, you will get 1,2,3.
When called as a function, f will return the value of the second
parameter. When called as a method, the same code will nee
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
Perl's systen() tries to execute an external command directly when
doesn't find any any shell metacharacters in the command line.
Otherwise, it defaults to the shell.
--
avva
"There's nothing simply good, nor ill alone" -- John Donne
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
Hi!
I adopted the Zcode interpreter that leo posted in February. Luckily,
he did the hard parts.
I added some opcodes, README/CHANGES/TODO files, and testing, and,
finally, did my first Parrot checkin. How exciting!
There's much much more to do - 41 more opcodes just for version 3 of
the Z-machi
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
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 losing the magic from =>'d pairs isn't buying us named args w
28 matches
Mail list logo
