All Projects → ekmett → Coda

ekmett / Coda

Licence: other
A language experiment -- irc.freenode.net ##coda

Programming Languages

haskell
3896 projects

Projects that are alternatives of or similar to Coda

Awesome Vscode
🎨 A curated list of delightful VS Code packages and resources.
Stars: ✭ 19,659 (+13183.11%)
Mutual labels:  vscode-extension, visual-studio
vscode-theme
A modern, good-looking, productivity-increaser theme for Visual Studio Code
Stars: ✭ 46 (-68.92%)
Mutual labels:  visual-studio, vscode-extension
Shades Of Purple Vscode
🦄 Shades of Purple — A professional theme with hand-picked & bold shades of purple to go along with your VSCode. Reviewed by several designers and 75+ theme versions released to keep it updated. One of the top rated best VSCode themes on VS Code Marketplace. Download →
Stars: ✭ 486 (+228.38%)
Mutual labels:  vscode-extension, visual-studio
firecode
VS Code Firestore Rules Extension
Stars: ✭ 35 (-76.35%)
Mutual labels:  visual-studio, vscode-extension
Vscode Terraform
A Visual Studio Code extension for Hashicorp Terraform
Stars: ✭ 672 (+354.05%)
Mutual labels:  vscode-extension, visual-studio
Vscoq
A Visual Studio Code extension for Coq [[email protected],@fakusb]
Stars: ✭ 138 (-6.76%)
Mutual labels:  vscode-extension
Latex Utilities
An add-on to LaTeX Workshop that provides some features that go beyond the bare essentials
Stars: ✭ 142 (-4.05%)
Mutual labels:  vscode-extension
Helm Intellisense
Extension for Visual Studio Code - Intellisense in helm-templates from the values.yaml
Stars: ✭ 137 (-7.43%)
Mutual labels:  vscode-extension
Vscode Swift Development Environment
New home of Swift Development Environment for VS Code
Stars: ✭ 137 (-7.43%)
Mutual labels:  vscode-extension
Vsnotes
Simple VS Code extension for plain text note taking.
Stars: ✭ 146 (-1.35%)
Mutual labels:  vscode-extension
Live Share
Real-time collaborative development from the comfort of your favorite tools
Stars: ✭ 1,920 (+1197.3%)
Mutual labels:  visual-studio
Arepl Vscode
program python in real-time
Stars: ✭ 142 (-4.05%)
Mutual labels:  vscode-extension
Iosreextension
A fast and elegant extension for VSCode used for iOSre projects.
Stars: ✭ 139 (-6.08%)
Mutual labels:  vscode-extension
Chronoshift
An open source re-implementation of Red Alert written in C++.
Stars: ✭ 144 (-2.7%)
Mutual labels:  visual-studio
Vscode Mjml
This repo is archived. MJML preview, lint, compile for Visual Studio Code.
Stars: ✭ 138 (-6.76%)
Mutual labels:  vscode-extension
Codelf
A search tool helps dev to solve the naming things problem.
Stars: ✭ 12,052 (+8043.24%)
Mutual labels:  vscode-extension
Vscode Coding Tracker
🕙 A coding activities tracker(time, file, type)
Stars: ✭ 137 (-7.43%)
Mutual labels:  vscode-extension
Vscode Stylelint
Official Visual Studio Code extension to lint CSS/SCSS/Less with stylelint
Stars: ✭ 141 (-4.73%)
Mutual labels:  vscode-extension
Serverless Ide Vscode
Serverless IDE: Enhanced support for AWS SAM and CloudFormation in VS Code
Stars: ✭ 145 (-2.03%)
Mutual labels:  visual-studio
Processing Vscode
A Visual Studio Code extension for the programming language Processing
Stars: ✭ 141 (-4.73%)
Mutual labels:  vscode-extension

coda

Travis Continuous Integration Status

This package will eventually provide a toy compiler.

For now, it provides an entertaining series of crashes and confusing error messages.

Table of Contents

Installation

To 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.

Once cabal new-install works, this will become a lot easier.

To work on the extension, you'll need to:

  1. Download the repository from https://github.com/ekmett/coda if that isn't where you are reading this file from.

  2. Run code . from root of that repository

  3. Start debugging to launch the extension-host following the instructions in Running and Debugging Your Extension.

Alternately you can link the directory directly into your ~/.vscode/extensions folder, which may be useful if you're working on the typescript bits.

Autocompletion

Once you have an installed coda executable, bash command line autocompletion is available with:

$ source <(coda --bash-completion-script `which coda`)

You can add this to your .profile or .bashrc

Requirements

Currently, 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.

Patches that help increase portability are welcome.

Documentation

Once there is an actual language here documentation will be forthcoming on it.

In the meantime, API documentation is available from https://ekmett.github.io/coda/

Directories

Directory Usage
.vscode Visual Studio Code configuration for the current workspace
bin Executable scripts
lib/coda* Haskell code for the language
code Typescript code for the extension
images The logo, etc.
test/code Typescript code for testing

License

Licensed under either of

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual-licensed as above, without any additional terms or conditions.

Contact Information

Contributions and bug reports are welcome!

Please feel free to contact me through github or on the ##coda or #haskell IRC channels on irc.freenode.net.

-Edward Kmett

What is all this about?

This is the response from ekmett to this question on reddit:

The short version of what coda is about is fixing a number of things that keep functional programming from scaling.

I'm leaving what particular dimension 'scaling' applies to as a free variable.

One way we can fill in that variable is to talk about execution speed:

FP 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.

One way we can fill in that variable is to talk about scalability of abstraction:

The 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?

One way we can fill in that variable is to talk about scalability of the library ecosystem:

Another 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?

One way we can fill in that variable is to talk about scalability of proof effort:

It 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.

There are other directions to explore here.

How to scale in terms of parallelizing team efforts? e.g. Letting more people work on proof infrastructure.

How 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?

How 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.

How 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.

Most 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.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].