adelhult / hypatia

Domain-specific language for units and arithmetic calculations

Hi there!

Here on my GitHub page you can find various smaller experiments and hobby projects. I like to tinker with programming/markup languages, systems programming, human-computer interaction and web technologies (especially WASM related). Mostly writing Rust and Haskell for fun, but also some C++, JavaScript and Python when needed.

Currently, I’m pursuing a M.Sc. in Computer Science (Algorithms, Languages and Logic) at Chalmers University of Technology in Gothenburg, Sweden.

hypatia's Issues

Prefix group drafts

//declaring new prefixes, not assigned to groups at first
prefix kilo k = 1000
prefix deci d = 0.1
prefix centi c = 0.01

//new prefix group with three prefixes, may use keyword prefixgroup instead of group
group metric = kilo, deci, centi

//creating new prefixes and adding them directly? I prefer the first option
prefix dussin d = 12 in äggmått
prefix tjog in äggmått = 20

unit ägg ä = 1 using äggmått //adding prefix groups to new units
use metric for gram //adding prefix groups to existing units, alternative syntax may be "gram using metic"

x = 1 dussin meter //okay since long names are used, low risk for conflicts
y = 1 dm //okay since short names are used and meter is using metric group, so no conflict
z = 1 dussin ägg + 2 dä // equals 3 dussin ägg, no conflicts since short names are used and only äggmått is used for ägg, not metric

These are my proposals:

• Long names should always be allowed and group belongings doesn't matter for long names, since risk for collision is low anyways
• All units have a list of prefix groups that are allowed for that unit
• A prefix can be in multiple prefix groups, and should hold a list of which prefix groups they are in
• Every prefix is in its own prefix group (prefix tjog is in the group tjog), this will then allow unit x using tjog without adding tjog to a dummy group
• There should be one "global" prefix group
• If a prefix has no prefix groups specified (at creation time or later), they should be in the global group, skipping the prefix group configuration for non-advanced users
• If a unit has no prefix groups specified (at creation time or later), they should use the global group, also skipping the prefix group configuration for non-advanced users
• If a prefix group which is undefined is specified, make a new one and allow it to be used
• I do prefer using x, y, z to using (x, y, z), I doubt it will be any parsing problems since it is the last part of a statement and looks less like programming and more notebook-y
• use will be a new keyword for adding groups to units after creation
• group will be a new keyword for grouping prefixes (might be changed to prefixgroup but I prefer group)

Some thoughts on implementation:

• Every prefix should have a list of their own group belongings
• Similarly, every unit should have a list of their groups
• Try to parse an unit as we already do, by searching the Trie and backing on chars until a prefix and unit is found. Then, if prefix and unit is short, double-check if the unit can use that prefix group. Otherwise skip it, since it may be a false match
• When making a new prefix, add it to its own group and the group _global. Whenever a group is added to a prefix, remove _global if it exists. This will make sure it won't be in the group _global if you manually add a group, but make sure it is possible to manually add a prefix to global, and that _global is treated as global, so that you may have a prefix which you add to one group and to the global group
• When making a new unit, add it to the group _global and do as above so that you may manually add global if you want
• We may have a global database over groups, and if we do, we can easily check if a new group is added or if a group doesn't exist instead of iterating over all unit/prefixes
• When a name that doesn't exist is typed, just create a new group there. I think that we should do this regardless if the global database exist or not. I do not think we need a global database but we might add it in the future to facilitate listing of groups etc

Integration test with multiple threads

Since the front-end stores the Environment struct as a global variable the code needs to be thread safe. It would be great to have a minimal integration test that ensures that this compiles so that you don't have to test the frontend for every change in the "core" crate.

Roadmap and basic features

• Expose a nicer API with a parse and eval function (or maybe just a eval that takes a &str)
• Add scopes
• Create a way of testing files in the samples dir
• Add "update" keyword
• Replace Number with Quantity
• Disallow units and variable names to collide
• Allow for omitting numeric values in unit expressions (i.e. unit foo = 2 m * kg
• Add a prelude
• Add in conversion operator
• Add comparison operators
• Add logical operators
• Add functions
• Fix lexical scope bug
• Add useful math functions sin, cos etc.
• Integrate into a notebook editor on the web via a WASM build
• Perhaps a postfix application operator
• Add unit prefixes (kilo, mega, etc.)
• Add support for binary and hex literals as well as maybe bit manipulation operators (this might require a distinction between Real and Integer types)

Refactor tuple structs

I find tuple struct really hard to read (thing.0 . 1) so it might be a good idea to convert most of them into normal structs.

Parser bug, comment before eof produces syntax error

Programs ending with a comment failes to parse. See screenshot.

Complete the resolve rewrite and fix bug with variables

I should get around to merging the resolve branch and also fix the newly introduced bug that makes it impossible to bind variables to the global scope.

Custom prefix declaration

Currently all units can also be used with a metric (or binary) prefix like "km" and "kilometer". However, it would be nicer if units / quantifiers could be declared in the prelude instead of baked into the language. This would also lower the chance of name collisions because we can avoid having things like "centijoul" which never will be used.

Something like this perhaps:

prefix kilo k = 1000

prefixgroup foo = (kilo) 

unit bar using foo

Autocomplete suggestions for greek unicode symbols

Writing "\alpha" should use code mirror completion suggestions to replace with "α" etc.

Support unicode identifiers

Currently the language only supports c-like identifiers. Fix this by replacing the ident parser.