Explore Projects

<p>Add support of deprecation pragmas within module exports. This would ease the transition between different versions of the software by warning the developers that the functions/types/classes/constructors/modules that they are using are deprecated.</p>

<p>This is a proposal to add serialization and deserialization support for TOML in the functional configuration language Dhall. TOML is a relatively new configuration language that is easily human readable, supports dates and times, and is unambiguous. The biggest users of TOML are Rust’s Cargo, and consequently many Rust programs read TOML. Adding support for TOML in Dhall would mean users do not have to choose between readability and the power to program their configurations.</p>

Haskell language server (HLS) implements the server part of Language Server Protocol (LSP) to improve user experience of reading and writing Haskell. Signature help is a LSP language feature which shows function signatures and documentation when the cursor is inside a function application. It can also highlight part of the signature related to the current parameter the cursor is at. Users want this useful feature. This project implements signature help for HLS.

<p>TidalCycles is an Embedded Domain Specific Language for pattern, in use by 10,000s of musicians worldwide. However it has had little work done on the user interface side; text editor plugins exist for vscode, atom, vim and emacs, but they are all simple wrappers around the ghci REPL. As a result Tidal is difficult to install, with many dependencies (ghc, cabal,libraries, build tools, and the supercollider digital signal processing system and its plugins) which developers may be comfortable with installing, but end-user ‘live coders’ are often turned away by. My idea is to develop the proof-of-concept for a Tidal API and editor plugin that allows new interactions with Tidal, and opens it up to a broader userbase.</p>

<p>Large scale haskell projects tend to have a problem with lockstep distribution of packages (especially backpack projects, being extremely granular). The unit of distribution (package) coincides with the buildable unit of code (library), and consequently each library of such an ecosystem (ex. amazonka) requires duplicate package metadata (and tests, benchmarks...).</p> <p>This project aims to separate these two units by introducing multiple libraries in a single cabal package.</p> <p>This proposal is based on <a href="https://github.com/haskell/cabal/issues/4206" target="_blank">this issue</a> by ezyang.</p> <p>Current status: <a href="https://github.com/haskell/cabal/projects/5" target="_blank">https://github.com/haskell/cabal/projects/5</a> and <a href="https://summer.haskell.org/news.html" target="_blank">https://summer.haskell.org/news.html</a></p>

<p>While much of the functionality required to use the <code>new-*</code> commands has already been implemented, there are not-insignificant parts of the design that was created last year that remain unrealized.</p> <p>By completing more of this design, I plan to help the <code>new-</code> prefix go away and to allow this safer, cleaner system to replace old-style cabal usage fully by rounding off the unfinished edges of the current proposal.</p>

This project aims to integrate the official GHC/WebAssembly backend into xeus-haskell, a Jupyter kernel for Haskell. Currently, the kernel relies on MicroHs, which, while lightweight, lacks support for the vast majority of the Hackage ecosystem. I will implement a dual-backend architecture by introducing a new C++ bridge and a reactor-model Wasm REPL module based on the GHC API. Key deliverables include: GhcRepl: A GHC-based WebAssembly REPL module maintaining persistent session state. C++ Bridge: A new interface (ghc_repl.cpp) to communicate with the GHC/Wasm runtime via the Wasm C API. Backend Abstraction: A unified virtual interface to allow seamless switching between MicroHs and GHC/Wasm. WASI Integration: A configured browser shim to handle I/O and package database access within JupyterLite

hackage-server as of yet does not support more advanced algorithm for sorting relevant packages (at the moment user rating is used), this proposal aims to implement a algorithm similar to the one in crates ("rust hackage"). This would help with finding relevant packages.

<p>This proposal aims to add call hierarchy support in Haskell Language Server(HLS).</p> <p>Language Server Protocol(LSP) has <a href="https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_prepareCallHierarchy" target="_blank">supported</a> call hierarchy in 3.16, which make us implement it in HLS possible.</p> <p>Inspired by <a href="https://github.com/haskell/haskell-language-server/issues/738" target="_blank">this issue</a>, my proposal involves the following steps this summer to contribute to call hierarchy:</p> <ol> <li><a href="https://github.com/haskell/lsp" target="_blank">LSP</a> spec support.</li> <li><code>prepareCallhierarchy</code> implementation.</li> <li><code>incomingCalls</code> implementation.</li> <li><code>outgoingCalls</code> implementation.</li> <li>Test</li> </ol> <p>I hope I can contribute to HLS to go further this summer.</p>

<p>Currently, the package candidates are not using the templating system and their UI can be improved. To improve the candidates publishing process, we need to add certain functionality to smooth the process. The final goal is to implement a fixed workflow for package candidates and have the docbuilder and docuploads worked with them.</p>

The Chrome DevTools Protocol (CDP) serves a variety of automation use cases by providing programmatic access to Chrome. These include data collection, website testing, form submission and PDF generation. This project aims to address the absence of an actively maintained client library for Haskell, leveraging its type system to provide a strongly typed interface for utilizing Chrome.

The project aimed to build a playground for Modern Fortran which enables users to run their code online. It will be offered as an extension to the official fortran-lang website where users can experiment with their code and play around with supported libraries. The playground also offers an interactive tutorial for Fortran newcomers, giving them an overview of the language syntax and features.

