2023-03-10 10:30:54 -05:00
|
|
|
#!/bin/bash
|
|
|
|
|
# Generate DOT representation of TAMER's ASG ontology
|
|
|
|
|
#
|
|
|
|
|
# See sibling `asg-ontviz.awk` for more information;
|
|
|
|
|
# this is just a thin wrapper around it that invokes it with a list of
|
|
|
|
|
# source files.
|
|
|
|
|
|
|
|
|
|
cd "$(dirname "$0")"
|
|
|
|
|
|
|
|
|
|
# We explicitly filter files in this directory to ensure that the expected
|
|
|
|
|
# ontological definitions (`object_rel!`) are actually present,
|
|
|
|
|
# because otherwise they were moved and we need to update the path.
|
|
|
|
|
# This is enforced by the script.
|
|
|
|
|
#
|
|
|
|
|
# So, to be clear:
|
|
|
|
|
# do _not_ do something like `grep -rl 'object_rel!' ../src/asg`.
|
tamer: src::asg::graph::object::pkg::name: New module
This introduces, but does not yet integrate, `CanonicalName`, which not only
represents canonicalized package names, but handles namespec resolution.
The term "namespec" is motivated by Git's use of *spec (e.g. refspec)
referring to various ways of specifying a particular object. Names look
like paths, and are derived from them, but they _are not paths_. Their
resolution is a purely lexical operation, and they include a number of
restrictions to simplify their clarity and handling. I expect them to
evolve more in the future, and I've had ideas to do so for quite some time.
In particular, resolving packages in this way and then loading the from the
filesystem relative to the project root will ensure that
traversing (conceptually) to a parent directory will not operate
unintuitively with symlinks. The path will always resolve unambigiously.
(With that said, if the symlink is to a shared directory with different
directory structures, that doesn't solve the compilation problem---we'll
have to move object files into a project-specific build directory to handle
that.)
Span Slicing
------------
Okay, it's worth commenting on the horridity of the path name slicing that
goes on here. Care has been taken to ensure that spans will be able to be
properly sliced in all relevant contexts, and there are plenty of words
devoted to that in the documentation committed here.
But there is a more fundamental problem here that I regret not having solved
earlier, because I don't have the time for it right now: while we do have
SPair, it makes no guarantees that the span associated with the corresponding
SymbolId is actually the span that matches the original source lexeme. In
fact, it's often not.
This is a problem when we want to slice up a symbol in an SPair and produce
a sensible span. If it _is_ a source lexeme with its original span, that's
no problem. But if it's _not_, then the two are not in sync, and slicing up
the span won't produce something that actually makes sense to the user. Or,
worse (or maybe it's not worse?), it may cause a panic if the slicing is out
of bounds.
The solution in the future might be to store explicitly the state of an
SPair, or call it Lexeme, or something, so that we know the conditions under
which slicing is safe. If I ever have time for that in this project.
But the result of the lack of a proper abstraction really shows here: this
is some of the most confusing code in TAMER, and it's really not doing
anything all that complicated. It is disproportionately confusing.
DEV-13162
2023-05-04 12:28:08 -04:00
|
|
|
find ../src/asg/graph/object/ -maxdepth 1 -name '*.rs' \
|
2023-03-10 10:30:54 -05:00
|
|
|
-a \! -name 'rel.rs' \
|
|
|
|
|
-a \! -name 'test.rs' \
|
|
|
|
|
| xargs awk -f asg-ontviz.awk
|