2026-08-14 –, Room 2
With this talk, GoMeta will be released. This package finally implements a vastly matured offspring of a [my] half-baked idea proposed at JuliaCon2025.
The core concept remains the same: Add interpretable meaning to comments within a Julia file by means of brief, simple, expressive and extendable metadata. The crux of the idea lies in its potential to serve a wider variety of different packages and even facilitating interactions between them.
However, in order to truly fulfill what had been promised, in particular to allow for the desired expressiveness and extensibility, language-like features had to be incorporated in the proposed schema.
Moreover, metadata needs to be absorbed, i.e.: parsed and interpreted, from somewhere before it can be applied somewhere. Thus far, both tasks had been executed on a Block-level [a section of consecutive lines]. BLS now provides a distinctly finer granularity by introducing Components such as Block, Line and Segment. This not only necessitated a complete overhaul of GoMeta's implementation but also of the grammar being used.
The primary aim of this talk is to motivate embedding formalized meaning into a Julia file's comments by example. The same principles are easily extended to other programming languages or project data in general. These illustrations go hand in hand with the introduction of GoMeta.
GoMeta handles the metadata. However, before it can begin its work, BLS reads the file[s], extracts features of interest and records them in a tree-like structure based on the content at hand. The basic building block of the aforementioned structure consists of the Component. Blocks, Lines and Segments are all Components at different levels in the hierarchy. The records include where a Component starts and ends, its flavor [to avoid the term Type] such as code, metadata or text, its place in the tree structure and much, much more.
Next, GoMeta absorbs, i.e.: parses and interprets, the metadata stored in the corresponding Components. The result can then be passed to a separate program or plug-in. At this point the question may arise: What would such a program or plug-in possibly use this for? What can actually be gained from embedding formalized metadata within comments?
To address this question, before continuing with the technicalities of GoMeta, lets consider four, seemingly unrelated use cases which together ought to resonate with the vast majority of JuliaCon's attendees:
Over time a large number of Julia files can accumulate. Wouldn't it be wonderful to speedily retrieve any desired, long forgotten poignant example, powerful code snippet, insightful explanatory statement or laboriously tweaked plot related to some task at hand? Adding meaning to content can change the game. On top of that, an instrument solving this problem might prove even more invaluable when collaborating in a group sharing a repository of documents and it is also not restricted to Julia files only.
One might want to [inter]link a certain fragment of one file with another fragment, possibly contained in some other file. E.g.: linking an intricate piece of code to an enlightening explanation or a clarifying toy example. Occasionally it could also be handy to swap entire sections of text / code of one file with alternate versions, depending on the circumstances.
Would you like to harness the power of
Documenter, enjoying simplified control while sticking to pure Julia files rather than having to deal with additional markdown documents? More generally, a Julia file can serve as a source for all kinds of outputs.Being able to control how individual blocks of code / text are being executed, respectively rendered, can be beneficial. E.g.: certain passages of a file might be intended for personal usage only. Marking them as such would allow automated removal before sharing.
GoMeta's own source code, available onGitHub, has been processed this way. Another example is the ability to restrict execution to code blocks pertaining to a particular group only.
Similar to Literate & Co., segments of code and text can live happily together, weaved into the same files. These serve as source files which can subsequently be converted into a variety of formats such as notebooks, standard markdown or even documenter markdown files. A suitable system for metadata allows exerting precise control over these format's wide ranging capabilities from within the Julia source file and provides the means to generalize Literate's core idea and more. The concept extends well beyond Julia and can be applied not only to other programming languages but to all sorts of text documents such as lectures notes or any number of scripts concerning a project, research or otherwise.
So what does the proposed schema for metadata look like?
Any line starting with #~ is considered to be a metaline i.e.: it will be processed as metadata. Contiguous metalines constitute a coherent block of metadata separating it from others. By positioning such a block just above a block of code or text [no vertical spacing in between] the former gets attached to the latter – similar to how docstrings get associated with Julia structures following them. For the purpose of inheritance, a hierarchy of blocks of metadata can be defined by appending additional ~s to the head of a metablock's first metaline or, alternatively, adding there a digit representing the desired depth within the metahierarchy.
All this is readily exemplified by a self-explanatory toy example. It is contained in the GoMeta folder together with instructions and additional tools revealing some insights into the package's inner workings.
The first three lines in the code below form a Block of metadata at level 1. The optional {} following hide on line 1 allows the user to specify conditions under which hide may get applied. In this case, a Block, say aBlock, inheriting from it will be hidden, if it has been attributed :label4 or is a code Block provided there is no opposing statement closer to aBlock overruling it. Analogously, :label1 gets assigned to anything which inherits from this first meta Block, if it is text and containsMeta or is itself meta, provided there is no other statement closer by, overruling this.
#~ hide{ :label4 , isCode } ## This is a comment within a `Block` of meta.
## The above `Line` of meta initiated this `Block` of meta.
#~ :label1{ (isText && containsMeta), isMeta } ## This meta `Block` ends here.
# This `Line` of text starts a new `Block` of text.
# This `Block` is NOT attached to metadata - it does NOT INHERIT metadata.
# However, this `Line` will get discarded due to this: #~ discard
#~2 :label5 show{ !:label5} ## This is line 9. It is a one-line meta `Block`.
using Plots ## This `Line` starts a new `Block` of code.
## This code `Block` is ATTACHED to metadata - it inherits metadata from above.
## Therefore, this code `Block` receives label5.
## `show` from line 9 above does NOT get applied to this `Block`
## as this can only happen
## if label5 has NOT been applied. Note `{!:label5}` following `show`.
## Instead, this code `Block` inherits `hide` from line 1 above
## since this is a code `Block` satisfying the condition `{isCode}` following `hide`.
println("!!! NOTE !!! Only Code and Text `Block`s may contain empty lines.")
println("\t Whereas an empty line after a meta `Line` starts a new `Block`.")
#~3 :label4 discard{:label3} :label3
# This `Block` of text receives label4
# plus label5 from further above
# plus label1 since it `isText` AND `containsMeta` [see last statement of this `Block`].
# `discard{:label3}` has NO effect here
# since label3 has NOT been applied yet,
# it gets added only after `discard{:label3}` has been issued.
# Instead, it gets "hidden" due to its label4 and `hide{:label4}` on line 1.
# This `Line`, however, will NOT get hidden. #~ show
#~2 :label5 ## This one-line meta `Block` is at level 2.
## Thus, this meta `Block` inherits only from the first meta `Block` at the top.
md"""
This is a `Block` of markdown text. #~ hide
"""
The alert reader may have noticed that this example alludes to the possibility of a finer grained grammar. For instance, a Segment of metadata within a Line is applied to the Segments preceding it. This also applies within Blocks which are not attached. However, a more thorough discussion of the matter is beyond the scope of this proposal.
More importantly though, GoMeta does not execute the instructions inscribed in the metadata. Instead, it provides additional functions and other packages with the means to do so. The source code for GoMeta available on GitHub has been stripped of all tests and non-essential print statements as well as personal notes and metadata by applying one single, simple function using the output of GoMeta. Conversely, these discarded entities can easily and selectively be re-integrated if so desired.
It is worth pointing out, that the vocabulary of instructions used in the example above has been restricted to a bare minimum for the purpose of illustrating the concept. Due to the modular design of GoMeta it is easily altered, extended and enables future contributors to integrate their own types of metadata. Moreover, () are used for argument passing. But again, a more thorough discussion of the matter is beyond the scope of this proposal.
In the near future, AI will automate much of the labeling in the background. Crucially, if this black box is confined within a formalized framework of metadata, intermediary steps can be systematically recorded, making the process not only better traceable but allowing for subsequent adjustments, if necessary – potentially enabling the agent to improve over time.
Profile stuff will follow :-)