X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 7 Feb 2015 11:24:52 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] FOSDEM
In-Reply-To: <C7176C00-0F98-483E-89BA-FE748ACE4B5C@icloud.com>
Message-ID: <alpine.DEB.2.00.1502071054090.7324@igor2priv>
References: <1420499386 DOT 3521 DOT 3 DOT camel AT cam DOT ac DOT uk> <CAGde_xN-iNZUvHh-E47kx1EyoPRt1018wWiDwHhYQ9+od+cJwA AT mail DOT gmail DOT com> <20150203112631 DOT 3507a0c1 AT Parasomnia DOT thuis DOT lan> <20150204054256 DOT Horde DOT Pm1JV8RJbICk9SHvIGwZ7A3 AT webmail DOT in-berlin DOT de>
 <CAOP4iL2stWVCy3WK0=SNu2zAbs8t6B0uyAgFuOnzG8v_MrYNfw AT mail DOT gmail DOT com> <CAGde_xN5gs5r_on=HP2RN7cy6E=2EL9eK3cp+sd9BfBaWNLVew AT mail DOT gmail DOT com> <20150204193720 DOT Horde DOT 42xUN-NzhCJRWZne-M5eCQ1 AT webmail DOT in-berlin DOT de> <90236728-E79D-47C7-BFB1-34140DB85ACB AT sbcglobal DOT net>
 <CAOFvGD4M48Ap=UQzL_T3yzas2rJrNFfxXRUOkOe8gA8J3bQCHg AT mail DOT gmail DOT com> <201502042333 DOT t14NX28o024789 AT envy DOT delorie DOT com> <7C1A5871-3056-482C-BC58-173D90D80F77 AT icloud DOT com> <CAOFvGD7vdircWqDYWKrKPY49gpYo4ZGsw20q9yE+4+gno3ZkhA AT mail DOT gmail DOT com>
 <F66800B5-AAC3-459C-B6BC-B2F1E4AC98CC AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1502061931470 DOT 7324 AT igor2priv> <0BB497A3-1B7E-41FD-A6A3-935EB1259DD9 AT icloud DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1502071002040 DOT 7324 AT igor2priv> <C7176C00-0F98-483E-89BA-FE748ACE4B5C AT icloud DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



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.