Which Haskell features prevent guaranteed loop detection?


Which Haskell features prevent guaranteed loop detection?

In my experience, when I finally run some code I've been developing for a while, all that's left are obvious (in hindsight) errors in logic, and infinite loops. The former is an easy fix, but the latter can often take quite a while, particularly if it happens inside some sort of bracket operation.

How many of Haskell's features would need to be disabled in order to have some form of LoopSafe Haskell? Are we talking most of it, or primarily obscure features that often aren't need, or somewhere in between?

Submitted June 16, 2017 at 11:04PM by runeks
via reddit http://ift.tt/2sj9Gt4

Advertisements

Zero-cost abstractions


Zero-cost abstractions

A zero-cost abstraction can be evaluated at compile-time to reduce run-time-overhead.

In Haskell we're lucky and all our run-time-dependencies are reflected in our types via the IO-monad. In return, we can identify all run-time-independent fragments of code just by observing whether an expression depends on IO. Intuitively, this suggests some potential for compile-time-optimizations: We could, for instance, transform every run-time-independent expression to weak-head-normal-form before byte-code-generation. In theory (or at least in my mind), this strategy applies all "safe" zero-cost abstractions at compile-time, and only generates code for run-time-sensitive abstractions. With "safe" i mean, that the application does not alter run-time-behavior. The strategy is not complete in the sense that some zero-cost abstractions might be overseen, because some code-fragments depend on IO, but don't branch on possible inputs. Another issue is, that the trade-off (reduced run-time for increased compile-time) might introduce non-termination in the compilation-step.

I have several questions:

  1. Is my argument sound or are there any mistakes or wrong assumptions?
  2. Did i oversee a crucial disadvantage?
  3. Does GHC or any other Haskell-compiler apply this optimization?
  4. Is there a technical term or a keyword for the described strategy?
  5. Can you recommend any literature concerning this topic?

Submitted June 16, 2017 at 11:06PM by 1UnitedPower
via reddit http://ift.tt/2ryHrtD

cleaning user input for safe eval of math


cleaning user input for safe eval of math

function normalizeExpression(code: string) { if (code === "") return ""; code = code.toLowerCase(); code = code.replace(/[[{]/gm, "("); // convert all {[ to ( code = code.replace(/[\]}]/gm, ")"); // convert all {[ to ( code = code.replace(/\)\(/gm, ")*("); // (x+a)(x-2) => (x+a)*(x-2) code = code.replace(/[^a-z0-9(),.*/+^-]/gm, ""); code = code.replace(/(a?sin|a?cos|a?tan|log|ln|exp)/gm, (m,a) => a.toUpperCase() ); // duplicate lines below 1. xxxx => x*xx*x 2. x*xx*x => x*x*x*x code = code.replace(/([a-z0-9])\(/gm, (m, a, b) => a + "*(" ); code = code.replace(/([0-9])([a-z])/gm, (m, a, b) => a + "*" + b ); code = code.replace(/([a-z])([a-z])/gm, (m, a, b) => a + "*" + b); code = code.replace(/([a-z])([a-z])/gm, (m, a, b) => a + "*" + b); return code.toLowerCase(); } 

My users will enter math like "2x+4x+sin(3x)"

Assuming code executed by eval after cleanup – does this seem safe ?

Submitted June 16, 2017 at 10:54PM by total_refund
via reddit http://ift.tt/2rzBkoH