At 8:54 AM -0500 1/21/03, Christopher Armstrong wrote:
On Tue, Jan 21, 2003 at 08:41:47AM +, Simon Wistow wrote:
Speaking of games, it would be interesting to see Parrot be used in that
direction. A lot of games currently are pretty much developed along the
lines of 'custom scripting langu
At 6:10 PM +0100 1/21/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay, I can be a bit slow, but I finally figured out what's going
on with IMCC and OS X. imclexer.c is autogenerated (duh!) and flex,
or whatever's being used to do it, spits out bad code. Could the
IMCC folks upgrade to the
At 5:48 PM +0100 1/21/03, K Stol wrote:
Is it possible for parrot-code to call functions in other parrot files?
(which implies there is some program which consists of multiple files)
Oh, absolutely.
What one generally does is load in other bytecode files. Those files,
on loading, will install
At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and attributes,
though that's not too surprising all things considered. That may make
interoperability interesting, but I was already expecting that to som
At 11:43 PM -0800 1/21/03, Paul Du Bois wrote:
The advantage of Lua (at least for my project, which is a game) is that it
is quite easy to embed, and quite easy to customize. The C API is small and
easily understandable (at the expense of being a little bit of a pain to
use), and the internals ar
Jason Gloudon wrote:
On Tue, Jan 21, 2003 at 08:21:42PM +0100, Leopold Toetsch wrote:
# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
#$i++;
#eval("goto LAB if ($i==6)");
Ok. Having inter_cs call DO_OP just seems more involved than it has to be.
Yep.
How about a single self-contained
On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> I'm not a Lisp enthusiast, by and large, but I think he makes some
> interesting observations on language design. Take a look if you're
> feeling adventurous...
I can't help feeling slightly deflated. Given the chance to re-design
Lis
Damian Conway writes:
>
> Not equivalent at all. C<$foo~>bar> means "append $foo to the argument list
> of subroutine C". C means "make C<$foo> the invocant for method
> ".
>
> Curiously enough, the confusions I'm hearing over this issue are, to me, the
> strongest argument yet for using
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Of course, _I'd_ even prefer using <- and -> as the 'piping' operators,
> and having ~> or |> for pointy sub, because then $a->foo and $a.foo
> really _could_ be the same thing, 'cept for precedenc
Smylers wrote:
Thom Boyer wrote:
The primary advantage, to my mind, in using C, is that it
eliminates the dangling-else ambiguity -- so splitting it in half
removes almost ALL the value of even having an C keyword.
Surely it's the compulsory braces, even with a single statement, which
eliminat
On 01/21/2003 5:24 AM, Leopold Toetsch wrote:
Jürgen Bömmels (via RT) wrote:
PS orig description again:
This patch is the beginning of an effort to make PackFile format
extendible. At the moment its combatible with the old bytecode
format.
Ok, to the details:
It appends a 4th segment behind the
I lost the original mail asking for suggestions, so there is no quoted
text here, but have you looked at Joy
(http://www.latrobe.edu.au/philosophy/phimvt/joy.html). Looks to be quite
clean and simple. I haven't had the time to delve into it, but when I was
reminded of it on the Ruby list, I t
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hinting me, how to handle this beast.
(s thread "[perl #20315] [PATCH] eval - inter code segment branches")
The fixuptable may h
James Mastros wrote:
I'd be much happier seeing a packfile format that began with DIRECTORY,
and then had the other major sections located dynamicly.
Yep. The simple reason for keeping the old format still a while is
assemble.pl. When switching to imcc is done, there is no need to keep
the o
On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
> $a = sub ($a, $b) { ... }
> $x = -> ($y, $z) { ... }
>
> The pointy-arrow doesn't buy anything here.
IMHO, it's actually a loss. I have yet to come up with any mnemonic
for "pointy arrow means sub" that will actually stick in my br
The question is, can I create a method on a class with a different scope than
the class itself has? Put another way, it seems like
module ArrayMath;
sub sum(Array $this){
$this.reduce(operator::+, 0);
}
method Array::sum(;){
.reduce(operator::+, 0);
}
(modulo syntax errors) then both
--- Andy Wardley <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> > I'm not a Lisp enthusiast, by and large, but I think he makes some
> > interesting observations on language design. Take a look if you're
> > feeling adventurous...
>
> I can't help feel
On Wed, 22 Jan 2003, Austin Hastings wrote:
> I'm done with 'P'. That's it. Putative planners of programming
> paradigms must proffer some prefix preferable to the pathetic
> palimpsest that is 'P'!
As with operators, so with programming languages -- Unicode comes not a
moment too soon.
/s
At 4:53 PM +0100 1/22/03, Leopold Toetsch wrote:
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hinting me, how to handle this beast.
(s thread "[perl #20315] [PATCH] eval - i
Dan Sugalski wrote:
At 4:53 PM +0100 1/22/03, Leopold Toetsch wrote:
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hinting me, how to handle this beast.
(s thread "[perl #
At 6:13 PM +0100 1/22/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 4:53 PM +0100 1/22/03, Leopold Toetsch wrote:
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hintin
Dan Sugalski wrote:
At 6:13 PM +0100 1/22/03, Leopold Toetsch wrote:
IMHO plain jumps do not work:
Sure they do. They work as well as jumps within code, which also has a
not-insignificant potential for problems.
But the issues you raised are some of the reasons I'd prefer
inter-segment jum
All~
Regarding MM dispatch, I implemented a version of this for a class of mine
once. The version I have is in C++, and heavily uses templating to provide
compile time type checks where appropriate. Despite these differences,
however, I think that the system of caching methods and the system of
"David Storrs" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > And then we can replace the ~> with ->:
> >
> > for 1,2,3,4
> > -> sub ($a, $b) { $a+$b }
> > -> sub ($a) { $a**2 }
> > -> { $^foo - 1 }
> > -> print;
> >
> > And this begs the que
On Tuesday, January 21, 2003, at 03:52 PM, Dave Whipp wrote:
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 -> ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
That's an excellent observation. I like the 'for' syntax quite a bit,
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Cc: [EMAIL PROTECTED]
> Date: Wed, 22 Jan 2003 09:03:13 -0600
> From: "Adam D. Lopresto" <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> The question is, can I create a method on a class with a different
> Date: Wed, 22 Jan 2003 10:38:23 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> On Tuesday, January 21, 2003, at 03:52 PM, Dave Whipp wrote:
> > But in a for loop:
> >
> > for 1,2,3,4 { ... }
> > for 1,2,3,4 -> ($a,$b) {...}
> >
> > its cuteness works because the brain sees it as a pipi
Michael Lazzaro writes:
> And it provides a very visual way to define any pipe-like algorithm, in
> either direction:
>
> $in -> lex -> parse -> codify -> optimize -> $out; # L2R
>
> $out <- optimize <- codify <- parse <- lex <- $in; # R2L
>
> It's clear, from looking at e
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
[[... Massive elision ...]]
> I'm thinking it would be a very good idea to unify C and C
> in their argument style. I still think the distinction between
> C's void and C's list context is a good one; i.e. don't
> make them I synonyms.
>
> But it seems
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have
in either the packfile (on disk) or in the bytecode (in memory).
Keep in mind that parrot
Since face to face meetings are usually a lot more productive than
e-mail exchanges when working design things out, I figure that maybe
it'd be in our best interests to see if it's worth having a parrot
developer day somewhere, where some set of us can get together and
hash out things.
It's di
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are all
meant for movement within a segment of bytecode. They are *not*
supposed to leave a segment. To do so was arguably a bad idea, now
it's officially
At 12:28 AM -0500 1/22/03, James Mastros wrote:
If we care about reading old packfiles on newer parrots,
Until we reach 1.0, we don't. As long as we make sure the magic
number in the header of the file is sufficient to make the execution
fail, that's fine for now.
--
At 03:00 PM 1/22/2003 -0500, you wrote:
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are all
meant for movement within a segment of bytecode. They are *not* supposed
to leave a segment. To do so was a
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
> >interface-oriented?) to allow the best of both worlds -- I'm far too
> >novice wrt Parrot to figure out what
David Storrs <[EMAIL PROTECTED]> writes:
> On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
>
>> $a = sub ($a, $b) { ... }
>> $x = -> ($y, $z) { ... }
>>
>> The pointy-arrow doesn't buy anything here.
>
> IMHO, it's actually a loss. I have yet to come up with any mnemonic
> for "poi
Dan --
Cincinnati, Ohio.
And, I'll make my office available for the meeting, if there aren't so
many
people that it would be impractical (unlikely, I expect, but CMA anyway).
-- Gregor
Dan Sugalski <[EMAIL PROTECTED]>
01/22/2003 03:22 PM
To: [EMAIL PROTECTED]
cc:
I'm confused by nci.pmc's mark() routine. It calls pobject_lives() on
the ->cache.struct_val pointer. But in set_string_keyed(), that seems
to be set to a pointer to a function, which is definitely not a PObj*.
The ->data field, on the other hand, appears to be a PObj*. And
changing mark() to mark
Michael Lazzaro wrote:
> *Now*, what to do about the fantastic magic that pointy-sub provides?
> The _spectacular_ win would be if we could just recognize an optional
> parameter list as part of a block.
>
> map @a : ($a,$b) {...} # params + closure = closure with params?
> for @a : ($a
At 6:24 PM -0500 1/22/03, Benjamin Stuhl wrote:
At 03:00 PM 1/22/2003 -0500, you wrote:
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are
all meant for movement within a segment of bytecode. They are *
The Perl 6 Summary for the week ending 20030119
Summary time again, damn but those tuits are hard to round up. Guess,
what? perl6-internals comes first. 141 messages this week versus the
language list's 143.
Objects (again)
Objects were still very much on everyone's mind as the d
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start discussing
>
> metadata. What sorts of metadata do people think are useful to have
> in either the packfile (on disk) or
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
> On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> > >But who knows, maybe it could be made modular enough (i.e., more
> > >interface-oriented?) to allow the best of b
Christopher Armstrong:
# On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
# > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
# > >But who knows, maybe it could be made modular enough (i.e., more
# > >interface-oriented?) to allow the best of both worlds --
# I'm far too
# > >
44 matches
Mail list logo
