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.

Sign up for GitHub

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

Jump to bottom

Clarify note about eager vs. lazy evaluation #901

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
+19 −0
Open

Clarify note about eager vs. lazy evaluation #901

Changes from 10 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
1d89191
Clarify note about eager vs. lazy evaluation
catamorphism Oct 8, 2024
519d5dd
Update spec/formatting.md
catamorphism Oct 8, 2024
d74ea7e
Avoid using 'may'
catamorphism Oct 8, 2024
f87e643
Add language about writing vs. reading mutable state; add note that f…
catamorphism Oct 8, 2024
61a4bd2
Try again
catamorphism Oct 8, 2024
648d365
Update spec/formatting.md
catamorphism Oct 9, 2024
cda3e57
Split the addition into a normative part and an editorial part
catamorphism Oct 9, 2024
1fb1c73
Fix NOTE markup
catamorphism Oct 9, 2024
4d5f4fe
Fix markup again
catamorphism Oct 9, 2024
bf1cb2f
Update spec/formatting.md
catamorphism Oct 10, 2024
2d152c4
Make language stricter and say that call-by-name is forbidden
catamorphism Oct 21, 2024
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
18 changes: 18 additions & 0 deletions spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,24 @@ nor be made available to _function handlers_.
> _declarations_ affecting _variables_ referenced by that _expression_
> have already been evaluated in the order in which the relevant _declarations_
> appear in the _message_.
>
> Implementations and users SHOULD NOT create _function handlers_
> that mutate external program state,
> particularly since such a _function handler_ can present a remote execution hazard.
>

> [!NOTE]
>
> Function handlers can also be written that depend on external mutable state
> (for example, the current date and time).
> Lazy evaluation might involve evaluating the same _expression_ multiple times
> (call-by-name) or evaluating every expression at most once (call-by-need).
Comment on lines +72 to +73
Copy link
Collaborator

@gibson042 gibson042 Oct 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really think it's a mistake to allow the same expression to ever evaluate to a different value inside a single message formatting operation. This is something that CEL (to pick a roughly analogous technology) gets very right.

> In the presence of custom function handlers that either depend on or modify
> mutable state external to the message formatter, this implementation
> choice affects the result of formatting a message.
> If all function handlers return a result that depends only on their _operand_
> and _options_, then the choice of evaluation strategy has no effect
> on the result of formatting a message.

## Formatting Context

Expand Down