Skip to content

Roadmap for the first working version

It is with satisfaction that I, Dooms, announce the roadmap for a first working version of H-hat. For legacy reasons, it will be starting as the version 0.3.

Summary

  • The H-hat development will be divided into two steps: Python based (step 1), and Rust based (step 2)
  • For everyone, the way to use the language is through the Rust-written interpreter/compiler (aka stable)
  • For those willing to test new features or even develop them, the Python-written interpreter/compiler is the way to go (aka experimental)
  • Heather is the default H-hat's dialect shipped with either Python or Rust interpreter/compiler
  • Version 0.3-E0 in Python to roll over by the beginning of next year, as well as initial development for 0.3.0 in Rust

Explanation

So far, exploratory steps were taken mercilessly, scrapping, rewriting, fixing things without second thoughts. Now, things are getting more clear and solid, specifically on my proficiency at understanding what software requirements for the language development are needed, as well as improving the community interaction and exploring how to design a toolchain around it.

Python and Rust

A common sense between me and Inho (mostly) is that, while the language is not bootstrappeable and there is a mismatch between people interested on quantum with programming language skills and good programming languages to build programming languages, there is going to be a two-step development cycle system for H-hat: step 1 is test it in Python, and step 2 is establish it in Rust.

In practice, it means that new features, new ideas, new concepts, and breaking changes will be first developed in Python. Why is that? Because most of the people with some knowledge and interest in quantum right now may be (only or mostly) familiar with Python, so we want to make sure their ideas and suggestions can be easily tested/added to the language so we can understand how things will work. Thus, for those willing to test new features or develop them, the Python-written interpreter/compiler is the way to go.

Once those features/changes are accepted to be incorporated into H-hat, the next step is followed; let's implement that in Rust. It means that stable, (much more) performant and reliant version of the language will be written in Rust. For everyone, this will be the way to use the language: through the Rust-written interpreter/compiler. But, why Rust? you may ask. Simple reason I can find is: I would rather write it in Rust than in any other language that can offer some performance due to their systems programming capabilities and compiled nature. And since Rust seems to be a good language to do most of the work needed here and people are willing to learn it, it seems compelling to pursue this PATH.

Versioning scheme

Now, regarding the versioning. Python code version will be defined as the experimental side of things, so its versioning scheme is as follows: <MAJOR>.<MINOR>-E<PATCH> (example: 0.3-E1 ), while Rust code version will be defined as the stable side and thus having the versioning scheme as: <MAJOR>.<MINOR>.<PATCH> (example: 0.3.4).

The distinction between both is to make it clear what their purposes are for, so there is no confusion which one to download or build, for instance. Also, it shows that the patch version from Python's has no relation to the patch version of Rust's, because they may have independent cycles and independent bugs/fixes.

The only thing they share is the core concepts to be leverage from one to the other. It means that a version 0.3-Ex in Python code version should present the same language features as the one in version 0.3.y in Rust (where x and y are unrelated to each other). It also means that Python code version will always be ahead of Rust's. Once 0.3-Ex is approved, the pipeline will move towards implementing the features described on it to the Rust code version. It alone will have the traditional scope, as 0.3.0-beta for beta versions and 0.3.0 once it is officially released, for instance. Regarding release candidate (e.g. 0.3.0-rc), it still is not clear, but let's see how it goes. At that point, Python code version must start developing at the version 0.4-Ex.

I also plan to have a 0.3-STABLE tag to direct to the latest, most stable version (in Rust). I particularly am not a fan of having version x.y.z overall, because you never know which z is the latest or more stable one. This will align better with some ideas I have for the future of the language as well. But I will discuss it in a future post.

Dialects

One important aspect of H-hat is to be a rule system with core concepts to be followed, rather than a strict syntax, semantics and compilation implementation. The reason is that throughout the years presenting H-hat to people from various backgrounds, I noticed a pattern: people always want to have something familiar to look for; thus, I always had the "why not having the syntax as ?". I realized that nobody was happy with any syntax I would ever try to present to appease their tastes. So instead, I decided to define the rules in which H-hat is composed on and write dialects on top of it to demonstrate the features I want to present.

In the long term, I envision some interoperability between dialects happening, so people could write their own dialect with their favorite syntax/semantics and easily integrate with existing code or be easily integrated with future code in other dialects.

For now, Heather is the current dialect that ships with the language (Python and Rust code versions will have it). Its main point is to manifest H-hat capabilities, so we can build things and understand how to do better in the next version.

Content of version 0.3

  • Types definitions: single, struct, enum
  • Heather dialect
  • Classical and quantum data types and functions constructs
  • Built-in data types:
  • bool
  • u32
  • u64
  • i32
  • i64
  • f32
  • f64
  • str
  • hashmap
  • @bool
  • @u2
  • @u3
  • @u4
  • Built-in functions:
  • basic IO features on: keyboard input and binary file reading, terminal printing and binary file writing
  • basic math operations on: logic, arithmetic, trigonometry
  • basic quantum data transformation: single- and multi-index operations
  • Function construction and overloading
  • Basic distributed computing features
  • Cast system to enable quantum and classical data interoperability
  • low level quantum languages: OpenQASM v2 and NetQASM
  • target backends: qiskit (IBM machines) and netsquid
  • Modifier feature
  • Meta module feature

Version 0.3 release roadmap

  • Python, experimental version (0.3-Ex)
  • September and October: built-in functions feature, openqasmv2 and cast system
  • October and November: cast system, qiskit and modifier feature
  • November and December: netqasm, modifier and meta module features
  • January and February: netsquid, distributed features

Rust version will follow through shortly.

Final remarks

Exciting months ahead and looking forward to knowing what you think about it! You can reach us out at the Unitary Foundation's Discord server (linked at README.md file) #h-hat channel.

See you around :))