Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expression phase terminology #2964

Merged
merged 3 commits into from
Jul 6, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 93 additions & 0 deletions proposals/p2964.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
# Expression phase terminology

<!--
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
Exceptions. See /LICENSE for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->

[Pull request](https://github.com/carbon-language/carbon-lang/pull/2964)

<!-- toc -->

## Table of contents

- [Abstract](#abstract)
- [Problem](#problem)
- [Background](#background)
- [Proposal](#proposal)
- [Rationale](#rationale)
- [Alternatives considered](#alternatives-considered)

<!-- tocstop -->

## Abstract

Update terminology around expression properties:

- "value phase" -> "expression phase"
- "symbolic value" -> "symbolic constant"
- "constant" -> "template constant"
- "constant or symbolic value" -> "constant"

Implements the decision in
[#1391](https://github.com/carbon-language/carbon-lang/issues/1391).

## Problem

There are a few concerns with the current terminology:

- We were not happy with it at the time it was introduced in
[proposal #1378](https://github.com/carbon-language/carbon-lang/pull/1378/files/198c7bd152bc4e223f1fc2484455e17ba31f19f9#r921592116),
but didn't want to block that proposal on finding better names.
- It is a property of expressions, not values. We are switching from "value
categories" to "expression categories" for the same reason. See
[proposal #2006](https://github.com/carbon-language/carbon-lang/pull/2006)
and [PR #2744](https://github.com/carbon-language/carbon-lang/pull/2744).
- No good term for the bindings that use `:!`, which share a number of
properties, and often we want to refer to those together.

The concerns about the names of the individual phases led to
[questions-for-leads issue #1391: New name for "constant" value phase](https://github.com/carbon-language/carbon-lang/issues/1391).
This proposal implements the resolution from that issue.

## Background

The current names were introduced in
[proposal #1378: Design overview update part 7: values](https://github.com/carbon-language/carbon-lang/pull/1378)
based on a discussion in
[#typesystem on Discord](https://discord.com/channels/655572317891461132/708431657849585705/996547601451204630).
I am not aware of corresponding terminology in other programming languages.

## Proposal

We update terminology around expression properties, specifically what we
previously referred to as "value phase" and values it can have, as follows:

- "value phase" -> "expression phase": since this is a property of
expressions, not values.
- "symbolic value" -> "symbolic constant": for symbolic compile-time values
like checked-generic parameters.
- "constant" -> "template constant": for compile-time values where the value
is available during type checking, like literals and `template` parameters.

By making these last two terms both end in "constant," we allow their
combination (including all compile-time values) to be collectively referred to
using the term "constant." For example, either kind of constant may be passed to
a function with either kind of constant binding.

## Rationale

The goals of this proposal are:

- clearer and more concise communication, and
- making it easier for people to learn Carbon by using more consistent
terminology.

This supports Carbon's goal of having
[Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write).

## Alternatives considered

We were happy with this option and did not spend time coming up with more
alternatives.