Types for cross-compilation (OCamlLabs related)
Increasing number of applications are targetting heterogenous execution environments such as server-side,
Java, ARM, LLVM) and libraries allowing interoperability. In such a scenario, certain parts of code may be
compiled only for certain platform-specific environments, but some can be safely shared. This project should
extend the OCaml type system in order to track execution environments for which an expression can be compiled,
and simplify writing code that cross-compiles for multiple platforms and diverse execution environments.
This project could be done as part of the OCamlLabs,
but it could be equally implemented as an extension to another programming language.
Web programming with alternative formlets
Formlets provide an interesting abstraction for web programming - they represent
a web "form" that can be rendered (on the server-side) to get HTML representing a form.
When the user fills in form information and submits the result, the "formlet" can
process the incoming data to get a data-structure representing the result of the form
(such as customer information).
Formlets are designed for old-fashioned web programming where most of the
processing happens on the server-side, so the question is, could we adapt them
to make them more useful on the client-side too?
One interesting option is using the
Alternative type, which
extends the core concept behind formlets and adds a notion of choice.
This means that one could build forms with multiple different options
and the option could be chosen on the client-side dynamically. However, there
are probably many other interesting approaches!
Visual editor for domain specific languages
Domain specific languages (DSLs) give a powerful technique for writing reusable libraries
(not just) in functional languages. Given a problem (i.e. processing lists), we design a
set of reusable combinators (mapping, filtering, etc.). A specific problem (such as a task
to multiply elements of two lists by some number and then combine them in some way) can then
be easily solved just by using the available combinators.
The approach is used not just for list processing, but in many other areas - for
composing user interfaces, specifying event handling, modelling financial contracts,
etc. Here is an example of list processing (using F#):
List.zip (list1 |> List.map (fun x -> x * 10))
(list2 |> List.map (fun x -> x * -10))
|> List.iter (fun (a, b) -> printfn "left %d, right %d" a b)
The code can be quite nicely represented visually, showing how the data flow through
The idea of this project is to design some editor (or, at least, visualizer) that
can take code written using DSL and display it visually and allow the user to edit
it. This should work for any DSL (although it may need to be annotated in some way).
In statically typed programming languages, the type system is used to check that types
of expressions are used correctly and are correctly composed (i.e. you call a function
with an argument of a correct type).
However, sometimes we do not quite surely know what the type of an expression is. This
may be because we're calling some dynamically typed code or because we're loading data
from an external data source that does not have a clear type.
The goal of this project is to create a "fuzzy" type system that can deal with such
uncertainty in programs. For example, if the type system can tell us that the
property "Name" is a string in 99% of the cases, then that's quite useful information!
This is probably more theoretical or experimental project, but it could be implemented
as a simple language (i.e. for data processing) or it could be written as an additional
checker for dynamic programs or programs in Haskell, F# or other language.
- Fuzzy Logic - type systems
for functional languages are connected to logics, so the new type system would be
probably related to fuzzy logics in some way