Grammar for parsing fluid file (.fl) syntax

[Paul Hahn]

Of course I know fluid can parse its syntax. But I am wondering if there is a standardized BNF-style grammar out there for it? By that I mean, the rules not the parser code itself.

Thanks!

[Matthias Melcher]

I am afraid not. The file writing commands are inside wrapper class implementations, many of them using fprintf and fscanf style commands because there is no .fd reader or writer class. All .fd related functions are in Fluid/file.h . `read_word' and `write_word` minimally escape characters with special meanings.

There are read_properties() and write_property() methods for all Types that take care of widget properties. It's probably easies to do a global search on `read_word` to find most of the logic, and `read_file` and `read_children` to see how hierarchies are handled. Not sure if I can convince Backus or Naur to put this into a meta language.

[Paul Hahn]

On Friday, November 4, 2022 at 4:49:50 PM UTC-5 Matthias Melcher wrote:

I am afraid not. The file writing commands are inside wrapper class implementations, many of them using fprintf and fscanf style commands because there is no .fd reader or writer class. All .fd related functions are in Fluid/file.h . `read_word' and `write_word` minimally escape characters with special meanings.

There are read_properties() and write_property() methods for all Types that take care of widget properties. It's probably easies to do a global search on `read_word` to find most of the logic, and `read_file` and `read_children` to see how hierarchies are handled. Not sure if I can convince Backus or Naur to put this into a meta language.

OK thank you for the valuable insights.

Just in case, if some enterprising and bored FLTK master reads this and is inspired to try and write a grammar, then I would ask them respectfully to utilize cpp-peglib . Just asking that selfishly because such a grammar is ideally what I can best utilize (or write myself if I get time). It is also IMHO the easiest and fastest way to create language grammars.

[Matthias Melcher]

I did another round trip into the Fluid code. I am afraid that it is not easy at all to catch all properties for all FLTK Type options. Please try to look at all the write_properties() functions to get an idea. In particular, the use of is_valuator() makes it quite hard to know exactly which properties are available to which widget type.

[Ian MacArthur]

On Sunday, 6 November 2022 at 14:54:34 UTC Matthias Melcher wrote:

I did another round trip into the Fluid code. I am afraid that it is not easy at all to catch all properties for all FLTK Type options. Please try to look at all the write_properties() functions to get an idea. In particular, the use of is_valuator() makes it quite hard to know exactly which properties are available to which widget type.

FWIW, I think this sounds like it overlaps with the thread in coredev: https://groups.google.com/g/fltkcoredev/c/2JA-CcTbrX4/m/GxnUjHOYAAAJ 

 

[Paul Hahn]

I had not seen that discussion in coredev til now, but I agree it involves the same core issue as in my case. To me, in a general sense, that core issue is the ability to transform GUI representations between FLTK and an external system utilizing (or based on, like the fl2rust case) FLTK. I believe a FLUID grammar-based approach to formally describing an FLTK GUI is an effective way to attack the issue, because the same grammar can be realized as different parsers to transform an FLTK GUI into the framework of the external systems (and vice-versa, via system-specific, custom inverse grammars). Again, different parsers for the different external systems, but all able to utilize the same formal FLUID grammar as the basis for the transformations.

Beyond such abstractions, in my case, the concrete of it is my need to implement my own idea of "forms" supported by a specification language that is parse-able by my FLTK-based application. And being that my application is FLTK-based, then what could be better to use for a specification language than FLUID's own?

O course, by comparison, in Qt we can use QML. Shouldn't FLTK be able to "compete" in the same arena?

Bottom line: I want to parse FLUID files without having to do so in some kind of ad-hoc way (like maybe had to be done for fl2rust?)!

[Matthias Melcher]

I agree that having the .fl file format redone in a more professional way would be very nice. This is however a new field to me, and I would not know how to define this serialisation in a good way. But I'll be happy to listen and learn, and see what I can actually implement.

Funny thing about QML which is advertised as a language, but from the little I have seen, contains pretty similar information to .fd file, albeit in an orderly manner. We can't possibly compete with Qt. How many paid developers do the have? ;-)

[Matthias Melcher]

Please check out this file: .fd File Format, and let me know if this is of any use. Feel free to reformat and I will try to adapt.

[Paul Hahn]

On Sunday, November 6, 2022 at 6:03:35 PM UTC-6 Matthias Melcher wrote:

Please check out this file: .fd File Format, and let me know if this is of any use. Feel free to reformat and I will try to adapt.

Looks very good as a foundation. I request that you give me a day or so and I will use this as a basis to try to generate some kind of equivalent cpp-peglib grammar (again, just as a foundation), and report that back here. Thanks!

[Paul Hahn]

OK, I think I perceive better now where you were going with your document. Yes it helps tremendously. I respectfully ask that you please complete it as soon as you can, because the information in it will facilitate me (or anyone else) to create a corresponding grammar -- i.e., not just in cpp-peglib, my preference, but whatever other parser-generateor system someone might want to use.

So if you can complete the document relatively soon, I think that would suffice for my needs (but it needs to become "official" and kept current by the FLTK developer team, naturally!).

[Paul Hahn]

Matthias, I see that you created the file fluid/README_fl.txt in the repository. This appears to be very clear and I believe sufficient for my purposes.

II most sincerely appreciate your work on this! Of course, my thanks also go to your co-author Peter0x44 (per what I see in the git log)!

[Matthias Melcher]

