With Ethereum, BlockChain technology moves from being an implementation technology for virtual currency to being the basis
for developing a new kind of software with smart contracts. The goal of this project is to analyse and improve high-level development
and analysis tools for this new kind of software.
Users like banks and insurance companies need tools that model their processes and level of confidentiality of the information shared though
blockchain technology, especially on public blockchains.
For this, users need a solution that provides a higher level way to model systems than solidity code or even low-level byte-code. In addition,
blockchain based solutions often employ multiple programming languages. Especially the later poses a risk for later software maintenance.
This project can be done in collaboration of a company (utocat).
The goal of this project is to work on high level IDE / modelling tools for blockchain technology like Ethereum.
The plan is to
- Analyse the current state: tools and languages in the context of blockchain technologies.
- Analyse the current state: modelling tools and processes with a focus in decision processes both in communities and commercial use.
- Explore how to improve the state of the art, especially with a focus on providing tools for users of blockchain solutions in industry.
- Implement prototypes for IDEs/modelling tools for Ethereum, possibly using Pharo. Directions to explore will be both related to generating and analysing solidity code as well as complete solutions used in industrial projects.
- Results will be submitted to be publish in international conferences and journals.
- A possible path is also to understand if a language capturing smart contracts and workflow can be proposed to end-users with adequate tools.
Contact: marcus.denker@inria.fr and stephane.ducasse@inria.fr
Keywords: Object-Oriented Programming, Language Design, Multiple inheritance, Mixins, Traits, Dynamically Typed Languages.
Context:
We define traits [BSD03],[CDW07]. Traits are units of reuse that are essentially composed of methods. Traits can be applied to different classes orthogonally to inheritance. Traits can be composed of subtraits.
The composer of traits is responsible of handling conflict. Traits while initially developed in
Squeak (a Smalltalk implementation ancestor of Pharo, got ported to various languages such as Perl 6, Squeak [IKM+97], PhP, Slate. They influenced also Scala and Fortress of SUN Microsystems. Several extensions have been proposed [Qui04, BDNW07, DWBN07] as well as type systems [FR03, SD05, NDS06, LS07].
Subject:
Traits as originally defined do not include state and there is a competition between classes and traits.
A trait defines methods but cannot define state but a class can and a class can have instance while a trait cannot. In this design a trait acts as a kind of macros and it is static. It can only apply at compile-time.
This aspect was part of the idea that traits could be removed (or flattened) and that the classes with flattened traits would be equivalent to their counterpart without traits.
The goal of this work is to revisit traits. Can we get one dynamically typed
language with only traits: objects that can be composed, have states and methods
and can define instances. In addition can we have dynamic traits as in Talents? Pablo Tesone proposed an alternate implementation showing that talents can be proposed to mainstream developers.
A possible roadmap is the following
- Understanding how to use traits as in Pharo
- Looking at extensions or other models such as Eiffel inheritance, self prototypes or subObjects developed by Marko van Dooren, or Talents
- Propose one or two models
- Take a little Pharo image: such as candleLight (which contains only a little core) and implement different models.
- The implementation may also use reflectivity the reflective layer of Pharo to perform some advanced lookup or implementation tricks.
References
[Talents] Jorge Ressia, Tudor Gîrba, Oscar Nierstrasz, Fabrizio Perin, and Lukas Renggli. Talents: Dynamically Composable Units of Reuse. In Proceedings of International Workshop on Smalltalk Technologies (IWST 2011), p. 109—118, 2011. DOI PDF →
[BSD03] Andrew P. Black, Nathanael Schärli, and Stéphane Ducasse. Applying traits to the Smalltalk collection hierarchy. In Proceedings of 17th International Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA’03), volume 38, pages 47–64, October 2003.
[BDNW07] Alexandre Bergel, Stéphane Ducasse, Oscar Nierstrasz, and Roel Wuyts. Stateful traits. In Advances in Smalltalk — Proceedings of 14th International Smalltalk Conference (ISC 2006), volume 4406 of LNCS, pages 66–90. Springer, August 2007.
[DWBN07] Stéphane Ducasse, Roel Wuyts, Alexandre Bergel, and Oscar Nierstrasz. User-changeable visibility: Resolving unanticipated name clashes in traits. In Proceedings of 22nd International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA’07), pages 171–190, New York, NY, USA, October 2007. ACM Press.
[CDW07] Damien Cassou, Stéphane Ducasse, and Roel Wuyts. Redesigning with traits: the nile stream trait-based library. In Proceedings of the 2007 International Conference on Dynamic Languages (ICDL 2007), pages 50–79. ACM Digital Library, 2007.
[DNS+06] Stéphane Ducasse, Oscar Nierstrasz, Nathanael Schärli, Roel Wuyts, and Andrew Black. Traits: A mechanism for fine-grained reuse. ACM Transactions on Programming Languages and Systems (TOPLAS), 28(2):331–388, March 2006.
[FF98] Matthew Flatt and Matthias Felleisen. Units: Cool modules for hot languages. In Proceedings of PLDI ’98 Conference on Programming Language Design and Implementation, pages 236–248. ACM Press, 1998.
[for] The Fortress language specification.
[FR03] Kathleen Fisher and John Reppy. Statically typed traits. Technical Report TR-2003-13, University of Chicago, Department of Computer Science, December 2003.
[LS07] Luigi Liquori and Arnaud Spiwack. FeatherTrait: A modest extension of Featherweight Java. ACM Transactions on Programming Languages and Systems (TOPLAS), 2007.
[Qui04] Philip J. Quitslund. Java traits — improving opportunities for reuse. Technical Report CSE-04-005, OGI School of Science / Engineering, Beaverton, Oregon, USA, September 2004.
[Sla] Slate.
[sca] The scala programming language.
[SD05] Charles Smith and Sophia Drossopoulou. Chai: Typed traits in Java. In Proceedings ECOOP 2005, 2005.
Contact: stephane.ducasse@inria.fr
Pharo provides a very advanced debugging infrastructure. Over the last releases,
the Debugger model, the UI as well as the reflective foundations have seen
major improvements.
Based on these new foundations, new research can be carried out in a much simpler
way than before.
One example is the idea to enhance a debugging sessions optionally with aliasing
information. Research on this topic has been done in the past [1] but the resulting
system needs a modified Virtual Machine to run and showed problems with the amount of
memory used.
The goal of this internship is:
1) Realise the Alias execution infrastructure without the need to change the Virtual Machine
based on the new reflective foundation found in Pharo6.
2) Analyse the use of Memory. Evaluate the new 64bit virtual machine for allocating large
amounts of memory, evaluate possible other solutions (store on disk, send to other machine...)
3) Explore the new "moldable" Debugger UI for providing a user interface to the Alias data.
Here both interactive UIs as well as interactive queries are interesting directions to explore.
[1] Lienhard, Girba, Nierstrasz: Practical Object-Oriented Back-in-Time
Debugging, Proceeding ECOOP '08
Contact: stephane.ducasse@inria.fr
Keywords: Object-Oriented Programming, Language Design, Relationships, Dynamically Typed Languages.
Context:
Object-oriented methodologies promote the use of relationships. However, programming languages do not represent relationships and as such forced to use low level data structures such as dictionaries. Since Pharo 50, Pharo supports first class instance variables named Slots. The developer can define instance variables and associate to them compilation behavior. For example, active values are special instance variables with notification behavior. The programmer can then reuse logic encapsulated inside first class instance variables.
Subject:
The goal of this project is to do develop an extension to default the object-oriented model (class, method and fields). Such extension should offer a variety of first class relationships.
Here is a possible outline of work:
- The student will study Streamlined-Object-Modeling-Patterns-Implementation [SOMP] since it defines a list of patterns and relationships.
- The student will study how new slots can be defined.
- He will design a library of first class relationships.
- A validation on reimplementing part of the FAMIX metamodel will be proposed.
Pré-requis
- Willing to learn
- Pharo is a plus but not mandatory
References
Contact: stephane.ducasse@inria.fr
Keywords: Object-Oriented Programming, Language Design, Dynamically Typed Languages.
Context:
Shared and often global state is a simple and handy mechanism to share state between different objects. It is also a simple persistency mechanism: state hold by it will persist as long as the program is alive and running. Now global state poses multiple problems. Now having global state poses several problems as described in [Poli14].
- Logic duplication. Each developer may reimplement its own logic for LRU or other cache strategies.
- Non-explicit. When bootstrapping [Poli 14], serializing objects [Dias 11], or transporting objects between environment [Unga 05] there is a need to understand exactly the state of the object graphs. Without explicit properties it is really difficult for the tools to take appropriate actions.
- Often incomplete. Often programmers develop partial solutions for their particular needs. This hampers future reuse.
Subject:
The goal of this project is to introduce first class variables and to identify key characteristics to describe based
and to show the benefits of such representations on key scenarios.
Here is a possible outline of work:
- The student will study [Poli 14].
- He will study the preliminary representation of first class variables in Pharo.
- He will design a library of first class variables.
- He will evaluate the benefits in the context of
- the Fuel object serializer [Dias 11]
- the bootstrapping process and object initialization.
Pré-requis
- Willing to learn :)
- Pharo is a plus but not mandatory
References
- [Poli 14] Guillermo Polito, Noury Bouraqadi, Stéphane Ducasse, Luc Fabresse, Understanding Pharo’s global state to move programs through time and space, IWST 2014.
- [Unga 05] David Ungar. Annotating objects for transport to other worlds. In Proceedings of the tenth annual con- ference on Object-oriented programming systems, languages, and applications, OOPSLA ’95, pages 73–87, New York, NY, USA, 1995. ACM.
- [Dias 11] Martín Dias, Mariano Martinez Peck , Stéphane Ducasse, and Gabriela Arévalo, Fuel: A Fast General Purpose Object Graph Serializer, Softw. Pract. Exper. 2011.
- [Poli 14 ] G. Polito, S. Ducasse, L. Fabresse, N. Bouraqadi, and B. van RyseghemBootstrapping Reflective Systems: The Case of Pharo, Computer Programming - Journal - Elsevier. 2014.
Contact: stephane.ducasse@inria.fr, guillermo.polito@mines-douai.fr