{"id":17249268,"url":"https://github.com/ekmett/coda","last_synced_at":"2025-10-15T18:16:41.433Z","repository":{"id":24198407,"uuid":"100850826","full_name":"ekmett/coda","owner":"ekmett","description":"A language experiment -- irc.freenode.net ##coda","archived":false,"fork":false,"pushed_at":"2024-04-10T06:04:55.000Z","size":2824,"stargazers_count":162,"open_issues_count":5,"forks_count":14,"subscribers_count":21,"default_branch":"master","last_synced_at":"2025-03-30T05:11:24.425Z","etag":null,"topics":["coda","haskell","node","programming-language","visual-studio","vscode-extension"],"latest_commit_sha":null,"homepage":"","language":"Haskell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ekmett.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-08-20T09:20:14.000Z","updated_at":"2024-12-12T08:15:40.000Z","dependencies_parsed_at":"2023-01-14T01:30:13.284Z","dependency_job_id":null,"html_url":"https://github.com/ekmett/coda","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekmett%2Fcoda","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekmett%2Fcoda/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekmett%2Fcoda/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ekmett%2Fcoda/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ekmett","download_url":"https://codeload.github.com/ekmett/coda/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250536520,"owners_count":21446748,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["coda","haskell","node","programming-language","visual-studio","vscode-extension"],"created_at":"2024-10-15T06:43:49.439Z","updated_at":"2025-10-15T18:16:36.411Z","avatar_url":"https://github.com/ekmett.png","language":"Haskell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# coda\n\n[![haskell ci](https://github.com/ekmett/coda/actions/workflows/ci.yml/badge.svg)](https://github.com/ekmett/coda/actions/workflows/ci.yml)\n\nThis package will eventually provide a toy compiler.\n\nFor now, it provides an entertaining series of crashes and confusing error messages.\n\n**Table of Contents**\n\n- [Installation](#installation)\n- [Autocompletion](#autocompletion)\n- [Requirements](#requirements)\n- [Documentation](#documentation)\n- [Directories](#directories)\n- [License](#license)\n- [Contact Information](#contact-information)\n\nInstallation\n============\n\nTo install the `coda` executable, you will need GHC 8.4.1 release candidate 1 or later, and you'll need to run `cabal new-build`, and fish through `dist-newstyle` for the executable and put it somewhere in your path.\n\nOnce `cabal new-install` works, this will become a lot easier.\n\nTo work on the extension, you'll need to:\n\n1. Download the repository from \u003chttps://github.com/ekmett/coda\u003e if that isn't where you are reading this file from.\n\n2. Run `code .` from root of that repository\n\n3. Start debugging to launch the extension-host following the instructions in [Running and Debugging Your Extension][debugging-extensions].\n\nAlternately you can link the directory directly into your `~/.vscode/extensions` folder, which may be useful if you're working on the typescript bits.\n\nAutocompletion\n==============\n\nOnce you have an installed `coda` executable, bash command line autocompletion is available with:\n\n```\n$ source \u003c(coda --bash-completion-script `which coda`)\n```\n\nYou can add this to your `.profile` or `.bashrc`\n\nRequirements\n============\n\nCurrently, the build process is being tested on GHC 8.2, but I'm not actively doing anything to shut off older GHCs or newer ones.\n\nPatches that help increase portability are welcome.\n\nDocumentation\n=============\n\nOnce there is an actual language here documentation will be forthcoming on it.\n\nIn the meantime, API documentation is available from https://ekmett.github.io/coda/\n\nDirectories\n===========\n\n| Directory     | Usage |\n| ------------- | ----- |\n| `.vscode`     | Visual Studio Code configuration for the current workspace |\n| `bin`         | Executable scripts |\n| `lib/coda*`   | Haskell code for the language |\n| `code`        | Typescript code for the extension |\n| `images`      | The logo, etc. |\n| `test/code`   | Typescript code for testing |\n\nLicense\n=======\n\n[Licensed](LICENSE.md) under either of\n * Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0)\n * BSD 2-Clause license (https://opensource.org/licenses/BSD-2-Clause)\nat your option.\n\nContribution\n============\n\nUnless you explicitly state otherwise, any contribution intentionally submitted\nfor inclusion in the work by you shall be dual-licensed as above, without any\nadditional terms or conditions.\n\nContact Information\n===================\n\nContributions and bug reports are welcome!\n\nPlease feel free to contact me through github or on the ##coda or #haskell IRC channels on irc.freenode.net.\n\n-Edward Kmett\n\n [debugging-extensions]: https://code.visualstudio.com/docs/extensions/debugging-extensions\n [shake]: http://shakebuild.com/\n [travis]: http://travis-ci.org/ekmett/coda\n [travis-img]: https://secure.travis-ci.org/ekmett/coda.png?branch=master\n\n What is all this about?\n ====================\n\n*This is the response from ekmett to this question on [reddit](https://www.reddit.com/r/programming/comments/bip6ho/graydon_hoare_on_21_compilers_a_wander_through_a/em5grcg/):*\n\nThe short version of what coda is about is fixing a number of things that keep functional programming from scaling.\n\nI'm leaving what particular dimension 'scaling' applies to as a free variable.\n\nOne way we can fill in that variable is to talk about execution speed:\n\nFP has been good at getting us code that scales down to the core level, but we aren't getting more cores terribly fast. Moore's law used to equate to speed, then it equated to speed * cores, now it mostly equates to speed * cores * width of the SIMD processing unit when it applies at all. I'm interested in ways to apply SPMD-on-SIMD evaluation techniques to functional programming. These are the techniques that make the Intel SPMD Program Compiler work as well as it does. It also provides a window onto how to execute this sort of code on GPU and TPU style hardware. If I want symbol pushing techniques to be at all relevant in a world where these are becoming the norm, we can't fail to scale past the core.\n\nOne way we can fill in that variable is to talk about scalability of abstraction:\n\nThe typeclass mechanism Haskell uses favors finding a few good abstractions over accurate abstraction selection. If I tried to make the standard library of Haskell have a mathematical concept of a 'Field' and put 600 superclasses with all of the algebra I know above that point, the community would mutiny on day 1. On day 30 when I found it should be 601, and went to make the change all of that code would break. How can we make deep extensible type classes with typeclass hierarchies that actually branch out and aren't linear chains?\n\nOne way we can fill in that variable is to talk about scalability of the library ecosystem:\n\nAnother dimension where I don't see it scaling is that there are a number of language design decisions in Haskell that keep me from scaling. I maintain a rather ridiculous number of Haskell libraries, all of which have to work together. Haskell is pretty darn good at solving diamond dependency issues, compared to something like node, which just ignores the problem, in a way that makes it easy to depend on ridiculous numbers of dependencies, but building a haskell project still consists of spending 97%+ of your time compiling instances for classes that never occur in the final program in a way that is forced by the structure of package management. You have to supply instances for every package that came before you in the Haskell ecosystem or you are just incompatible because of uniqueness of instance resolution. Orphan instance packages can be forgotten or mis-used. How do we fix this problem?\n\nOne way we can fill in that variable is to talk about scalability of proof effort:\n\nIt took 13000 lines of basically nonreusable code, 9 months worth of effort and a PhD to prove the correctness of the GMP sqrt function. Most issues I'm interested in are bigger than that.\n\nThere are other directions to explore here.\n\nHow to scale in terms of parallelizing team efforts? e.g. Letting more people work on proof infrastructure.\n\nHow to factor apart what it means to prove something correct, and finding a space of equivalent, correct programs, and then to make it fast by selecting tactics style out of a space of equivalent correct programs the one you want?\n\nHow to throw program synthesis techniques at problems to increase the grain size of problems that the compiler just handles for you? The work on synquid by Nadia Polikarpova, Barliman by Will Byrd, and Blodwen by Edwin Brady all point generally at something in this space. Each offers different ways to prune the search space drastically by using types or different generation techniques.\n\nHow to scale the number of machines that are used for synthesis? I know tons of people who work in rendering films. There we spin up 10k+ machines to save artist time. Is developer time less valuable? This also drastically changes the scope of what is considered synthesizable when this is your baseline.\n\nMost of my efforts lately have gone into this subgoal of program synthesis, hence coda itself has languished while I build the pieces there that I need to build the type checker infrastructure on top of. The irony is not lost upon me that this languishing arises largely due to my inability to scale up my own local development efforts, personally.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fekmett%2Fcoda","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fekmett%2Fcoda","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fekmett%2Fcoda/lists"}