[kwlug-disc] Modern way of doing Lex/Yacc

[Mikalai Birukou]

> I'm not tied to C.  Yes, "domain specific language".  Input data would 
> come from users.  If the data is "passive", then I can require well 
> known format (eg. JSON).  I run the parser library, then do the 
> business logic.
> Eg.
>     - read from sensor and append it to file or upload to URL.
>     - post amount to this account and that account.
>
> In reality, data doesn't stay "passive" for long.  Soon, they want 
> conditional, loop, function, etc.
> Eg.
>     - if this, then do something.
>     - do job #10 to job #20.
>
> How do you express these in JSON format?  Maybe
>     "cooling": {
>     "temperature_set_to" : 25,
>     "exec" : "air_conditioner.exe"
>     },
>     "heating": {
>         "temperature_set_to" : 15,
>     "exec" : "furnace.exe"
>     }
>
> I don't want to write, test, and debug parsers.  I want to concentrate 
> on business logic.  That's why I asked.
>
> I mean, this kind of thing is everywhere:
>     - Every printer run its own command interpreter.
>     - Awk, Sed, Shell are specific interpreters for line texts.
>     - bc, dc are calculator interpreter.
>     - Even systemd unit file is descriptive script, which systemd 
> parses and executes.
>
> They all have their own business logic, but also they all run parser 
> at the front.


And they will ask you for syntax highlights, and type checking, i.e. IDE 
experience, .... for a thermostat.


>> Since you mention Lex/Yacc/Flex/Bison, do you specifically require 
>> this to work in the C language, or are you open to using a more 
>> modern/expressive programming language?
>>
>> It sounds like you want to create a "domain specific language" (DSL). 
>> Is this DSL going to be used only by the developer (inside the 
>> application code), or is it supposed to be used by users (to 
>> configure/customize the application)?
>>
>> Doug.
>>
>> On Tue, Jun 21, 2022, at 11:37 PM, William Park via kwlug-disc wrote:
>>> To Computer Science guys,
>>>
>>> You come across a situation that calls for little "embedded 
>>> interpreter"
>>> solution.
>>>       - You can use already existing embedded interpreter like Tcl or
>>> Lua.  But, these bring their own baggages.
>>>       - Or, you can use Lex/Yacc (or Flex/Bison) solution which you
>>> studied in school.  For simple situation, this may be the way to go.
>>>
>>> But, I'm curious.  Is there something more modern?  Something that
>>> leverages 40 years of collective experience in software development.
>>> Something more than "state machine", but less than full "interpreter".
>>>
>>> ____