[perl #18622] [PATCH] Befunge now supports the pop and push instructions of the PerlArray PMC
# New Ticket Created by Jerome Quelin # Please include the string: [perl #18622] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18622 > Well, the topic says it pretty much: befunge now supports the push and pop instructions builtin in PerlArray PMC, and I can get rid of my own crafted version of push and pop in Parrot Assembly. Fear, cause now I'll be able to find even more bugs! :-) Jerome -- [EMAIL PROTECTED] -- attachment 1 -- url: http://rt.perl.org/rt2/attach/42194/33997/461ca0/befunge_use_pop_push.patch ? .timestamp ? languages/Befunge-93/befunge.pbc Index: languages/Befunge-93/Changes === RCS file: /cvs/public/parrot/languages/Befunge-93/Changes,v retrieving revision 1.1 diff -u -d -r1.1 Changes --- languages/Befunge-93/Changes 14 Sep 2002 13:56:44 - 1.1 +++ languages/Befunge-93/Changes 23 Nov 2002 09:27:40 - @@ -1,5 +1,10 @@ Revision history for Befunge-93 interpreter written for Parrot. +0.04 Sat Nov 23 10:22:51 CET 2002 +- now using the push and pop instructions of the PerlArray + PMC, and thanks go to Steve Fink for his hack to pop an + empty PerlArray. + 0.03 Mon Sep 9 21:26:11 CEST 2002 - taking advantage of Parrot's 'chr' instruction, getting rid of Clinton Pierce's hack. Index: languages/Befunge-93/README === RCS file: /cvs/public/parrot/languages/Befunge-93/README,v retrieving revision 1.3 diff -u -d -r1.3 README --- languages/Befunge-93/README 14 Sep 2002 13:56:44 - 1.3 +++ languages/Befunge-93/README 23 Nov 2002 09:27:41 - @@ -1,19 +1,19 @@ DESCRIPTION --- -This is a Befunge interpreter written in Parrot assembler, version 0.03 +This is a Befunge interpreter written in Parrot assembler, version 0.04 This interpreter should be Befunge-93 compliant. This means the playfield is limited to 80x25 and can hold *only bytes*. This means that you can't fetch/store numbers greater than 255 or less than 0 in the torus (even if I do not check for over/underflow - for now). -You should compile the files with: +You should compile and test the files with: $ make test Then you can run your Befunge program with: - $ ../../parrot befunge.pbc [-v] foo.bef + $ ../../parrot befunge.pbc [-v] foo.bef The -v flag makes the befunge interpreter more verbose. @@ -26,8 +26,7 @@ flow.pasm handles the flow-control instructions io.pasm handles the io related instructions maths.pasm handles all the maths instructions -stack.pasm handles the stack operations as well as stack -instructions +stack.pasm handles the stack instructions Makefilea tiny, little Makefile to help (me) during developement test.befa befunge script that test almost all the Index: languages/Befunge-93/flow.pasm === RCS file: /cvs/public/parrot/languages/Befunge-93/flow.pasm,v retrieving revision 1.1 diff -u -d -r1.1 flow.pasm --- languages/Befunge-93/flow.pasm 17 Aug 2002 00:18:34 - 1.1 +++ languages/Befunge-93/flow.pasm 23 Nov 2002 09:27:41 - @@ -43,8 +43,10 @@ # after: ... # delta <- if (b) (-1,0) else (1,0) FLOW_EW_IF: -bsr POP -restore I10 +set I10, P2 +unless I10, FLOW_EW_IF_POP_1 +pop I10, P2 +FLOW_EW_IF_POP_1: eq I10, 0, FLOW_GO_EAST branch FLOW_GO_WEST @@ -54,8 +56,10 @@ # after: ... # delta <- if (b) (0,-1) else (0,1) FLOW_NS_IF: -bsr POP -restore I10 +set I10, P2 +unless I10, FLOW_NS_IF_POP_1 +pop I10, P2 +FLOW_NS_IF_POP_1: eq I10, 0, FLOW_GO_SOUTH branch FLOW_GO_NORTH @@ -67,16 +71,19 @@ # Result is either 1 or 0. FLOW_COMPARE: pushi -bsr POP -restore I10 -bsr POP -restore I11 +set I10, P2 +unless I10, FLOW_COMPARE_POP_1 +pop I10, P2 +FLOW_COMPARE_POP_1: +set I11, P2 +unless I11, FLOW_COMPARE_POP_2 +pop I11, P2 +FLOW_COMPARE_POP_2: set I12, 1 gt I11, I10, FLOW_COMPARE_TRUE set I12, 0 FLOW_COMPARE_TRUE: -save I12 -bsr PUSH +push P2, I12 popi branch MOVE_PC Index: languages/Befunge-93/io.pasm === RCS file: /cvs/public/parrot/languages/Befunge-93/io.pasm,v retrieving revision 1.2 diff -u -d -r1.2 io.pasm --- languages/Befunge-93/io.pasm 14 Sep 2002 13:56:44 - 1.2 +++ languages/Befunge-93/io.pasm 23 Nov 2002 09:27:41 - @@ -6,8 +6,7 @@ IO_PUSH_CHAR:
More tests.
I've added a slew of new tests to the p6-literals test-suite, including: - Error tests. - Bit-type. - Subscripted variable interpolation. - Variable method interpolation. - Many conversion tests. I was a bit unsure (read: possibly rong as wrabbits) on some of the error and conversion tests, so let me know if you find any errors or discrepancies. Find them at: http://jryan.perlmonk.org/images/literals.tar.gz
Re: Numeric Literals (Summary 4)
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote: This: > - radix > 36, only colon form is allowed, not alpha digits implies that this: > 256#0_253_254_255 # base 256, NOT identical! is actually not allowed, no? %Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] |
Re: TERN-discuss mailing list finally available
[EMAIL PROTECTED] (Joseph F. Ryan) writes: > Are these people serious? What on earth is the point? I suggest a Tern versus Rindolf shootout. -- An algorithm must be seen to be believed. -- D.E. Knuth
Re: String concatentation operator
[EMAIL PROTECTED] (Smylers) writes: > >... they believed that the + should concatenate the two strings. > > > > Makes perfect sense to me. > > Makes sense in a language where variables are typed It also makes sense in a language where values are typed. They just have to be slightly more strongly typed than just "scalar". But Perl 6 is already going to support INT and STRING built-in types, right? So I see no problem with + doing string concat. I could mention some other languages (or at least, a language (of which I'm becoming considerably more fond as I get to know it (especially having just come back from Japan (excuse the jet lag which takes this approach. -- Sigh. I like to think it's just the Linux people who want to be on the "leading edge" so bad they walk right off the precipice. (Craig E. Groeschel)
Re: String concatentation operator
On Sat, Nov 23, 2002 at 07:34:47PM +, Simon Cozens wrote: >I could mention some other > languages (or at least, a language (of which I'm becoming considerably > more fond as I get to know it (especially having just come back from > Japan (excuse the jet lag which takes this approach. Lisp is Japanese? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: String concatentation operator
On Sat, Nov 23, 2002 at 07:34:47PM +, Simon Cozens wrote: : [EMAIL PROTECTED] (Smylers) writes: : > >... they believed that the + should concatenate the two strings. : > > : > > Makes perfect sense to me. : > : > Makes sense in a language where variables are typed : : It also makes sense in a language where values are typed. They just : have to be slightly more strongly typed than just "scalar". But Perl 6 : is already going to support INT and STRING built-in types, right? So I : see no problem with + doing string concat. I could mention some other : languages (or at least, a language (of which I'm becoming considerably : more fond as I get to know it (especially having just come back from : Japan (excuse the jet lag which takes this approach. While no assumption is going unquestioned for Perl 6, I do still believe that the decision not to overload + for concatenation is one of the few things I did right in Perl 1. When people look at $a + $b in Perl they don't have to wonder what it means. Addition is such a fundamental operation that it should be kept as clean as possible, both for readability and for optimizability. (The two are not unrelated.) There are several things I like about Ruby, but using + for string concatenation is not one of them. It's another one of those areas where the Principle of Least Astonishment is misapplied. Any language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. Ruby's scoping rules also fail on this point, in my estimation. Larry
long double error
When's the long double "KNOWN ISSUE" going to be fixed? What's the work around, just to build a perl with NV==double? I've looked around, can't find anything about it except in KNOWN_ISSUES (only match in RT is "Parrot_sprintf-related stuff"). Scan of the archives turns up nothing. Thanks, Dave Isa. 40:31
[perl #18637] PDD06: Incomplete sentence at end of section
# New Ticket Created by kj Woolley # Please include the string: [perl #18637] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18637 > Hello Dan and folks, I've been reading through the PDDs, and I'm really quite impressed -- so far, they have answered most of the questions I've had, and the writing quality is great (though I will submit patches to fix some typos and grammatical errors on my second read-through). One that leaves me hanging is source line 185 of PDD06 -- "String and integer constants don't need to be put in a separate" and the sentence cuts there. Do you have any insight as to what the end of that sentence should be? I'm guessing "namespace", but it seems to me like there might be more missing. Not a huge deal, but it is kind of a cliff-hanger. :) Cheers, ~kj
Dynamic scoping (take 2)
First, I'd like to confirm I've understood C and C right: 1. C dynamically scopes changes to a variable's value to the enclosing block. It does not dynamically scope the name. The variable can obviously be a global. It can also make sense if it is lexical. Is the latter currently allowed? 2. C is a conditional C; it only restores a variable's value if, on exit from the enclosing block, the block is somehow considered to have "failed". It can be applied to a global or lexical. The above two features are basically sugar for what would otherwise be achieved with paired FIRST/LAST/UNDO blocks. Both must be applied to an existing variable. Next, I want to do a better job of stating a problem I wonder about: Consider "environmental" values such as "screen sizes, graphics contexts, file handles, environment variables, and foreign interface environment handles." [1] Consider a sub One that is going to call a 10 deep stack of subs such that sub Ten needs to access one of these environmental values. How do you pass the data? A. Globals. Bad. Disastrous in threads. B. Passed as args to all intervening subs. Verbose. Sometimes incredibly verbose. C. Aggregate info into objects. But then you still have to do either 1 or 2 above with the object references. And it's a shame to be forced to the object paradigm unnecessarily. D. Use $CALLERS::. Relatively succinct, but definitely error-prone and ugly. Given what I understand of Perl 6 syntax, Parrot, and Perl philosophy, I suspect P6 should, and could fairly easily, provide a good solution to the problem outlined above. Does anyone agree the problem I've outlined is inadequately addressed by $CALLERS::? In previous emails I've suggested: 1. The notion of something like attaching a C property on variables, and picking appropriate defaults for its args (not/ro/rw), to allow the writer of a sub to easily strictly limit what a called sub can access. 2. The notion of args that are explicitly defined in a sub's sig but implicitly passed. This kills most of the verbosity of B above, while, in combination with the previous point, being otherwise just as safe as passing args explicitly all the way down the call stack. [1] http://tinyurl.com/2yhl -- ralph
Re: Dynamic scoping (take 2)
> [temp] > [implicit args] Here's a snippet of conversation on a haskell list about implementation of implicit args : http://tinyurl.com/2ym1 -- ralph
Dynamic scoping
First, I'd like to confirm I've understood C and C right: 1. C dynamically scopes changes to a variable's value to the enclosing block. It does not dynamically scope the name. The variable can obviously be a global. It can also make sense if it is lexical. Is the latter currently allowed? 2. C is a conditional C; it only restores a variable's value if, on exit from the enclosing block, the block is somehow considered to have "failed". It can be applied to a global or lexical. The above two features are basically sugar for what would otherwise be achieved with paired FIRST/LAST/UNDO blocks. Both must be applied to an existing variable. Next, I want to do a better job of stating a problem I wonder about: Consider "environmental" values such as "screen sizes, graphics contexts, file handles, environment variables, and foreign interface environment handles." [1] Consider a sub One that is going to call a 10 deep stack of subs such that sub Ten needs to access one of these environmental values. How do you pass the data? A. Globals. Bad. Disastrous in threads. B. Passed as args to all intervening subs. Verbose. Sometimes incredibly verbose. C. Aggregate info into objects. But then you still have to do either 1 or 2 above with the object references. And it's a shame to be forced to the object paradigm unnecessarily. D. Use $CALLERS::. Relatively succinct, but definitely error-prone and ugly. Given what I understand of Perl 6 syntax, Parrot, and Perl philosophy, I believe P6 should, and can fairly easily, provide a good solution to the problem outlined above. Does anyone agree the problem I've outlined is inadequately addressed by $CALLERS::? In previous emails I've suggested: 1. The notion of something like attaching a C property on variables, and picking appropriate defaults for its args (not/ro/rw), to allow the writer of a sub to easily strictly limit what a called sub can access. 2. The notion of args that are explicitly defined in a sub's sig but implicitly passed. This kills most of the verbosity of B above, while, in combination with the previous point, being otherwise just as safe as passing args explicitly all the way down the call stack. [1] http://tinyurl.com/2yhl -- ralph
Re: Dynamic scoping (take 2)
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
# unless it is passed
# to a sub explicitly.
my $foo;# same for $foo
my $baz is yours; # $baz will automatically
$baz = 10; # be passed to /directly/
# called subs that "ask"
# explicitly for $baz.
&waldo($foo);
}
sub waldo ($b ; $baz is yours)
{ print $baz; &emer; }
sub emer (;$baz is yours(no))
{ print $baz; &qux; }
sub qux { ... }
Running this prints '1010'. Here's why:
A property exists that can mark any lexical
as "yours". When a variable is marked yours
it is automatically passed to any directly
called sub (not nested subs) that mentions
it appropriately.
The "automatic" $_ (available without
declaring with a 'my') is marked "yours"
by default.
All other (ie declared) lexicals are, by
default, not yours, hence guaranteed to be
private lexicals unless explicitly passed
to a sub. This is safer than the current
perl 6 design in which use of $CALLER::,
and even builtins and subs that merely
use the topic, might accidentally clobber
one of my lexicals at any time.
Once execution reaches the body of waldo,
there is a new lexical called $baz that is
bound to the lexical with the same name in
the body of the caller.
The C in waldo's sig has two
effects:
1. It requires that any /caller/ has a
variable of the same name marked as
yours or must pass a variable/value
using the named arg syntax for that
arg name;
2. It propogates the marking of $baz as
a yours marked variable for any sub
called from this, the body of waldo.
Once execution reaches the body of emer,
there is a new lexical called $baz that is
bound to the lexical from waldo which is in
turn bound to the lexical within qux.
The '(no)' at the end of the C
means that $baz is private to emer -- it
will not be passed to called subs by the
yours mechanism.
In summary, you mark variables that are
to be automatically passed from sub to
sub with 'is yours' where appropriate.
--
ralph