Thanks. I am glad I finally wrote this down, and I found some little surprises myself. Please keep us posted if you build any public parsers and language generators. We voted to not integrate language generation into Fluid, but I have been playing with the idea to allow Fluid to automatically call external generators to make the source code live view window work for other languages too.

The current version of Fluid has now live previews for the .fl file and the i18n strings as well as header and source.

[Paul Hahn]

On Wednesday, November 9, 2022 at 6:30:49 PM UTC-6 Matthias Melcher wrote:

Thanks. I am glad I finally wrote this down, and I found some little surprises myself. Please keep us posted if you build any public parsers and language generators. We voted to not integrate language generation into Fluid, but I have been playing with the idea to allow Fluid to automatically call external generators to make the source code live view window work for other languages too.

The current version of Fluid has now live previews for the .fl file and the i18n strings as well as header and source.

 

I am working on a cpp-peglib grammar based on your new document. I am wondering if there is missing information for properties for Fl_Group? These are referenced at line 454 under the discussion for the properties of Fl_Flex thus: "  ... : inherits more from Fl_Widget (not Fl_Group)". Maybe I am missing something but I cannot seem to locate that information in the document.

[Paul Hahn]

CORRECTION -- I meant at line 440 with text " ... : inherits more from Fl_Group"

[Matthias Melcher]

In Fl_Group_Type:204, Fl_Flex writes group properties with Fl_Group_Type::write_properties(); In line 252, I read them.

As for the comment in line 454 in the README: in Fl_Window_Type.cxx:1518, Fl_Window_Type writes the Fl_Widget_Type properties, but not the Fl_Group_Type properties. Same for the read in 1549.

Footnote to 454: There is only a semantic difference between Fl_Widget_Type and
Fl_Group_Type properties. The virtual method Fl_Group_Type::read_property
is not implemented, so the call falls back to Fl_Widget_Type::read_property.
Same for write_properties. Groups differ from Widgets because they can have
children, but children are not written as part of the properties. If a Type
has children in the Type Tree, Fluid will write them to the .fl file, even
if the Fl_Type is not Fl_Group_Type. A good example is menu based types.
They have no children in FLTK, but the Fl_*_Type write the menu structure
instead. In that respect, Fl_Group_Type is not really special when
writing .fl files.

[Paul Hahn]

On Wednesday, November 9, 2022 at 6:30:49 PM UTC-6 Matthias Melcher wrote:

Please keep us posted if you build any public parsers and language generators.

OK just FYI (only) I have attached a file containing an early but incomplete snapshot of the cpp-peglib grammar I am working on. Again, this is INCOMPLETE and just a momentary SNAPSHOT to give you an idea of my efforts. Note this is grammar code written in the C++ API for cpp-peglib; please see the previously-mentioned github site for the API operator constructs (e.g., "zom" = "zero or more", "seq" = "sequence", ""cho" = "choice", etc.). Note the "G(blah-blah)" in my file are the C++ grammar rule objects which in proper ccp-pegelib correspond to DEFINITIONs (I do not show those).

Note I have not included in this file any C++ parser code handling the semantics -- I am not there yet and it would be mostly proprietary anyway (unless of course I was re-writing fluid's parser for the purpose of making a public contribution, which may happen if I ever get the time!).

Yes my grammar is verbose, because I have chosen to write explicit rules for as much as possible in order to let the parser (TBD) enforce the syntax accordingly. One could write a more terse grammar then build a lot of the rules into the C++ parser code handling the semantics, but for my purposes it is better to have the more verbose, explicit grammar.

[Matthias Melcher]

Amazing! Today I learned a lot about writing a grammar. Thanks!

[Domingo Alvarez Duarte]

Hello Paul !

Thank you for helping improve FLTK !

I'm attaching your grammar converted to "peg" and "EBNF".

The "peg" can be viewed/edited/tested on cpp-peglib playground at https://yhirose.github.io/cpp-peglib/ .

The "EBNF" can be viewed at https://www.bottlecaps.de/rr/ui copy and paste it on the tab "Edit Grammar" then click the tab "View Diagram" to view/download a navigable railroad diagram.

I hope it'll help you in developing the grammar further !

Cheers !

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/45293a5a-e847-4057-89ae-2c0d8decb95dn%40googlegroups.com.

[Paul Hahn]

On Friday, November 11, 2022 at 4:35:04 AM UTC-6 mingodad wrote:

The "peg" can be viewed/edited/tested on cpp-peglib playground at https://yhirose.github.io/cpp-peglib/ .

The "EBNF" can be viewed at https://www.bottlecaps.de/rr/ui copy and paste it on the tab "Edit Grammar" then click the tab "View Diagram" to view/download a navigable railroad diagram.

I hope it'll help you in developing the grammar further !

Cheers !

Thank you so much for your helpful contribution!

Since I utilize C++ so extensively in my work, I am accustomed to writing cpp-peglib grammars using its C++ API, but I think many other developers would probably prefer the "peg" form, at least because it is more portable. And of course they (we) can exploit the cpp-peglib playground you cited.

Your "EBNF" translation is especially noteworthy and appreciated, not only because it is undoubtedly recognizable to a wider audience of developers, but also because you wrote it to be suitable for pasting into Railroad Diagram Generator. In fact, I was not aware of the Railroad Diagram Generator.before this - it is very cool and my first impression is that it fits into that unique category of software that is not only "neat and  cool", but also practical. So I am as of this morning pondering a move to "EBNF". It could speed things up for me in terms of producing a reliable and correct result. But ditto in regards to the "peg" format with the cpp-peglib playground . In either case, I can subsequently back-translate into the cpp-peglib C++ API form.

Thanks again!