UDL2

[arg0d]

The current UDL syntax is awkward in some cases, and the UDL parser is straight up hostile towards the user. The goal of this post isn't to provide a final proposal, but rather to concentrate discussions about the following problems in a single issue, and possibly refine some kind of action plan.

While the current UDL syntax itself is rather straight forward, it's quite foreign when considering that UDL goes hand in hand with writing Rust code. I propose to overhaul the UDL syntax completely, in order to bring it more inline to Rust syntax and make it feel more native.

• rename certain types/keywords to match Rust, e.g.
  • dictionary -> struct
  • string -> String
  • sequence<> -> Vec<>
  • record<> -> HashMap<>
  • T? -> Option<>
  • etc..
• invert variable name and type order, i.e. String name -> name: String
• invert function/method return type declaration, i.e. String hello_world() -> hello_world() -> String
• separate "flat" enums and enums with associated data into distinct types, i.e. enum for "flat" enums, and union for enums with associated data.
• etc..

The current implementation of UDL parser does not generate useful error messages, making it hostile towards users, especially new ones. Making basic syntax errors, such as missing semicolons, or misplacing comma, generates unhelpful error messages, leaving the user scratching their head and wasting time and energy to manually figure out what is wrong with the syntax in their UDL. Solving this issue requires a different parser, one that would generate clear and helpful error messages. The use of a different parser could be implemented as a standalone feature, without revamping UDL syntax.

With the proc-macro related changes to enable creation of ComponentInterface while still supporting UDL, I feel like implementing/supporting adjacent implenentation for UDL2 syntax/parser should be quite easy. My current working idea is to use lalrpop to implement a new syntax and parser. From what I've seen, parsers implemented using lalrpop look really lean, and I believe that this would make it trivial to support UDL2. I'm gonna try to find some time to create POC, and come back to this issue with some working code.

Does this sound like something you agree with?