Re: Bytecode metadata
Juergen Boemmels wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: It might be even possible to dump the jitted code. This would increase the startup. Then strip the bytecode to reduce the size of the file and TADA: Yet another new binary format. When you then are able to to get the same memory layout for a newly created interpreter, it might even run ;-) I'm really not sure if I'm serious here boe leo
Re: Bytecode metadata
Dan Sugalski wrote: At 8:39 PM + 1/23/03, Dave Mitchell wrote: in such a way that it (or most of it) can simply be mmap-ed in (RO), analogously to executables. This is the way the bytecode currently works, and we will *not* switch to any bytecode format that doesn't at least allow the executable code to be mmapped in. s/works/should work/ The file get mmap()ed if possible, then the bytecode get's memcpy'd and the map is munmap'd. leo
Re: Odd JIT timings
Dan Sugalski wrote: I just gave a run of examples/assembly/mops_p.pasm, getting some performance numbers. Here's an interesting timing. no jit: 24.9 seconds with jit: 33.6 seconds This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. I'm pretty new to this, so I apologise if this is useless information. perl assemble.pl examples/assembly/mops_p.pasm > mops_p.pbc ./parrot mops_p.pbc Iterations:1 Estimated ops: 2 done Elapsed time: 53.746114 M op/s:3.721199 ./parrot -j mops_p.pbc Iterations:1 Estimated ops: 2 done Elapsed time: 4.450022 M op/s:44.943598 I'm running Linux 2.4.19 on x86, gcc 3.2. My Parrot is a fresh checkout/build within the past hour. Someone care to check it out and poke around a bit? 'Fraid I probably wouldn't be of much use there. Douglas
Re: Odd JIT timings
Dan Sugalski wrote: I just gave a run of examples/assembly/mops_p.pasm, getting some performance numbers. Here's an interesting timing. no jit: 24.9 seconds with jit: 33.6 seconds This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. Someone care to check it out and poke around a bit? $ languages/imcc/imcc examples/assembly/mops_p.pasm Iterations:1 Estimated ops: 2 done Elapsed time: 20.521627 M op/s:9.745816 $ languages/imcc/imcc -j examples/assembly/mops_p.pasm Iterations:1 Estimated ops: 2 done Elapsed time: 3.261104 M op/s:61.328924 It depends on implemented functions in JIT. i386 has a bunch of vtable functions JITed (which isn't too hard to do). leo
Re: Odd JIT timings
On Friday 24 January 2003 04:43, Dan Sugalski wrote: > I just gave a run of examples/assembly/mops_p.pasm, getting some > performance numbers. Here's an interesting timing. > >no jit: 24.9 seconds >with jit: 33.6 seconds > > This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. > > Someone care to check it out and poke around a bit? CG vs JIT (running with non jitted opcdes) wins CG, always. Daniel Grunblatt.
Re: Bytecode metadata
Leopold Toetsch wrote:
I'm currently simplifying the whole packfile routines. It still does
read the old format, but the compat code is centralized now in one place.
Registered types are consecutively numbered, unknown types still get
unpacked or dumped:
typedef enum {
PF_DIR_SEG,
PF_UNKNOWN_SEG,
PF_FIXUP_SEG,
PF_CONST_SEG,
PF_BYTEC_SEG,
PF_DEBUG_SEG,
PF_MAX_SEG
} pack_file_flags;
Here is a sample dump of a packfile with file/line info generated by
$ imcc -d -o eval.pbc eval.pasm
$ pdump eval.pbc
DIRECTORY => { # 3 segments
type 3 name CONSTANToffs 0x1c length 35
type 4 name BYTECODEoffs 0x40 length 14
type 5 name BYTECODE_DB offs 0x4f length 17
}
CONST => [
### snipped (as old) ###
],
BYTECODE => [ # 14 ops at ofs 0x40
0041: 0349 0001 0003 0057 0001 0002 0347
0048: 0001 0345 001a 0001
]
BYTECODE_DB => [ # 17 ops at ofs 0x4f
0050: 6c617665 7361702e 006d 0001 0002 0003 0004 0005
0058: 0006
0060:
]
(the line array is currently too big (per opcode not per ins ;-))
Anyway, packing/unpacking and dumping above packfile data is working now.
Does anybody want to have a look at the patch?
Should I check in - or send it to the list?
$ diffstat packf.diff
TODO |5
debug.c|2
include/parrot/packfile.h | 129 +++---
languages/imcc/TestCompiler.pm |6
languages/imcc/imclexer.c |2
languages/imcc/main.c |2
languages/imcc/pbc.c |6
languages/imcc/t/harness | 15
languages/imcc/t/syn/eval.t| 61 ++
packdump.c |4
packfile.c | 848 ++---
packout.c | 156 +++
pdump.c| 23 -
13 files changed, 715 insertions(+), 544 deletions(-)
leo
[BUG] substr messing up array elt
In debugging a regex problem, I gradually whittled a test case down to
the following code. It does roughly:
@a = ('aaa', 'ac');
$x = $a[0];
print $x;
$x = substr("aaacacaaba", 3, 3); # "cac"
$y = $a[0]
print $y;
and prints out
aaa
cac
So the substr is somehow modifying the first element of the array.
I'll dive back into this tonight, but maybe somebody has an idea? It
acts as if the '$x = $a[0]' ('set_s_p_kic S0, P0[0]') makes a
reference to the array element that gets modified via substr. Am I
just confused about how things are supposed to work? (Note that
changing the substr to either 'set S0, "cac"' or 'assign S0, "cac"'
will make the problem disappear.
new_p_ic P0,13 # PerlArray
set_p_kic_sc P0[0],"aaa"
set_p_kic_sc P0[1],"ac"
set_s_p_kic S0,P0[0]
print_s S0
print_sc "\n"
substr_s_sc_ic_ic S0,"aaacacaaba",3,3
set_s_p_kic S1,P0[0]
print_s S1
print_sc "\n"
end
Re: Bytecode metadata
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote: > How many mmap's can $arch have for one program and for all? > Could we hit some limits here, if every module loaded gets (and stays) > mmap()ed. I just wrote a quick C program that successfully mmap-ed in all 1639 files in my Linux box's /usr/share/man/man1 directory. Note that in Perl5 we already (indirectly) rely on the OS's ability to mmap in the library code for any XS-based modules. -- "But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged." Lady Croom - Arcadia
RE: Parrot Developer Day(s)? [x-adr]
From: Nicholas Clark [mailto:[EMAIL PROTECTED]] > On Thu, Jan 23, 2003 at 10:23:22AM +, Leon Brocard wrote: > > > Useful resources for finding your longitude, latitude: > > If you're in the UK you can get lat and long conversions from > http://www.streetmap.co.uk/ Which is useful, as they let you > look up locations by postcode, OS grid reference and lots of > other things. I await to see how many people this is useful > for. In the US, you can do these lookups by zipcode at: http://tiger.census.gov/cgi-bin/mapbrowse-tbl -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Odd JIT timings
At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote: On Friday 24 January 2003 04:43, Dan Sugalski wrote: I just gave a run of examples/assembly/mops_p.pasm, getting some performance numbers. Here's an interesting timing. no jit: 24.9 seconds with jit: 33.6 seconds This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. Someone care to check it out and poke around a bit? CG vs JIT (running with non jitted opcdes) wins CG, always. Ah, OK. No function preambles/postambles in the CG case. Hrm, time to go learn PPC assembly, I guess... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Bytecode metadata
At 5:32 PM + 1/24/03, Dave Mitchell wrote: On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote: How many mmap's can $arch have for one program and for all? Could we hit some limits here, if every module loaded gets (and stays) mmap()ed. I just wrote a quick C program that successfully mmap-ed in all 1639 files in my Linux box's /usr/share/man/man1 directory. Linux is not the universe, though. And what it'll do depends on the version. We have to worry about Windows and a half-zillion other flavors of Unix, at the very least. IIRC, some versions of BSD weren't too thrilled about a lot of mmaps. Note that in Perl5 we already (indirectly) rely on the OS's ability to mmap in the library code for any XS-based modules. No, we use dlopen, which isn't the same thing at all. It can be, but doesn't have to me. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Odd JIT timings
On Fri, 24 Jan 2003 12:26:10 -0500, Dan Sugalski wrote: >At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote: >>On Friday 24 January 2003 04:43, Dan Sugalski wrote: >>> I just gave a run of examples/assembly/mops_p.pasm, getting some >>> performance numbers. Here's an interesting timing. >>> >>> no jit: 24.9 seconds >>> with jit: 33.6 seconds >>> >>> This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. >>> >>> Someone care to check it out and poke around a bit? >> >>CG vs JIT (running with non jitted opcdes) wins CG, always. > >Ah, OK. No function preambles/postambles in the CG case. Hrm, time to >go learn PPC assembly, I guess... :) IBM hosts a tutorial on Linux PowerPC assembly, with links to instruction set, ABI, and optimization: http://www-106.ibm.com/developerworks/linux/library/l-ppc/ You were probably joking, but my knee jerked :) -- Hope this helps, Bruce Gray
Re: Odd JIT timings
At 12:17 PM -0600 1/24/03, Bruce Gray wrote: On Fri, 24 Jan 2003 12:26:10 -0500, Dan Sugalski wrote: At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote: On Friday 24 January 2003 04:43, Dan Sugalski wrote: I just gave a run of examples/assembly/mops_p.pasm, getting some performance numbers. Here's an interesting timing. no jit: 24.9 seconds with jit: 33.6 seconds This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. Someone care to check it out and poke around a bit? CG vs JIT (running with non jitted opcdes) wins CG, always. Ah, OK. No function preambles/postambles in the CG case. Hrm, time to go learn PPC assembly, I guess... :) IBM hosts a tutorial on Linux PowerPC assembly, with links to instruction set, ABI, and optimization: http://www-106.ibm.com/developerworks/linux/library/l-ppc/ Yow! Cool, thanks! -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [BUG] substr messing up array elt
Steve Fink wrote:
In debugging a regex problem, I gradually whittled a test case down to
the following code. It does roughly:
@a = ('aaa', 'ac');
$x = $a[0];
print $x;
$x = substr("aaacacaaba", 3, 3); # "cac"
$y = $a[0]
print $y;
and prints out
aaa
cac
This is my illegal speed hack for substr/life.pasm giving roughly 50%
more life cycles. Dan did decide, that reusing string headers this way
(and giving strings more object like semantics) isn't. String ought to
be values (which I don't like, it prohibits effectively reusing string
headers)
s. also Subject ~~ "string_set is back"
Anyway:
--- string.cSat Jan 4 11:00:13 2003
+++ /opt/src/parrot-leo/string.cFri Jan 24 20:17:06 2003
@@ -624,7 +624,7 @@
}
/* do in-place i.e. make a COW string */
-#if 1
+#if 0
dest = string_set(interpreter, *d, src);
#else
dest = make_COW_reference(interpreter, src);
leo
Re: Odd JIT timings
Dan Sugalski wrote: At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote: CG vs JIT (running with non jitted opcdes) wins CG, always. Ah, OK. No function preambles/postambles in the CG case. Hrm, time to go learn PPC assembly, I guess... :) Ne need to have a deep understanding of $arch's assembly for implementing the vtable calls. It's almost only: - prepare stack frame - push value - push address - call a vtable function indexed by x - get return value (opt) - save return value (opt) s. jit/i386/jit_emit.h:Parrot_jit_vtable_*() Of course, you should know, how to prepare arguments for function calls and call a function. But debugging an -O3 compiled parrot and "stepi" does help a lot - so did I learn it ;-) And of course: $perldoc docs/jit.pod /Debugging leo
ic cpu specs
Dan Sugalski wrote: > At 12:17 PM -0600 1/24/03, Bruce Gray wrote: > > > >IBM hosts a tutorial on Linux PowerPC assembly, with links to > >instruction set, ABI, and optimization: > >http://www-106.ibm.com/developerworks/linux/library/l-ppc/ > > Yow! Cool, thanks! Also of interest may be: http://www.mit.edu/afs/sipb/contrib/doc/specs/ic/cpu/ -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Odd JIT timings
At 8:14 PM +0100 1/24/03, Leopold Toetsch wrote: Dan Sugalski wrote: At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote: CG vs JIT (running with non jitted opcdes) wins CG, always. Ah, OK. No function preambles/postambles in the CG case. Hrm, time to go learn PPC assembly, I guess... :) Ne need to have a deep understanding of $arch's assembly for implementing the vtable calls. It's almost only: - prepare stack frame - push value - push address - call a vtable function indexed by x - get return value (opt) - save return value (opt) s. jit/i386/jit_emit.h:Parrot_jit_vtable_*() Of course, you should know, how to prepare arguments for function calls and call a function. But debugging an -O3 compiled parrot and "stepi" does help a lot - so did I learn it ;-) Heh, I'm not worried--it certainly won't be the first assembly language I've learned. :) Just a matter of getting the time to do it, which is the bigger problem. Pity the automagic .s parsing code in JITv1 didn't ultimately work out... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Odd JIT timings
Dan Sugalski wrote: At 8:14 PM +0100 1/24/03, Leopold Toetsch wrote: Of course, you should know, how to prepare arguments for function Heh, I'm not worried--it certainly won't be the first assembly language I've learned. :) I knew that. Just a matter of getting the time to do it, which is the bigger problem. And guessed this too :-) ... Pity the automagic .s parsing code in JITv1 didn't ultimately work out... Trial to (ab?)use gcc for generating JIT code, probably. But: mops.pasm: JIT/i386 ~800 MOps at 800 MHz Athlon i.e. 1 op/cycle gcc -O3 (native code) ~300 Mops Of course this doesn't give real time program values, but shows some optimization potential for tight loops where loop variables can be reduced to bo native integers. And of course JIT code is not "J" like just, one code segment get's JITed and no there is no run loop, all instructions need the space they occupy, which is currently (size in bytes, with PBC size in ops): jit.c:838 /* estimate size needed * 10 times pbc code size seems to be enough for i386 */ ... but computers tend to have more RAM, and the more the fast. leo
Re: Array/Colon question
On Friday, January 24, 2003, at 10:10 AM, Brent Dax wrote: # 1 .. $a # 1 .. $a : 2 # $a .. $b # $a .. $b : 2 # $a .. $b : $c # 1 .. 10 : $c # 2.5 .. 10.0 : 0.5 To my knowledge, these are all fine. Thanks, you're right. I was confusing the 'lazy' discussion with the 'range' discussion. All of those should work. As should $a .. Inf but not Inf .. $a :-) MikeL
Re: Multimethod/multisub thought...
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> In my quest to eliminate as many explicit conditionals from my code
> as
> possible, I found myself wondering if Perl 6's multidispatch
> mechanism
> would allow one to write:
>
>sub gmttime ( $time = time() ) is in_scalar_context {
> strftime( $perls_default_time_format, $time );
>}
>
>sub gmttime ( $time = time() ) is in_list_context {
> ...
>}
>
> where 'in_scalar_context' and 'in_list_context' are place holders for
> better syntax.
>
> Thoughts?
I think that if RFC 21 is approved (general-purpose C, with
smartmatch flavors) the information to dispatch these should be
available.
OTOH, it also seems like this is asking for trouble, MMD-wise.
=Austin
Re: Array/Colon question
On Thursday, January 23, 2003, at 02:24 PM, Brent Dax wrote: I suspect that the prototype for '..' is like this: So the 'step' use of colon may _only_ be used in conjunction with a "ranged" list, e.g. C<..>, correct? In _any_ other context, it means something else. In looking at A3, I also can't seem to find anything definitive on the allowed operands to C<..>: specifically, if they can be anything but literals, or integers. Would all of the following therefore be syntax errors? @a : 2 1 .. $a 1 .. $a : 2 $a .. $b $a .. $b : 2 $a .. $b : $c 1 .. 10 : $c 2.5 .. 10.0 : 0.5 MikeL
Re: Multimethod/multisub thought...
At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Array/Colon question
Michael Lazzaro:
# On Thursday, January 23, 2003, at 02:24 PM, Brent Dax wrote:
# > I suspect that the prototype for '..' is like this:
#
# So the 'step' use of colon may _only_ be used in conjunction with a
# "ranged" list, e.g. C<..>, correct? In _any_ other context, it means
# something else.
In *all* contexts, it's a supercomma. C<..> interprets whatever comes
after the supercomma as being a step.
# In looking at A3, I also can't seem to find anything
# definitive on the
# allowed operands to C<..>: specifically, if they can be anything but
# literals, or integers.
They can be variables in Perl 5, so I suspect Perl 6 is fine with it
too.
# Would all of the following therefore be syntax errors?
#
# @a : 2
This isn't a syntax error, but it doesn't do what you want.
# 1 .. $a
# 1 .. $a : 2
# $a .. $b
# $a .. $b : 2
# $a .. $b : $c
# 1 .. 10 : $c
# 2.5 .. 10.0 : 0.5
To my knowledge, these are all fine.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 7:30 AM + 1/24/03, Piers Cawley wrote: > >In my quest to eliminate as many explicit conditionals from my code > as > >possible, I found myself wondering if Perl 6's multidispatch > mechanism > >would allow one to write: > > Okay, I think I remembered the problem. Assume the following: > > list bar(int); # bar takes an int, returns a list > scalar bar(int); # bar takes an int, returns a scalar > > and also assume the following: > > xyzzy(scalar); # xyzzy takes a scalar > xyzzy(list); # xyzzy takes a list > > and then we make the call: > > xyzzy(bar(1)); > > Which bar do we call? And which xyzzy? In theory, if there's a return type expected, we could use that as the final arbiter. If not, but "if it looks like a scalar" ... xyzzy(bar 1); # Scalar xyzzy(bar(1)); # Scalar xyzzy(bar((1))); # List? xyzzy(bar(list(1))); #List xyzzy(bar(scalar(1))); # Scalar Optionally, we whinge about "ambiguous method invocation at line ..." and punt; requiring the user to cast or establish context. Welcome to namespace hell. Woo-hoo! It's just like the C++, only with one more dimension to consider. =Austin
RE: Multimethod/multisub thought...
Dan Sugalski:
# At 7:30 AM + 1/24/03, Piers Cawley wrote:
# >In my quest to eliminate as many explicit conditionals from
# my code as
# >possible, I found myself wondering if Perl 6's multidispatch
# mechanism
# >would allow one to write:
#
# Okay, I think I remembered the problem. Assume the following:
#
# list bar(int); # bar takes an int, returns a list
# scalar bar(int); # bar takes an int, returns a scalar
#
# and also assume the following:
#
# xyzzy(scalar); # xyzzy takes a scalar
# xyzzy(list); # xyzzy takes a list
#
# and then we make the call:
#
# xyzzy(bar(1));
#
# Which bar do we call? And which xyzzy?
This is also a problem with using want().
If we don't provide wants_scalar/wants_list, someone will build it with
want(), so we might as well try to address it. I suggest that want()
return a special value when the calling context is ambiguous, and any
wants_scalar/wants_list property be designed to accommodate this
(probably by specifying which one should be the default).
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
On Fri, Jan 24, 2003 at 10:02:13AM -0800, Austin Hastings wrote: > --- Dan Sugalski <[EMAIL PROTECTED]> wrote: > > At 7:30 AM + 1/24/03, Piers Cawley wrote: > > >In my quest to eliminate as many explicit conditionals from my code > > as > > >possible, I found myself wondering if Perl 6's multidispatch > > mechanism > > >would allow one to write: > > > > Okay, I think I remembered the problem. Assume the following: > > > > list bar(int); # bar takes an int, returns a list > > scalar bar(int); # bar takes an int, returns a scalar > > > > and also assume the following: > > > > xyzzy(scalar); # xyzzy takes a scalar > > xyzzy(list); # xyzzy takes a list > > > > and then we make the call: > > > > xyzzy(bar(1)); > > > > Which bar do we call? And which xyzzy? > > In theory, if there's a return type expected, we could use that as the > final arbiter. > > If not, but "if it looks like a scalar" ... > > xyzzy(bar 1); # Scalar > xyzzy(bar(1)); # Scalar > xyzzy(bar((1))); # List? > xyzzy(bar(list(1))); #List > xyzzy(bar(scalar(1))); # Scalar Strange. I think parameters to subroutines are in list context unless stated otherwise. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: "Arc: An Unfinished Dialect of Lisp"
On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley 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 feeling slightly deflated. Given the chance to re-design > Lisp from scratch, the tasks on the top of my TODO list to address would > be: > >* getting rid of some/all those damn parenthesis >* renaming cons/car/cdr to something meaningful > > Alas, these are about the only parts he's not changing. He promises that > Arc will have a syntax one day, but there isn't one yet. These slides are over a year old. There hasn't been much of Arc since Paul Graham's early musings on it. But one of the things he did do was rename lambda to fn. This is proof that the holy grails can be tossed out of the window. The problem with cons/car/cdr is that they're fundemental operations. Graham *has* learned from perl, and is receptive to the idea that fundemental operators should be huffman encoded (lambda -> fn). It would be easy to simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. Austin mentioned that the syntax has eliminated the need for some of the parens, so that's a start. Perhaps a real syntax can follow. :-) > The other comments that caught my eye were that Arc is designed for > Good Programmers[tm] and that it was particularly targetted at developing > web applications. Alas, my experience seems to suggest that most of > the people writing web applications are monkeys who would rather have > something designed for Bad Programmers, like PHP. "Good Programmers [tm]" has been a theme of Graham's work. Figure that less than 10% of programmers make this cut. Lisp hackers like to assert that good programmers eventually migrate to Lisp or something lisp-like (er, functional). Count up all of the Lisp/Scheme/ML/Haskell programmers you know relative to the total number of programmers, and that's the percentage of web programmers he's targeting. The fact that a good many web programmers want ASP/PHP doesn't really have an impact on what he's trying to do. A bigger problem is that employers demand large numbers of these folks to do the job that someone Good [tm] could do in a day. Alone. While reading email. Z.
RE: Multimethod/multisub thought... [x-adr]
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > Okay, I think I remembered the problem. Assume the following: > > list bar(int); # bar takes an int, returns a list > scalar bar(int); # bar takes an int, returns a scalar > > and also assume the following: > > xyzzy(scalar); # xyzzy takes a scalar > xyzzy(list); # xyzzy takes a list > > and then we make the call: > > xyzzy(bar(1)); > > Which bar do we call? And which xyzzy? So the question is: if the calling context is ambiguous, do we dispatch to the implementation matching: 1) first valid signature w/ warning 2) most valid signature w/ warning 3) default calling context w/ warning 4) exception when ambiguous I'd take what's behind door number 1... Brent Dax wrote: > > This is also a problem with using want(). > > If we don't provide wants_scalar/wants_list, someone will > build it with want(), so we might as well try to address > it. I suggest that want() return a special value when > the calling context is ambiguous, and any wants_scalar/ > wants_list property be designed to accommodate this > (probably by specifying which one should be the default). Where "special value" is a junction: 'scalar' | 'list'? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Multimethod/multisub thought... [x-adr]
Garrett Goebel:
# Brent Dax wrote:
# >
# > This is also a problem with using want().
# >
# > If we don't provide wants_scalar/wants_list, someone will
# > build it with want(), so we might as well try to address
# > it. I suggest that want() return a special value when
# > the calling context is ambiguous, and any wants_scalar/
# > wants_list property be designed to accommodate this
# > (probably by specifying which one should be the default).
#
# Where "special value" is a junction: 'scalar' | 'list'?
Actually, I was thinking C, though a junction of all the possible
contexts might be good too. Remember, want() is more than just
scalar/array now.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
At 10:02 AM -0800 1/24/03, Austin Hastings wrote: --- Dan Sugalski <[EMAIL PROTECTED]> wrote: At 7:30 AM + 1/24/03, Piers Cawley wrote: >In my quest to eliminate as many explicit conditionals from my code as >possible, I found myself wondering if Perl 6's multidispatch mechanism >would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? In theory, if there's a return type expected, we could use that as the final arbiter. If not, but "if it looks like a scalar" ... xyzzy(bar 1); # Scalar xyzzy(bar(1)); # Scalar xyzzy(bar((1))); # List? xyzzy(bar(list(1))); #List xyzzy(bar(scalar(1))); # Scalar There's also the fun of: Dog bar(int); Cat bar(int); and xyzzy(Dog); xyzzy(Cat); with the call of: xyzzy(bar(1)); Just one of the many brain-benders that I'm glad Larry has to deal with, not me. (Though this may be one of the reasons A6 is taking so long...) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod/multisub thought...
On Fri, Jan 24, 2003 at 10:15:48AM -0800, Brent Dax wrote: > Dan Sugalski: > # Okay, I think I remembered the problem. Assume the following: > # > # list bar(int); # bar takes an int, returns a list > # scalar bar(int); # bar takes an int, returns a scalar > # > # and also assume the following: > # > # xyzzy(scalar); # xyzzy takes a scalar > # xyzzy(list); # xyzzy takes a list > # > # and then we make the call: > # > # xyzzy(bar(1)); > # > # Which bar do we call? And which xyzzy? > > This is also a problem with using want(). > > If we don't provide wants_scalar/wants_list, someone will build it with > want(), so we might as well try to address it. I suggest that want() > return a special value when the calling context is ambiguous, and any > wants_scalar/wants_list property be designed to accommodate this > (probably by specifying which one should be the default). What? A junction of all the possible contexts valid here? Nicholas Clark
RE: Multimethod/multisub thought...
From: Brent Dax [mailto:[EMAIL PROTECTED]] > Garrett Goebel: > # Brent Dax wrote: > # > > # > This is also a problem with using want(). > # > > # > If we don't provide wants_scalar/wants_list, someone will > # > build it with want(), so we might as well try to address > # > it. I suggest that want() return a special value when > # > the calling context is ambiguous, and any wants_scalar/ > # > wants_list property be designed to accommodate this > # > (probably by specifying which one should be the default). > # > # Where "special value" is a junction: 'scalar' | 'list'? > > Actually, I was thinking C, though a junction of all > the possible contexts might be good too. Remember, want() > is more than just scalar/array now. sure, sure... I was ambiguously referring back to Dan's example, were xyzzy(scalar) and xyzzy(list) were the only valid options. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Multimethod/multisub thought...
Garrett Goebel:
# From: Brent Dax [mailto:[EMAIL PROTECTED]]
# > Actually, I was thinking C, though a junction of all
# > the possible contexts might be good too. Remember, want()
# > is more than just scalar/array now.
#
# sure, sure...
#
# I was ambiguously referring back to Dan's example, were
# xyzzy(scalar) and
# xyzzy(list) were the only valid options.
Ah. Then yes, that would be fine.
I suggest that we might require a special property to say "dispatch on
return value", which would give us a place to put in some information to
resolve conflicts.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
Dan Sugalski wrote: > There's also the fun of: > > Dog bar(int); > Cat bar(int); > > and > > xyzzy(Dog); > xyzzy(Cat); > > with the call of: > > xyzzy(bar(1)); > > Just one of the many brain-benders that I'm glad Larry has to deal > with, not me. (Though this may be one of the reasons A6 is taking so > long...) > -- Ada handles this kind of problem. This is what used to be called operator overloading, before the phrase was coopted by C++ (before C++ came along, the limited version of operator overloading used in C++ was called *operand* overloading, since you're only allowed to overload based on operand types). To disambiguate a call in the presence of full operator overloading, two full complete passes over the expression tree are required. The first pass is a bottom-up pass to collect all the potential return types; the second is a top-down pass that uses the context to eliminate some (hopefully all but one) of the available return types computed in the first pass. In Ada, if the second pass doesn't completely disambiguate the expression, it's considered an error. I studied this stuff for my masters thesis, for which I added (Ada style) operator overloading to a Modula-2 compiler. When it was all over, I decided that I much prefer (C++ style) operand overloading. The computation to decide what the programmer meant is too complicated. For the user, not the compiler. Although the compiler can do it [the code is bulky, but not difficult to understand], I think that the programmer will be left in the dust. And I think that's a bad thing. In all but the simplest cases, the coder will have a very difficult time figuring out what the compiler's actually going to do. As a matter of fact, I always thought that C was a nice compromise: let the programmer decide exactly what to do in the small number of cases where it's really useful. So here's *my* vote against return-type multi-method disambiguation. =thom "Don't use that word [fantastic] to a lawyer; straining at gnats and swallowing camels is a required course in law school" -- _Stranger_in_a_Strange_Land_
Re: "Arc: An Unfinished Dialect of Lisp"
> The problem with cons/car/cdr is that they're fundemental operations. > Graham *has* learned from perl, and is receptive to the idea that > fundemental operators should be huffman encoded (lambda -> fn). It > would be easy to simply rename car/cdr to first/rest, but that loses > the huffman nature of car/cdr. hmm...ML uses hd and tl. I believe that is pretty coded :)
Re: "Arc: An Unfinished Dialect of Lisp"
On Fri, Jan 24, 2003 at 01:00:26PM -0500, Tanton Gibbs wrote: > > The problem with cons/car/cdr is that they're fundemental operations. > > Graham *has* learned from perl, and is receptive to the idea that > > fundemental operators should be huffman encoded (lambda -> fn). It > > would be easy to simply rename car/cdr to first/rest, but that loses > > the huffman nature of car/cdr. > > hmm...ML uses hd and tl. I believe that is pretty coded :) Good point. I've used Scheme and Lisp, but not ML... Z.
RE: Multimethod/multisub thought...
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> I suggest that we might require a special property to say "dispatch
> on return value", which would give us a place to put in some
> information to resolve conflicts.
In keeping with the notion of "a language for good programmers," I
think that the very act of defining two methods which are equivalent in
all but name is pretty much a deliberate statement of intent to
"dispatch on return value."
Perhaps an "is ambiguous" keyword to stuff the warning which we should,
in all fairness, emit for those who didn't actually mean what they
typed.
In the event that two modules export functions that collide, the
warning should prompt the user to add:
Dog bar($p is int) is ambiguous is default;
==
10 minutes and a visit to RFC-land later, I have some guy named after a
70's comedian writing:
http://dev.perl.org/rfc/256.html#Handling_dispatch_failure
However, experience indicates that sometimes the more specialized
variants of a multimethod are only provided as optimizations, and a
more general variant (in this case, the (Peg,Hole) variant) would
suffice as a default where such an ambiguity exists. It is proposed
that an additional parameterized attribute -- :default(ambiguous) -- be
provided so that one particular multimethod can be nominated as the
dispatch recipient in cases of ambiguity:
sub put_peg(Peg,Hole) : multi default(ambiguous) {
print "some kinda peg in some kinda hole\n"
}
Now, whenever a call to put_peg can't be dispatched because it's
ambiguous, this default variant will be called, rather than throwing an
exception.
==
Man, it gripes my wagger when he gets there first... :-/
Where two xyzzy functions could invoke different bar functions, the
list of bar() multis to invoke is as above, and the dispatch distance
is 1 in each case.
So either there is a C or there's an
exception.
Look, the water still beads!
=Austin
Re: "Arc: An Unfinished Dialect of Lisp"
Adam Turoff <[EMAIL PROTECTED]> writes: > On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley 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 feeling slightly deflated. Given the chance to re-design >> Lisp from scratch, the tasks on the top of my TODO list to address would >> be: >> >>* getting rid of some/all those damn parenthesis >>* renaming cons/car/cdr to something meaningful >> >> Alas, these are about the only parts he's not changing. He promises that >> Arc will have a syntax one day, but there isn't one yet. > > These slides are over a year old. There hasn't been much of Arc since > Paul Graham's early musings on it. But one of the things he did do was > rename lambda to fn. This is proof that the holy grails can be tossed > out of the window. > > The problem with cons/car/cdr is that they're fundemental operations. > Graham *has* learned from perl, and is receptive to the idea that > fundemental operators should be huffman encoded (lambda -> fn). It > would be easy to simply rename car/cdr to first/rest, but that loses > the huffman nature of car/cdr. ISTR that he was also a fan on the 'composibility' of car and cdr, giving operators like (caar list), which means (car (car list)). I can see where he's coming from, but I can also see that those tricks could also be dismissed as clever dickery.
AW: Multimethod/multisub thought...
> Strange. I think parameters to subroutines are in list > context unless stated otherwise. > > -Scott I agree. Do we miss something ? Murat
Re: Bytecode metadata
On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:
> Are you expecting to have chunk type determined by order? If so, what
> will you do if a future restructuring means you either don't need chunk
> type X or you need a new, highly incompatible version? Will you leave
> in an "empty" ghost chunk?
>
> I would suggest (roughly) the following format for a chunk:
>
> TYPE: One 32-bit number
> VERSION: One 32-bit number; suggested usage is as four eight-bit
> components
> SIZE: One 32-bit number of bytes (or maybe 64-bit)
> DATA: arbitrary length
>
> For C-heads, think of it like this:
>
> struct Chunk {
> opcode_t type;
> opcode_t version;
> opcode_t size;
> void data[];
> };
I agree with the "roughly" bit, but I'd suggest ensuring that you put
in enough bits to get data[] 64 bit aligned. Mainly because at least 1
architecture exists that has no 32 bit types (Crays I know about; others
may exist. I can't remember if perl 5.8 passes 100% of tests on Crays.
We certainly tried)
> If there's a directory of some sort, it should record the type ID and
> the offset to the beginning of the chunk. This should allow for a
> fairly quick lookup by type. If you think that there might be a demand
> for multiple instances of the same type of metadata, you may want to add
> a chunk ID of some sort.
It might be useful for making "portable" fat bytecode.
On Thu, Jan 23, 2003 at 01:39:03PM -0500, Dan Sugalski wrote:
> At 10:29 PM -0800 1/22/03, James Michael DuPont wrote:
> >You will probably think that this is overkill for parrot,
>
> Why yes, yes I do. On the other hand, when we hand people bazookas to
> deal with their fly problems, we often find they start in on the
> elephant problems as well.
No wonder the rolls of sticky elephant paper never sold.
> The proposal in general interests me--it looks like a general
> annotation system we can attach to the bytecode. (I admit, I haven't
> read the page you pointed at) I will admit, though, that I was
> thinking more about metadata that the engine could use itself, or
> would provide to programs running on it, but the scheme you've
> outlined may be useful for that.
I'm thinking that register usage information from imcc could be of use
to the JIT, as that would save it having to work out things again. So that
probably needs a segment.
Also some way of storing a cryptographic signature in the file, so that you
could compile a parrot that automatically refuses to load code that isn't
signed by you.
On Thu, Jan 23, 2003 at 05:05:54PM -0500, Dan Sugalski wrote:
> Which will generally be the case, I expect. Tell a sysadmin that they
> can reduce the memory footprint of mod_parrot by 50% by running a
> utility (that we provide in the parrot kit) over the library and I
> expect you'll see smoke from the keyboard as he/she whips off the
> command at supersonic speeds... :)
Followed by writs for claims for supersonic RSI addressed to p6i
On Fri, Jan 24, 2003 at 07:59:13AM +0100, Leopold Toetsch wrote:
> Juergen Boemmels wrote:
>
> >Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> >It might be even possible to dump the jitted code. This would increase
> >the startup. Then strip the bytecode to reduce the size of the file
> >and TADA: Yet another new binary format.
>
>
> When you then are able to to get the same memory layout for a newly
> created interpreter, it might even run ;-)
So the JITted code contains lots of hard references to address in running
interpreter? It's not just dependent on that particular binary's layout?
I guess in future once the normal JIT works, and we've got the pigs flying
nicely then it would be possible to write a Not Just In Time compiler that
saves out assembly code and relocation instructions.
Bah. That's "parrot -o foo.o foo.pmc" isn't it?
Nicholas Clark
Re: Transferring control between code segments, eval, and suchlike things
On Thu, Jan 23, 2003 at 12:11:20AM -0500, Dan Sugalski wrote: > Every sub doesn't have to fit in a single segment, though. There may > well be a half-zillion subs in any one segment. (Though one segment > per sub does give us some interesting possibilities for GCing unused > code) For an interpreter that is allowing eval (or a namespace that isn't locked against eval) I think that you could only GC the old definition of redefined subroutines, and any anonymous subroutines that become unreferenced. Anything else is the potential lucky destination of a random future eval. Nicholas Clark
