High-level views on low-level representations Export

@inproceedings{citeulike:333539, abstract = {This paper explains how the high-level treatment of datatypes in functional languages---using features like constructor functions and pattern matching---can be made to coexist with bitdata. We use this term to describe the bit-level representations of data that are required in the construction of many different applications, including operating systems, device drivers, and assemblers. We explain our approach as a combination of two language extensions, each of which could potentially be adapted to any modern functional language. The first adds simple and elegant constructs for manipulating raw bitfield values, while the second provides a view-like mechanism for defining distinct new bitdata types with fine-control over the underlying representation. Our design leverages polymorphic type inference, as well as techniques for improvement of qualified types, to track both the type and the width of bitdata structures. We have implemented our extensions in a small functional language interpreter, and used it to show that our approach can handle a wide range of practical bitdata types.}, address = {New York, NY, USA}, author = {Diatchki, Iavor S. and Jones, Mark P. and Leslie, Rebekah}, booktitle = {ICFP '05: Proceedings of the tenth ACM SIGPLAN international conference on Functional programming}, citeulike-article-id = {333539}, citeulike-linkout-0 = {http://portal.acm.org/citation.cfm?id=1086365.1086387}, citeulike-linkout-1 = {http://dx.doi.org/10.1145/1086365.1086387}, comment = {=== Top-3 contributions of the paper: === * Provide "bit representation" in Functional Languages: typed encoding of binary data, with concatenation and pattern-matching * Provide "bitdata": translates binary representations into almost-algebraic data-types * All these things come without loosing type inference! === Most glaring problems: === * "Junk" is badly dealt with, IMHO: in a Total functional programming mindset, I would rather ask "fromBit" to be called in a Maybe monad or something like that. I also understand there design choice, though. * The interaction with the Garbage Collector is not discussed. However, I suspect that the GC expects the data to be packed in a certain, uniform way. It's not the case here. For instance, how do we "mark" a 32 bits binary data on a 32 bits architecture? * The comparison/interaction with IDL's might deserve a longer discussion: especially, I would have loved to hear about the potential interactions between IDL and a pure functional language (basically, doesn't the IDL define the combinators of a (Driver) monad?) === What could be improved: === The future works mentioned at the end are interesting. I'll stay here, holding my breath until it's done. === What are the implications for the Research community: === Extremely general design that solves an important problem for the adoption of Functional Programming languages in low-level System design.}, doi = {10.1145/1086365.1086387}, isbn = {1595930647}, keywords = {data-structure, language-haskell, project-master-thesis, system-programming}, pages = {168--179}, posted-at = {2008-11-27 16:36:55}, priority = {0}, publisher = {ACM Press}, title = {High-level views on low-level representations}, url = {http://dx.doi.org/10.1145/1086365.1086387}, year = {2005} }

TY - CONF ID - citeulike:333539 L3 - citeulike-article-id:333539 N2 - This paper explains how the high-level treatment of datatypes in functional languages---using features like constructor functions and pattern matching---can be made to coexist with bitdata. We use this term to describe the bit-level representations of data that are required in the construction of many different applications, including operating systems, device drivers, and assemblers. We explain our approach as a combination of two language extensions, each of which could potentially be adapted to any modern functional language. The first adds simple and elegant constructs for manipulating raw bitfield values, while the second provides a view-like mechanism for defining distinct new bitdata types with fine-control over the underlying representation. Our design leverages polymorphic type inference, as well as techniques for improvement of qualified types, to track both the type and the width of bitdata structures. We have implemented our extensions in a small functional language interpreter, and used it to show that our approach can handle a wide range of practical bitdata types. SN - 1595930647 AD - New York, NY, USA EP - 179 TI - High-level views on low-level representations PB - ACM Press T2 - ICFP '05: Proceedings of the tenth ACM SIGPLAN international conference on Functional programming SP - 168 KW - data-structure KW - language-haskell KW - project-master-thesis KW - system-programming N1 - === Top-3 contributions of the paper: === * Provide "bit representation" in Functional Languages: typed encoding of binary data, with concatenation and pattern-matching * Provide "bitdata": translates binary representations into almost-algebraic data-types * All these things come without loosing type inference! === Most glaring problems: === * "Junk" is badly dealt with, IMHO: in a Total functional programming mindset, I would rather ask "fromBit" to be called in a Maybe monad or something like that. I also understand there design choice, though. * The interaction with the Garbage Collector is not discussed. However, I suspect that the GC expects the data to be packed in a certain, uniform way. It's not the case here. For instance, how do we "mark" a 32 bits binary data on a 32 bits architecture? * The comparison/interaction with IDL's might deserve a longer discussion: especially, I would have loved to hear about the potential interactions between IDL and a pure functional language (basically, doesn't the IDL define the combinators of a (Driver) monad?) === What could be improved: === The future works mentioned at the end are interesting. I'll stay here, holding my breath until it's done. === What are the implications for the Research community: === Extremely general design that solves an important problem for the adoption of Functional Programming languages in low-level System design. AU - Diatchki, Iavor AU - Jones, Mark AU - Leslie, Rebekah PY - 2005/// UR - http://dx.doi.org/10.1145/1086365.1086387 ER -