Perl -> JS Interpretation Suggestion
opened this issue · comments
Hello,
As someone who is very interested in this project, I wanted to know what would be the simplest way of going about running Perl in the browser. I see that in order to do this, we will likely have to work with the binary data that comes with each file. However, why not have the Perl script saved or "read" as a text file, then JavaScript receives the data and runs functions based on what was written (with Python as a medium)? It seems possible because the file can be interpreted line by line instead of doing a bunch of str.replace()s. We can use JavaScript's object to translate each Perl method while keeping note of brackets.
One reason for me suggesting this is because, looking through the scripts, this seems to be geared more towards the server-side of things, when users may have to test Perl on the client-side of their programs. Plus, it seems a lot simpler than having to go through an entire build process of procedures.
P.S.: It would really be helpful if you could include which files are useable and which files are to be worked on for/by users in the README.
JSON will likely have to be incorporated with transitioning the Perl .txt into JavaScript as a mediator as well.
Thanks very much for your interest! Unfortunately, I'm having a bit of trouble understanding what you are suggesting.
I see that in order to do this, we will likely have to work with the binary data that comes with each file. However, why not have the Perl script saved or "read" as a text file ...
The Perl scripts loaded by WebPerl are regular script (text) files; the only "binary" data is the WebPerl WebAssembly binary.
... then JavaScript receives the data and runs functions based on what was written (with Python as a medium)? It seems possible because the file can be interpreted line by line instead of doing a bunch of
str.replace()s. We can use JavaScript's object to translate each Perl method while keeping note of brackets.
I'm very sorry, but I've read this a few times now and I'm not sure I entirely understand what you mean. Perhaps you could show an example (with code)?
If you're suggesting that Perl be transpiled to JavaScript, then while theoretically not impossible, it would be a monumental task. Either, one would have to limit oneself to a strict subset of Perl (e.g. like RPerl does), or one ends up re-implementing the entirety of perl, because "only perl can parse Perl" - this is why I chose to port the actual perl binary instead. Therefore, sorry, but translating Perl to JavaScript is outside the scope of this particular project. However, the advantage of this project is that it is (to my knowledge) the only way to run the entirety of Perl on the client side in the browser (subject to the limitations of the browser environment).
looking through the scripts, this seems to be geared more towards the server-side of things
No, WebPerl runs entirely on the client side, with no server-side interaction required. I did include a bunch of examples that also use the server, but that's not required for the use of WebPerl - for example, two of the apps I wrote, the Demo Code Editor and the Regex Tester, don't require a server.
it seems a lot simpler than having to go through an entire build process of procedures
The build process does require a Linux machine, but I don't think there's really a better way to do this. However, there have been a few suggestions like #10 to make it easier to load some modules into Perl, so that rebuilds of WebPerl are required a little less often.
P.S.: It would really be helpful if you could include which files are useable and which files are to be worked on for/by users in the
README.
I chose to include the documentation in the GitHub pages, which you can access on https://webperl.zero-g.net/, or you can do what I do and check out the pages, for example, in the webperl directory checked out from GitHub, you can do: git clone -b gh-pages https://github.com/haukex/webperl.git pages - I think you can find the information you're looking for there, if not, please feel free to get back to me with questions.
... then JavaScript receives the data and runs functions based on what was written (with Python as a medium)? It seems possible because the file can be interpreted line by line instead of doing a bunch of
str.replace()s. We can use JavaScript's object to translate each Perl method while keeping note of brackets.
In JSON format, JavaScript is able to identify and run functions. With Python, we can make a loop that looks at each line of the Perl script and replace anything that needs to.
Why does the build require a Linux machine? Is it because of the shell scripts to install dependencies?
(One thing that I think will make this much more user friendly is if we remove all the dependencies by including what we only need in the repository.)
I suspect that you may be missing some of the key obstacles to running perl in the browser without embedding perl as a binary. Sure - you could transpile a few functions but anything non-trivial would break down pretty quickly. Have you got the code built and working in a browser? If not and you are just skimming the code then strongly suggest going through the motions and getting something to work before suggesting transpiles etc.
@pscott-au
What are some of the obstacles that are in the way?
My understanding is that essentially if you have to ask then you really don't want to keep on that path. Maybe skim over this The Perl TMTWWTDI maxim means that many people use popular but syntactically diverse approaches to their coding style. Read through the Perl OOP man page or do some searches on functional programming with Perl. The regex engine is not something you can just 'translate' to JS. How about memory management, threading etc. Many of the popular idioms won't parse well without massive amounts of coding - people think of Perl as an old simplistic language but whatever the latest trendy patterns are that define and constrain other languages - I'm amazed how frequently there are usualy idiomatic approaches to achieve the same thing and often more elegantly. Of course if all you want is to parse a few basic loop structures and simplistic data structures then sure you could go ahead; You'll suck all the hidden magic and elegance out of Perl and make it as simple as JS to avoid using Webpack and end up with code that looks like Perl but is even more restricted that Javascript.
NB - I am no expert so please let me know if you have any success worth sharing as it sounds like an interesting approach but not really related to this repo or project I suspect.
Without looking too far .. consider parsing this:
BEGIN {
if( 0.5 < rand() ) {
eval "sub whatever() { }; 1" or die $@;
} else {
eval "sub whatever { }; 1" or die $@;
}
}
whatever / 25 ; # / ; die "this dies!";@ForgivenNin:
In JSON format, JavaScript is able to identify and run functions.
Note that JSON does not support functions.
With Python, we can make a loop that looks at each line of the Perl script and replace anything that needs to.
That sounds like transpiling, which @pscott-au and I explained is much more complex than your one sentence here :-)
Why does the build require a Linux machine? Is it because of the shell scripts to install dependencies?
IIRC it's mostly because it was easier to integrate with the Emscripten environment and for the build script to call the external commands it needs to run under Linux. I don't plan on adding Windows support for the build process myself anytime soon; spinning up a Linux VM is trivial nowadays, and anyway it's only required if someone wants to rebuild WebPerl instead of using the prebuilt files (available under the Releases tab).
One thing that I think will make this much more user friendly is if we remove all the dependencies by including what we only need in the repository.
I'm not sure what you mean - I try not to make my projects too dependency-heavy, but there are some CPAN modules required, nothing too heavy IMHO. Are you suggesting I copy the CPAN modules I use into this repository? Sorry, but that doesn't make sense to me.
A previous version of your comment said:
An idea that just came to mind as I thought about this is that JavaScript can detect the type of text a
<script>tag is classified as.
webperl.js already does this - I suggest you take some time to read the documentation, the links above, and play with the prebuilt WebPerl. Let me know if you have any questions (feel free to open new issues if they are unrelated to this one).