Language changes out of new resolver?

[max-sixty]

What's up?

Is it worth discussing the language changes that we'll need to make from the new resolver?

@aljazerzen briefly spoke on a call a few weeks back, possibly with an idea of requiring a prefix on local variables. I've also had thoughts about requiring some data references to have a prefix of ., similar to jq, as part of establishing a more formal notion of scope.

To the extent those are going to be big changes, is it worth discussing them before implementing things in detail?¹

Footnotes

1. OTOH I'm also hesitant about saying "we have to agree on everything before anyone starts writing code", given our main constraint is writing our complicated code rather than having discussions. But for big changes I do think it's worth covering the tradeoffs... ↩

[aljazerzen]

Sure, I can list them here, but I don't think they are worth discussing.

I'm not advocating for these changes to be merged into the language, they were just in the way of me making progress. After my current work is done, maybe I can re-implement workarounds so there changes are not necessary.

1. references to variable definitions require fully-qualified paths, that must start with one of:

   • project (reference to the root of the module tree, analogous to crate in Rust),
   • module (reference to current module),
   • db (for accessing project.db, the default database modules),
   • std (for accessing project.std

   Example:

   let a = 5
   
   from db.x
   select {module.a}

   Any identifier without these prefixes is treated as if it had this. prefix.

2. table names don't make it into tuples
   (when instantiating a relation, its name is not injected into its type)

   from employees
   select {employees.name}
           ^^^^^^^^^ Error: unknown name `employees`
   
   Hint: available names are `employee_id`, `name`, `age`.

3. forbid references to fields of current tuple
   (when declaring tuples, field expression cannot refer to previous fields)

   from x
   select {a, b}
   select {
      c = 1,
      d = c + 1 # Error: unknown name `c`. Available names: `a`, `b`
   }
   

4. x.a will infer name a only

   from employees    # type: [{name = ...}]
   select {e = this} # type: [{e = {name = ...}}]
   select {e.name}   # type: [{name = ...}]
   select {e.name}   # error: unknown name `e`
   

[max-sixty]

I'm not advocating for these changes to be merged into the language, they were just in the way of me making progress. After my current work is done, maybe I can re-implement workarounds so there changes are not necessary.

OK! Definitely no need to discuss if not yet helpful + no irreversible decisions.

Thanks for outlining them all the same!