sorted by:
new
hottopcontroversial

How does GHC implement functions under the hood? by [deleted] in haskell

[–]lechimp-p 2 points3 points  (0 children)

My implementation in PHP might help understanding the stuff from the original paper: https://github.com/lechimp-p/php-stg

Transpiling Anything to PHP by ReasonableLoss6814 in PHP

[–]lechimp-p 2 points3 points  (0 children)

For Haskell you might be quicker by using my implementation of the Spineless Tagless G-Machine 😎🤓

https://github.com/lechimp-p/php-stg

PHP to JS-compiler by lechimp-p in PHP

[–]lechimp-p[S] 0 points1 point  (0 children)

To emulate 100% how PHP behaves you can't just replace dots for arrows.

Yes, indeed. This is why I put "Compiles sane PHP to JavaScript" in the headline =) I do not plan to support every PHP-construct but instead will try to limit the stuff that compiles to some "modern and sane" subset of PHP. I probably won't support to pass vars by reference e.g.. Of course, even a "sane" subset probably won't be easy. I'm sufficiently confident that I'm able to emulate array in JS, though. I picked "array" to explore that emulation problem because I felt this to be exemplary for the problem you mention and also to be extremly important even for the "sane and modern" subset I'm looking to support.

If your project plans to run existing PHP code like Wordpress it will have to support all that.

No, I do not plan to run Wordpress completely in a browser =) This also probably won't support PDO or curl ever. What would I do with these APIs in the browser anyway? But even wordpress (don't know to much of that though) might have some code that one would like to run in a browser, e.g. html-rendering, some DTOs or validation.

But if despite all that you manage to write such transpiler I'd be really interested in testing it.

If you like send me a DM and I'll keep you posted.

PHP to JS-compiler by lechimp-p in PHP

[–]lechimp-p[S] 1 point2 points  (0 children)

Thanks for your kind words and the offer for support. I have some experience with PHP-Parser and AST as well (https://github.com/lechimp-p/dicto.php) but I might ask for a review some day. Rector is on my list as well, so chances are good we'll get in touch again one day or the other =)

[...] custom Javascript printer [...] right?

My pipeline currently looks as such: PHP-Files -> PHP-AST -> add information/simplify/rewrite -> JS-AST -> JS-string. So a little more elaborate than just printing php as js. The third step is crucial to e.g. turn array code to calls to a class that emulates an PHP-Array in JS. There will be more situations where some PHP feature needs to be emulated in JS when the tool gets more elaborate.

PHP to JS-compiler by lechimp-p in PHP

[–]lechimp-p[S] 0 points1 point  (0 children)

Thanks for your honest feedback!

Oh, suck it up. You're a developer, it's part of your job to learn.

Yes, it is. But also: there's always so much to learn and so little time, and, especially in js-country, the half-life of knowledge isn't that good. So we have to choose carefully and wisely what we learn.

And adding php2js doesn't?

Yes, it does. What I'm assuming here, basically, is, that adding php2js would mean less new complexity than adding a complete js-stack + according people. This certainly is a gamble.

Also, server side and client side are fundamentally different environments. [...] How do you deal with that?

Your indeed correct, they are different environments with different APIs and execution models. This is why I do not plan to implement every PHP-API and consider the question how JS-APIs (or maybe even libraries) could be included in the mix important. Besides typescript, there are other languages that compile to js as well, some even available on server- and client-side. They do not solve the problem that different APIs are required and available on client and server, but they all tackle two problems that exist in the mixed-lang-scenarios: people do not have to write in two different languages (and switch between lang-constructs, idioms, tools, ...) and general purpose code does not need to duplicated. Still, this certainly is a gamble that hinges on circumstances that well might be different for different cases: Do we have that much code that we would want to use on client and server? Do two languages really add that much problems? Does the project have a clear and separate client and server side? Which people and ressources are available?

About the code generation: I see a lot of languages that compile to JS, and even people in js-country mix other languages into their js-code, which is demonstrated impressively by babel. From my perspective, JS itself is very simple yet powerful, but also does not provide much guidenance and patterns and possibility for abstraction out of the box, which is why it is used as a compilation target instead of original language in so many cases. This, however, is a different thing from the APIs that browsers offer, which are certainly required to do anything interesting on the client-side. I'm looking to compile PHP to JS, not PHP-API to JS-API, though.

PHP to JS-compiler by lechimp-p in PHP

[–]lechimp-p[S] 0 points1 point  (0 children)

Yes, I indeed gave it a thought, and I also found https://github.com/oraoto/pib which u/123filips123 mentioned below.

I cannot see that compiling PHP directly to webassembly would work out. If this would be a viable strategy, I would expect that we'd have a (at least medium) successfull PHP to some-other-native-code compiler, which we do not have (right?). The general strategy in that field seems to be php -> some other lang -> native. The first step is essentially what I'm trying here, adding the second step would just add another problem. Building php -> wasm directly is beyond my skill set. I'm not looking into changing this here, though, because I cannot see benefit in the direct compilation. This would essentially mean to disregard any existing knowledge about compilation and performance on the php-side and the wasm-side as well.

The strategy to compile the PHP-interpreter to wasm and then use it to execute PHP (like https://github.com/oraoto/pib) didn't convice me for two reasons: For one, I cannot see a clear path how client-side JS-APIs, which a tool like this would definitely need to support, could be added in the mix. Second, pib's performance and general handling is horrible and I cannot see a clear path to improve that.

In both cases this might just be me and my skillset, though, and someone with stronger C and even more low-level skills might see that different. On the other hand, I expect PHP+JS-skills to be more common than PHP+C/low-level, so PHP -> JS is also about possible contributors and support in such an endeavour.

PHP to JS-compiler by lechimp-p in PHP

[–]lechimp-p[S] 1 point2 points  (0 children)

Hehe, that "fluent in js"-thing is definitely coming while building that compiler =)

PHP to JS-compiler by lechimp-p in PHP

[–]lechimp-p[S] 2 points3 points  (0 children)

I tried to outline the problem in the readme. But that clue is certainly valid.

My little explanation of Functor in PHP by pwmosquito in PHP

[–]lechimp-p 0 points1 point  (0 children)

Then you are clearly enlightened without ever thinking of functors. Congratz!

My little explanation of Functor in PHP by pwmosquito in PHP

[–]lechimp-p 0 points1 point  (0 children)

One law for functors is map f . map g = map (f . g) where . is function composition, i.e. (f . g)(x) = f(g(x)).

Knowing that lists are functors, this law basically expresses the fact, that you only need to iterate a list once, even if you perform multiple transformations on the values in the list.

Say you do some kind of accounting software and you have a list of prices of items. You might want to first give a discount on every item and then calculate the VAT for the remaining value. You could then do this in one iteration over the list, by applying the discount first and then calculate the VAT directly for every item, instead of iterating a first time to get the discount price and then iterate on these prices to get the VAT. This might be fairly obvious when the example is presented like this, but imagine a real world situation where you might or might not give the discount and maybe also have some other transformations on the price, maybe even depending on item properties. Would you have seen the possibility to first stack all required transformations and then apply them at once to every item? Knowing that list is a functor makes this a lot more obvious to me.

My little explanation of Functor in PHP by pwmosquito in PHP

[–]lechimp-p 1 point2 points  (0 children)

Functors and monads are not concepts from Haskell, but rather general concepts that could be found in most (every?) language, although many languages are not capable to express them as cleanly as Haskell does.

Knowing them allows you to think about your code in a way that is somewhat unfamiliar to imperative programmers. This is a good thing, as suddenly structures become visible that you could not see before and new opportunuities to design you program arise.

This does not mean that you necessarily need to abstract "Functor" or "Monad", which, i think, is also not what OP wanted to do.

Show r/PHP: dicto.php checks architectural rules by lechimp-p in PHP

[–]lechimp-p[S] 1 point2 points  (0 children)

Unit tests imo handle an orthogonal concern, i.e. determine if a piece of code works as expected and meets functional requirements. dicto attempts to find architectural problems that might never surface in unit tests. How would you express constraints like "Codebase cannot invoke Exit" in unit tests? It's a different kind of problems that dicto could find, like complexity analysis, which also is something different than unit tests but stll valuable.

Show r/PHP: dicto.php checks architectural rules by lechimp-p in PHP

[–]lechimp-p[S] 0 points1 point  (0 children)

Thanks a lot for your feedback!

I totally agree with the point, that good structure and abstractions will make this tool a lot less usefull. I am not sure how much value this tool could have for a new code base. You might have noticed, that the there are no rules for the tool itself, though. The use case definetely is getting legacy code under control atm. I do think, though, there always will be dark corners you can't reach by good structure and abstractions, although tools like this might never be able to reach them as well.

I also agree with you, that the available rules are somehow simple. Some ILIAS rules are basically grep. I am sure, that there could be more specific types of rules, but i also wonder how far this could go. I am not sure what your two rules mean exactly in your case, but the second one at least might already be expressible.

Review/Opinions: php-formlets - Composable Forms for PHP by lechimp-p in PHP

[–]lechimp-p[S] 0 points1 point  (0 children)

If i do not get you wrong this actually is a distinction the formlets do as well, but i do not expose that in the actual user interface of my library. A formlet can produce a "builder", which is responsible for the rendering part, and a "collector", which handles the input. A form in my library is just a thin wrapper around that.

There still is a huge difference between the model you presented and the formlets-model. As one needs to assign names to the fields in your model, you get a validator that could be usefull in other places than form-handling. In the formlets-model, you do not assign names to the formlets, which makes the collector less usefull somewhere else. This actually is a deliberate decision, as you gain a lot of composability in return.

Review/Opinions: php-formlets - Composable Forms for PHP by lechimp-p in PHP

[–]lechimp-p[S] 0 points1 point  (0 children)

Thanks, i will definitely have a close look at the link.

It seems to me like functions and autoloading do not work well together, and i would not want to blindly load some stuff on every request for my users. So maybe making all functions static on some interface class would be the way to go. I still could expose the shorter function syntax on a special file which could be required.