Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Actually, they're fundamentally quite different! At least in Haskell, at any rate.</p> <p>Guards are both simpler and more flexible: They're essentially just special syntax that translates to a series of if/then expressions. You can put arbitrary boolean expressions in the guards, but they don't do anything you couldn't do with a regular <code>if</code>.</p> <p>Pattern matches do several additional things: They're the <strong>only way to deconstruct data</strong>, and they <strong>bind identifiers within their scope</strong>. In the same sense that guards are equivalent to <code>if</code> expressions, pattern matching is equivalent to <code>case</code> expressions. Declarations (either at the top level, or in something like a <code>let</code> expression) are also a form of pattern match, with "normal" definitions being matches with the trivial pattern, a single identifier.</p> <p>Pattern matches also tend to be the main way stuff actually happens in Haskell--attempting to deconstruct data in a pattern is one of the few things that forces evaluation.</p> <p>By the way, you can actually do pattern matching in top-level declarations:</p> <pre><code>square = (^2) (one:four:nine:_) = map square [1..] </code></pre> <p>This is occasionally useful for a group of related definitions.</p> <p>GHC also <a href="http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#view-patterns" rel="noreferrer">provides the ViewPatterns extension</a> which sort of combines both; you can use arbitrary functions in a binding context and then pattern match on the result. This is still just syntactic sugar for the usual stuff, of course.</p> <hr> <p>As for the day-to-day issue of which to use where, here's some rough guides:</p> <ul> <li><p>Definitely use pattern matching for anything that can be matched directly one or two constructors deep, where you don't really care about the compound data as a whole, but do care about most of the structure. The <code>@</code> syntax lets you bind the overall structure to a variable while also pattern matching on it, but doing too much of that in one pattern can get ugly and unreadable quickly.</p></li> <li><p>Definitely use guards when you need to make a choice based on some property that doesn't correspond neatly to a pattern, e.g. comparing two <code>Int</code> values to see which is larger.</p></li> <li><p>If you need only a couple pieces of data from deep inside a large structure, particularly if you also need to use the structure as a whole, guards and accessor functions are usually more readable than some monstrous pattern full of <code>@</code> and <code>_</code>.</p></li> <li><p>If you need to do the same thing for values represented by different patterns, but with a convenient predicate to classify them, using a single generic pattern with a guard is usually more readable. Note that if a set of guards is non-exhaustive, anything that fails all the guards will drop down to the next pattern (if any). So you can combine a general pattern with some filter to catch exceptional cases, then do pattern matching on everything else to get details you care about.</p></li> <li><p>Definitely don't use guards for things that could be trivially checked with a pattern. Checking for empty lists is the classic example, use a pattern match for that.</p></li> <li><p>In general, when in doubt, just stick with pattern matching by default, it's usually nicer. If a pattern starts getting really ugly or convoluted, then stop to consider how else you could write it. Besides using guards, other options include extracting subexpressions as separate functions or putting <code>case</code> expressions inside the function body in order to push some of the pattern matching down onto them and out of the main definition.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POWhat is the difference between Pattern Matching and Guards?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USC. A. McCann
    1. USC. A. McCann
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat is the difference between Pattern Matching and Guards?
      singulars
      1. PTQuestion
    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. CODon't forget about their baby, pattern guards!
      singulars
      1. PO
      1. USluqui
    2. CO@luqui: Ah, yes! An embarrassing oversight on my part; thank you for the reminder.
      singulars
      1. PO
      1. USC. A. McCann
 

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