search

bazelbuild / starlark

Starlark Language
Apache License 2.0
2.48k stars 163 forks source link

spec.md minor self-contradiction on scope of `load` statements #227

Open eqvinox opened 2 years ago

eqvinox commented 2 years ago

From current spec.md:

https://github.com/bazelbuild/starlark/blob/3d97ad778123d9267be19375a2a412a21599da69/spec.md?plain=1#L1344-L1359

a and b are listed as both module-scoped and file-scoped, which isn't exactly possible. I'm assuming this is an oversight with the https://github.com/bazelbuild/bazel/issues/5636 change and a and b should simply be removed from the module scope list? (I'm not fully aware of the history here but it seems like load-imported names have been changed to not be re-exported…)

adonovan commented 2 years ago

The correct wording can be found at https://github.com/google/starlark-go/blob/master/doc/spec.md#name-binding-and-variables, which was updated in https://github.com/google/starlark-go/pull/178. A similar update needs to be applied to bazelbuild.

eqvinox commented 2 years ago

The correct wording can be found at google/starlark-go@master/doc/spec.md#name-binding-and-variables, which was updated in google/starlark-go#178. A similar update needs to be applied to bazelbuild.

Easy enough, thanks for the quick confirm :+1: — was about to open a quick PR but then noticed the CLA requirement, so, uh, apologies, not gonna do that as I don't really expect to become a contributor. :disappointed:

(I'm also slightly alarmed by the existence of multiple slightly-different variations of what seems to be 99% the same spec? Is the one in starlark-go more up to date?)

adonovan commented 2 years ago

(I'm also slightly alarmed by the existence of multiple slightly-different variations of what seems to be 99% the same spec? Is the one in starlark-go more up to date?)

The Go implementation and its docs came out of an effort to build a reference implementation and derive a sensible language spec. It identified a number of places where the Java implementation (used by Blaze) did not match the ideal semantics; many of those have since been fixed. The bazelbuild copy of the document was copied from the Go one, and the portions of the spec that the Java implementation did not implement were deleted without further ado. In an ideal world they would have been flagged as missing features and the two documents converged. The Go implementation and its document are closer to what I think we all agree are the ideal semantics; the Java implementation still lacks in terms of string encodings and support for byte strings. The team has been too short-staffed to spend more time on implementation and documentation convergence recently.