Devlog

These are my daily notes and internal conversations during development. They may be helpful to understand the larger context of decisions that were made, and how I learned and explored while building.

Devlog < 2023 < February < 21

| by date | | thread: collect |

Yesterday’s explorations were helpful but messy. Some of the main issues so far are around “what are the actual components of this syntax?”. Honestly almost everything is a “function” which expects a number of arguments. One of the gotchas is that some of the arguments are just plain text strings which can usually have spaces and frequently also have new lines, making c style function notation a little awkward.

Thinking about this more, a lot of these are not actually functions, but flags or commands, with parameters. Most of this syntax is for defining data structures (map schema, map instance, map renderer, collection query), but there is also need to wrangle plain text strings. The plain text strings have two main forms, short “inline” strings, and larger “block” strings. They are functionally equivalent, but mainly exist for concision. The last weird part is that I want to mix in small bits of logic, especially around cases for the previous and next elements in the collection. I want to be able to test for and branch on first/last cases, and to also fetch parameters inside the prev/next elements.

Went on a walk to think about this, and really just feel like the core thing to consider is the ability to provide bare minimum tools for building collections and iterating through items. Structuring data as string->string maps is easy, and not worth a lot of attention. When querying, we are only going to worry about group information, so only membership in the group and its index. The other thing we want to do is render a collection into text; this means that for each element in the collection, we will pass the map into a renderer and append all the outputs together into a string. The last thing is that we want to use some conditions, like has-previous or has-next when rendering an element, or things like is-empty when rendering the collection. This also brings up the fact that there may be nested renderers, where an entire collection is being rendered, and inside that there is an element, and an element contains a list. I believe that this may be as deep as is allowed, though… is that valid? Can an element contain other elements? That sounds like a nightmare. Assuming that that’s it, we have query-renderer, map-renderer, and text-renderer, taking in a collection query, a map element, and a text string respectively.

query renderer:

map renderer:

text renderer:

So a renderer has a scope bound to a “self/this” concept, and a collection can only invoke map renderer, and a map renderer can only invoke text renderers. Maybe you use values via ‘$.key’ (or just ‘$’). What about conditional branching?

					@query-renderer(rend-name, query-name)
				
	@main
	Here is my content:
		@render-element(rend-name)
	@close
				
@end
				
@map-renderer(rend-name, map-type)
section: $.title
	$.author @render-text(rend-name, $.tags)
	$.content
@end
				
@text-renderer(rend-name)
^|u|
@end
				

Okay, as I started writing out that last bit, I realized that I might want to access the next/prev items in different groups, even outside of the currently queried collection. We can maybe solve this by adding a group name parameter to the next/prev functions, but how does the context of a map element pass around? I guess every text renderer must be run inside a map renderer, so the context could be implicitly passed in. Does this become too unreadable?

I also still haven’t figured out branching should work.

---

Was just reading about lisp conditionals, perhaps that could work?

					@text-renderer(next-bar)
				
	@block(prev)
	@cond(@has-prev(@($.group))) @lit({prev}(a|href=“@(prev.id)”))
	@cond(default) @lit()
	@end
				
	@block(next)
	@cond(@has-next(@($.group))) @lit({next}(a|href=“@(next.id)”))
	@cond(default) @lit()
	@end
				
	@main
	@insert(prev) | @($.title) | @insert(next)
	@end
				
@end
				
| thread: collect | | by date |