cut namespaces

This commit is contained in:
Allen Webster
2021-06-12 10:17:14 -07:00
parent f54f1771b9
commit 0832e601b7
9 changed files with 0 additions and 641 deletions
-1
View File
@@ -526,7 +526,6 @@ struct MD_ParseResult
MD_Node *node;
MD_Error *first_error;
MD_u64 bytes_parsed;
MD_Node *namespaces;
};
//~ Command line parsing helper types.
-130
View File
@@ -2006,83 +2006,10 @@ MD_ParseWholeString(MD_String8 filename, MD_String8 contents)
// NOTE(allen): setup parse context
MD_ParseCtx ctx = MD_Parse_InitializeCtx(filename, contents);
// NOTE(allen): setup namespace structure
MD_Node *namespaces = _MD_MakeNode_Ctx(&ctx, MD_NodeKind_List,
MD_S8Lit(""), MD_S8Lit(""), ctx.at);
MD_Map namespace_table = MD_MapMake();
// NOTE(allen): setup default namespace
MD_Node *default_ns = _MD_MakeNode_Ctx(&ctx, MD_NodeKind_List,
MD_S8Lit(""), MD_S8Lit(""), ctx.at);
MD_PushChild(namespaces, default_ns);
MD_MapInsert(&namespace_table, MD_MapKeyStr(default_ns->string), default_ns);
// NOTE(allen): parse loop
MD_NodeFlags next_child_flags = 0;
MD_Node *selected_namespace = default_ns;
for(;;)
{
// TODO(allen): I don't get it... this can only happen once between
// each normal node?
// It feels to me like the picture of "ParseOneNode" and the full
// parse loop is underdeveloped all around. Namespaces can be in
// the full loop but not the single case. Why? What is the
// justification for that? If a new feature is added to the grammar
// how will we determine if it is or isn't in the "single" case?
// Are we sure there is no way to make sense of a namespace in the
// "single" case?
// If it turns out there really isn't a good way to
// namespace in the "single" case, we still need to think through
// how features that only appear in the full loop will be
// expressed. Right now the answer appears to just be "the loop
// will grow more gnarly with each feature".
// It might be useful to figure out an example of a second feature
// that would make sense outside of the "single" case (if this is
// indeed the right direction for namespaces to begin with).
// Suppose, finally, that there are reasons why we specifically
// want to disallow this in the single case *and* we want to
// disallow back-to-back namespaces, that still doesn't mean we
// want to disallow back-to-back `#` cases, right? And we'd want an
// actual error detection path for that rule too, right? Sorting
// these out "later" makes me nervous.
// NOTE(allen): I've brain stormed some ideas on what it might look
// like to address some of these concerns. Ideas in the comments.
// Search for `Allen's Namespace Ideas`
// NOTE(rjf): #-things (just namespaces right now, but can be used for other such
// 'directives' in the future maybe)
if(MD_Parse_Require(&ctx, MD_S8Lit("#"), MD_TokenKind_Symbol))
{
// NOTE(rjf): Namespaces
if(MD_Parse_Require(&ctx, MD_S8Lit("namespace"), MD_TokenKind_Identifier))
{
MD_Token token = MD_ZERO_STRUCT;
if(MD_Parse_RequireKind(&ctx, MD_TokenKind_Identifier, &token))
{
MD_MapKey ns_key = MD_MapKeyStr(token.string);
MD_MapSlot *ns_slot = MD_MapLookup(&namespace_table, ns_key);
if (ns_slot == 0){
MD_Node *ns = _MD_MakeNode_Ctx(&ctx, MD_NodeKind_List,
token.string, token.string, token.outer_string.str);
MD_PushChild(namespaces, ns);
ns_slot = MD_MapInsert(&namespace_table, ns_key, ns);
}
selected_namespace = (MD_Node *)ns_slot->val;
}
else
{
selected_namespace = default_ns;
}
}
// NOTE(rjf): Not a valid hash thing
else
{
MD_Token token = MD_Parse_PeekSkipSome(&ctx, 0);
MD_PushTokenErrorF(&ctx, token, MD_MessageKind_Error, "Invalid '#' directive \"%.*s\"",
MD_StringExpand(token.outer_string));
}
}
// NOTE(allen): parse the next node
MD_ParseResult parse = MD_ParseOneNodeFromCtx(&ctx);
MD_Node *child = parse.node;
@@ -2093,7 +2020,6 @@ MD_ParseWholeString(MD_String8 filename, MD_String8 contents)
// connect node into graph
MD_PushChild(root, child);
MD_PushReference(selected_namespace, child);
// check trailing symbol
MD_u32 symbol_flags = 0;
@@ -2112,7 +2038,6 @@ MD_ParseWholeString(MD_String8 filename, MD_String8 contents)
// setup next_child_flags
next_child_flags = MD_NodeFlag_AfterFromBefore(symbol_flags);
}
result.namespaces = namespaces;
result.bytes_parsed = (MD_u64)(ctx.at - contents.str);
result.first_error = ctx.first_error;
}
@@ -2747,61 +2672,6 @@ MD_FileIterIncrement(MD_FileIter *it, MD_String8 path, MD_FileInfo *out_info)
#endif
}
// NOTE(allen): Allen's Namespace Ideas
// 1. > '#' handling goes into 'ParseOneNode'.
// > 'ParseResult' from 'ParseOneNode' can indicate that a node is a 'namespace'.
// > The parse loop does all parsing through 'ParseOneNode' first and then
// packages the results into the larger structure in different ways based on
// what came from from 'ParseOneNode'.
//
// Strength: + unify what counts as "valid metadesk"
// + simplify the 'ParseWholeString' loop by driving it with
// 'ParseOneNode' entirely
// Weakness: - boxes us in; we're now committed to all '#' meaning a single node
// - lacks discussion of the difference between '#' at top-level and
// anywhere else
//
// 2. > '#' handling goes into 'ParseOneNode'.
// > Until a non-'#' is consumed, 'ParseOneNode' keeps parsing, and combines all the
// '#' effects it sees along the way.
// > The parse loop does all parsing through 'ParseOneNode' and does not special
// handling of it's own.
//
// Strength: + unify what counts as "valid metadesk"
// + simplify the 'ParseWholeString' loop by driving it with
// 'ParseOneNode' entirely
// + simplify the 'ParseWholeString' loop by taking away any
// responsibility for constructing the result
// Weakness: - boxes us in; we're now committed to all '#' being processed in
// one go without a chance in the API for intervention from the user
// - lots of state handled between calls of 'ParseOneNode' getting
// carried through the context -> likely hard to provide simple APIs,
// more lock in of systems hurting long term maintenance, higher
// likelihood of bugs.
//
// 3. > '#' handling stays where it is
// (except maybe with helper functions involved if that helps anything)
// > We fix the bugs that are there and make things work as they are
//
// Strength: + not a lot of work in the short term
// + no possibility of hidden change in the way namespaces work
// Weakness: - there is no unification between what is "valid metadesk"
// between 'ParseOneNode' and 'ParseWholeString'
// - lacks discussion of the long term maintenance plan for '#' features.
//
// 4. > cut '#' and namespace, reserve '#' as a character for future expansion
//
// Strength: + end up with less code, easy
// + not boxed into any particular direction for '#'
// Weakness: - *may* just be throwing away something we actually want only to
// force ourselves to face this issue again later
// - may have to track down and modify some existing code? (I couldn't
// find much besides our samples, but who knows?)
// Observation: The reasons I wanted namespaces in Datadesk are actually less
// relevant in Metadesk. There is no restriction against name collision.
// I can easily create my own namespace concept if I really need it with
// `@namespace foo;`
/*
Copyright 2021 Dion Systems LLC