mooncakes.io

marianoguerra/pure-py/profile does not have a README file

Feature

pub(all) enum Feature {
  ChainedBoolean
  ChainedComparison
  Identity
  Slicing
  DestructuringAssignment
  ExtraBuiltins
  BuiltinMethods
  DefaultArguments
  FStrings
} derive(Compare, Eq, Hash, @moonbitlang/core/debug.Debug
Debug)

A feature PurePy does not have and a profile may add.

The doc comment on each arm cites the upstream issue the sieve cites, so the two can be read together.

Arms are APPENDED, never inserted: the derived Compare is tag order, and tag order is the order Profile::features answers in. Adding one is additive for a caller who builds a profile and breaking for one who matches a Feature exhaustively, which is the usual trade for an open enum.

Feature::name

source

fn Feature::name(self : Feature) -> String

The name a --profile flag prints and a person reads.

Profile

source

pub struct Profile {
  features : @moonbitlang/core/immut/sorted_set.SortedSet
SortedSet[Feature]
} derive(Eq, @moonbitlang/core/debug.Debug
Debug)

Which superset of PurePy a caller opted in to.

A sorted set, because that is how the rest of this codebase gets a deterministic order out of a set: features iterates it, and what pure-py profiles prints has to be the same twice.

The field is readable, as every pub struct in this library is, but there is no way to CONSTRUCT one except from core by adding. That is the property worth having: a Profile is always a superset of PurePy, never a subset, and no caller can spell one that takes something away.

Eq is derived because "did the caller ask for the same language I did?" is a fair question; Debug because a failing test should be able to say which profile it had. adding rather than with only because with is a keyword.

Profile::adding

source

fn Profile::adding(self : Profile, fs : Array[Feature]) -> Profile

This profile with more features. Stacking is this and nothing else.

Profile::contains

source

fn Profile::contains(self : Profile, other : Profile) -> Bool

Whether every feature of other is a feature of this one.

What "builds on top of" means, as a question that can be asked rather than a claim in a comment.

Profile::features

source

fn Profile::features(self : Profile) -> Array[Feature]

Every feature this profile has, in tag order.

Profile::has

source

fn Profile::has(self : Profile, f : Feature) -> Bool

Whether this profile has a feature. The one question the sieve, the checker and the evaluator ask.

accepted_by

source

fn accepted_by(feature : String) -> String?

Which named profile accepts a form the sieve refused, if any does.

Keyed on the feature STRING the sieve passes to not_yet, because @error.Kind::NotYetSupported already carries it and nothing else names the rule. That is also why this lives here and not in lib/error: a hint about profiles is a rendering concern, and Diagnostic::message is compared against the reference checker's output word for word.

The caller decides whether to show it. A run that asked for no profile should print what it printed before profiles existed.

builtins

source

fn builtins() -> Profile

A profile by the name a --profile flag or a playground selector uses. pending, and a larger set of builtin functions.

Nothing here is syntax: a program written against this profile parses as PurePy and would be refused only for the NAMES it uses. That makes it the cheapest superset to reason about, and the one an embedder most often wants -- three builtins is a small language to write in.

by_name

source

fn by_name(name : String) -> Profile?

core

source

let core : Profile

PurePy exactly as specified: no feature at all, and the default of every function in this library that takes a profile.

A let rather than a fn, as @analysis.empty is, so that the default argument on a dozen public functions allocates nothing.

methods

source

fn methods() -> Profile

builtins, and the non-mutating methods of the builtin types.

The largest superset here, and the one that makes PurePy read like Python rather than like a calculator: ",".join(parts), s.split(), d.get(k, 0).

It does not make anything mutable. Every method it adds answers with a new value, because a Value is immutable and has no identity, so there is nothing a mutating one could write to -- see lib/value/method.mbt.

names

source

let names : Array[String]

Every name by_name answers to, in the order they stack.

pending

source

fn pending() -> Profile

The features upstream has already committed to, as far as they are implemented here.

Everything in it is a form the sieve refuses today with an issue number -- not yet supported (#82) and its neighbours -- which makes it the profile with the least to lose: upstream intends to make these core, so this SHRINKS as each one lands rather than drifting away from the specification.

It grows one feature per commit until it covers the whole table in implementation-plan.md § "After the plan: the pending features". Ask it what it holds -- Profile::features, or pure-py profiles -- rather than assuming a feature from that table is in it yet.