in reply to Brainfuck Interpreter

Have a look at my Brainf*ck interpreter :).
Please note that not all Brainf*ck programs will work with our implementation, because the original brainfuck:

Perl makes it easy to make both those things unlimited, but that means that if $array[$pointer] is 255, + will set it to 256, instead of 0. It also means that if $pointer is 29999, the next one will be 30000, not 0.

And of course, @_[0] is better written as $_[0] but -w probably already told you. (Further, it isn't smart to interpolate if the end result will be the exact same string, and it might be nice to use the new 3-argument open() for safety)

Next point of comment: <> will wait for $/, while , is supposed to get just a single character. 

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

Replies are listed 'Best First'.
Re: Re: Brainfuck Interpreter
by tomhukins (Curate) on Mar 13, 2002 at 12:54 UTC
    @_[0] is better written as $_[0]

    That depends on your definition of "better". If you're writing code to parse a language which is deliberately confusing, it's arguably better to parse it in as confusing a way as possible.

    I found this parser really easy to understand - why not write an obfuscated parser for obfuscated code? ;-)

    Update: Perhaps I need to make it clear that I'm not being entirely serious. It's certainly a bad idea to use the side effects of an array slice in real code. On the other hand, if you want to do something confusing, do it in the most confused way possible!

[reply]
[d/l]
[select]

      That depends on your definition of "better". 

      2;0 juerd@ouranos:~$ perl -we'@_[0]'
Scalar value @_[0] better written as $_[0] at -e line 1.

      [download]
      That's my definition. @_[0] is an array slice, which happens to have a single value, and just happens to work because of that. For example: 
      my @foo = qw(a b c d e f g h i j);
my @bar = @foo[1, 5, 6, 4];         # @bar is now qw(b f g e)
my $bar = $foo[0];

      [download]
      When you want a scalar, USE a scalar :)

      If you're writing code to parse a language which is deliberately confusing, it's arguably better to parse it in as confusing a way as possible.

      Perhaps, but I don't agree. And even if you were right, there's no need to use PERL for that. (note: "PERL" ne "Perl"). 

      U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

[reply]
[d/l]
[select]
Re: Re: Brainfuck Interpreter
by o(o_o)o (Scribe) on Mar 13, 2002 at 15:33 UTC

    I'm gonna take that stuff into consideration when implement .02 which will hopefully have load of cool features which i was thinking about when i wrote the code, but didn't implement in v.01...

    i'll add in all the restraints on the language too like the size of the buffer, and the single byte per value...

    my intention for "," as input was to have <> trap whatever the user input but it will only push the first character of the string inputted onto the stack... but i'll make it trap only 1 character in the future..

    Thanks very much for your help o(o_o)o

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    i would slit my wrists for you
[reply]

      another thing ;)... i know most people think that it should maybe be written obfu'd, but that wasn't really my way of thinking... i set out to write an interpreter which will be easy to understand so that modifications could easily be made to 1)make the code better, 2)add extra features and make extra commands(ie.another language), 3)allow easy integration of more functions of the interpreter such as debugging and stepover. but i see where u lot are all coming from ;)

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      i would slit my wrists for you
[reply]

In Section Cool Uses for Perl