Re: [INFO] Buffer/PMC unification
Leopold Toetsch wrote: I will start $subject soon. This will generate a lot of changes in CVS. The first of a bunch of patches is in. (If you want to shorten rebuild times, please install ccache - great tool) - BUFER_*_FLAGs have moved to the new include/parrot/pobj.h - string.c is done All direct access to buffer->flags or pmc->flags is deprecated, when all is done. Accessor macros in pobj.h should be used instead: e.g. PObj_external_TEST(o), PObj_external_SET(o), PObj_external_CLEAR(o) for testing, setting and clearing the flag "external" for a PObj "o". For commonly used combinations of flags there are special macros like: PObj_is_cowed_TESTALL(o). The flags themself can be accessed by: PObj_get_FLAGS(o). leo
Re: right-to-left pipelines
Michael Lazzaro asked:
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Hmm. Does operator precedence allow that?
I don't think the method-call syntax allows it. I think methods
need their parens. So we need:
(@foo, @bar) := @a
. grep( { $_ > 0} )
. sort( { $^b <=> $^b } )
. part( [/foo/, /bar/] );
which is no huge imposition.
On the other hand, my C proposal doesn't require parens at all. ;-)
Damian
how to code a lazy pipeline?
How would one most nicely code what I'll call a lazy pipeline, such that the first result from the final element of the pipeline can appear as soon as the first result has been processed from the intervening elements? -- ralph
Re: right-to-left pipelines
[EMAIL PROTECTED] (Damian Conway) writes:
> I don't think the method-call syntax allows it. I think methods
> need their parens. So we need:
>
> (@foo, @bar) := @a
> . grep( { $_ > 0} )
> . sort( { $^b <=> $^b } )
> . part( [/foo/, /bar/] );
*Why* do methods need their parens? If methods can be specified to possibly
take a block, such as grep and sort do, then they shouldn't need parens.
Or at least, I know a language in which this is possible... :)
--
"Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats."
-- Howard Aiken
Re: [INFO] Buffer/PMC unification
Leopold Toetsch wrote: I will start $subject soon. Next piece. BUFFER_*_FLAGs and PMC_*_FLAGs are now united, same things have the same value. Please do a "make clean" after check out due to lacking dependencies in classes. BTW what are the BUFFER_needs_GC_FLAG / PMC_private_GC_FLAG. Are these a synonym for active_destroy_FLAG? leo
Re: [INFO] Buffer/PMC unification
Next one. #3. The ugly, everywhere warning producing, static buffer_lives() went to dod.c where it belongs to. leo
Re: how to code a lazy pipeline?
On 12/10/2002 4:54 AM, Me wrote:
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
I belive the short answer is "make sure all elements of your pipeline
return a lazy list". Exactly how one does this, and the distinction
between a lazy list and an iterator, I belive is still somwhat up in the
air. (If I'm wrong, please correct me.)
IOW:
foreach (map {$_+1} grep {$_>0} @foo but lazy) {
do_somthing_here($_);
die "Bye-bye universe!" if ($_=42);
}
Will never compute anything after the first 41 element in @foo occours.
(I'm assuming map, grep, and any other list-oriented function that can
get away with it will act lazily when given a lazy-list argument.)
-=- James Mastros
Re: right-to-left pipelines
On 10 Dec 2002 11:41:23 +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Damian Conway) writes:
> > I don't think the method-call syntax allows it. I think methods
> > need their parens. So we need:
> >
> > (@foo, @bar) := @a
> > . grep( { $_ > 0} )
> > . sort( { $^b <=> $^b } )
> > . part( [/foo/, /bar/] );
>
> *Why* do methods need their parens? If methods can be specified to possibly
> take a block, such as grep and sort do, then they shouldn't need parens.
> Or at least, I know a language in which this is possible... :)
To know whether the method takes a block, you need to know how it's been
declared. In other words, the type of @a needs to be known to find grep's
declaration. In turn, grep must specify its return type in order to find
sort's declaration, and sort must specify its return type so that part's
declaration may be found.
That's all fine for the standard/builtin methods on arrays, but its a bit
unperl-like to force users to highly specify everything. Of course, if they
do declare methods with all the bells and whistles, they get the benefit of
not having to use parens later on.
--
Peter Haworth [EMAIL PROTECTED]
"Although they all look the same to me, doormats and other furnishings
probably have a strict social heirarchy. Every chair a god. Every item
of pottery from the Franklin mint, an angel. Man, I love decor."
-- Ashley Pomeroy
Re: right-to-left pipelines
[EMAIL PROTECTED] (Peter Haworth) writes: > To know whether the method takes a block, you need to know how it's been > declared. In other words, the type of @a needs to be known to find grep's > declaration. Well, that's what always happens on a method call. > In turn, grep must specify its return type in order to find > sort's declaration, No, not at all. As I've said, you assume that all methods *can* take a block. -- What would happen if you ran up to Hitler and mentioned Usenet? - Kibo
Re: right-to-left pipelines
On 10 Dec 2002 15:34:11 +, Simon Cozens wrote: > [EMAIL PROTECTED] (Peter Haworth) writes: > > To know whether the method takes a block, you need to know how it's been > > declared. In other words, the type of @a needs to be known to find > > grep's declaration. > > Well, that's what always happens on a method call. At run time, yes. However, at compile time, due to Perl's dynamic nature, you don't know how methods have been declared unless the programmer is using the optional B&D features. > > In turn, grep must specify its return type in order to find sort's > > declaration, > > No, not at all. As I've said, you assume that all methods *can* take > a block. Fair enough; that simplifies things somewhat. However, you can't tell how many arguments they take. How do you parse this without the programmer specifying a great deal more than they're used to in Perl 5? $foo.bar $baz,$qux Is it $foo.bar($baz),$qux or $foo.bar($baz.$qux) or even a syntax error (though this would require bar()'s declaration to be known at compile time): $foo.bar() $baz,$qux -- Peter Haworth [EMAIL PROTECTED] Spider Boardman: I'm having fun with it. Dan Sugalski: Inside the [perl] tokenizer/lexer? This has got to be the scariest thing I've heard in a long time. You are a sick, sick man.
Re: right-to-left pipelines
[EMAIL PROTECTED] (Peter Haworth) writes: > Fair enough; that simplifies things somewhat. However, you can't tell how > many arguments they take. How do you parse this without the programmer > specifying a great deal more than they're used to in Perl 5? > > $foo.bar $baz,$qux I see no block here. I'm just talking about passing a block to a method. You think I'm talking about a clever way of specifying a block's argument signature. I'm not. -- These days, if I owned the M$ division that built Lookout and SexChange, I'd trade it for a dog, and then I'd shoot the dog. - Mike Andrews, asr.
Re: [INFO] Buffer/PMC unification
Changes #4 and #5 are in. This completes the changes on BUFFER_*_FLAGs. leo
Re: A work list! (Coming soon)
On Mon, Dec 09, 2002 at 01:40:37PM -0500, Dan Sugalski wrote:
> What I'd like is for folks to take the next day or three to think of
> the things that they need parrot to do that aren't working or
> designed yet, and throw them at the list. (Try against the latest
> CVS, just to make sure that it's not gotten done when you weren't
> looking) In the mean time I'll work on my list, and we'll get a Big
> List 'O Things, throw them into RT, and start digging through them.
This is possibly a big stuff wish list. I'm not sure how many are on the "maybe
never" list.
Apart from the obvious ("moon on a stick", "a pony", "Quantum Larry (writing
the apocolypses in parallel universes in constant time)") I'd like
Exceptions that can be thrown from C
Regression tests for all the ops (even if not all the cases within them)
Regression tests that cause 100% code coverage (that's probably impossible to
ever get to, but it's a number to aim at)
A unified parrot bytecode generation library (probably in C, but with a perl
interface)
The assembler, IMCC and anything else all using the unified bytecode generation
library
No C compiler warnings on a single platform
No C compiler warnings on any platform
ppc linux to pass (copying varargs issue; probably not hard)
JIT to be aware of different sized integers, floats
computed goto core to compile with less resources
all the little languages that have test suites to be built and run as part of
the tinderbox (with a target in the standard makefile to do this)
JIT to be run as part of the tinderbox (I don't think it is currently)
Fleshing out what parrot IO should do. Particularly how it relates to async IO,
event loops, and the perl5.8 IO layer system
A Java bytecode to parrot bytecode translator
Loading dynamic opcode libraries
Foreign opcode translation (at load time or runtime)
A z-code interpreter (based on the two previous items)
Implementation of an existing general purpose scripting language on parrot
(such as Python or Ruby)
I may have forgotten some things :-)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: String Literals, take 3
On Thu, 05 Dec 2002 15:17:57 -0500, Joseph F. Ryan wrote:
> Again, C<< "STRING".split(' ') >> is different than
> C<< "STRING".split(/\s+/) >>. The latter will add an empty element to
> the beginning of the string if there is leading whitespace, which is
> not the behaivor <<>> will have (if it acts like qw(), at any rate.)
I hate this special case. Why is there no way of specifying the removal of
leading empty elements with any other separator string?
--
Peter Haworth [EMAIL PROTECTED]
"[Microsoft is] a potential threat to our nation's economic well-being."
-- Stanley Sporkin
Re: right-to-left pipelines
On 10 Dec 2002 17:25:34 +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Peter Haworth) writes:
> > Fair enough; that simplifies things somewhat. However, you can't tell
> > how many arguments they take. How do you parse this without the
> > programmer specifying a great deal more than they're used to in Perl 5?
> >
> > $foo.bar $baz,$qux
>
> I see no block here. I'm just talking about passing a block to a method.
> You think I'm talking about a clever way of specifying a block's argument
> signature. I'm not.
Actually, I was accepting your point about block arguments not needing
parens, and generalising it to other kinds of arguments.
You want this to work:
@b = @a.grep { /\S/ };
instead of/as well as this:
@b = @a.grep( { /\S/ } );
I can agree that it's much cleaner looking. However, I want to be sure that
it doesn't introduce ambiguity. If the programmer wants $c on the end, and
writes this:
@b = @a.grep { /\S/ }, $c;
how does the compiler know whether $c is an argument to grep, or another
element to be assigned to @b?
Maybe a method can either be called with a parenthesised argument list, no
arguments (without parens), or with a single paren-less block. That also
gets around the chaining issue of:
@a.grep { /\S/ }.grep { .foo };
If the block is surrounded by implicit parens, that stops it getting
parsed as:
@a.grep( { /\S/ }.grep( { .foo } ));
Anyway, my point was that methods with paren-less arguments are either
ambiguous or greedy, unless you restrict the types of arguments this
applies to. If it's just blocks, them I'm fine with it.
--
Peter Haworth [EMAIL PROTECTED]
"The usability of a computer language is inversely proportional to the
number of theoretical axes the language designer tries to grind."
-- Larry Wall
Re: Partially Memoized Functions
On Tue, Dec 10, 2002 at 01:53:28PM +1100, Damian Conway wrote:
> And in those rare cases where you really do need partial caching, the
> simplest solution is to split the partially cached subroutine into a
> fully cached sub and an uncached sub:
>
> sub days_in_month(Str $month, Int $year)
> {
> $month = lc $month;
> if $month eq 'feb'
> {
> my sub feb_days (Int $year) is cached {
> my $leap = $year % 4 == 0
> && ($year % 100 != 0 || $year % 400 == 0);
> return $leap ? 29 : 28;
> }
> return feb_days($year);
> }
>
> else
> {
> # Simple look-up, so caching would be counter-productive:
> return %days{$month}; # %days was declared above (honest)
> }
> }
I don't think that works correctly. This will create a new cached
sub each time $month eq 'feb'? That'll generate a lot of cached
subs, values will be calculated each time $month eq 'feb, and none
of the values will ever be returned from any of those caches.
Schwern's approach of factoring out days_in_feb into a cached sub
is the same basic idea, and doesn't have this issue.
Z.
Re: Partially Memoized Functions
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote: > --- Adam Turoff <[EMAIL PROTECTED]> wrote: > > It doesn't matter whether some of the values are cheap lookups > > while other values are "complex calculations". Once a cached sub > > is called with a set of parameter values, the return value will > > always be a cheap lookup in the memoized sub's cache. > > You may get some disagreement from those for whom memory is neither > virtual nor free. Memoization is simply the exchange of cheap memory lookups for complicated calculations. If memory is more precious than a few CPU cycles, then you shouldn't be memoizing. Z.
Re: Partially Memoized Functions
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
> --- Adam Turoff <[EMAIL PROTECTED]> wrote:
> > I think you're trying to overoptimize something here. I can't see
> > a benefit to caching only sometimes. If there is, then you probably
> > want to implement a more sophisticated cache management strategy
> > for your sub, not warp the language for a special case.
>
> Ahh. This is better. How does one implement a more sophisticated cache
> management strategy?
By memoizing specific cases by hand, of course. :-)
> That is, what is the mechanism for manipulating the run-time system
> behavior of subs?
Memoization does not have to involve manipulating runtime behavior.
However, manipulating runtime behavior is a simple, generic and
effective way to memoize random subs.
Here's an example of a memoizing only the values for 'feb'.
Schwern's solution is simpler and easier to read though.
{
## start of a lexical scope to hide %feb_cache
my %feb_cache;
sub days_in_month(Str $month, Int $year) {
$month = lc $month;
if $month eq 'feb' {
unless $feb_cache{$year} {
my $leap = $year % 4 == 0
&& ($year % 100 != 0 || $year % 400 == 0);
$feb_cache{$year} = $leap ? 29 : 28;
}
return $feb_cache{$year};
} else {
return %days{$month};
}
}
}
Z.
Re: Partially Memoized Functions
On Mon, Dec 09, 2002 at 02:20:01PM -0800, Austin Hastings wrote: > --- Paul Johnson <[EMAIL PROTECTED]> wrote: > > How about the same way as one would do it now? Presumably we won't > > all > > forget how to program when Perl 6 comes out. > > I think you've missed the point. The original poster (Smylers) asked if > there was a benefit to only cacheing certain values, presuming the > remainder would be either trivial to compute or internally cached, or > both. I think *you've* missed the point. There's not enough benefit to support "caching certain values" through linguistic warping. That technique is possible, and it's the kind of solution that is better suited to (1) hand-rolling a cache management strategy, or (2) refactoring the code to work with standard memoization. The best solutions involve caching all of the values returned by this function (ignoring the possible waste as insignificant), or refactoring the code so that "all of the meaningful values" are cached (and computed by a separate cached sub). Z.
Multmethods by arg-value
I was reading the "Partially Memorized Functions" thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub days_in_month( Str $month, Int $year )
{
...
}
sub days_in_month( Str $month is value{ rx:i/feb[ruary]?/ }, Int $year ) is
cached
{
...
}
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
Re: Multmethods by arg-value
On Tue, Dec 10, 2002 at 11:37:58AM -0800, David Whipp wrote:
> I was reading the "Partially Memorized Functions" thread, and the thought
> came to mind that what we really need, is to define a different
> implementation of the method for a specific value of the arg. Something
> like:
>
> sub days_in_month( Str $month, Int $year )
> {
> ...
> }
>
> sub days_in_month( Str $month is value{ rx:i/feb[ruary]?/ }, Int $year ) is
> cached
> {
> ...
> }
That strikes me as a lot of bugs waiting to happen.
What happens when you have multiple values that would match a given
parameter?
What happens when some module you don't even see loads a variant
of a sub you declare that matches some of the arguments you expected
to process?
XSLT has something similar. The rules are subtle and easy to mess
up. The XSLT spec also states that defining multiple subs (templates)
that could match a piece of input is an error, but may be resolved
by a specific algorithm (last definition prevails). I'm not so
sure I like that behavior in Perl; it's all too easy to create new
subs at runtime...
Z.
RE: right-to-left pipelines
Peter Haworth:
# @b = @a.grep { /\S/ }, $c;
#
# how does the compiler know whether $c is an argument to grep,
# or another element to be assigned to @b?
The same way it does when it sees a normal sub?
I know, late binding and all that. But when you think about it, a lot
can be done to simulate the conditions otherwise. For example, with a
definition like this:
class Foo {
method bar($self: $baz) { ... }
}
And a call like this:
@b=$foo_obj.bar $baz, $quux;
Where we can see *at runtime* that $quux is too many arguments, we can
just append it to the end of bar()'s return value. (This would only
happen when there were no parentheses.) Similarly, with:
class Foo {
method bar($self: HASH $baz) { ... }
}
And:
%b=foo_obj.bar { baz() };
We can call the closure and construct a hashref from the value.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: right-to-left pipelines
On Tue, Dec 10, 2002 at 01:02:18PM -0800, Brent Dax wrote:
> Peter Haworth:
> # @b = @a.grep { /\S/ }, $c;
> #
> # how does the compiler know whether $c is an argument to grep,
> # or another element to be assigned to @b?
>
> The same way it does when it sees a normal sub?
>
> I know, late binding and all that. But when you think about it, a lot
> can be done to simulate the conditions otherwise. For example, with a
> definition like this:
>
> class Foo {
> method bar($self: $baz) { ... }
> }
>
> And a call like this:
>
> @b=$foo_obj.bar $baz, $quux;
>
> Where we can see *at runtime* that $quux is too many arguments, we can
> just append it to the end of bar()'s return value. (This would only
> happen when there were no parentheses.)
Seems to me that you just gave a really good argument for requiring
the parentheses.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: right-to-left pipelines
Jonathan Scott Duff:
# > Where we can see *at runtime* that $quux is too many
# arguments, we can
# > just append it to the end of bar()'s return value. (This
# would only
# > happen when there were no parentheses.)
#
# Seems to me that you just gave a really good argument for
# requiring the parentheses.
I've always hated that methods are treated so differently from subs. It
trips me up constantly, and I'd like to see it changed. Such a thing
can be done. The cop-out may be easier--but is it the *right* way to do
this language? If we wanted an easy language to implement, we would
have stuck with something that looks and feels like C. Perl is designed
to make the *programmer*'s life easier, not the implementer's.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Naiive .const directive for imcc
Leo --
I tried my hand at adding a naiive (that is, incorrect) version of
.const =
to imcc. I'm forwarding the patch. What it does is combine the
creation of the identifier with the assignment of the value. It is
incorrect (of course) because it uses a register, when it should
not be necessary to assign a register. Although, I suppose a
later version of imcc could determine that there was a single
assign of a literal value to the register and optimize it away,
substituting the constant literal value...
This is useful for the .imc that jakoc generates to reflect the
intended semantics (even though right now its generating
using a register rather than the smarter way).
I did not commit the changes, since I don't "own" the imcc
goals, design, or implementation. If you think this is consistent
with the goals and design of imcc, though, either I can commit
it, or you could apply the patch
Also, the patch does not include changes to the documentation,
although that would not be hard.
--
I don't know where to start to add the ability to have .locals declared
in the straight line code be accessible (like globals) inside .subs.
But, this also is a critical feature before I can commit the latest jakoc
code, since using multiple .subs instead of the one big bracketing
one like I used to is now thwarting my use of .local for *all* symbolics.
Can you provide any assistance/guidance here? If you think imcc
already supports other ways (that is, ways that are more correct,
rather than just workarounds -- I could work around it by going back
to my old "outer .sub only" approach) of doing what I'm trying, I'm
eager to learn...
Regards,
-- Gregor
Index: imcc.l
===
RCS file: /cvs/public/parrot/languages/imcc/imcc.l,v
retrieving revision 1.18
diff -u -r1.18 imcc.l
--- imcc.l 7 Dec 2002 13:29:59 - 1.18
+++ imcc.l 10 Dec 2002 19:34:31 -
@@ -93,6 +93,7 @@
".namespace"return(NAMESPACE);
".endnamespace" return(ENDNAMESPACE);
".local"return(LOCAL);
+".const"return(CONST);
".param"return(PARAM);
"end" return(END);
"goto" return(GOTO);
Index: imcc.y
===
RCS file: /cvs/public/parrot/languages/imcc/imcc.y,v
retrieving revision 1.34
diff -u -r1.34 imcc.y
--- imcc.y 10 Dec 2002 08:55:14 - 1.34
+++ imcc.y 10 Dec 2002 19:34:31 -
@@ -367,7 +367,7 @@
}
%token CALL GOTO ARG PRINT IF UNLESS NEW END SAVEALL RESTOREALL
-%token SUB NAMESPACE ENDNAMESPACE CLASS ENDCLASS SYM LOCAL PARAM
+%token SUB NAMESPACE ENDNAMESPACE CLASS ENDCLASS SYM LOCAL CONST
PARAM
%token INC DEC
%token SHIFT_LEFT SHIFT_RIGHT INTV FLOATV STRINGV DEFINED LOG_XOR
%token RELOP_EQ RELOP_NE RELOP_GT RELOP_GTE RELOP_LT RELOP_LTE
@@ -470,6 +470,7 @@
| if_statement
| NAMESPACE IDENTIFIER{ push_namespace($2); }
| ENDNAMESPACE IDENTIFIER { pop_namespace($2); }
+| CONST { is_def=1; } type IDENTIFIER '=' var { $$ = MK_I("set",
R2(mk_ident($4, $3), $6)); is_def=0; }
| LOCAL { is_def=1; } type IDENTIFIER { mk_ident($4, $3);is_def=0;
}
| PARAM { is_def=1; } type IDENTIFIER { $$ = MK_I("restore",
R1(mk_ident($4, $3)));is_def=0; }
Index: t/syn/namespace.t
===
RCS file: /cvs/public/parrot/languages/imcc/t/syn/namespace.t,v
retrieving revision 1.1
diff -u -r1.1 namespace.t
--- t/syn/namespace.t7 Dec 2002 13:30:02 - 1.1
+++ t/syn/namespace.t10 Dec 2002 19:34:31 -
@@ -6,8 +6,7 @@
##
output_is(<<'CODE', <<'OUT', "namespace 1");
.sub _foo
-.local int x
-x = 5
+.const int x = 5
.namespace A
.local int x
x = 3
Re: A work list! (Coming soon)
If memory serves me right, Nicholas Clark wrote: > A Java bytecode to parrot bytecode translator Oh... the horror ... ! ... I wrote the entire JVM loading features of JILC (now in jilc.sf.net, because the savannah project got removed from inactivity).. I'm not working on or doing anything similar like the JILC (more due to being unmentioned on their website, than boredom) . Having said all that ... It would be good to wait for the Object stuff to start working before starting with something like this ... I'd think that having 32 Object registers (or are they going to be special PMCs ?), and the spillover tactics of imcc can take you there ... The question here, why would you need it ? ... (other than running Swing). A real Java compiler is more flexible and a better tool when it comes to optimized codegeneration ... Life was too simple when iload_0 iload_1became $I0=LOCVAR_I0 + LOCVAR_I1; iadd Let's move on a bit before planning this out ... (thankfully mapping 256 opcodes to a sparse set of 4 G opcodes is comparitively easier)... Gopal -- The difference between insanity and genius is measured by success
Parrot v0.0.9 code freeze
Heads up. The weather report indicates a feature freeze on Sat 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to a release on Wed 2002-Dec-18. So if you have any feature changes that you want to get into 0.0.9 (and it isn't too destabilizing), please commit them before Saturday. Sometime between now and then, I'll compile a list of changes since 0.0.8. This release will go out even if the tinderbox isn't completely green, because I don't want to delay it any further, but I would greatly appreciate any improvements in that area. Feel free to use http://foxglove.dnsalias.org/parrot/ to get a snapshot view of what tests are failing.
Re: String Literals, take 3
Peter Haworth wrote:
On Thu, 05 Dec 2002 15:17:57 -0500, Joseph F. Ryan wrote:
Again, C<< "STRING".split(' ') >> is different than
C<< "STRING".split(/\s+/) >>. The latter will add an empty element to
the beginning of the string if there is leading whitespace, which is
not the behaivor <<>> will have (if it acts like qw(), at any rate.)
I hate this special case. Why is there no way of specifying the removal of
leading empty elements with any other separator string?
Given that strings and regular expressions are different types of
objects, maybe the "single whitespace" rule could be extended to
any single character delimeter; e.g.:
@one = "|||x|h|i".split('|');
# @one = ('x','h','i');
@two = "|||x|h|i".split(/\|/);
# @two = (,'','','','x','h','i');
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Partially Memoized Functions
Michael G Schwern wrote: > On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote: > > > That way a function could decide to cache some return values but not > > all of them. > > The example above is a classic example of premature optimization. > There's nothing which ways the cache would be counter-productive for > simple calculations since the caching logic is nearly as simple. OK. There was something on MJD's QOTW recently where using the current Perl 5 Memoize module slowed code down -- that gave me the impression that caching had the potential. > However, if you *really* want to do partial caching and given that > this is an edge case, ... It wasn't supposed to be claiming to be a serious function where caching would be useful! > I'd say to just do it as two functions Yeah, I thought of that (thanks for bothering to write it out) then I thought of having the caching be per-C and couldn't work out whether it'd be generally useful or not, which is why I asked here, for an increased sample size. And that increased sample size indicates "not", so I'll forget about it. > rather than making the caching semantics more involved. (As hard as this may seem to believe, the idea actually sprang from wanting to make caching _less_ involved. I think my brain was going along the lines of "I've just writing this expensive calculation to compute a value, let's save it somewhere before returning it" so wanting to deal with the caching at _that_ point; I hadn't thought about caching when writing the C line some time previously and it seemed inconvenient to have to go back there now that I was considering it. Or something.) Smylers
Re: Partially Memoized Functions
On Tue, Dec 10, 2002 at 10:46:07PM -, Smylers wrote: > > The example above is a classic example of premature optimization. > > There's nothing which ways the cache would be counter-productive for > > simple calculations since the caching logic is nearly as simple. > > OK. There was something on MJD's QOTW recently where using the current > Perl 5 Memoize module slowed code down -- that gave me the impression > that caching had the potential. Applying memoization to really simple calcuations, such as the number of days in a month, will probably wind up slower than just doing the original calcuation. This is also an example of premature optimization. :) For something as simple as your example, the cost of entering and exiting the subroutine is probably more expensive than the code to actually do the work. In that case you likely want to inline the code which flies off into a whole other class of optimizations... > > However, if you *really* want to do partial caching and given that > > this is an edge case, ... > > It wasn't supposed to be claiming to be a serious function where caching > would be useful! I meant that the idea of partial caching is an edge case. > > I'd say to just do it as two functions > > Yeah, I thought of that (thanks for bothering to write it out) then I > thought of having the caching be per-C and couldn't work out > whether it'd be generally useful or not, which is why I asked here, for > an increased sample size. > > And that increased sample size indicates "not", so I'll forget about it. I dunno, my motto is "never hurts to put it in a library". -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One MERV GRIFFIN!
Re: right-to-left pipelines
Simon Cozens asked:
*Why* do methods need their parens?
Because calls to them are not resolved until run-time and because methods
can be overloaded by signature, so we can't tell at parse time what the
parameter list of the called method will be (i.e. where it will end),
so we can't determine how to parse the arguments.
For example. consider:
$obj.method $obj.method { closure() } $arg1, obj.method $arg2, $arg3;
Is that:
$obj.method( $obj.method( { closure() }, arg1, obj.method($arg2, $arg3) ) );
or:
$obj.method( $obj.method({ closure() }, arg1), obj.method($arg2, $arg3) );
or:
$obj.method( $obj.method({ closure() }), arg1, obj.method($arg2, $arg3) );
or:
$obj.method( $obj.method({ closure() }), arg1, obj.method($arg2), $arg3 );
???
*All* of them might be valid interpretations, and *none* of them might be known
to be valid (or even knowable) at the point where the code is parsed.
Throw multimethods into the mix and things get an order of magnitude worse.
Incidentally, the indirect object syntax will suffer from exactly the same problems
in Perl 6.
To solution in both cases is to defer the parameter/argument type checking and
the method dispatch until run-time. That works fine, but only if the compiler
can determine exactly how many arguments to pass to the method call. For that,
it needs either explicit parens, or a default rule.
Perhaps Perl 6 *will* have the default rule. Maybe that each method is passed
as many arguments as possible, working recursively outwards (and right-to-left) in
an expression. That would, for example, mean that:
$obj.method $obj.method { closure() } $arg1, obj.method $arg2, $arg3;
would always mean:
$obj.method( $obj.method( { closure() }, arg1, obj.method($arg2, $arg3) ) );
That *might* be okay, except that people are going to be very annoyed if the only
possible valid interpretation was:
$obj.method( $obj.method({ closure() }, arg1), obj.method($arg2, $arg3) );
and they get a run-time error instead.
For that reason, even if we can solve this puzzle, it might be far kinder
just to enforce parens.
Damian
Re: Partially Memoized Functions
Adam Turoff wrote:
sub days_in_month(Str $month, Int $year)
{
$month = lc $month;
if $month eq 'feb'
{
my sub feb_days (Int $year) is cached {
my $leap = $year % 4 == 0
&& ($year % 100 != 0 || $year % 400 == 0);
return $leap ? 29 : 28;
}
return feb_days($year);
}
else
{
# Simple look-up, so caching would be counter-productive:
return %days{$month}; # %days was declared above (honest)
}
}
I don't think that works correctly. This will create a new cached
sub each time $month eq 'feb'?
Nope. It simply declares C to be a *named* subroutine (i.e.
*not* a closure) that happens to be lexically scoped to inside
C.
In other words, it works exactly as if I had left off the C, except
(with the C) it avoids polluting a global namespace with a subroutine
that's not relevant anywhere else.
That'll generate a lot of cached subs
Nope. It's a named subroutine. So "thar ken be onla one" ;-)
values will be calculated each time $month eq 'feb, and none
of the values will ever be returned from any of those caches.
Nope.
Schwern's approach of factoring out days_in_feb into a cached sub
is the same basic idea, and doesn't have this issue.
That's true. But my version doesn't have the issue either, and also
elegantly illustrates why we're adding lexical subroutines to Perl 6. :-)
Damian
Re: Multmethods by arg-value
David Whipp wrote:
I was reading the "Partially Memorized Functions" thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub days_in_month( Str $month is value{ rx:i/feb[ruary]?/ }, Int $year ) is
cached
{
...
}
Yes. I have raised this prospect with Larry. It's certainly a very powerful
capacity, and there are precedents in other languages. But, last I recall,
we were not certain that the advantages it would provide would outweigh the
complexities of implementation and usage that it would introduce.
Let's just say, we're still weighing our courage against our sanity on that
idea. ;-)
Damian
REs as generators
On occasion, I have found it useful to cobble up a "little language" that allows me to generate a list of items, using a wild-card or some other syntax, as: foo[0-9][0-9] yields foo00, foo01, ... I'm wondering whether Perl should have a similar capability, using REs. -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: right-to-left pipelines
Damian Conway wrote: For that reason, even if we can solve this puzzle, it might be far kinder just to enforce parens. I might be weird, but when I use parens to clarify code in Perl, I like to use the Lisp convention: (method $object args) Hopefully that will still work even if Perl 6 requires parens. - Ken
Re: REs as generators
> "RM" == Rich Morin <[EMAIL PROTECTED]> writes: RM> On occasion, I have found it useful to cobble up a "little language" RM> that allows me to generate a list of items, using a wild-card or some RM> other syntax, as: RM>foo[0-9][0-9] yields foo00, foo01, ... RM> I'm wondering whether Perl should have a similar capability, using REs. the problem is that regexes can be very wide in accepting data but your needs are narrow. how do you expand . or .* ? what you want is more like a macro facility. my favorite macro support came with macro-11. it had .IRPC (indefinite repeat char) so you could do this (untested and surely bad syntax :) .IRPC $A, 0123456789 .IRPC $B, 0123456789 .ASCII 'foo$A$B' .END .END there has been debate here about what level of macro support to have. we can't do lisp's as we don't have easy access to generated code and we have to be better than cpp which is useless IMO as you don't have nested calls and loops. but for stuff like table and data structure building we should have some way to generate perl source/data with decent control. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: Curses Life
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 4:45 PM + 12/5/02, Leon Brocard wrote: >>Leon Brocard sent the following bits through the ether: >> >>> Now to get the hand of the signatures... >> >>Ah, well, I gave up on SDL as it was a little complicated. Instead, I >>played with curses. Please find attached a cute little curses life >>program loading and calling curses at runtime with dlfunc. >> >>Oh, and I made the shape a small spaceship as it's more interesting. > > Leon, you're really scary, y'know that? :) I've suggested he work on getting Readline working next. Then, once he's done the zmachine loader and got a zmachine opcode set up and running... -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Parrot v0.0.9 code freeze
I'm looking at the Tru64 problem. The manifest problem is trivial: languages/jako/docs/jako.pod needs to be added to the MANIFEST The multiarray problem only occurs if you turn on --gc-debug...still looking at it Tanton - Original Message - From: "Steve Fink" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 10, 2002 4:45 PM Subject: Parrot v0.0.9 code freeze > Heads up. The weather report indicates a feature freeze on Sat > 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to > a release on Wed 2002-Dec-18. So if you have any feature changes that > you want to get into 0.0.9 (and it isn't too destabilizing), please > commit them before Saturday. > > Sometime between now and then, I'll compile a list of changes since > 0.0.8. > > This release will go out even if the tinderbox isn't completely green, > because I don't want to delay it any further, but I would greatly > appreciate any improvements in that area. Feel free to use > http://foxglove.dnsalias.org/parrot/ to get a snapshot view of what > tests are failing. > >
Re: REs as generators
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
> On occasion, I have found it useful to cobble up a "little language"
> that allows me to generate a list of items, using a wild-card or some
> other syntax, as:
>
> foo[0-9][0-9] yields foo00, foo01, ...
>
> I'm wondering whether Perl should have a similar capability, using REs.
Dominus has an example of an 'odometer' written using closures. If
you want to specify a simple sequence like this using a regex, then
you need to parse the regex (but in reverse).
Alternatively, you could write a generic odometer generator generator
that takes a series of scalars and lists:
my $generator = make_generator('foo', [0..9], [0..9]);
while ($_ = $generator->()) {
## progressively generate foo00, foo01, ...
}
Z.
Re: right-to-left pipelines
On Tue, Dec 10, 2002 at 01:17:22PM -0800, Brent Dax wrote: > Jonathan Scott Duff: > # > Where we can see *at runtime* that $quux is too many > # arguments, we can > # > just append it to the end of bar()'s return value. (This > # would only > # > happen when there were no parentheses.) > # > # Seems to me that you just gave a really good argument for > # requiring the parentheses. > > I've always hated that methods are treated so differently from subs. Beware the hobgoblin of foolish consistency :-) > Perl is designed > to make the *programmer*'s life easier, not the implementer's. Another good argument for requiring the parentheses! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: REs as generators
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Tue, 10 Dec 2002 21:07:34 -0500
> From: Adam Turoff <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
> > On occasion, I have found it useful to cobble up a "little language"
> > that allows me to generate a list of items, using a wild-card or some
> > other syntax, as:
> >
> > foo[0-9][0-9] yields foo00, foo01, ...
> >
> > I'm wondering whether Perl should have a similar capability, using REs.
>
> Dominus has an example of an 'odometer' written using closures. If
> you want to specify a simple sequence like this using a regex, then
> you need to parse the regex (but in reverse).
>
> Alternatively, you could write a generic odometer generator generator
> that takes a series of scalars and lists:
>
> my $generator = make_generator('foo', [0..9], [0..9]);
>
> while ($_ = $generator->()) {
> ## progressively generate foo00, foo01, ...
> }
>
> Z.
It only differentiates between arrays an non-, but it would be trivial
to add other semantics, if you figure out what they actually are.
sub make_generator(*@pats) {
return unless @pats;
given shift @pats -> $pattern {
when Array {
for @$pattern -> $item {
my $generator = make_generator(@pats);
yield $item ~ $_ for <$generator>;
}
}
otherwise {
my $generator = make_generator(@pats);
yield $pattern ~ $_ for <$generator>;
}
}
}
You'd use it just like I did in the sub, as an iterator.
This would have been dastardly complex without corouties. :-)
Luke
Re: REs as generators
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Tue, 10 Dec 2002 15:38:58 -0800 > From: Rich Morin <[EMAIL PROTECTED]> > X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ > > On occasion, I have found it useful to cobble up a "little language" > that allows me to generate a list of items, using a wild-card or some > other syntax, as: > >foo[0-9][0-9] yields foo00, foo01, ... > > I'm wondering whether Perl should have a similar capability, using REs. Why use regexen when you can just use junctions? my $foos = 'foo' ~ any(0..9) ~ any(0..9); That's a bit shorter that the code sample I just wrote... not by much though :-P. Unfortunately, this one doesn't come in order, but a C should fix that. We have a I language on our hands, people. Luke
Re: REs as generators
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes: LP> Why use regexen when you can just use junctions? LP> my $foos = 'foo' ~ any(0..9) ~ any(0..9); should that be @foos or will it make an anon list of the foos and store the ref? LP> We have a I language on our hands, people. i know but changing my brane to think like that will take some time and practice. i brought up a macro idea but this is what i wanted to do with maps or nested loops. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: REs as generators
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > From: Uri Guttman <[EMAIL PROTECTED]> > Date: Wed, 11 Dec 2002 00:43:13 -0500 > > > "LP" == Luke Palmer <[EMAIL PROTECTED]> writes: > > LP> Why use regexen when you can just use junctions? > > LP> my $foos = 'foo' ~ any(0..9) ~ any(0..9); > > should that be @foos or will it make an anon list of the foos and store > the ref? Actually $foos will be a junction. You could use C to get each state out of the junction in an array. my @foos = states $foos; Luke
Re: REs as generators
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes: LP> my $foos = 'foo' ~ any(0..9) ~ any(0..9); >> >> should that be @foos or will it make an anon list of the foos and store >> the ref? LP> Actually $foos will be a junction. You could use C to get LP> each state out of the junction in an array. LP> my @foos = states $foos; that is going to take a while to become normalized in my neurons. very useful but not in my vernacular yet. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
