From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Vollmer To: Rob Browning Cc: guile-gtk@sourceware.cygnus.com Subject: Re: g-wrap and guile-gnome/gtk Date: Wed, 15 Nov 2000 06:42:00 -0000 Message-id: <87aeb171wr.fsf@zagadka.ping.de> References: <20001111173022.14524.qmail@nwcst322.netaddress.usa.net> <87lmuqnud4.fsf@zagadka.ping.de> <87lmupf7je.fsf@raven.localnet> X-SW-Source: 2000-q4/msg00028.html Rob Browning writes: > Marius Vollmer writes: > > > Build-guile-gtk is still a one-off hack and needs to be redone > > completely to make it reasonably clean. This includes the syntax > > of the defs files themselves, but hopefully we can clean that up > > in a backward compatible way because they are already defs files > > out there that are distributed independently from guile-gtk. > > Well, since everything's just scheme forms, and since the .defs > files aren't even allowed to be general scheme syntax, this should > be easy. We could probably even just write a translator script that > was nothing more than a set of guile macros that rewrote and > "displayed" their contents as g-wrap specs. Hmm, I'm more leaning towards keeping the existing syntax of the defs files and using g-wrap as a back-end. The defs file syntax is quite specialized and not really general but that's actually a feature, I think. With a specialized syntax, tzhere is less opportunity for making mistakes and it's easier for people to add their own things confidently. And when a defs file is just Scheme code, people can > always fall back to the g-wrap features when the need arises. > One thing we might want to decide is if it's OK that the API spec > files are just scheme code. Yes, I think that's the right thing. > G-wrap handles it that way right now, but that could be changed. > Allowing arbitrary scheme code does have its advantages since it's > really easy to do things like conditional inclusion, and other > things you haven't thought of, and so I tend to favor it, but it > also has its weaknesses (like making it harder to spot and flag > syntax errors), so I'd certainly be willing to consider the issue. Reporting errors is a challange, but I think we can make that work. Maybe Guile needs to be changed a bit, but this problem should be quite general. For example, I have a simulator that uses Scheme as its description language and I want to report errors in user code in a nice way. I found a way to make this work, but it could be improved with support from Guile itself.