Anonymous user
Talk:Algebraic data types: Difference between revisions
no edit summary
mNo edit summary |
No edit summary |
||
Line 39:
:That said, I think the task is also incomplete (it includes no explicit feature tests). It's also going to be highly inefficient, in J, because of the low fan-out on each node. So don't worry about efficiency or usefulness if you implement this in J. --[[User:Rdm|Rdm]] 15:14, 2 March 2012 (UTC)
:: The "algebraic" part is not about underlying representation. It's because the data type itself forms a free algebra. "Algebra" here means a set with some operations (effectively the data type's constructors) on it. A "free" algebra is one where the only way two terms can represent the same element is by being the same term. On the programming side, two things are only the same if they're made by calling the same constructor with the same arguments. A simple example of a free algebra is Peano-encoded natural numbers: Z ("zero") is a 0-ary constructor, and S ("successor") is a unary constructor. Z, S(Z), S(S(Z)), etc. are all different things. If we introduce a P ("plus") constructor, it's no longer free because, e.g., P(Z, S(Z)) = P(S(Z), Z). Pattern matching is the usual way to consume this kind of data type. Pattern matching is a form of conditional where each case in a match expression specifies what the constructor must be and then gives names to the constructor's arguments. J doesn't really have built-in support for ADTs or pattern matching (this is possibly an argument in favor of splitting this page's task as suggested above -- keep the J implementation of red-black tree up, but it probably doesn't belong on a page about destructing an ADT by pattern matching). [[User:Jrslepak|Jrslepak]] ([[User talk:Jrslepak|talk]]) 16:20, 9 September 2014 (UTC)
:J stores symbols in a red black tree. Maybe we need only show symbol code. Ha ha. An implementation detail, not a language feature. --LambertDW 16:31, 10 March 2012 (UTC)
| |||