This is the mail archive of the guile-gtk@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: g-wrap and guile-gnome/gtk


Rob Browning <rlb@cs.utexas.edu> writes:

> Marius Vollmer <mvo@zagadka.ping.de> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]