Mail Archives: geda-user/2015/02/07/05:26:32
On Sat, 7 Feb 2015, Chris Smith wrote:
>
>> On 7 Feb 2015, at 09:09, gedau AT igor2 DOT repo DOT hu wrote:
>>
>>> On Sat, 7 Feb 2015, Chris Smith wrote:
>>> What is the problem with depending on a Lua interpreter? Please bear in mind that we're not talking about a behemoth like Python or PERL here, with numerous dependencies and files scattered over the system. Lua is a single C library with a simple API, about 50kB in size that can be statically linked if you want. Bindings to other languages of choice are available.
>>>
>>> I think Lua is being skewed in people's minds by the terms 'script' and 'interpreter'. In use Lua behaves much more like an XML or YAML library.
>>
>> The point is simple: some people suggest to have a simple file format with an open spec so anyone can write his own parser. You suggest using an existing language and always link to a specific lib parsing it.
>
> XML is a simple file format with an open spec. Would you write your own parser? I wouldn't, unless I had to. I'd first go looking for a library someone else had already written. The same goes for Lua. The syntax is easy enough that I could easily write my own parser if I wanted to, but why on earth would I?
Would I write my own XML parser? In some extreme situation absolutely yes^1.
In other situations, no. Would I like if some "interchange format" was
designed from ground up assuming one way or the other, effectively making
the decision instead of me? Absolutely no. And this is where our views
differ, you prefer to use a lib and you are willing to make decisions that
would make it harder for other developers to do their part in a non-lib
way.
Writing a full xml parser is hard, because the language is large. I
believe a full lua parser would not be too easy either. To me it seems
lua syntax is much more complex (and powerful) than what I would think is
needed for describing a schematics or a footprint or a PCB. The more
extra features it has over the minimum, the more effort it is to
implement a correct parser.
On the low end of the scale is a minimalistic, "stupid" language that supports
the bare minimum that is absolutely needed for describing the data you
want to store. On the other end of the scale is a huge language that
features 10000 things you won't ever need but have to implement in order
to stay on the safe side (because some other user did use it in one
footprint or will use it in the future).
Your examples, lua and xml, are in between.
The current file formats for PCB and gschem are in between too, but (in my
opinion) very close to the low end, and definetly closer to the low end
than to lua.
Choosing the right magnitude on this scale matters a lot and has many
other aspects as well:
- going too low or too high may affect how easy the file formats
are edited by hand; I do understand how easy it is to parse gschem's
format, but I don't find it easy to edit using a text editor, I believe
because it's too low on this scale (it's also question of taste, don't
want to trigger a flamewar); an example of a too high is probably an svg
exported from inkscape, which is nice and structured, but simply too large
to handle with a text editor
- going too low may affect extensibility; while i really like PCB's
format and find it easy to use with scripts and text editors, I believe
PCB suffers from this problem. Some features proposed would require such
change in the format that would make it incompatible with previous
versions. Going too high may make you spend too much time/bytes on
administration and the actual data is lost in excess housekeeping garbage.
What I am trying to say is rushing into lua only because liblua is small
and nice and the language clearly supports what we need (and more) and
"why would I ever want to write an interpreter/parser for anything
anyway" is probably not the best strategy. I personally would look for
something smaller and would explicitly assume some people will want to use
libs while others will want to write their own parser. I would try to
keep features of the language to a minimum that provides enough
flexibility but allows simple "grep like approaches" to work (don't take
this literally). And I would definetly try to go for a solution that
makes both "want to write my parser" and "want to use a lib" developers
happy.
Maybe a well defined subset of lua syntax would fit in that view, if it
could be guaranteed that lua interpreters can warn the user if the file
starts using features over the subset.
Regards,
Igor2
footnotes:
^1 I'm a programmer in my daytime job. Over the past decade, I've seen
many examples of people writing their own parsers for different languages,
and/or subsets of languages, even for xml. Some of these efforts were
totally unreasonable and I would have used an existing lib. Others were
reasonable - or even so reasonable that using an existing lib would have
not worked at all.
- Raw text -