Matthias Zenger and Martin Odersky. Extensible algebraic datatypes with defaults. In Proc. 6th ACM SIGPLAN International Conference on Functional Programming (ICFP), Firenze, Italy, September 2001.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....and methods to an AST node and its subclasses; we require that this uniform mixin extension be implementable without subclassing all the extended node classes. Scalable extensibility is a challenge because it is difficult to simultaneously extend both types and the procedures that manipulate them [30, 38]. Existing programming methodologies such as visitors [13] improve extensibility but are not a complete solution. In this paper we present a methodology that supports extension of both compiler passes and AST nodes, including mixin extension. The methodology uses abstract factories, delegation, ....

....extensible compilers, macro systems, and visitor patterns. JaCo is an extensible compiler for Java written in an extended version of Java [39] that supports ML style pattern matching. JaCo does not provide mixin extensibility. It relies on a new language feature extensible algebraic datatypes [38] to address the difficulty of handling new data types without changing existing code. Polyglot achieves scalable extensibility while relying only on features available in Java. CoSy [1] is a framework for combining compiler phases to create an optimizing compiler. Compiler phases can be added ....

Matthias Zenger and Martin Odersky. Extensible algebraic datatypes with defaults. In Proc. 6th ACM SIGPLAN International Conference on Functional Programming (ICFP), Firenze, Italy, September 2001.

....is an extended version of the paper of the same name in the 2002 International Conference on Functional Programming, Pittsburgh, PA, October 4 6, 2002. 1 Introduction Many researchers have noted a difference in the extensibility benefits offered by the functional and object oriented (OO) styles [26, 8, 23, 10, 18, 14, 28]. Functional languages like ML allow new operations to be easily added to existing datatypes (by adding new fun declarations) without requiring access to existing code. However, new data variants cannot be added without a potentially whole program modification (since existing functions must be ....

....are known, rather than once on the functor body. However, it is possible that most of ITC could still be performed on the functor body in isolation, with only a few additional checks performed per instantiation. 6 Related Work OML [25] and ML# [3] were described earlier. Zenger and Odersky [28] describe an extensible datatype mechanism in the context of an OO language. Extending a datatype has the effect of creating a new datatype that subtypes from the original one. To ensure exhaustiveness in the presence of datatype extension, all functions on extensible datatypes must include a ....

M. Zenger and M. Odersky. Extensible algebraic datatypes with defaults. In Proceedings of the 2001.

....of existing source code, promoting a smooth software evolution process. The overall design of the module system was guided by the aim to develop a pragmatic, implementable, and conservative extension of Java [6] We are currently implementing a compiler based on the extensible Java compiler JaCo [19, 20]. JaCo itself is designed to support unanticipated extensions without the need for source code modifications. JaCo is currently written in a slightly extended Java dialect making use of an architectural design pattern that allows refinements in a similar way. We hope to be able to re implement ....

M. Zenger and M. Odersky. Extensible algebraic datatypes with defaults. In Proceedings of the International Conference on Functional Programming, Firenze, Italy, September 2001.

....one cannot be implemented in a straightforward way. For functional programming languages, various proposals were made to support extensibility of algebraic datatypes. Among them, the most prominent ones are Garrigue s polymorphic variants [14] and the extensible types of the ML2000 proposal [1] [31] compares both approaches with our work. Several papers discuss the extensibility of algebraic types in the context of building extensible interpreters in functional languages [19, 10, 8] Due to lack of space we refer to [17] for a short discussion. The literature also provides several ....

....if all new variants are properly treated by the existing default behaviour. The experience with our extensible Java compiler showed that for extended compilers, the majority of the existing operations can be reused as is for extended types, without the need for adapting them to new variants [31]. If it would be possible to specify a default case for every function operating on an extensible type, a function would have to be adapted only in those situations, where new variants require a specific treatment. This technique would improve as is code reuse significantly. We present a ....

[Article contains additional citation context not shown here]

M. Zenger and M. Odersky. Extensible algebraic datatypes with defaults. In Proc. International Conference on Functional Programming (ICFP 2001), Firenze, Italy, September 2001.

No context found.

Matthias Zenger and Martin Odersky. Extensible algebraic datatypes with defaults. In Proc. 6th ACM SIGPLAN International Conference on Functional Programming (ICFP), Firenze, Italy, September 2001.

No context found.

Matthias Zenger and Martin Odersky. Extensible algebraic datatypes with defaults. In Proceedings of ICFP '01, SIGPLAN Notices 36(10), pages 241 -- 252, 2001.

No context found.

Matthias Zenger and Martin Odersky. Extensible algebraic datatypes with defaults. In Proc. International Conference on Functional Programming. ACM Press, Florence, Italy, September 2001.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC