|
in reply to A Perl interpreter written in Perl?
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.
|
Re^2: A Perl interpreter written in Perl?
by LanX (Saint) on Apr 16, 2025 at 20:28 UTC
|
> 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] |
|
|
I'm not sure why you are talking about performance now.
ECMAScript's language specification led to many competing implementations.
And having an alternative implementation of Perl would naturally involve the need of a specification and/or help define it.
> Now, a somewhat reduced and limited Perl written in JavaScript
perlito was already mentioned twice in this thread.
Haukex' webperl is feature complete (not "reduced") but it's not written in JS (apart tiny parts for bridging), but cross compiled to WebAssembly
| [reply] |
Re^2: A Perl interpreter written in Perl?
by 1nickt (Canon) on Apr 16, 2025 at 13:39 UTC
|
| [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] |
Re^2: A Perl interpreter written in Perl?
by harangzsolt33 (Deacon) on Apr 16, 2025 at 13:51 UTC
|
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] |
|
|
I'm not aware of any real interpreter languages anymore. That's a distinction from the 80s or 90s, reality evolved faster than terminology.¹
Perl has a compiler creating optimized op-codes, you can even precompile .pl to .plc code.
The engine running this code is roughly kind of like the JVM, but not as flexible because of many idiosyncracies.
The real difference nowadays is not interpreted vs compiled, but dynamic typing vs static typing.
Compare JavaScript vs TypeScript.²
In this light, it's hard to answer the OP because I don't know what he thinks an interpreter does.
¹) Microsoft BASIC was interpreted, the source for almost all BASIC dialects back then. But even here the source code was normalized internally to 2 letter mnemonics to optimize space and speed.
²) That's a fair comparison, since JS was heavily influenced by Perl.
| [reply] |
|
|
|
|
|
|
| [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] |
|
|
