A meta-circular language for active libraries

Servetto, Marco; Zucca, Elena

doi:10.1016/j.scico.2014.05.003

Cited by 4 publications

(10 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We extend [9] by allowing methods to be annotated with pre/post-conditions. In addition to requiring that all the traits are well-typed before they are used (as in [9]) we also require that traits are correct in terms of their method contracts. Traits directly written in the source code are statically verified, while traits resulting from metaprogramming are ensured correct by only providing trait operations that preserve correctness.…”

Section: Combining Metaprogramming and Static Verificationmentioning

confidence: 99%

“…A leaked exception during compile-time metaprogramming would become a compile-time error. Our approach is very similar to [9] and does not guarantee the success of the code generation process, rather it guarantees that if it succeeds, correct code is generated.…”

Section: Concrete Examplementioning

confidence: 99%

“…Rename and hide adapt a single trait by renaming a method or by making a method private. Many works in the literature allow adapting traits by renaming or hiding methods [9,7,3]. Hiding a method may also trigger inlining if the method body is simple enough or used only once.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Iteratively Composing Statically Verified Traits

Gariano¹,

Servetto²,

Potanin³

et al. 2019

Electron. Proc. Theor. Comput. Sci.

Self Cite

View full text Add to dashboard Cite

Static verification relying on an automated theorem prover can be very slow and brittle: since static verification is undecidable, correct code may not pass a particular static verifier. In this work we use metaprogramming to generate code that is correct by construction. A theorem prover is used only to verify initial "traits": units of code that can be used to compose bigger programs.In our work, meta-programming is done by trait composition, which starting from correct code, is guaranteed to produce correct code. We do this by extending conventional traits with pre-and postconditions for the methods; we also extend the traditional trait composition (+) operator to check the compatibility of contracts. In this way, there is no need to re-verify the produced code.We show how our approach can be applied to the standard "power" function example, where metaprogramming generates optimised, and correct, versions when the exponent is known in advance.

show abstract

Section: Combining Metaprogramming and Static Verificationmentioning

confidence: 99%

Section: Concrete Examplementioning

confidence: 99%

See 1 more Smart Citation

Iteratively Composing Statically Verified Traits

Gariano¹,

Servetto²,

Potanin³

et al. 2019

Electron. Proc. Theor. Comput. Sci.

Self Cite

View full text Add to dashboard Cite

show abstract

“…Such "synthesized" packages can be used for code reuse without inducing subtyping. DeepFJig(DJ) [16,27,37] is a module composition language where nested classes with the same name are recursively composed. This paper shows a simple language design, called 42 µ , addressing the this-leaking problem and decoupling subtyping from inheritance.…”

Section: Introductionmentioning

confidence: 99%

“…In appendix A, we then provide a compact formalization. The hard technical aspects of the semantics have been studied in previous work [2,3,6,7,8,16,26,27,37]; the design of 42 µ synthesizes some of those concepts. The design ideas have been implemented in the full 42 language, which supports all the examples we show in the paper, and is available at: http://l42.is.…”

Section: Introductionmentioning

confidence: 99%

Separating Use and Reuse to Improve Both

2019

Self Cite

View full text Add to dashboard Cite

Context: Trait composition has inspired new research in the area of code reuse for object oriented (OO) languages. One of the main advantages of this kind of composition is that it makes possible to separate subtyping from subclassing; which is good for code-reuse, design and reasoning [15]. However, handling of state within traits is difficult, verbose or inelegant.Inquiry: We identify the this-leaking problem as the fundamental limitation that prevents the separation of subtyping from subclassing in conventional OO languages. We explain that the concept of trait composition addresses this problem, by distinguishing code designed for use (as a type) from code designed for reuse (i.e. inherited). We are aware of at least 3 concrete independently designed research languages following this methodology: TraitRecordJ [6], Package Templates [26] and DeepFJig [16].Approach: In this paper, we design 42 µ , a new language, where we improve use and reuse and support the This type and family polymorphism by distinguishing code designed for use from code designed for reuse. In this way 42 µ synthesise the 3 approaches above, and improves them with abstract state operations: a new elegant way to handle state composition in trait based languages.Knowledge and Grounding: Using case studies, we show that 42 µ 's model of traits with abstract state operations is more usable and compact than prior work. We formalise our work and prove that type errors cannot arise from composing well typed code.Importance: This work is the logical core of the programming language 42. This shows that the ideas presented in this paper can be applicable to a full general purpose language. This form of composition is very flexible and could be used in many new languages. ACM CCS 2012Theory of computation → Formalism; Software and its engineering → Object oriented languages; Designing software; Formal language definitions; 1 IA={interface method int ma()} //interface with abstract method 2 Utils={static method int m(IA a){return ...} } 3 ta={implements IA //This line is the core of the solution 4 method int ma(){return Utils.m(this);}} 5 A=Use taThis code works: Utils relies on interface IA and the trait ta implements IA. Any class reusing ta will contain the code of ta, including the implements IA subtyping declaration; thus any class reusing ta will be a subtype of IA. Therefore, while typechecking Utils.m(this) we can assume this<:IA. It is also possible to add a class B as follows: 12:5Separating Use and Reuse to Improve Both 1 B=Use ta, { method int mb(){return this.ma();} } This also works. B reuses the code of ta, but has no knowledge of A. Since B reuses ta, and ta implements IA, B also implements IA.Later, in appendix A we will provide the type system. Here notice that the former declaration of B is correct even if no method called ma is explicitly declared. DJ and TR would instead require explicitly declaring an abstract ma method: 1 B=Use ta, { method int ma() //not required by us 2 method int mb(){return this.ma();} } In 42 µ , methods are...

show abstract