标签：#purescript

When you combine the absolute safety and elegance of a purely functional language with the raw execution speed of a modern low-level language, it's like discovering that space and time are inextricably linked: a whole new dimension opens up to you. In my previous article , I introduced phpurs , a compiler backend that brings the absolute mathematical safety of PureScript to the 70% of the web that still runs on PHP. The goal was to prove that we do not have to sacrifice modern safety and ergonomics just because we target a runtime that is, at first glance, not the most natural. Today, we are looking at the exact opposite end of the spectrum. If PHP was about ultimate portability and legacy compatibility, what happens when we want pure, raw metal speed ? What happens when we want true multi-core concurrency, static native binaries, and a garbage collector designed for extreme high-throughput? Say hello to one of my recent projects: gopurs , a super-optimized PureScript-to-Go compiler. And let me spoil the end of the story right away: by combining the high-level semantic purity of PureScript with the raw execution force of modern Go, the final compiled code matches Chez Scheme speed on pure computational benchmarks. Yes, Chez Scheme, one of the absolute historical champions of functional AOT compilation (i.e., decades of compiler optimizations). This will be a shorter article in the series, but here is a quick version of the story... Breaking the AOT ceiling: how TAST changed everything Historically, compiling highly polymorphic functional languages (like PureScript or Haskell) to statically typed languages like Go has often been a nightmare. Older attempts often relied on mapping everything to Go's interface{} (or any ). It works, but it's a performance sacrifice. Every primitive value you assign to an interface{} is boxed and escapes to the heap , generating massive pressure on Go's Garbage Collector. To solve this, gopurs initially used a flat Value struct (a tagge

I've watched too many TradingView strategies look great in the Strategy Tester and then fall apart the moment real money went live. Almost every time, the code compiled fine. The bug wasn't syntax. It was repainting, the script quietly using information it shouldn't have had yet. Repainting doesn't throw an error. It just quietly makes your backtest better than your live trading will ever be. Here are the four places it actually comes from, and how to catch each one before you trust a strategy. 1. request.security() with the wrong lookahead If you pull a higher-timeframe value with request.security() and don't handle the offset correctly, the current, still-forming HTF bar can leak into your calculation. The fix is barmerge.lookahead_off combined with offsetting the source by one bar, e.g. close[1]. lookahead_on is only safe when you've already offset the source yourself. Using it directly on a live value is the single most common repaint source in Pine scripts posted online. 2. Signals computed before the bar closes If your entry logic runs on close or ta.crossover() without a barstate.isconfirmed guard, the signal can appear, then disappear, then reappear as the candle's still-forming close price changes. What you saw fire in real time is not always what the finished bar actually did. Guard any entry/exit logic that matters with barstate.isconfirmed if you're evaluating it intrabar. 3. Same-bar stop/target ambiguity When your stop and your target could both have been hit inside the same bar's high-low range, the Strategy Tester has to guess which one happened first. It doesn't always tell you which assumption it made, and that one hidden assumption can flatter your win rate without you ever seeing it happen. 4. Bar Replay is the real manual test TradingView's Bar Replay tool is the closest thing to a repaint detector you already have. Step through history bar by bar and watch whether a signal that appeared in the past matches what you originally saw. If a signal m

It is time to bring opposites together, to stir up these stagnant waters, and to restore an industry that is dynamic from within, with multiple connections that were previously impossible or unimaginable. In the previous parts of this series, we explored how PureScript acts as a quiet rewrite of the Web , offering a territory of mathematical precision above JavaScript, and how its universal polymorphism allows it to target wildly different runtimes like Node.js, Erlang's BEAM, Chez Scheme, etc. But hey, what about the elephant in the room? Yes, what is running the majority of the web, today, in the shadow? You know. The eternal one, the big one, the one whose death everyone talks about, but who never truly dies. PHP. While the modern JavaScript ecosystem (among others) races toward edge computing and containerized microservices, around 70% of the web is still powered by PHP . From legacy WordPress sites to affordable shared hosting (cPanel, OVH, GoDaddy, basic LAMP stacks), a massive portion of the internet lives in environments where escaping the PHP runtime is either financially unviable, technically impossible, or simply unnecessary. And yet... For a long time, the PHP ecosystem has been left without a true, strictly typed functional and safe alternative, like TypeScript for Javascript. Even though recent PHP versions introduced fantastic features (short closures, match expressions, Fibers), the frustration that comes with its historical limitations and dynamic typing remains very real for some of its users. Very well! This is why I built phpurs : a brand new compiler backend that transpiles PureScript directly to modern PHP 8.4+ syntax. It is no longer a proof of concept. It is passing the official PureScript test suite , and it is ready for production. Here is how we bring the elegance of purely functional programming to the big web, while keeping deployment as simple as a legacy FTP upload, or anything alike. The easy deployment paradox In modern DevOps, deplo