<p>Finding the best example of full-stack Haskell web development project is hard as a beginner to intermediate Haskell developer. This is based on my experience when learning Haskell for web development. Moreover, many misinformed statement regarding how to do web development using Haskell especially about the library, tooling, and architecture to use leads to make a Haskell newcomer afraid to express their idea in web project using the language.</p> <p>Hackage Matrix Builder is one of the example project which planned to be a full-stack functional programming project that can help beginner to see how web based project looks like using Haskell. However, it is not entirely use Haskell and it sometimes make it hard for newcomer to learn two language at the same time for their example project. In addition, Hackage Matrix Builder is one of the project that aims to provide the best build compatibility test service to the Haskell community for all the packages published on Hackage.</p> <p>In this project, I am aiming to make a full-stack Haskell web development project example as well as adding UI feature in Hackage Matrix Builder to maximize its purpose as QA or CI service for everyone.</p>

This project proposes various new features for the haskell language server(HLS). While HLS already comes with the most important ones, a few haven’t been implemented yet. These important unimplemented features of Language Server Protocol(LSP) have to be implemented. Namely, Semantic Highlighting, Folding ranges, Linked editing, Change Annotation, Document links, and Completion / Code Action / Code Lens resolving.

This proposal aims to enhance Liquid Haskell’s name resolution mechanism by enabling qualified imports for both (logic) type and predicate aliases. Currently, ambiguities arise when identical aliases are exported from multiple modules, adversely affecting both user experience and internal processing. The proposed solution will modify the internal alias representation and update all relevant use sites to construct fully qualified names, thereby allowing users to disambiguate identical aliases. Additionally, the project will conduct a detailed study of predicate alias use cases to evaluate the potential deprecation of these aliases in favor of the overlapping functionality provided by inline annotations. The primary deliverables include merged pull requests implementing qualified import support for type and predicate aliases, comprehensive documentation, and a blog post detailing design decisions, implementation processes, and the outcomes of the predicate alias study.

This proposal aims to add new features to the Hackage server, mainly include package sorting, user info update and user notification emails. It's planned that first a week is needed to read the codebase, then about a month to implement the three features above, and add some additional interesting feature if time permits.

<p>The proposed outcome of this Summer of Haskell research is the production of a library or package for live coding autonomous music through integration with existing Haskell libraries and languages, such as the TidalCycles live coding environment Hasktorch library for neural networks and tensors.</p>

<p>Hasktorch has two distinct APIs for tensors: Torch.Tensor and Torch.Tensor.Typed. While the untyped version can initially be easier to use and experiment with, the typed version offers static analysis of tensor’s shape, layout, precision, and compute device. The typed version not only helps with debugging and maintainability but also offers better support for type-driven development via GHC features like type holes. However, it is currently difficult to mix the two approaches, e.g., statically specifying tensor’s embedding size while keeping other dimensions unchecked is not possible. Gradual typing is the proposed solution that fuses the two APIs by adding Torch.GraduallyTyped type. The new API allows for more granular control by letting the user choose which properties of the tensor should be given a static type. The goal of the project is to bring maturity to the gradually typed tensor API, add missing features, and experiment with new ideas.</p>

<p>Figures play a central role in the life cycle of all kinds of research and analysis. That is: The communication of results.</p> <p>What we propose in this project is to extend <code>pandoc</code>’s figure handling capabilities to represent composite figures. This will provide a concise way to construct them compared with the alternative of writing LaTex code; and thus, facilitate source publishing.</p>

PETSc, the Portable, Extensible Toolkit for Scientific Computation, is for the scalable (parallel) solution of scientific applications modeled by partial differential equations (PDEs). Besides its native API in C it has bindings for Fortran and Python. PETSc also contains TAO, the Toolkit for Advanced Optimization, a software library supporting MPI and GPUs through CUDA, HIP, Kokkos, or OpenCL. While most of the Fortran interfaces can be generated automatically from the C-API, functions with "complex" arguments such as procedure pointers, pointers to arrays, and strings require the manual creation of interface code on both the C and the Fortran side. Moreover, due to the discrepancy of features between C and Fortran, a one-to-one translation of APIs leads to Fortran interfaces that don't leverage the capabilities of modern Fortran. Examples include overloaded functions for different types in Fortran, for which a C-API requires VOID and an explicit type argument and arrays, for which the length is part of the type definition in Fortran but requires a second argument in the C-API. This project aims to improve the automation of generating Fortran interfaces by leveraging modern Fortran features such as BIND(C) and ISO_C_BINDING along with annotation strategies to reduce the need of manual generation of interfaces. The improved system will enhance both usability for end-users and maintainability for developers.

This project enhances Goal - a library of machine learning algorithms based on Haskell - with a GPU backend provided by Hasktorch. Goal strikes a careful balance between a lightweight type system ensuring correctness, and burdening the user with complex types. Thus, a primary objective attempts to maintain the existing developer experience by providing a clean abstraction over Hasktorch primitives. Furthermore, configuring a GPU can be arduous. Therefore, as a secondary objective we provide a packaging option via nix to extend the pleasant developer ergonomics of the Goal library to installation and the development environment.

<p>Project is to build a sequence-to-sequence encoder-decoder model as a module of the Hasktorch library, and demonstrate it on an NLP task.</p>

For GHC 9.2.x to achieve more widespread adoption, tooling will need to support its best features. For years users have been frustrated by Haskell's conspicuous lack of support for namespacing features common in other languages. Haskell provides a limited form of namespacing with qualified imports, but using it to namespace field selectors tends to require hacky file structures. Fortunately, Haskell now provides `DuplicateRecordFields`, and GHC 9.2 introduced the `OverloadedRecordDot` language extension. These together provide a cleaner and more ergonomic interface for working with record types, a step towards better namespace support in Haskell. HLS already supports record dot-syntax to a small extent. For example, in the line `y = x.a`, type information is available when hovering over `y` or `x`. To unlock the full potential of this syntax though, HLS users should be able to "dot into" the record to see its fields, enabling IDE-driven API exploration. Additionally, type information for the `.a` part should be available to the user on hover. These are the main features I propose to add to HLS for this project.