Talk:Algebraic data types: Difference between revisions
no edit summary
(I don't get it.) |
No edit summary |
||
Line 27:
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)
:I am uncertain, myself about this task. Here's what I believe I know:
::"algebraic data type" means that data types are represented by numbers which list the number of possible values that can be represented by that data type. A bit data type would be represented by the number 2. An 8 bit character would be represented by the number 256. A 32 bit integer would be represented by the number 4294967296. An type that represents the program being in an error state would be represented by the number 0. This system allows you to use algebra to work with the properties of composite and derived types.
::Implicitly, languages which support types often have syntax rules to prevent certain combinations of types from being used. Typically, these syntax rules get associated with defined words which represent functions, and these syntax rules approximate the domain of those functions. (In some cases you get an exact match , but this cannot be guaranteed without solving the halting problem.) This, I think, is what encourages a proliferation of types.
::I think that the task is encouraging the use of a type system which distinguishes between "red" and "black" nodes by using different types for them. I think that the implicit desire, here, is to use types which are represented syntactically (in code paths). (But to explicitly require specific syntax would conflict with what rosetta code tasks are.)
::I believe that there are also some other implicit statements here, which I would have to have a different background to appreciate.
:That said, I think the task is also incomplete (it includes no explicit feature tests). --[[User:Rdm|Rdm]] 15:14, 2 March 2012 (UTC)
| |||