https://github.com/alan-turing-institute/nocell

A language for spreadsheets
https://github.com/alan-turing-institute/nocell

hut23 hut23-418

Last synced: about 2 months ago
JSON representation

A language for spreadsheets

• Host: GitHub
• URL: https://github.com/alan-turing-institute/nocell
• Owner: alan-turing-institute
• License: mit
• Created: 2020-09-09T08:21:19.000Z (over 4 years ago)
• Default Branch: main
• Last Pushed: 2024-02-26T11:29:41.000Z (about 1 year ago)
• Last Synced: 2025-01-12T22:42:17.486Z (3 months ago)
• Topics: hut23, hut23-418
• Language: Racket
• Homepage:
• Size: 1.05 MB
• Stars: 1
• Watchers: 2
• Forks: 0
• Open Issues: 18
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# nocell

A language for spreadsheets

![Tests](https://github.com/alan-turing-institute/nocell/workflows/Run%20tests/badge.svg)

## Design

- [See the wiki for plan and design](https://github.com/alan-turing-institute/nocell/wiki)

- [The documentation lives here](https://alan-turing-institute.github.io/nocell/index.html)

## How we work together

### Branches

* `main` - is demo-able

* `develop` - the tests pass

* `feature/xy` - Feature branches

* Pull requests - Mandatory, if you change an interface; Optional, if you want a review.

### Style 

* Explcitly provide rather than `all-defined-out`

* Use `contract-out` on provides

* No owners, but let people know what you are working on (eg, Slack or grab an issue)

### Documentation

**Please think about and edit this section**

In the new world of remote-working, it seems likely that documentation will be

more valuable. I (James G) intend to try to write more "planning-type"

documentation -- ie, design principles, architecture, and so on -- rather than

just diving into code. I propose to try to make this documentation precise but

pithy.

There's some trade-off here that I don't really know how to manage. Typically

one needs to try out ideas in code, and those ideas will change. But on the

other hand, writing things in advance is a way to help one think, which is

important since we don't meet up in person with a whiteboard any more. And if

one writes code too early, the design tends to ossify.

I think perhaps the implication is that one needs to be slightly less ambitious

(end-to-end) and more about building stuff that does a small thing, but

works. That fits quite well with this project since the end-to-end prototype has

already been worked out.