|
Re: A Perl interpreter written in Perl?
by stevieb (Canon) on Apr 16, 2025 at 16:26 UTC
|
| [reply] |
|
|
Yes, that looks very close!
| [reply] |
Re: A Perl interpreter written in Perl?
by LanX (Saint) on Apr 16, 2025 at 20:06 UTC
|
> but that's not what I mean
So what do you mean?
A pure interpreter would
- parse
- immediately execute
Perl code inside the perl engine.
So how should Perl interpret a map or printf other than using map or printf?
If you are talking about compiling Perl to other engines...
Yes this was attempted, like with perlito
| [reply] |
|
|
I have never heard of Perlito. Wow. That is some amazing project!!!
So how should Perl interpret a map or printf other than using map or printf?
The print function should be called directly, because we cannot reduce it any further, but printf can be, because of the formatting. In fact, JavaScript does not have a builtin printf() function, and I decided to write one. And it's not as easy as it first sounds... The printf function could be broken down into smaller units, or it could be just a call to the builtin printf(). But I don't think this is a big issue, because there are much larger issues. For example, when the perl parser sees a line like this, it has to figure out where to even begin: $J = A() + B() * C(D(F() - 1) - E() / 2 + 1);
Then where do we stop? The perl parser could use a single variable and assume that that's the computer's memory. So, one could implement a memory manager, garbage collector, reference counters, etc. The problem is that perl is relatively new to me, so I don't even know what parts it has. I'm still at the point where I don't even know how much I don't know about perl. lol
I wrote a little program in Perl that emulates 64-bit integer math on 32-bit processors. Of course, it's terribly slow, but it's interesting. Writing that thing was as exciting as building an artificial engine made of glass. Of course, such an engine would never be used in a car; it's for show only. But still, it's fun to build!
I typed this yesterday, but I couldn't send it because the PerlMonks website was down. Even now I have trouble accessing it sometimes. It's super unreliable...
| [reply] |
|
|
As already mentioned, there are already alternative parsers available, like PPI
For running that source exactly like in the original you'd need to compile the source to OP-Code (and namespaces, etc.)
How this OP-code is interpreted (here the usage of the word is correct), i.e. either from Perl's runtime engine in full speed or by an emulation implemented in Perl, is another question.
Parser, compiler and runtime interpreter are very different beasts, which IMHO should be approached independently.
Keep in mind that Perl's compile and runtime are interwoven.
Every BEGIN-block is injecting a run into compilation, and every eval is triggering a compilation while running.
| [reply] |
Re: A Perl interpreter written in Perl?
by choroba (Cardinal) on Apr 17, 2025 at 09:29 UTC
|
If you know Java, you can translate the PerlOnJava to Perl.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply]
[d/l] |
|
|
Good to see that Flavio is still on it
> translate the PerlOnJava to Perl.
Using Perl to create JVM bytecode is rather a cross compiler than an interpreter.
And a very limited one, since eval wouldn't work.
I'd rather stick with Flavio's perlito projects
| [reply] |
Re: A Perl interpreter written in Perl?
by cavac (Prior) on Apr 16, 2025 at 10:52 UTC
|
Uhm, what would even be the point of that excersise? I huge amount of never-ending work, only to do things a lot slower than eval() and the perl binary can already do.
| [reply] |
|
|
> point of that excersise
Creating a formal language definition, perhaps?
Consider what happened to JavaScript 1.0 after it evolved to ECMAScript.
But doing this in Perl would lead to a logical paradox, unless it's a reduced simpler Perl for bootstrapping the definition.
| [reply] |
|
|
Not to mention the whole thing would probably be awfully slow. And it would probably be a compromise anyway, if the plan is to reach full Perl compatibility. I mean, how would you load C-Libraries, for example? You can either do that in the underlying Perl binary, or you start including a whole C/C++/machine code interpreter...
A limited/reduced/simplified Perl interpreter certainly has its use cases. But if you need a full-blown Perl installed to run it, that somewhat defeats the point.
Now, a somewhat reduced and limited Perl written in JavaScript, that could be damn useful for web development.
| [reply] |
|
|
|
|
|
|
| [reply] |
|
|
From my point of view, there's a bit of a difference between writing a simple, very basic HTTP client design for a specific use case and writing a full blown Perl interpreter that also needs to keep pace with normal Perl releases.
You may disagree off course. And i'd be more than willing to run my projects on your Perl interpreter to check it out, report bugs and maybe even contribute some patches. I don't have an extra lifetime available to donate fulltime to such a project. If someone comes up with a use case where a (slower) Perl interpreter written in Perl actually justifies the amount of work required, i would be more supportive.
Also, not exactly sure why you bring up my Async HTTP client at all. I had a need for one of my projects of such a thing, i wrote it to support that specific use case, and it took me less time to do it that to rewrite existing software to support one of the other HTTP clients. I released the source code because it might be useful for someone else. If you don't like it, fine, use something else. You don't like it that there is no one to support it if i die or loose interest? Doesn't rob me of a minute of sleep.
| [reply] |
|
|
I'm not sure, but it would be an interesting exercise. I know that other languages have produced their interpreters or compilers in their language. For example, there is a Python interpreter written in Python. There are Basic interpreters written in Basic. There's a Rust compiler written in Rust. And of course, there are C compilers written in C. But I guess, the whole point is to prove that it CAN BE done, and it would be an interesting exercise. And I think, if we look at languages, the more popular a language is, the more likely that there will be many such seemingly "pointless" exercises written in that language, because people want to spend time coding in that language. So, they'll write all sorts of things, even things that don't make any sense. So, this would be one of those projects.
| [reply] |
|
|
A compiler can be written in a "slow" language and still be producing fast/efficient binaries, slowly. Whereas, with an interpreter things are a bit different because the speed of the running script is determined by both the script's efficiency and the interpreter's efficiency. You can get rid of the compiler once your program is compiled but you can never get rid of the interpreter, you need it every time and you suffer its inefficiencies every time you run your script. I am not sure whether Perl is strictly interpreting the script or it compiles (parts of?) it somehow. For this reason, it is logical to write your compiler in as high-level language there is available/you are familiar with. And write your interpreter in as "fast" a language there is. C IMO was the sweet spot for speed/efficiency/high-level. Perhaps not any more. But it works well for the Perl interpreter, it is fast.
I believe a C compiler starts as an assembly program or as a program in another language preceding C for which there is a compiler available. Then, once you have the C compiler binary, you write the compiler in C and compile that. And then you don't depend on other languages in order to maintain/evolve your C compiler, assuming you already have a C compiler binary. If all the C compiler binaries of the world disappear one day (here is a grand SciFi scenario!) perhaps because antivirii gone mad, then we need to start from assembly again. Or modula-2 or whatever language for which there is a compiler available. The higher level the easier it would be.
A compiler also depends on a parser to parse the input program. And that can get really complex if in assembly (in fact that's how Yacc was developed). But once you have a basic C compiler then you can write the parser (aka compiler-compiler) in C and compile that. The benefit being the higher level language will be helpful in adding more features/complexity to your parser. In fact a parser acts as a rudimentary compiler (omitting the efficiency heuristics a fullfledge modern compiler has) therefore it can be said that "a compiler is written in its "grammar"", which the parser parses, as opposed to "a compiler is written in C", for example.
I do not know what other reasons there are for writing a C compiler in C. But do not discount these: it would be a good test for the language and the compiler program. Plus, the whole exercise has a turing-complete kind of sound to it. Oh, and because Computer Science curriculum was really nerdy at some point in time and the students loved it immensely, despite the famous book cover being a red Godzilla (dinosaur?).
Of course all the above do not apply for Python. For Python there must be one and only one reason: the perversity of a sect of Conformists.
| [reply] |
|
|
|
|
|
|
|
Using a digital computer? Bah, piker.
The Oracle hands you a large roll of paper tape and a hole punch engraved with the name "A. Turing".
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] |
|
|
| [reply] |
