This does a mass rename of:
- `SourceLoc()` -> `source_loc()` for property naming
- `loc` -> `source_loc_` for underscore+consistency
- Generally changing function args to `source_loc` for consistency
- `Tag()` -> `kind()` for property naming and `Kind` parity
- `tag` -> `kind_` for underscore
Also renames `Pos` and `Results` on `Action`. These are a bit of an exception in that most base classes only have `Tag` and maybe `SourceLoc`, whereas `Action` has a little more. I felt okay having `source_loc()` and `kind()` on the base class where children do `Exp()` and the like, but it felt weird to me to mix it on the same class.
The reason for doing this cross-class in one PR is so that I can do it efficiently with a global replace in the codebase, rather than e.g. changing `Expression` but having to read through compiler errors to determine where it's calling `Expression`'s `Tag` versus a different `Tag`. The end result should be equivalent.
This enables the interpreter logic to express its intent more directly, especially in the common cases, and enables us to get rid of ValAction. It's also a step toward simplifying and encapsulating `state->stack`.
This also eliminates the ctad wrapper for Stack: I think the leaning is to remove it. It felt worth keeping the constructor because constructing with a single element is a common use-case.
Adds a single-argument constructor for Scope because the `std::list<std::string>()` is common, and eliding it is consistent with what we've done for things like tuples.
I was considering a vector constructor due to the double-Push on line 1139, but thought the Push() semantics may mean that it's better not to provide.
`Pattern` is intended to pilot some changes I would like to apply to all our sum types:
- The alternatives are expressed as derived classes rather than members of a `std::variant`.
- The alternatives are classes in the [style guide sense](https://google.github.io/styleguide/cppguide.html#Structs_vs._Classes), meaning they can have invariants, but can't have public data members.
- Creating an object is expressed using a constructor rather than a factory function.
- Accessing an alternative is expressed as a cast (using LLVM's RTTI system) rather than `std::get` or a `Get` method.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
I was looking for something like this, I think it's a straightforward simplification for code. Internally, it handles skipping the separator on the first print.
See the bottom of: https://llvm.org/doxygen/StringExtras_8h_source.html
- Switch code to llvm::raw_ostream as part of standardizing output forms.
- Preferring llvm::raw_ostream over std::ostream because other tooling code should be expected to rely on llvm more closely, and an overall preference towards library consistency.
- There are a couple spots in syntax/ that still use std streams, but I'd prefer to take a separate PR to see how best to address those.
- std::boolalpha doesn't work with llvm, so I've implemented equivalent in a couple places (not enough that it felt like worth making a helper function).
- Implement Print(ostream) as consistently as we can, as an instance member.
- This facilitates the use of the common/ostream.h template to provide operators.
- Preferring this approach so that Print is easily accessible via gdb, per suggestion on #executable-semantics.
- Switch code currently calling `type->Print(ostream)` to instead do `ostream << *type`.
- Remove the unused `PrintTypeEnv`, nothing used it and the declaration didn't match the definition.
- Move Heap and Frame/Scope to their own headers.
- Move some functions to more appropriate headers (e.g. CopyValue -> value.h).
- Define a separate Bazel rule for each header/cpp pair.
- Modify PrintValue to not print the frames of a ContinuationValue. This was necessary to break a dependency cycle between PrintValue, PrintFrame, and Action::Print.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
We will eventually need the ability to materialize temporaries eventually, but we don't really seem to need it yet, and when we do, I think we should do it in a way that gives uniform treatment to temporaries and local variables.
* moved most of logic from HandleValue into the Step functions
* removed the HandleValue function
* added some comments
* responses to Geoffrey
* move increment of act->pos out of the step logic for value actions
* changed act->pos to start at 0 and not have any gaps
* Update executable_semantics/interpreter/action.h
Co-authored-by: Geoff Romer <gromer@google.com>
* update comment based on Geoffrey's suggestion
Co-authored-by: Geoff Romer <gromer@google.com>
Making Values const allows us to separate the actual mutations (search for "*&" in this change) from places where the Value is effectively passed by-value.
* improve abstraction for AssocList, fix bug in optional else
* add flag for tracing output, clean up code for output
* turned off tracing by default, updated goldens, removed two examples that use pointers, shouldn't have been there yet
Replaces low-level uses of `Cons` with a first-class `Stack` data structure. Also removes an unused algorithm.
Co-authored-by: Jeremy Siek <jsiek@indiana.edu>
Possible next step: use `std::stack` instead.
Notes versus what jsiek wrote:
- This adopts Bazel for building.
- System-local versions of bison/flex are used. I found https://github.com/jmillikin/rules_bison, but those print a lot of warnings (things like -Wsign-compare IIRC) which makes builds hard to read. Plus I think the underlying bison_cc_library rule didn't work, so this would really only get a hermetic bison/flex build (helpful, but didn't seem worth more time).
- I'm adding in a .bazeliskrc to push a somewhat more standard choice of bazel versions. I noticed I was getting unstable versions by default, possible Google-specific, but seemed good to include.
- The `-lpthread` kludge.
- Turn all of the examples into golden tests.
- Including adding a golden test rule.
- Fixed various style guide issues. For example:
- Fixing function names to be CamelCase instead of snake_case (https://google.github.io/styleguide/cppguide.html#Function_Names)
- Removed exception use (https://google.github.io/styleguide/cppguide.html#Exceptions)
- File name fixes (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/cpp_style_guide.md#file-names)
- Dropped `using` of `std` names -- I believe this is preferred (maybe we should be explicit about this in the Carbon style guide)
- Switched `enum` uses to `enum class` for ease-of-identification.
- Spent some time breaking out files to hopefully be easier to read/edit pieces, and understand relations between structs.
- Added `code requires` to `syntax.ypp` to address include issues
Possibly other things -- but the fundamental structure is, I believe, unchanged. I put in the golden tests pretty early to ensure I wasn't mutating output/results.
Geoff RomerandJon Meow
Jeremy G. SiekandGeoff Romer
Dave Abrahams