in reply to Re: What could I do with just Perl?
in thread What could I do with just Perl?

No. Turing equivalence is not enough.

Turing equivalence allows you to compute the same things, true, but it does not allow you to _do_ the same things. For instance if you take brainf*ck, well known to be turing complete, how do you get brainf*ck to do a syscall? You can't.

Besides the computational power you also need the "functional" power. In Unix this means that you need syscalls. If you have syscalls then you have it all. (Since I/O for instance translates into syscalls).

On a more theoretical note you might observe that the Turing machine has an "infinite tape". So any machine that is equivalent to a turing machine will have to have infinite storage capacity.

  • Comment on Re: Re: What could I do with just Perl?

Replies are listed 'Best First'.
Re: What could I do with just Perl?
by jonadab (Parson) on Dec 01, 2003 at 03:31 UTC
    Turing equivalence allows you to compute the same things, true, but it does not allow you to _do_ the same things.

    Besides computation, the only other thing there is to _do_ is I/O. Whether Perl has adequate I/O without modules is going to depend I suppose on what kind of I/O you need to do, but in general if you compare it to other existing languages it fares quite well in that regard. Syscalls are not, strictly speaking, needed for anything other than I/O.

    However, I certainly agree that Turing equivalence is in itself not enough to expect out of a good language. That was actually my point, though maybe I didn't state it very clearly. If that were enough, we could all just use assembly language, or, as far as that goes, program using hexadecimal numbers directly. Having a good language is about making things more efficient, easier, better, et cetera; for Perl, part of that is the CPAN; I personally do not consider any Perl installation to be complete or terribly useful in practice without a working CPAN.pm

    There happens to be at the moment more on this topic (Turing equivalence and its inadequacy as a criterion for determining the usefulness of a language) on my pad, as I am presently in the process of piecing together there a pending meditation which may or may not end up getting posted. (Feedback on it, including whether it is worth posting, is welcome.)


    $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
      This depends a bit on what you mean by "io". Do you think that the "kill" syscall represents io? What about "reboot"? Certainly all syscalls interact with the operating system, but not all syscalls interact with the user, a disk, a printer or the network. But yeah IO is sort of important. And since perl has a syscall builtin it is certainly powerful enough in this respect too.

      Yes. I certainly agree with the practical side of what you were saying. The structure of a programming language is extremely important. It shapes how we think. I mean, just think about 1986 and how they shape language to shape thought. Language designers get to do the very same things. And it is very exciting. I just pounced on the theoretical point (because I was dodging real work).

      As for Lazy evaluation. Don't go totally down that path. The functional language community has tried this in Haskell, and while it has theoretical beauty it has practical problems. Some of the practical problems have to do with side effects. In the presence of side effects you face problems with incoherency and such depending on reduction order and other estotheric things. (There are papers written on this of course, these people write more paper than code sometimes).

      That being said. Maybe partial laziness might be a good thing. Perhaps partial laziness could be implemented with a keyword and a source filter in Perl 5. Hmm. Yes. Lazy assignments.

      my $result =[l] calc(30,20,"FooBar"); my $result2 =[l] calc($result,20,"YoYo"); my $result3 = $result + $result2;
      We'd have to take care that it was never evaluated more than once though. Hmm. I think this might be doable. Yes a source filter and a hidden tied scalar is what we need. And some duct tape.

      Danged. Now I forgot what my post was about. Anyhow, the musing seem interesting.

      A quick edit.. A search on CPAN returned: http://search.cpan.org/~jenda/Data-Lazy-0.5/Lazy.pm

      I would still want it in the semantics though, so maybe just couple it with a source filter.

        Ah yes. I had never made a source filter before, so I tried my fingers at a little hack. It has some obvious defects, but it works on the little example. It also uses Data::Lazy. Note how laziness of evaluation plays tricks with us here in the last example. Use only if you know what you are doing. Here is the simple module:
        package LazyFilt; use 5.8.0; use warnings; use strict; use Data::Lazy; use Filter::Util::Call; our $state = 0; sub import { filter_add([]); } sub filter { my $status = filter_read(); return $status unless $status > 0; my $result = ""; my @stmts = split /;/; foreach my $stmt (@stmts) { my @lazyass = split /=\[l\]/,$stmt; if (@lazyass == 1) { $result .= $stmt . ";"; next } die "We don't support this (@lazyass)!" if (@lazyass > 2); $result .= "tie $lazyass[0], 'Data::Lazy', sub { $lazyass[1] };"; } $result .= "\n"; $_ = $result; return $status; } 1;
        And a small example that uses it:
        use LazyFilt; use strict; use warnings; sub calc { my ($p1,$p2,$p3) = @_; print "Here is where really slow stuff happens\n"; my $sum = $p1 + $p2; } my $result =[l] calc(30,20,"FooBar"); my $result2 =[l] calc($result,20,"YoYo"); print "Just about now I need to show the first result: $result\n"; my $result3 = $result + $result2; print "And now I need the whole result: $result3 \n"; print "After this it is free to poke around: $result2\n"; my $a = 10; my $result4 =[l] 2+$a; $a = 14; print "Result? $result4\n";
        If anyone actually fancies this I could even clean it up properly.