Talk:Algebraic data types: Difference between revisions

From Rosetta Code
Content added Content deleted
(I don't get it.)
Line 13: Line 13:


There's also unification - when a variable name appears multiple times in a pattern, it must stand in for the (fsvo) same data in all cases. But pattern-matching is most commonly used in conjunction with languages with Hindley-Milner type checkers and should be understood in terms of these implementations. foobie-bletch 18:02, 6 August 2009 (UTC)
There's also unification - when a variable name appears multiple times in a pattern, it must stand in for the (fsvo) same data in all cases. But pattern-matching is most commonly used in conjunction with languages with Hindley-Milner type checkers and should be understood in terms of these implementations. foobie-bletch 18:02, 6 August 2009 (UTC)
----
I don't understand the essence of the task.

<lang J>NB. comparisons of arbitrary data types in j
compare=: <:@:(-: + +:@:A.@:/:@:,:&:<)
assert _1 -: 0 compare 1 NB. less than
assert 0 -: compare~'abc' NB. equal
assert 1 -:'0'compare 0 NB. consistent order of
assert _1 -: 0 compare'0' NB. dissimilar data types
assert 1 -:'a'compare'@' NB. greater than
</lang>

If I were to implement red-black tree I'd hash to compare integers, and the result would be to provide associative array functionality. Does this prove algebraic data type? I suppose. Data can be recovered via j verbs.
--LambertDW 20:47, 27 February 2012 (UTC)

Revision as of 20:47, 27 February 2012

I would like to see this task split into two tasks:

  • a simple example of pattern matching, and
  • an implementation of a red-black tree.

There are a couple reasons I think this would be better:

  • When I came to this page I was just looking for simple examples of pattern matching. It takes a lot of effort to understand the red-black trees.
  • I want to add a couple pattern matching examples, but I don't want to work through an entire red-black tree implementation.
  • I would also like to see an example of a red-black tree written without pattern matching, for comparisons sake. If pattern matching really does make the code more concise, the current examples would shine with a few huge implementations sitting near by.--Spaceg 01:19, 8 August 2008 (UTC)

I like the task, but I don't think it's a good application of the general case of pattern matching. Pattern Matching should probably be geared towards globs and regular expressions, while this page should get moved to something like Red-Black Tree. Thoughts? --Short Circuit 22:19, 6 November 2007 (MST)

Actually, I think this is an ideal example of a key functional programming loanguage capability. Most functional programming pattern matching examples use very trivial patterns which could just as easily be implemented with an imperative switch statement. This example shows how pattern matching can simplify rather complex decision making. Regex stuff is rather primitive by comparison. There are only a handful of programming languages that are powerful enough to implement this example, so I don't expect this page to grow very large. --IanOsgood 08:01, 7 November 2007 (MST)
There are two mostly distinct basic concepts: pattern matching/destructuring of data structures (which this task is about) and regular-expression-style text matching. There can also be systems which combine features of both; for example, E allows regular expressions within data-structure patterns, and uses regular-expression-style quantification within term-tree patterns. --Kevin Reid 11:19, 7 November 2007 (MST)

How about some test data?

There's also unification - when a variable name appears multiple times in a pattern, it must stand in for the (fsvo) same data in all cases. But pattern-matching is most commonly used in conjunction with languages with Hindley-Milner type checkers and should be understood in terms of these implementations. foobie-bletch 18:02, 6 August 2009 (UTC)


I don't understand the essence of the task.

<lang J>NB. comparisons of arbitrary data types in j compare=: <:@:(-: + +:@:A.@:/:@:,:&:<) assert _1 -: 0 compare 1 NB. less than assert 0 -: compare~'abc' NB. equal assert 1 -:'0'compare 0 NB. consistent order of assert _1 -: 0 compare'0' NB. dissimilar data types assert 1 -:'a'compare'@' NB. greater than </lang>

If I were to implement red-black tree I'd hash to compare integers, and the result would be to provide associative array functionality. Does this prove algebraic data type? I suppose. Data can be recovered via j verbs. --LambertDW 20:47, 27 February 2012 (UTC)