Re: take: bug or feature?
Ovid <[EMAIL PROTECTED]> writes: > Did something break? If so, I'll add a test. Otherwise, what's > wrong with this code? I noticed this as well, and believe it's a bug -- pugs accepts the code if you remove all the newlines. Then again, I'm not sure this is the desired behavior: pugs> group(1..10) ((1,), (2,), (3,), (4,), (5,), (6,), (7,), (8,), (9,), (10,)) /s
[patch] no strict for -e scripts
The enclosed patch removes strict 'vars' for -e scripts via the
nonstandard $?STRICT variable.
/s
Index: src/Pugs/Eval.hs
===
--- src/Pugs/Eval.hs (revision 13160)
+++ src/Pugs/Eval.hs (working copy)
@@ -268,6 +268,10 @@
-- Reduction for constants
reduceVal v = retVal v
+isStrict = do
+vb <- fromVal =<< readVar (cast "$?STRICT")
+return vb
+
-- Reduction for variables
reduceVar :: Var -> Eval Val
reduceVar [EMAIL PROTECTED] v_sigil = sig, v_twigil = twi, v_name = name, v_package = pkg }
@@ -287,7 +291,11 @@
-- $Qualified::Var is not found. Vivify at lvalue context.
lv <- asks envLValue
if lv then evalExp (Sym SGlobal var (Var var)) else retEmpty
-| otherwise -> retError "Undeclared variable" var
+| otherwise -> do
+s <- isStrict
+if s then retError "Undeclared variable" var
+ else do lv <- asks envLValue
+ if lv then evalExp (Sym SGlobal var (Var var)) else retEmpty
_scalarContext :: Cxt
_scalarContext = CxtItem $ mkType "Scalar"
Index: src/Pugs/Types.hs
===
--- src/Pugs/Types.hs (revision 13160)
+++ src/Pugs/Types.hs (working copy)
@@ -376,6 +376,7 @@
isGlobalVar :: Var -> Bool
isGlobalVar MkVar{ v_twigil = TGlobal } = True
isGlobalVar MkVar{ v_twigil = TDoc }= True -- XXX noncanonical
+isGlobalVar MkVar{ v_twigil = TMagical }= True -- XXX noncanonical
isGlobalVar _ = False
instance ((:>:) Var) ByteString where
Index: src/Pugs/Run.hs
===
--- src/Pugs/Run.hs (revision 13160)
+++ src/Pugs/Run.hs (working copy)
@@ -113,6 +113,7 @@
defSV <- newScalar undef
autoSV <- newScalar undef
classes <- initClassObjects (MkObjectId $ -1) [] initTree
+strictSV <- newScalar $ VBool (name /= "-e")
#if defined(PUGS_HAVE_HSPLUGINS)
hspluginsSV <- newScalar (VInt 1)
#else
@@ -161,6 +162,7 @@
, gen "%?CONFIG" $ hideInSafemode $ hashRef confHV
, gen "$*_" $ MkRef defSV
, gen "$*AUTOLOAD" $ MkRef autoSV
+, gen "$?STRICT" $ MkRef strictSV
] ++ classes
-- defSVcell <- (gen "$_" . MkRef) =<< newScalar undef
let env' = env
Re: [perl #16935] [PATCH] more regex stack manipulation
"Joshua Hoblitt via RT" <[EMAIL PROTECTED]> writes: > Since the rx_* ops are on the chopping block is there any objection to > closing this bug? No objection from me. Actually, I'm not an active Parrot developer now, and don't see myself becoming one again in the near future, so you can probably assume that I don't have objections to closing out my old bugs. /s
Re: [perl #801] [PATCH] PerlArray in scalar context
"Joshua Hoblitt via RT" <[EMAIL PROTECTED]> writes: > Isn't this a semantics issue that needs to be resolved via p6l? It is > however a design issue so I'm passing the buck to Chip to make a call > about this. Parrot/perl6 was completely different then, so this bug should be marked "irrelevant" or something. /s
Re: Namespaces, part 1 (new bits)
At Sat, 25 Sep 2004 00:53:25 -0400,
> By the way, this isn't the list for it, but it would be cool if perl6 had
> an interactive mode as good as python's. It's one of the few places I
> think python has a compelling lead.
I'm sort of partial to:
perl -MTerm::ReadLine -le '$t = new Term::ReadLine; print eval while $_ =
$t->readline("> ");'
Other than having to retrain yourself not to use "my" (because you
don't get lexicals across promps), it's not that bad. Or, if you're
an Emacs user and don't mind a few rough edges:
http://search.cpan.org/~seano/sepia-0.57/
/s
Re: bootstrapping the grammar
At Tue, 14 Sep 2004 12:31:44 -0400, Uri Guttman <[EMAIL PROTECTED]> wrote: > > > just a few musings on bootstrapping the grammar. someone mentioned the > idea of using Perl6::Rules to help with this and i think that could be a > great way to go for several reasons. FWIW, this was the idea motivating the prototype parser in languages/perl6/P6C/Parser.pm, so even though the language grammar has changed somewhat from the one p6c aims at, it might be worth looking at. A word of warning, though -- at the time, we tried speeding it up by changing P::RD to generate a big, hairy regex rather than code, and gave up because we couldn't work around perl5 regex engine bugs. The touchiest feature seemed to be using "local" for captures that might be backtracked, but I don't remember ever figuring out exactly what reliably caused segfaults or (worse) corrupt, incorrect captures. Though I haven't used it, my impression is that nontrivial uses of P6::R run into these same bugs. Just FYI, /s
Re: Synopsis 9 draft 1
At Fri, 3 Sep 2004 17:08:00 -0700,
[EMAIL PROTECTED] (Larry Wall) wrote:
>
> On Fri, Sep 03, 2004 at 05:45:12PM -0600, John Williams wrote:
> : If not, does @ints[-1] mean the element with index -1 or the last element?
>
> The element with index -1. Arrays with explicit ranges don't use the
> minus notation to count from the end. We probably need to come up
> with some other notation for the beginning and end indexes. But it'd
> be nice if that were a little shorter than:
>
> @ints.shape[0].beg
> @ints.shape[0].end
>
> Suggestions? Maybe we just need integers with "whence" properties... :-)
I think "@ints[-11]" is the obvious choice!
Also, it might be a decent default to have array parameters (or any
bindings) automatically readjust their indices to [0..$#array] unless
explicitly declared otherwise:
sub f1(@a) { @a[0] }
sub f2(@a is shape(:natural)) { @a[0] }
sub f3(@a is shape(-2..(-2 + @a.len))) { @a[0] }
my @array is shape(-1..1) = 1..3;
f1(@a); # ==> 1
f2(@a); # ==> 2
f3(@a); # ==> 3
That way, any code using non-zero-based indices would be clearly
marked as such, which seems prudent -- I know I don't use "$[" where
appropriate, and usually assume that "$#x + 1 == @x".
/s
Re: Pipeline Performance
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
> I would think you actually want to be able to define grep, map, et al.
> in terms of the mechanism for unraveling, and just let the optimizer
> collapse the entire pipeline down to a single map.
Even for map and grep this is a bit trickier, since map can produce
zero or more values for each input value, and calls its body in list
context, whereas grep produces zero or one value, and gets called in
scalar context. So you'd need something like a full call and return
prototype for each mapping function, e.g.:
FunctionReturn context Argument context
--
-> $a { $a + 2 }($y)($x)
grep(&block)($y is optional)($x)
map(&block) ([EMAIL PROTECTED]) ($arg)
Then your loop merging macro could deconstruct these into the
appropriate kind of loop (using foreach and pushing single items only
to make intention clear):
@a ==> map &b ==> @c
==>
foreach $a (@a) { foreach $b (map_item(&b, $a)) { push @c, $b } }
@a ==> (&b = -> $a { $a + 2 }) ==> @c
==>
foreach $a (@a) { push @c, b($a) }
@a ==> grep \&b ==> @c
==>
foreach $a (@a) { foreach $b (grep_item(&b, $a)) { push @c, $b } }
where "map_item" and "grep_item" are the single-element mapper
functions defining map and grep. I think that both the context and
the number of items consumed/produced could be gathered from
prototypes, so the only restrictions for mapping functions would be
(1) having a prototype available at definition time, and (2) being
side-effect-free.
/s
Re: Pipeline Performance
At Tue, 31 Aug 2004 13:23:04 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
> I would think you actually want to be able to define grep, map, et al.
> in terms of the mechanism for unraveling, and just let the optimizer
> collapse the entire pipeline down to a single map.
Even for map and grep this is a bit trickier, since map can produce
zero or more values for each input value, and calls its body in list
context, whereas grep produces zero or one value, and gets called in
scalar context. So you'd need something like a full call and return
prototype for each mapping function, e.g.:
FunctionReturn context Argument context
--
-> $a { $a + 2 }($y)($x)
grep(&block)($y is optional)($x)
map(&block) ([EMAIL PROTECTED]) ($arg)
Then your loop merging macro could deconstruct these into the
appropriate kind of loop (using foreach and pushing single items only
to make intention clear):
@a ==> map &b ==> @c
==>
foreach $a (@a) { foreach $b (map_item(&b, $a)) { push @c, $b } }
@a ==> (&b = -> $a { $a + 2 }) ==> @c
==>
foreach $a (@a) { push @c, b($a) }
@a ==> grep \&b ==> @c
==>
foreach $a (@a) { foreach $b (grep_item(&b, $a)) { push @c, $b } }
where "map_item" and "grep_item" are the single-element mapper
functions defining map and grep. I think that both the context and
the number of items consumed/produced could be gathered from
prototypes, so the only restrictions for mapping functions would be
(1) having a prototype available at definition time, and (2) being
side-effect-free.
/s
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 15:19:52 -0400, Dan Sugalski wrote: > > At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: > >At Tue, 24 Aug 2004 13:33:45 -0400, > >Dan Sugalski wrote: > >> 7) Strings are treated as floats for math operations > > > >I think we can do better than this by first converting a string to the > >"least" reasonable numeric type (with int < float < bignum), then > >re-dispatching to the appropriate numeric x numeric operation. Always > >treating strings as floats means we lose both when 2+3 != 2+"3" and > >when one of the strings is too large to be a floating-point number. > >Also, doing this redispatch means that the printed and internal > >representations of numbers will always behave the same way. > > I'm still not sure about doing dynamic down-typing (or whatever it's > called) to get the tighest possible type. I'm getting the distinct > feeling that it's what most people want, though. :) This doesn't have to involve dynamic down-typing, only a string-to-numeric converter that returns the most specific type. After that, operations between two numeric objects are welcome to do whatever they want. I actually agree with you that it's just not worth it to check for possible down-conversions. /s
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 13:33:45 -0400,
Dan Sugalski wrote:
> 6) Division of two ints produces a bignum
Where "bignum" means both "bigger than 32-bit integer" and "rational
number"? So
4 / 2 ==> Bignum("2/1")
which doesn't get automatically downgraded to a normal int. Ok.
> 7) Strings are treated as floats for math operations
I think we can do better than this by first converting a string to the
"least" reasonable numeric type (with int < float < bignum), then
re-dispatching to the appropriate numeric x numeric operation. Always
treating strings as floats means we lose both when 2+3 != 2+"3" and
when one of the strings is too large to be a floating-point number.
Also, doing this redispatch means that the printed and internal
representations of numbers will always behave the same way.
/s
Re: Instantiation
At Mon, 23 Aug 2004 15:51:00 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
>
> On Mon, 2004-08-23 at 15:19, Paul Seamons wrote:
> > > So, I was wondering about a synonym, like:
> > >
> > > uses Some::Module::That::Defines::A::Class $foo;
> >
> > Well if the long name is the problem:
> >
> > use Some::Module::That::Defines::A::Class as Foo;
>
> No, like I said: this is not golf. I'm trying to remove an element of
> redundancy that I think obscures the meaning of a set of statements.
>
> Saying,
>
> use reallylongnameforamodulethathassomeclass as Foo;
> our Foo $bar := .new;
>
> Still has the same redundancy, it's just been hidden a bit. If
> "use/instantiate" is a common practice for certain kinds of library,
> then I think we should have a mechanism to perform that pair as a single
> step.
How about making "use" a list operator returning the module's return
value (== its last statement?)? Then you could do something like
my $x = (use Some::Module::That::Defines::A::Class).new("blah");
This leaves a bad taste in my mouth -- I think importing a module and
instantiating its main class should remain separate -- but this looks
like a painless way to get what you want without a separate function
or keyword.
/s
Re: Progressively Overhauling Documentation
At Mon, 23 Aug 2004 19:46:34 +0200,
[EMAIL PROTECTED] (Juerd) wrote:
> I also think POD should be overhauled completely. I've been thinking
> about proposing something like:
>
> sub foo (
> Foo::Bar$bar,
> Quux::Xyzzy $xyzzy,
> +$verbose,
> +$foo
> ) description {
> Calculates the foo-intersection of $bar and $xyzzy, optionally
> blah blah blah...
> } returns Array | undef {
> # real code here
> }
>
> which would get rendered as:
>
> &foo (Foo::Bar $bar, Quux::Xyzzy $xyzzy, +$verbose, +$foo)
> returns Array | undef;
>
> Calculate the foo-intersection of $bar and $xyzzy, optionally
> blah blah blah...
I also think something like this is a great idea -- I've been doing a
lot of programming in Octave and Emacs Lisp, and the latter's
generated documentation makes it possible to program what would
otherwise be a completely baroque and unmanageable system. But I
wouldn't go for the syntax you have above. Why not just do it with a
property, then ship with a doc-generator that makes use of it?
sub foo($x is rw, $y) is doc <<.
Does some stuff, then frobs $x without mercy.
.
{
# ...
}
/s
Re: register allocation
[EMAIL PROTECTED] (Leopold Toetsch) writes: > The interference_graph size is n_symbols * n_symbols * > sizeof(a_pointer). This might already be too much. > > 2) There is a note in the source code that the interference graph could > be done without the N x N graph array. Any hints welcome (Angel Faus!). It looks like the way things are used in the code, you can use an adjacency list instead of the current adjacency matrix for the graph. If interference is typically sparse, which I think it should be, this is a win. So Dan -- while you're in there with the debugging statements, you might also want to keep a count of how many registers interfere with each other. /s
Re: one shootout result
fib_native.imc Description: Binary data
one shootout result
fib_native_nopcc.pasm Description: Binary data fib_native.imc Description: Binary data fib_pmc.imc Description: Binary data
Re: simple grammar example
[EMAIL PROTECTED] (Rafael Garcia-Suarez) writes: > Sean O'Rourke wrote: >> * To really show where P6 rocks, you need to show dynamic features. A >> simple example might be using a language with keywords kept in >> variables, allowing you change between e.g. "for, while, if", "pour, >> tandis-que, si", etc. > > Small correction : "pour, tant_que, si" :) Ouch! High school French fails me once again... /s
Re: simple grammar example
[EMAIL PROTECTED] (Aldo Calpini) writes: > I'm preparing a talk about Perl6 for the Italian Perl Workshop, and I > would like to have a slide comparing a BNF (yacc/bison) grammar to a > Perl6 one, to show how powerful in parsing/lexing Perl6 regexen are. > ... > am I missing something obvious here? will the above code work in Perl6? > do you have perhaps a better example, or just an idea about what to show? A few points: * Remember that with Yacc, you also need a lexer, while P6 combines lexing and parsing. Though it would complicate the example, it would make P6 look better to include a lex definition for NUM and the regex rule in P6. * I'd do infix, because it's not too much more complex, because it's more natural and familiar, and because it will show the differences in how you write recursive descent versus LALR grammars. * To really show where P6 rocks, you need to show dynamic features. A simple example might be using a language with keywords kept in variables, allowing you change between e.g. "for, while, if", "pour, tandis-que, si", etc. (hey, you could use LWP::Simple to babelfish your language on the fly!). A more complicated example might parse a construct that would add rules to the grammar, something that would be really hard with Yacc. /s
Re: backticks (or slash, maybe)
[EMAIL PROTECTED] (Juerd) writes:
> Sean O'Rourke skribis 2004-04-19 15:11 (-0700):
>> > I'd hate to give up dividing slash. It's one of the few operators that I
>> > sometimes type without whitespace. Simple because 1/10 is good enough
>> > and 1 / 10 is very wide.
>> You can have both, though.
>
> But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a
> hashref.
I'm saying "division" is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator. I've never tried to divide a hash or hashref by
something without it being a bug.
>> > That would mean giving up // for regexes (i.e. making the m
>> > mandatory).
>> Since modifiers have to be up front, and since hash slices won't have
>> a trailing '/', I don't think there's any ambiguity -- anything ending
>> in a '/' is a regex, anything otherwise is a hash slice.
>
> I don't understand. Could you give some examples? Is this in the context
> of bare /path/to/foo, even?
Sure:
/foo/ # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/ # trailing slash -- syntax error (m/foo/ bar/)
/foo/a # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/ # hash-path -- no trailing slash ($_.{'foo/'})
/s
Re: backticks (or slash, maybe)
[EMAIL PROTECTED] (Juerd) writes:
> Angel Faus skribis 2004-04-19 22:43 (+0200):
>> If we really need a ultra-huffman encoding for hash subscriptors, I
>> have always dreamt of being able to do:
>> %hash/key
>> $hashref/foo/bar/baz/quux
>> ...
>
> I'd hate to give up dividing slash. It's one of the few operators that I
> sometimes type without whitespace. Simple because 1/10 is good enough
> and 1 / 10 is very wide.
You can have both, though.
>>for /home/angel -> $file {
>
> That would mean giving up // for regexes (i.e. making the m
> mandatory).
Since modifiers have to be up front, and since hash slices won't have
a trailing '/', I don't think there's any ambiguity -- anything ending
in a '/' is a regex, anything otherwise is a hash slice.
/s
package DH;
require Tie::Hash;
@ISA = 'Tie::StdHash';
sub TIEHASH {
return bless {}, 'DH';
}
sub SCALAR {
return shift;
}
sub STORE {
my ($h, $k, $v) = @_;
$h->{$k} = $v;
}
use overload '/' => sub {
my ($x, $y, $rev) = @_;
if (!$rev) {
if (ref $y eq 'ARRAY') {
return [EMAIL PROTECTED]@$y}];
} else {
return $x->{$y};
}
} else {
return $y / keys %$x;
}
};
package main;
my %h;
tie %h, 'DH';
%h = qw(a 1 b 2 c 3);
my $xs = %h / [qw(a c)];
print %h / 'a', "\n";
print "@$xs\n";
Re: backticks
[EMAIL PROTECTED] (Juerd) writes:
> I think it has to go because `pwd`, `hostname`, `wget -O - $url`
> should not be easier than the purer Perl equivalents and because
> ``'s interpolation does more harm than good.
I have to disagree with you here. The Perl way is not always the Perl
way -- the beauty of Perl is that it makes it as easy as possible to
take advantage of existing tools. Sometimes this is best done with a
foreign interface like XS, but sometimes it's adequate and easier to
simply shell out and collect the output. I don't see "purity" as a
good motive here; in fact, rigid purity makes languages like Java and
Smalltalk somewhere between frustrating and useless.
As for it doing more harm than good, do you mean that `` is a security
threat? I find that there are still plenty of contexts in which `` is
nice and security is irrelevant.
Of course, I'd be fine with the slightly longer "qx{}"...
/s
Synopsis 3: quick junction question
S3 says: 1|2 + 3&4; # (4|5) & (5|6) but shouldn't that equal (1 + (3&4)) | (2 + (3&4)) = (4&5) | (5&6) = (4|6) & 5 # ??? For one thing, OR's of AND's (DNF) is just nicer than AND's of OR's (CNF). For another, I read that as "1 or 2 plus 3 and 4"; it would be surprising if that were equal to "(4 or 5) and (5 or 6)", since that equals "5 and 5". I haven't run through many examples, but I think it should be a general rule than when combining conjuctions with disjuctions through any operation, the conjuction should distribute over the disjuction. I know these aren't strictly logical ops, but if I say @a = (0,0,0,0,1,0); print "yes" if @a[1|2 + 3&4]; I would be chagrined if it printed "yes". Then again, I would be chagrined to have to read that code, anyways. /s
Re: Some PIR "How do I?" questions
>>At 5:38 PM + 11/27/03, Pete Lomax wrote:
At 12:02 PM 11/27/2003 +, Pete Lomax wrote:
>Perl6 already does interpolation without special support from IMCC.
>>>I'll rephrase. Is there anything knocking about which would help with
>>>eg:
>>>printf (pFile, "Amount %12.3f [%-10.10s]\n",balance,name);
Also, interpolation and (printf-style) formatting are completely
different beasts. Just think of interpolation as fancy syntax, or as
a mini-language:
"$x and @y and @{[something()]}"
becomes
stringify($x).' and '.stringify(@y).' '.stringify(something())
inside the compiler. P6C rips apart strings inside the parser and
outputs code for the above. Since this translation will be different
for every language, I don't think there's much code that can be
shared.
/s
Re: Control flow variables
[EMAIL PROTECTED] (Austin Hastings) writes:
> What does C do?
That's the operator that's used to assign values to C<$^x> and
friends in closures. In all its glory, you give it a set of values,
and it assigns them to a block's undefined variables, quieting those
annoying warnings:
@x = 1..10;
scatter @x {
$the = 1;
$teh + $the * $The
}
# ==> 1 + 1 * 2 = 3
/s
Re: [perl #24403] [PATCH] Force Perl6's "make test" to use perl6 rather than prd-perl6
Thanks. 'bout time, I suppose, since even _I_ have stopped using
prd-perl6.pl...
/s
[EMAIL PROTECTED] (Joseph F . Ryan) writes:
> # New Ticket Created by Joseph F. Ryan
> # Please include the string: [perl #24403]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24403 >
>
>
> Just a simple consistancy patch; as perl6 itself becomes more complex,
> there is a greater chance of a program running differently compared
> to prd-perl6.
>
> - Joe
>
>
> -- attachment 1 --
> url: http://rt.perl.org/rt2/attach/67019/50015/e2e3d9/TestCompiler.diff
>
> --- parrot/languages/perl6/P6C/TestCompiler.pm~ Sun Nov 2 15:06:26 2003
> +++ parrot/languages/perl6/P6C/TestCompiler.pmSun Nov 2 15:06:26 2003
> @@ -59,7 +59,7 @@ sub generate_pbc_for {
> my $pbc_f = Parrot::Test::per_test('.pbc',$count);
> my $parrot = "..$PConfig{slash}..$PConfig{slash}parrot$PConfig{exe}";
>
> -Parrot::Test::_run_command("$PConfig{perl} prd-perl6.pl --batch=$p6_f --imc",
> 'STDOUT' => $imc_f, 'STDERR' => $err_f);
> +Parrot::Test::_run_command("$PConfig{perl} perl6 $p6_f --imc", 'STDERR' =>
> $err_f);
> Parrot::Test::_run_command("$parrot -o $pasm_f $imc_f", 'STDERR' => $err_f);
> my $pasm;
> {
Re: [perl #24392] [PATCH] P6C xor really does return a value
applied thanks. /s
Re: [perl #24391] [PATCH] P6C closures use 'newsub' instead of assigning integer address
thanks, applied. /s
Re: P5 "B" backend for languages/perl6 - quasi-announcement
[EMAIL PROTECTED] (Scott Walters) writes: > I have work-related reason to add a "B" backend for Perl 5 to the > perl6 compiler. I'm looking at creating an assembler for Perl 5's > "B" bytecode along the lines of IMCC, and creating patches against > languages/perl6/IMCC.pm and languages/perl6/IMCC/* to conditionally, > using some sort of phrasebook, generate assembly for either Parrot > or B. This would involve some nontrivial refactoring, since both are unashamedly machine-dependent, and freely emit blocks of assembly directly from the AST walk. Unless B assembly is a lot like parrot assembly, simply replacing (or factoring out) these chunks might not be the best way. Of course, I've never used B assembly, so discount this impression appropriately. Everything up to IMCC* (i.e. parsing, tree munging, and "context" (wannabe typing)) should be fine, though. > The B assembler would use B::Generate to build up a bytecode tree, > and then B::Deparse to dump P5 or else more likely dump the raw > bytecode and use ByteLoader to suck it back in. Far be it from me to discourage you, but IMHO languages/perl6 is less complete and correct than the rest of Parrot. However, while the grammar reflects an older incarnation of Perl 6, it's written in fairly clean Parse::RecDescent, and it is ahead of the code generation in terms of completeness. You might be better off both performance-wise and other-wise either: 1. just using Parrot to run the subset of perl6 you need; or 2. using the languages/perl6 parser to translate directly to Perl 5. Since the languages are similar in a lot of ways, this should not be too hard in most cases (and very painful in a few), and since languages/perl6 doesn't do any optimization, you're not losing anything. > This should have been posted to perl6-language, but I'm not > subscribed there. This is probably internals, since it doesn't concern language design. Let me know if you have any other questions. /s
Re: Pondering argument passing
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Luke Palmer <[EMAIL PROTECTED]> wrote: >> Okay, considering that it's hard to pack registers into an array, and >> that it's easy to unpack an array into registers (in the context of >> signatures), why don't we make the unprototyped calling conventions just >> to pass everything in the overflow array? (Hmm, I think I remember >> saying this before... sorry if I'm repeating myself) > > This doesn't help for flattening (splat) function call arguments: > > f([EMAIL PROTECTED], [EMAIL PROTECTED]) > > repacking everything (at runtime!) into P3? Yes. It seems to me that this is exactly what has to happen, at least conceptually. Luke's point is clearest when considering how to implement a Perl5-style sub with a variable number of arguments. If args are passed in an array, they're all clustered together and easily handled by a for-loop (or assembly equivalent). If they're passed in registers, you have to have a huge, nasty switch statement at the start of the function like so: if $nargs == 0 goto done # handle P5 if $nargs == 1 goto done # handle P6 ... if $nargs == 10 goto done # handle overflow And that's just not pleasant. > And what if the call is: > > f([EMAIL PROTECTED], $b, $c) I'm not understanding your point here -- wouldn't this create an array "[EMAIL PROTECTED]@a[n], $b, $c]" in P3, just like the above? Steve -- As I see it, prototypes have two functions: (1) catching wrong-arguments errors at compile time, and (2) (perhaps) allowing for faster parameter passing. Since the second's really just an optimization, I'd suggest skipping it for the time being, doing the syntactic checking during compilation, but then passing everything in P3. This also gives us a baseline against which to benchmark prototyped passing. It's not clear to me a priori that it can be reasonably used often enough to actually be faster. /s
Re: cvs commit: parrot/languages/imcc/t/syn pcc.t
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Gordon Henriksen <[EMAIL PROTECTED]> wrote: >> >> | A C D E G I| >> | N S T V| >> > > WTF ... Hangman -- the goal is to guess the letters of a word or phrase, and unguessed letters are represented as "_"s (like "ge_n_ic_ic"). /s
Re: Pondering argument passing
Leopold Toetsch <[EMAIL PROTECTED]> writes: >> This sounds like the beginning of a whole set of things like "Warning >> #238: suboptimal implementation of xxx. Are you sure you know what you >> are doing?" > > If the user turns on optimization and the compiler finds such code, yes, > why not. SBCL, a fast and venerable Lisp compiler, does precisely this -- when you compile with full optimization, it tells you everywhere it can't eliminate runtime checks, use machine integers, etc. The warnings can be incredibly useful, because it's often hard to predict where the compiler will be smart enough to optimize, and where you'll need to help it. But most of the time, the incredible flood of warnings is just an annoyance that forces the programmer to ignore warnings entirely. These should definitely be available, but preferably only upon request. /s
Re: Problems building perl6 (perl version dependency?)
Andy Dougherty <[EMAIL PROTECTED]> writes:
> So the problem is actually a dependency on a module not shipped with
> perl5.00503.
>
> This problem's been around a while -- I know I've reported it before. Is
> it time to give up on 5.00503? I will retest with 5.8.x, but the
> compilation takes a *long* time.
I'm not personally a fan of 5.005 compatibility, but it looks to me
like the "use charnames" was gratuitous, since charnames is already
being used inside the nearby eval. Does this fly?
/s
*** String.pm.~1.6.~Sun Mar 16 01:02:08 2003
--- String.pm Mon Sep 15 09:07:00 2003
***
*** 216,222
error ("Error in interpolation of control-char: $@"),die if $@;
}
else {
- use charnames qw(:full);
# The charnames doesn't seem to propagate into the eval""
# for me -- sfink
$val = eval qq[use charnames qw(:full); "\\N{$_}"];
--- 216,221
Re: mission haiku
Nicholas Clark <[EMAIL PROTECTED]> writes: > Perl internals slow, > nigh on unmaintainable. > So we write parrot. Parrot: not just Perl but punctuated prowess perfected -- Befunge. /s
Re: PerlHash.get_pmc_keyed of non existing key
Luke Palmer <[EMAIL PROTECTED]> writes: > Gordon Henriksen writes: >> my $ref = [EMAIL PROTECTED]; >> $$ref = "value"; >> print '@ary[0] : ', @ary[0], "\n"; # -> @ary[0] : value > > That has to do with autovivification semantics. Particularly, do things > autovivify when you take a nonconstant reference to them. I think it's better seen as part of the semantics of references to nonexistent values. When you take a ref to a value slot that doesn't exist, you effectively create a tied variable that knows how to create that slot, and will do so only when you assign to it. /s
Re: [CVS ci] PackFile-15: print warning location
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> I like the ideas of a range of characters, and of variable amount of
> information. So, how about multiple setline variants?
>
>setline Ix # all code from here to the next set{line,file} op is line
> x
>setline Ix, Iy # set line,col number from here to next set* op.
>
>setline_i Ix # the next line is x, each succeeding line increases.
>
>setlinerange Ix, Iy # the following represents lines x..y of hll
> code.
>setlinerange Ix, Iy, Iz, Iw # line x, col y .. line z, col w.
setdim Ix # sets number of dimensions for subsequent code
setvel Px # set code velocity (general setline_i; Px is an Array)
Just making sure Parrot debug info can support Jerome's trefunge
interpreter.
/s
Re: Registers vs. Stack
"Tom Locke" <[EMAIL PROTECTED]> writes: > p.s. (and at the risk of being controversial :) Why did Miguel de > Icaza say Parrot was "based on religion"? Was it realted to this > issue? Why is he wrong? IIRC it is -- his take is that stack VM code provides useful information about variable lifetimes, which can help the JIT produce good code. If everything's jitted, then his contention is that bytecode opcount doesn't matter that much. I'm not going to stick my neck out and offer a technical opinion, but I'll just note that religion has been the driving force behind some great things in the past -- witness Europe's cathedrals ;). Oh, wait... we're supposed to be "the bazaar". /s
Re: hash access
Leopold Toetsch <[EMAIL PROTECTED]> writes: > We have keyed_int shortcuts to get/set items on array like aggregates. > Is there a reason, that we not have keyed_str to access hash elements > by STRING directly. I'm not so sure this would be worth it; since hash lookups are much more expensive than array indexing, the gain from avoiding a wrap/unwrap won't be nearly as significant. Of course the only way to tell would be to do some benchmarks, but it seems to me like ops and optimization time could better be spent elsewhere. /s
Re: languages using parrot
Leopold Toetsch <[EMAIL PROTECTED]> writes: > What about one subdir per language under languages containing at least > a README with a pointer to the author(s) webpage. How about just a single languages/OTHER or some such (maybe in doc/ instead) with this information? Adding extra directories may imply that we want these languages to become part of the standard Parrot distribution. While this will be true of some, some languages will no doubt always be distributed separately. /s
Re: there's no undef!
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> There's no way, in this program, for $x to be out of scope while $y is
> in scope.
But we're in Perl6(66)-land, where "delete caller.MY{'$x'}" and
"delete %OUTER::x" (sp?) can wreak havoc on your pad from all
sorts of strange places. It ain't moral, but it sure is legal.
/s
Re: [PATCH] imcc vim syntax file
Luke Palmer <[EMAIL PROTECTED]> writes: > FWIW, here's my personal imcc syntax highlighting file for vim. I've > found it very useful in reading imc code (but then, I'm very attached > to my syntax highlighting). Auto-generated editor configuration? Cool... > I'm still not sure how to add new files with cvs diff, so I used a > normal diff against /dev/null. `-N' Applied, /s
Re: [perl #23346] [PATCH] docs/running.pod: command line arguments
Kenneth A Graves (via RT) <[EMAIL PROTECTED]> writes: > Should the word "argv" be explicitly mentioned, or is "command line > arguments" clear enough? Thanks, applied (w/ mention of argv). /s
Re: keyed vtables
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Dan Sugalski <[EMAIL PROTECTED]> wrote: >> And semantic differences--don't forget those. > > A keyed "add" vtable doesn't help to provide more semantics. The set vs > assign thread applies here too. On the contrary: to provide all > semantics you would need "add_set_p_k_p_k_p_k" and "add_assign_p_k_p_k_p_k" > and possibly "add_clone_p_k_p_k_p_k". If I'm on target, what Dan's trying to avoid is having to create magic proxy objects for autovivification. If this is all we want out of keyed ops, then we can get it more cheaply by only adding keyed variants for the _out_ parameters of each op. That way the standard get_*_keyed ops can either return NULL, return a new PMC without insertion, or insert and return a new PMC for read parameters, while the *_pk_*_* ops can do "the right thing" with respect to autovivification. No temporary keys or null keys need be created. I think this covers the semantics. Beyond that, it's just a matter of performance -- extra opcodes vs. extra ops -- that we can fight out in the benchmark arena. /s
Re: pirate 0.01 ALPHA!
Michal Wallace <[EMAIL PROTECTED]> writes: > Tadaa! /me blinks at the list comprehensions. Cool stuff. test_microthreads failed for some reason I still need to look into, but there's a lot of cool stuff working already. Time for Dan to begin thinking about which direction the pie will fly. /s
Re: getprop and find_lex?
Michal Wallace <[EMAIL PROTECTED]> writes: > I expected getprop to behave like find_lex > and throw an exception if the property doesn't > exist, but it doesn't: Are you sure that properties are what you want to use here, rather than attributes (via get_pmc_keyed() or similar)? IIRC parrot's properties are supposed to support out-of-band data like Lisp's plists or Perl 6 properties (http://dev.perl.org/perl6/apocalypse/2#properties) /s
Re: Calling parrot from C?
Luke Palmer <[EMAIL PROTECTED]> writes: > How does one call a parrot Sub from C and get the return value(s)? I'd vote for stuffing args into the interpreter, calling the sub's invoke() method, then digging through the registers to pull out the return values (see e.g. Parrot_pop_argv in method_util.c, which may be outdated). Then again, it would be _your_ pain, not mine ;). /s
Re: why new_pad *INT*?
Michal Wallace <[EMAIL PROTECTED]> writes: > 1. Should there be a new_pad that takes > no arguments to do this, so we don't > have to keep count manually? > > 2. When would you NOT want to use > new_pad (current_depth+1) ? Remember, the pad depth reflects lexical scope nesting, not dynamic scoping. So if you mean "current_depth" as "current compile-time depth" above, then you're right, but the VM would have no way to tell. If you mean run-time depth, which the compiler could know about... A top-level sub should not create a new pad at depth + 1, since that would put it inside its caller's lexical scope, which would just be weird. /s
Re: Approaching m4
Bernhard Schmalhofer <[EMAIL PROTECTED]> writes: > I have started an implementation of m4 in PIR. The implications are staggering... Sure, plenty of compilers can bootstrap themselves, but how many can generate their own configure scripts via autoconf? With p4rrot, we may live to see this dream. /s
Re: pirate status / need help with instances
"K Stol" <[EMAIL PROTECTED]> writes: > I may be wrong, but where should the class be stored? > The newclass op has an out-parameter where the newly > created class is stored. Invoke doesn't have > that. (right?) Presumably it would just return the new object like an ordinary function call. /s
Re: pirate status / need help with instances
"K Stol" <[EMAIL PROTECTED]> writes: > invoke is defined in core.ops, and the return value > of the PMC implementation should be an address, > because this result is used in the GOTO macro. So, > only an address can be returned. Sorry, I mean "return" in the parrot sense, i.e. place on top of the stack, or put in P5, or whatever your calling convention would be for normal language subroutines. /s
Re: why new_pad *INT*?
Michal Wallace <[EMAIL PROTECTED]> writes: > Okay, I definitely need some help understanding this. Okay, I definitely did a suboptimal job trying to clarify... > Here's some python code that defines a closure: > > def make_adder(base): > def adder(x): > return base+x > return adder > h = make_adder(10) > print h(5) > > When I run this in python 2.2, it prints "15". > > When I run it through pirate, I get this: > >-scratch_pad: too deep > > Now, in my mind: > > depth 0 has: make_adder, h > depth 1 has: base, adder > depth 2 has: x This sounds right. > The top level .sub should start with 'new_pad 0' > The make_adder .pcc_sub should start with 'new_pad 1' > The adder .pcc_sub should start with 'new_pad 2' Right. > I think the error happens because I'm calling a depth 2 > function from depth 0, but if I change adder's new_pad > depth to 1, it can't find "base". > > I don't know how to get this to work the way I want. > Can anyone help me out here? > ... > # make_adder from line 2 > .pcc_sub _sub0 non_prototyped > .param object base > new_pad 1 > store_lex -1, 'base', base > setline 3 > newsub $P1, .Sub, _sub1 The problem is that when adder() gets returned, it needs to remember the enclosing pad. So this needs to be newsub $P1, .Closure, _sub1 which (IIRC) will save the lexical environment in which it was created (see closure.pmc), then restore that when it is invoked. /s
Re: pirate status / need help with instances
Michal Wallace <[EMAIL PROTECTED]> writes: > Py-pirate can now handle: Cool... >* make parrotclass handle "invoke" > this strikes me as the most efficient, > but I'm not really confident with C > so I'm hesitant to try it This seems to me like the way to go, except you might subclass parrotclass to pythonclass (since this lack- of-"new" seems to be the "Pythonic way"). The C should pretty much just turn around and call pmc_new, then return the original return address that was passed in. /s
Re: parrot, win32, stand-alone distribution, separate Parrot maillist
"Jonathan Worthington" <[EMAIL PROTECTED]> writes: > work something out. :-) However, Brent said "If you mean > precompiled binaries, not yet. Parrot is still under development, > so we aren't shipping binaries.", This doesn't make sense to me. People who don't like hacking C can still use a precompiled binary to hack in PASM or IMC. Heck, most of the languages in languages/* are written in Perl -- no whatsoever to configure and compile. /s
Re: [perl #23203] [PATCH] move languages/scheme to continuation passing style.
"Jürgen" "Bömmels" (via RT) <[EMAIL PROTECTED]> writes: > # New Ticket Created by Jürgen Bömmels > # Please include the string: [perl #23203] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=23203 > > > > Hello, > > this patch lies in my tree for month now, finally I got around to > finish it up: > > ... Thanks, applied. /s
Re: PMC methods?
On 23 Jul 2003, Luke Palmer wrote: > Instead of having a bunch of specialized ops made for > constructing/working on specific pmcs, have, say, four general-purpose > ops whose meaning could be given by each pmc that uses them. So, > instead of, for instance, newsub, we'd make a new .Sub pmc and call > the pmc1 op on it with the label. For a socket pmc, we'd call pmc1 to > set the port, pmc2 to set the protocol, etc. One problem with this is that it hides errors, since you can mistakenly send a message to a different type of PMC and still have it be legal. How much do you think this would save over doing a single findmethod and caching the result? On the other hand, the profusion of special-purpose ops has been bothering me as well. I'm not sure where we're drawing the line between ops and methods. For example, should socket operations be ops, or methods on a core Socket PMC? I think the latter, but only because sockets don't seem as "core" as addition, not for any principled reason. Another example: why does interpinfo exist, rather than the interpreter just looking like a hash or array and using the standard keyed get/set ops? Do others (Dan? Juergen? Leo?) have some stronger sense of what should and shouldn't be an op? /s
Re: Protocols
On 19 Jul 2003, Luke Palmer wrote: > [1] It would be totally cool to use a Haskell- or ML-style type > inference system, but those things just don't work in procedural > languages. Could you clarify what you mean by "don't work" here? ML has both assignment and type inference, so it seems like it's at least possible to do this; O'Caml generates some pretty fast code, too, so it seems like it can be practical as well. Of course, perl6's being _dynamic_ may sink this, but its being _procedural_ doesn't seem like it would pose a problem. /s
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
On Thu, 17 Jul 2003, Leopold Toetsch wrote: > > Replacing the next instruction with a branch to the signal handler > > (like adding a breakpoint) out of the question? > > I don't know, how to get the address of the next instruction i.e. the > "PC" above. Going this way would either mean: > - fill the bytecode segment with the handler opcode function or Yuck. > - locate the PC on the stack or in registers (like %esi in CGP) > The former seems rather expensive (at least if we heavily use events), > the latter seems to be possible only per platform/compiler(-revision). For non-jit code, the latter seems doable if we can find a way to force registers back out to memory if necessary (short of declaring the PC volatile, which would just suck). The Boehm collector uses a platform-independent setjmp() hack to do this. For jit code, we know the jit PC reg, so it shouldn't be a problem. Of course, you should probably take this with a grain of salt with size inversely proportional to the amount of the solution I've coded. (An infinite grain in this case...) /s
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
On Thu, 17 Jul 2003, Leopold Toetsch wrote: > PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions > > To be able to switch function tables, this then should become: > > PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP); > > Thus predereferncing the function pointer would place an offset into the > function table, not an absolute address. > > Or is there a better way to do it? Replacing the next instruction with a branch to the signal handler (like adding a breakpoint) out of the question? Of course, if we're sharing bytecode this is expensive, since you'd have to do something like this: bsr handler ... handler: if cur_thread == thread_with_signal goto real_handler # replaced instruction ret which penalizes all other bytecode users. I guess it depends how common we expect signal handling to be. /s
Re: [CVS ci] hash iter: buggy initial try
On Sat, 5 Jul 2003, Leopold Toetsch wrote: > This is a first attempt to iterate over hashes. > The hash is scanned linearly, until the given integer index is found. > > Is there a better way to locate the next entry, either by an integer idx > or by a key or some other means? It's constant time if you keep a bucket index and a pointer to the current hash bucket in the iterator (see e.g. hash.c:hash_clone()). /s
Re: This week's summary
On Tue, 24 Jun 2003, Leopold Toetsch wrote: > Piers Cawley <[EMAIL PROTECTED]> wrote: > > He's worried that the P6C tests > > break, > > ... albeit this is still an issue. Nobody answered, if we need another > Sub class implementing the old invoke/ret scheme ... I'd say "no". P6C is now compiling to an obsolete architecture. While we should all step back and be impressed at how well Intel has maintained backward compatibility in the x86, there's no particular reason we should do so ourselves. Rather, someone (me) needs to port P6C to the new machine. > > Whee! My first anniversary! > > Congrats and thanks for your great summaries. Seconded. /s
Re: [perl #22765] Unary '+' is not symmetric to unary '-' in languages/perl6
Looks good, except that this needs to make sure an int is being
returned, e.g.
+"42"-> 42
+"forty-two" -> 0
The lazy man in me would just shove it through an int reg, but that
loses precision if we go to bignums. Though for the moment I can't
think of a better way.
/s
+# unary plus.
+sub prefix_pos {
+my $x = shift;
+my $tmp = $x->args->val;
+my $res = newtmp;
+code(<{ctx});
+}
On Mon, 23 Jun 2003, Bernhard Schmalhofer wrote:
> # New Ticket Created by Bernhard Schmalhofer
> # Please include the string: [perl #22765]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=22765 >
>
>
> Hi,
>
> when playing with the stuff in 'languages/perl6', I noticed that code like
> print( +42, "\n" );
> didn't do the right thing. 'perl6' printed '42' but forgot about the "\n".
>
> The cause seemed to me that '+' isn't set up as an unary operator in
> 'P6C/Parser.pm'.
> After adding '+' in 'Parser.pm' and in a couple of othe files, it now seems
> to behave as expected.
>
> On my Linux machine there are some other tests failing in t/compiler, but
> these seem not to be related to unary '+'.
> One of these failures is a 'inf' vs. 'Inf' issue.
>
> A patch is attached.
>
> CU, Bernhard
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
>
> -- attachment 1 --
> url: http://rt.perl.org/rt2/attach/59761/44242/d4c34a/prefix_pos.patch
>
>
Re: This week's summary
On Mon, 9 Jun 2003, Adam Turoff wrote: > - roll-your-own inheritance mechanisms (see NEXT.pm) On a related note, you might also want to take a look at CLOS (the Common Lisp Object System) where it talks about method selection. They've got a pretty clear and general model that describes every imaginable (and unimaginable) thing you'd want to do with dispatch. It's broken into 3 steps, any one of which you can customize: - find all applicable methods - sort them in order of specificity - apply some kind of combining operation to this list (e.g. select 1st) Granted, this is hardly efficient, and from what I've seen you need to be careful in how you use MMD to get decent performance in Lisp. But it's still helpful in laying out the design space. /s
Re: Register access
On 30 May 2003, Bryan C. Warnock wrote: > Ha ha, just kidding, of course. I'm all for it, but given my record > today, that might be an imminent sign of its rejection. Or, given your historical record, you may have just killed the thread ;). /s
Re: [perl #22353] JIT!
On Wed, 28 May 2003, Luke Palmer wrote: > I get segfaults with both imcc -Oj and parrot -j (with assemble.pl) on > mandel.pasm and a bunch of others. I've noticed a number of these as well (linuxppc, gcc3.3), but then again I've been tweaking my copy of the JIT. I get these failures: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/arithmetics.t1 256381 2.63% 9 t/op/interp.t 1 256 21 50.00% 2 t/op/stacks.t 3 768403 7.50% 3 12 t/pmc/eval.t 3 768 33 100.00% 1-3 Which do you get? /s
Re: [perl #21668] APL doesn't use sigils
On Mon, 24 Mar 2003, Benjamin Goldberg wrote: > And what happens if a programmer wants to have two different variables, > of two different types, with the same name, such as @data and %data? > > Without sigils, it cannot be done. Actually, if you squint, other languages are far ahead of Perl in this respect -- Hungarian notation! sData, aData, hData, ppiData, ... /s
Re: Rules and hypotheticals: continuations versus callbacks
On Wed, 19 Mar 2003, Matthijs van Duin wrote: > >(4) (internals) Given that Parrot has so many different control mechanisms > >(call/ret, exceptions, closures, continuations, ...), how do we maintain > >consistency? And how much of that is parrot's responsibility (versus the > >perl6 compiler's)? > > I don't think there will be a big problem with that, but maybe I'm just > overlooking things. Exceptions, for example, will have to unwind dynamic bindings, stack frames, call user-defined exception handlers, etc. Using continuations for everything, this isn't a problem -- get it right once and it works everywhere (btw, languages/perl6 uses continuations for its exceptions now). However, they're much more expensive than normal sub calls, so we probably don't want to use them there. I'll let Dan talk about potential issues with throwing exceptions across languages, since he's given it much more thought than yours truly, /s
Re: Rules and hypotheticals: continuations versus callbacks
On Wed, 19 Mar 2003, Jonathan Scott Duff wrote:
> Are you implying that
>
> $fred = rx/fred/;
> $string ~~ m:w/ <$fred> { $fred = rx/barney/; } rubble /
>
> won't match "barney rubble"?
Or, worse, that
$fred = rx/fred/;
$string ~~ m:w/ { $fred = rx/barney/; } <$fred> rubble /
won't, either?
/s
Re: Rules and hypotheticals: continuations versus callbacks
On Tue, 18 Mar 2003, Matthijs van Duin wrote: > and maybe also: > What is the current plan? > > although I got the impression earlier that there isn't any yet for invoking > subrules :-) See line 1014, languages/perl6/P6C/rule.pm. The hack I used was to call rules like ordinary subs, and have them push marks onto the regex stack before they return. I'm not sure if this can be made to work with hypotheticals, and I'm sure it won't interact kindly with continuation-taking, but there's _something_. As for the interaction with continuations, I was about to post some of my concerns when I received your long and well-thought-out mail. I need to think about the discussion so far a bit more, but briefly: (1) There's more than one way to go when combining dynamically-scoped variables with continuations: for example, do you use dynamic bindings from where the continuation was taken, or from where it's invoked? (see e.g. Scheme's "dynamic-wind"). (2) (internals) The functional-language people have found that full continuations are slow, and put a lot of effort into avoiding them where possible. Backtracking languages like Icon and Prolog are implemented by special mechanisms rather than general continuations, probably for this reason. So if we're forced to do a regex engine using full continuations, it will probably be dog-slow (3) On the other hand, we probably want people to intermix regex backtracking, continuation-taking, and hypothetical/dynamic variables, and have it "do the right thing", where "right" means something like "mind-bendingly difficult to reason about, but consistent". How do we want these features to play with each other? (4) (internals) Given that Parrot has so many different control mechanisms (call/ret, exceptions, closures, continuations, ...), how do we maintain consistency? And how much of that is parrot's responsibility (versus the perl6 compiler's)? /s
Re: This week's Perl 6 Summary
First off, thanks to our relentless..., er, tireless summarizer for continuing to digest and clarify our wandering discussion. On Tue, 25 Feb 2003, Piers Cawley wrote: > Using IMCC as JIT optimizer > Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is > still faster than parrot -j' so he's been experimenting with adding > smarts to IMCC, making it add hardware register allocation hints to its > emitted bytecode. Sean O'Rourke liked the basic idea, but reckoned that > the information generated by IMCC should really be platform-independent, > suggesting that it'd be okay to pass a control flow graph to the JIT, This isn't really my idea, but is instead an area of active research. A good jumping-off point is http://citeseer.nj.nec.com/krintz01using.html. > Dan thought the idea was interesting too, but worried that the JIT might > spend more time optimizing code than it could possibly gain from the > optimization. Dan -- you might be interested in http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX subsription or a nearby university library). They stuff a full data-flow compiler into a JVM and, by carefully minimizing the number of passes, make it end up faster than a lightweight JIT on a number of programs. Granted, (IIRC) the real wins are on longer-running programs, so the result isn't as relevant to Parrot, but it _does_ show that there's room to put a fair amount of optimization into a JIT. /s
Re: Using imcc as JIT optimizer
On Thu, 20 Feb 2003, Leopold Toetsch wrote: > What do people think? Cool idea -- a lot of optimization-helpers could eventually be passed on to the jit (possibly in the metadata?). One thought -- the information imcc computes should be platform-independent. e.g. it could pass a control flow graph to the JIT, but it probably shouldn't do register allocation for a specific number of registers. How much worse do you think it would be to have IMCC just rank the Parrot registers in order of decreasing spill cost, then have the JIT take the top N, where N is the number of available architectural registers? /s
Re: Shortcut: ?=
Argh. Please disregard that last message as the ramblings of a pre-caffeinated mind. /s On Mon, 3 Feb 2003, Sean O'Rourke wrote: > On Mon, 3 Feb 2003, Dave Mitchell wrote: > > $var ??= 'succeeded' :: 'failed'; > > Aha! > > $var && 'succeeded' || 'failed'; > > Thank you, precedence. > > /s > >
Re: Shortcut: ?=
On Mon, 3 Feb 2003, Dave Mitchell wrote: > $var ??= 'succeeded' :: 'failed'; Aha! $var && 'succeeded' || 'failed'; Thank you, precedence. /s
Re: Bytecode metadata
On Sat, 25 Jan 2003, Leopold Toetsch wrote: > Is one PBC file a small thing? Or in other words, should we have a low > limit where we start again to malloc and copy PBC files? > Configure option? Commandline switch? Maybe a config option? The app I'm thinking of was pathological, in that it mapped in thousands of 20-byte files. Now that I think about it, unless someone implements something very strangely (or has absolutely enormous numbers of threads) this shouldn't be an issue. /s
Re: Bytecode metadata
On Sat, 25 Jan 2003, Dave Mitchell wrote: > On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote: > > On Sat, 25 Jan 2003, Leopold Toetsch wrote: > > > Dan Sugalski wrote: > > > > > > > At 5:32 PM + 1/24/03, Dave Mitchell wrote: > > > > > > > >> 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. > > > > How true. On Solaris, for example, mmap's are aligned on 64k boundaries, > > which leads to horrible virtual address space consumption when you map > > lots of small things. If we're mmap()ing things, we want to be sure > > they're fairly large. > > Okay, I just ran a program on a a Solaris machines that mmaps in each > of 571 man files 20 times (a total of 11420 mmaps). The process size > was 181Mb, but the total system swap available only decreased by 1.2Mb > (since files mmapped in RO effecctively don't consume swap). The problem's actually _virtual_ memory use/fragmentation, not physical memory or swap. Say you map in 10k small files -- that's 640M virtual memory, just over a fourth of what's available. Now let's say you're also using mmap() in your webserver to send large (10M) files quickly over the network. The small files, if they're long-lived get scattered all over VA-space, so there's a non-trivial chance that the OS won't be able to find a 10MB chunk of free addresses at some point. To see it, you might try changing your program to map and unmap a large file periodically while mapping the man pages. Then take a look at the process's address space with /usr/proc/bin/pmap to see what the OS is doing with the maps. Weird, I know, but that's why it stuck in my mind. You have to map quite a few files to get this to happen, but it's a real possibility with a 32-bit address space and a long-running process that does many small mmap()s and some large ones. Anyways... /s
Re: Bytecode metadata
On Sat, 25 Jan 2003, Leopold Toetsch wrote: > Dan Sugalski wrote: > > > At 5:32 PM + 1/24/03, Dave Mitchell wrote: > > > >> 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. How true. On Solaris, for example, mmap's are aligned on 64k boundaries, which leads to horrible virtual address space consumption when you map lots of small things. If we're mmap()ing things, we want to be sure they're fairly large. /s
Re: "Arc: An Unfinished Dialect of Lisp"
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
Re: L2R/R2L syntax
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> So 'if' and friends are just (native) subroutines with prototypes like:
>
>sub if (bool $c, Code $if_block) {...};
IIRC it's not that pretty, unfortunately, if you want to support this:
if $test1 {
# blah
} elsunless $test2 {
# ...
}
since that gets parsed as
if($test1, { ... }) # aiee: too many arguments to "if"
One possible solution would be to say that there's an implicit "whatever
we need" after a closed curly. In that case there are two ways to go:
(1) we can define things like "if" to be statements rather than
expressions (a la C), and closed-curlies as the last arguments of
"statement-like" functions can always have an implicit ";"; or (2) we can
say that "}" results in an implicit ";" whenever we're at the end of an
argument list and see a term rather than an operator. I think we turned
up some nasty ambiguities with (2) last time we discussed this. It would
certainly wreak havoc with unary minus.
The other way is the "newline after curly" rule, which has a foul taste
for those of us who cuddle our ifs.
/s
Re: The perl 6 parser
On Wed, 8 Jan 2003, Dan Sugalski wrote: > Could one of the folks working on the perl 6 parser give us a status > update as to where it stands? languages/perl6/README mostly reflects the status with respect to the language definition of about 4-5 months ago. Differences include: - IIRC hyper-assignment operators are there. - regex capture groups are partial/flaky, not completely unimplemented. Joseph Ryan has updated string and numeric literals to correspond to the latest consensus on the list. Other than that, it's inconsistent with the current spec in a number of ways. A lot of it's just syntax (e.g. hyper-ops, for which I'll have to cut-and-paste the non-ASCII bits). The tests should all still pass (barring inclement GC bugs), but they reflect the outdated spec. /s
Re: [perl #19183] languages/perl6/t/compiler.t -- multiple ways to spell "Inf"
On Mon, 16 Dec 2002, Nicholas Clark wrote: > Also, is the first of these a bug? > > $ ./perl6 -e 'print 3/undef; print "\n"' > Can't call method "tree" on an undefined value at ./perl6 line 342. Yes. The C function isn't fully, well, defined. /s
Re: Literal tests [was: Help with setting up Perl6]
On Thu, 12 Dec 2002, Jared Rhine wrote: > On to some tests, although I'm curious to see how tests of literals > turn out. Probably a lot of comparisons between different > representations of the same thing. Warning: most of the tests won't work now because the languages/perl6 is woefully incomplete, and because a lot of it was implemented before literals existed in their current form. If someone wants to get up to speed on the languages/perl6, this would be a great way to do it. If not, I'll put these on top of the stack for next time I have Parrot time (hopefully over break). /s
[perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #19090]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19090 >
The following defines a macro VA_TO_VAPTR(x) to convert va_list arguments
to pointers in a platform-independent way. Works for me on Linux-ppc.
Could someone with another CPU give it a spin and/or make sure I hid the
macro in the right part of {config/,lib/Parrot/Configure,...}?
/s
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/45059/35500/f05e2e/va.patch
Index: misc.c
===
RCS file: /cvs/public/parrot/misc.c,v
retrieving revision 1.30
diff -p -u -w -r1.30 misc.c
--- misc.c 10 Dec 2002 14:24:12 - 1.30
+++ misc.c 12 Dec 2002 23:51:53 -
@@ -35,7 +35,7 @@ STRING *
Parrot_vsprintf_s(struct Parrot_Interp *interpreter, STRING *pat, va_list args)
{
SPRINTF_OBJ obj = va_core;
-obj.data = &args;
+obj.data = VA_TO_VAPTR(args);
return Parrot_sprintf_format(interpreter, pat, &obj);
}
Index: config/gen/feature_h/feature_h.in
===
RCS file: /cvs/public/parrot/config/gen/feature_h/feature_h.in,v
retrieving revision 1.1
diff -p -u -w -r1.1 feature_h.in
--- config/gen/feature_h/feature_h.in 12 Dec 2002 11:20:44 - 1.1
+++ config/gen/feature_h/feature_h.in 12 Dec 2002 23:51:55 -
@@ -15,6 +15,15 @@ if (${jit_i386} && ${jit_i386} eq 'fcomi
print OUT "#endif\n";
}
+if (${jitcpuarch} eq 'ppc') {
+print OUT <<'END';
+#define VA_TO_VAPTR(x) (x)
+END
+} else {
+print OUT <<'END';
+#define VA_TO_VAPTR(x) (&(x))
+END
+}
#endif guard
print OUT "\n\n#endif\n"
Re: Help with setting up Perl6
On Wed, 11 Dec 2002, Jared Rhine wrote: > In languages/perl6/t/compiler/1_1.err, I get: > > Can't find loader Parrot_DynOp_core_0_0_7: ../imcc/imcc: undefined > symbol: Parrot_DynOp_core_0_0_7 > > which is suspicious for the 0_0_7 when I actually checked out 0_0_8. You're right on the mark here. If you re-checkout imcc from 2002/09/06 01:21:17 or later, the version number should be fixed, and things should work much better. /s
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Sean O'Rourke wrote: > On 5 Dec 2002, Rafael Garcia-Suarez wrote: > > John Williams wrote in perl.perl6.language : > > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > > ex(1) / vi(1) commands (where 're' stands for regular expression, of > > course) : > > :g/re/p > > :v/re/p > > Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" > for "Elide REgex" or "tang" for "Tog's A Negated Grep"? Gah. s/Tog/Tang/. /s
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: > John Williams wrote in perl.perl6.language : > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > ex(1) / vi(1) commands (where 're' stands for regular expression, of > course) : > :g/re/p > :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" for "Elide REgex" or "tang" for "Tog's A Negated Grep"? /s
Re: Literal Values
On Tue, 12 Nov 2002, Michael Lazzaro wrote: > What should be the syntax for closing a section? I'm partial to the LaTeX approach, where you specify the level and the computer figures out the rest. It seems like either level or closing-tag is sufficient by itself. Levels put all the information in one place, and seem to take up less space (hence supporting the idea of pod as lightweight markup). /s
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, 11 Nov 2002, Dave Whipp wrote:
> This is fine as a test, but not as documentation. Furthermore, it is
> depending on the "print" statement for its comparison (not necessarily bad;
> but I find that "golden-output" style tests tend to become difficult to
> maintain -- specific assertions tend to work better).
One thing the "golden-output" has going for it is that it gets into and
out of perl6 as quickly as possible. In other words, it relies on
perl6/parrot to do just about the minimum required of it, then passes
verification off to outside tools (e.g. perl5). I realize they can be
fragile, but at least for the moment, we can't rely on a complete
perl6 Test::Foo infrastructure, and I think that in general, we
_shouldn't_ require such a thing for the very basic tests. Because if we
do, and something basic is broken, all the tests will break because of it,
making the bug-hunter's job much more difficult.
> documentation, not code. An obvious question is how to extend it to be a
> more thorough test, whilst not spoiling the documentation. We'd want to
> intersperse text with the test-code; and probably mark a few bits as
> "hidden", from a normal documentation view (levels of hiding might be
> defined for overview vs. reference vs. guru levels of understanding).
Hm. I'm not sure how well it goes with the Perl philosophy ("the perl
language is what the perl interpreter accepts"), but we could embed the
_real_ test cases in whatever formal spec happens. This would be the
excruciatingly boring document only read by people trying to implement
perl6. I don't think real tests, which exercise specific corner cases,
mix very well with user-level documentation of any sort.
/s
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, 11 Nov 2002, David Wheeler wrote: > I think it'd be useful for folks to get a pointer to some existing Perl > 6 tests that they can model off of. Do any exist yet? languages/perl6/t/*/*.t is what we've got, though they're intended to exercise the prototype compiler, not the "real language" (which looks like it's changing quite a bit from what's implemented). The "sub main" should now be optional, btw. /s
Re: eq Vs == Vs ~~ ( was Re: Primitive Boolean type?)
See http://archive.develooper.com/perl6-internals@;perl.org/msg11308.html for a closely-related discussion. /s On Fri, 1 Nov 2002, David Whipp wrote: > In Perl6, everything is an object. So almost everything is > neither a number nor a string. It probably doesn't make sense > to cast things to strings/ints, just to compare them. We > probably want a standard method: .equals(), that does a > class-specific comparison. > > The question is, will we be modifying the definnitions of == > and eq, so that one will call the .equals method explicity. And > what does the other do? Do we want to define them in terms of > identity vs equality? Then, is identity a class-specific thing > (i.e. a .identical() method); or is it an "address-in-memory" > kind of thing? > > Did I miss a previous discussion of this? > > > Dave. >
Re: Return of RE match
On Mon, 7 Oct 2002, Dakkar wrote: > print "Yes r\n" if "0" =~ /0/; > print "Yes s\n" if "0" =~ "0"; > > prints: > > Yes s > > It appears that the RE match returns a false value. If I match: > > print "Yes r\n" if "1" =~ /1/; > > it does print "Yes r". I also tried: Probably a bug. Is this CVS parrot? If you want to take a whack at it yourself, have a look at IMCC/rule.pm or IMCC/Binop.pm (near the bottom, where "smartmatch" is handled). If not, could you run a "perl6 -k", then send me the resulting .imc file? /s
Re: RFC: static line number information
On Mon, 7 Oct 2002, Nicholas Clark wrote: > On Mon, Oct 07, 2002 at 08:27:29PM +0200, Juergen Boemmels wrote: > > But there must also be a way the higher level languages can assign > > line numbers. Maybe C-like > > #line 1 "foo.c" > > directives are a solution. > > or create dedicated assembler macros > > ..line > > ..file > > (maybe) .column > > ooh. nice. That's built in full debugging support for befunge, isn't it? We should probably add a ".plane" to support Trefunge, as well. Or just make "source position" a vector, to generalize to scripting languages of any dimension. /s
Re: Parrot file list
On Fri, 4 Oct 2002, Tanton Gibbs wrote: > I agree with this; however, I also think it would be nice to have it all in > one place. It's a nuisance to have to open every file just to see what it > is. By the time I figure out what the 60th file does, I've forgotten what > the first does. It would be nice to have the information at the top of the > file > and then have a program pull it and create a separate file...that way they > are always in sync. My thoughts exactly. Hopefully the boilerplate comment is regular enough that this should be easy-ish to write. /s
Re: Parrot file list
On Fri, 4 Oct 2002, mark sparshatt wrote: > Basically I'd like to know if there's any sort of listing that gives a > general description of what each file is used for. > > If there isn't, I've started making some notes of my own and if anyone else > thinks this would be useful then I can type them up in POD format and send > them in. I'd actually like to see this sort of info at the top of each file, perhaps in the overview section. That way it's less likely to drift away from reality when existing files are changed or new ones are added. For files where this is not possible (e.g. the pdds), maybe a per-directory README or WTFISTHIS could be used instead. Just a thought -- I have enough trouble keeping the manifest in sync ;). /s
Re: Self documenting comments for parrot
On Wed, 2 Oct 2002, Erik Lechak wrote: > I'm looking at it right now. Thanks for the link. This is the first > time I have heard of doxygen. I meant the pointer at least partly as a reminder that this is one wheel we shouldn't have to reinvent. I think there are plenty of solutions out there to the easy problem of marking up documentation, and to that of embedding blocks of doc in a program. At some point, we may also want to cross-link the documentation based on information gathered from the code, and (at least for C/C++) there are already good tools (doxygen among them) to handle this much more difficult problem. Rewriting any of these things sounds like a lot of work to me. If it's interesting work to you, please don't let me hold you back, but if the task were left to me, I'd grab something ready-made if it were at all possible to do so. > By the way is this an RFC thing? Should this "concept" be submitted > to someone other than this group? Who makes the call about what finds > its way into perl err ... I mean parrot? I'm sure we have a form for wanting to change the official project documentation format, but I don't remember the number. > If others want me to continue with this. The next step would be to > throw away 90% of my code and parse the parrotdoc into true XML. Then > that opens up parrotdoc to all the functionality of XML. Gack! :) The beauty of POD is that human beings can actually read it. XML, on the other hand, can easily become more than half meta-information, and thus less than half legible. If I were going the XML route, however, I'd suggest making it DocBook compatible, since people I've known who like their docs in XML seem to use that. btw, I think we'd have a much better idea of whether or not POD does what we need if we were a bit better at following our existing doc standards... /s
Re: Self documenting comments for parrot
On Wed, 2 Oct 2002, Erik Lechak wrote: > I was wondering if you could take a look at it and tell me if it has any > merrit, or if I should not waste my time on it and get back to the > "getting started guide". Have you had a chance to look at doxygen? It doesn't support Perl, but Perl is on the todo list, and (at least a couple of years ago) its C++ support was pretty impressive. http://www.stack.nl/~dimitri/doxygen/ /s
Re: Split Buffer
On Thu, 26 Sep 2002, Luke Palmer wrote: > Before people get I far on the regex engine, is there any plan to > implement split buffers; i.e. storing one string in multiple places and > tying them together? Has this already been done? I don't understand how this would affect the regex engine -- wouldn't it either be done inside the string implementation (since we always call string_index() to get the next char) or in its own PMC? /s
Re: perl6 operator precedence table
Thanks for taking the time to write this out.
On Thu, 26 Sep 2002, John Williams wrote:
> perl6 operator precedence
>
>leftterms and list operators (leftward) [] {} () quotes
>left. and unary .
>nonassoc++ --
>leftis but
This would lead to some scary things, I think:
$a = 3 + 4 but false
=> (= $a (+ 3 (but 4 false)))
Of course, so does having low precedence:
$a = 3 but false + 4
=> (= $a (but 3 (+ false 4)))
but I think the latter is unnatural enough that it deserves parens, so I'd
put 'but' above comma (and probably '='), but below just about everything
else.
> Larry mentions that other precedence unifications are possible. I can see
> the following as possibilites. Are there others?
> & with &&
> | with ||
It seems like a good idea to me to encourage people to think of bitwise
ops as mathematical, not logical, so I'd rather see them with different
precedences. Plus, anything that significantly goes against people's
hard-wired C expectations will just lead to confusion and pain. Finally,
having '|' below '&&' will probably lead to strange things, e.g.
1|2 && 3|4
=> 1 | (2 && 3) | 4
/s
Re: pre-PATCH: functions in languages/scheme
On 26 Sep 2002, Juergen Boemmels wrote: > These may be nice but not needed for scheme > * get keyed with INTVAL (getting direct to the Hashes) > * set keyed with INTVAL;STRING Both get(INTVAL;STRING) and set(INTVAL;STRING) are needed (or at least useful) for accessing hidden lexicals in outer scopes (e.g. "$OUTER::x"). /s
Re: for loop and streams
On Thu, 26 Sep 2002, Paul Johnson wrote: > Is that sufficiently vague? Not vague enough, because the current implementation manages to miss the broad side of that semantic barn... Different operators doing different things sounds awful to me, because it makes it hard to predict what will happen, because new operators will have to be able to control what they do with their operands, and because new types of "array-like" operands will have to tell operators how to treat them. Blech. Maybe treating lazy and/or infinite data structures as "infinitely short" for this purpose would capture most of what we mean, so hype(A,B) would take the longer of two finite lengths, the "more finite" of a finite and an infinite length, and infiniti for two infinite operands. Of course, this still doesn't account for what kind of extension makes most sense for a given operand/operator pair. It seems to me that anything more complex than "undef" (which is consistent with out-of-bounds array accesses) would be a nightmare to get right. /s
Re: perl6 on HP-UX 11.00
On Thu, 26 Sep 2002, Andy Dougherty wrote: > On Thu, 26 Sep 2002, Dan Sugalski wrote: > > > At 5:05 PM +0200 9/26/02, H.Merijn Brand wrote: > > > > > >perl t/harness > > >t/builtins/array.Can't bless non-reference value at > > >../../assemble.pl line 163. > > > > Hrm. What version of perl are you running? > > Doesn't matter (within reason). It's a 'make test' bug. Specifically, > > cd languages/perl6 && make test > > fails, but > > cd languages/perl6 && ./perl6 --test > > might succeed. > > I suspect it's actually an imcc calling-convention problem -- I see a > generated a.pasm file in my perl6 directory, but all of the t/*/*.pasm > files are empty. Sounds likely (Quick fix: change the makefile to use ./perl6 --test ;). > though perhaps a patch to assemble.pl to detect an empty .pasm file and > give a better warning would be in order. Probably. Though if we go in the "imcc generates bytecode" direction, assemble.pl can be mercifully laid to rest for P6C's purposes. > 'make test' ought to work. Yes. > It ought to automatically handle any Perl6Grammar regenerations > needed. This is a red herring for the problem you're seeing (though it is true that Perl6grammar.pm isn't automatically regenerated unless it doesn't exist). /s
Re: for loop and streams
On Thu, 26 Sep 2002 [EMAIL PROTECTED] wrote: > Hi folks! > > I did some tests with the new for loop and don't understand some of > the results. Perhaps this is just due to some warts in the > implementation at the moment. Yes. I personally think it makes more sense, in a language that allows infinite and/or lazy lists, to use the length of the shorter of the two streams, so that's what I did. When I implemented this, I had forgotten the Apocalypse passage mandating the other behavior. You're welcome to change it if you want ;). /s
Re: pre-PATCH: functions in languages/scheme
On 24 Sep 2002, Juergen Boemmels wrote: > I just got functions running in scheme. > > It uses a pre-version of Sean O'Rourkes scratchpad.pmc. (Sean, I had to > reimplement some functions to get it compile, did I get them right?) Hopefully it will be easy to reconcile our different versions (and will teach me not to send people partial patches ;). I'll look at this in the next couple of days, and hopefully send you a full clean patch before that. > and a (scheme-)list of the formal parameters. I hope it will be > possible to replace this by a Sub.pmc once it will be capable to store > the environment. I've done this in my local version, so let's see if it (or something like it) will meet your needs here. /s
