Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would argue that trying to care about evaluation order is counter productive in Haskell. Not only is the language designed to make evaluation order irrelevant but the evaluation order can jump all over the place in strange and confusing ways. Additionally, the implementation has substantial freedom to execute things differently[1] or to vastly restructure your program[2] if the end result is still the same so different parts of the program might be evaluated in different ways.</p> <p>The only real restriction is what evaluation strategies you <em>can't</em> use. For example, you can't always use strict evaluation because that would cause valid programs to crash or enter infinite loops.</p> <pre><code>const 17 undefined take 10 (repeat 17) </code></pre> <p>That said, if you really care, one valid strategy you could possibly use to implement all of Haskell is lazy evaluation with thunks. Each value is represented in a box that either contains the value or a thunk subroutine that can be used to compute the value when you finally need to use it.</p> <p>So when you write </p> <pre><code>let xs = 1 : [] </code></pre> <p>You would be kind of doing this:</p> <pre class="lang-none prettyprint-override"><code>x --&gt; {thunk} </code></pre> <p>If you never inspect the contents of x then the thunk stays unevaluated. However, if you ever do some pattern matching on the thunk then you need to evaluate the thunk to see what branch you take:</p> <pre><code>case xs of [] -&gt; ... (y:ys) -&gt; ... </code></pre> <p>Now, x's thunk is evaluated and the resulting value is stored in the box in case you ever need it. This is to avoid needing to recompute the thunk. Note that in the following diagram I'm using <code>Cons</code> to stand for the <code>:</code> list constructor</p> <pre class="lang-none prettyprint-override"><code>x ---&gt; {Cons {thunk} {thunk}} ^ ^ | | y ys </code></pre> <p>Of course, just the presence of the pattern math isn't enough you need first be forced to evaluate that pattern match in the first place. Ultimately, this boils down to your main function needing to print a value or something like that.</p> <p>Another thing to point out is that we didn't immediately evaluate the contents of the Cons constructor when we first evaluate it. You can check this by running a program that doesn't use the contents of the list:</p> <pre><code>length [undefined, undefined] </code></pre> <p>Of course, when we actually use <code>y</code> for something then its corresponding thunk gets evaluated.</p> <p>Additionally, you can use bang patterns to mark constructor fields as strict so they get immediately evaluated when the constructor gets evaluated (I don't remember if you need to turn an extension for this though)</p> <pre><code>data LazyBox = LazyBox Int data StrictBox = StrictBox !Int case (LazyBox undefined) of (LazyBox _) -&gt; 17 -- Gives 17 case (StrictBox undefined) of (StrictBox _) -&gt; 17 -- *** Exception: Prelude.undefined </code></pre> <hr> <p>[1]: One important optimization that GHC does is using strict evaluation in the sections that the strictness analyzers determines to be strict.</p> <p>[2]: One of the most radical examples would be <a href="http://www.haskell.org/haskellwiki/Short_cut_fusion" rel="nofollow noreferrer">deforestation</a>.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat requirements does non-strict semantics of Haskell have on the evaluation strategy?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USrcode
    1. UShugomg
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COProblem is that the performance can't be easily predicted if the evaluation strategy is not known.
      singulars
      1. PO
      1. USspockwang
    2. CO@spockwang: If you really really want predictable performance then Haskell isn't the language for you. That said, its not that bad - lazy evaluation is more composable so you are less likely to find bad performance surprises as the codebase grows ([dons mentions that sometime during this video](http://www.haskellcast.com/episode/002-don-stewart-on-real-world-haskell/)). Anyway in terms of big-O, lazy evaluation usually doesn't make the runtime performance worst - the real issue is predicting space use and preventing space leaks.
      singulars
      1. PO
      1. UShugomg
    3. CO@spockwang Performance can't be easily predicted in imperative languages with fixed evaluation strategies either! People (even very experienced programmers) are notoriously bad at predicting where the real performance bottlenecks are in the code they write. Hence "premature optimization is the root of all evil" and "always benchmark and profile your code before you optimise".
      singulars
      1. PO
      1. USBen
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload