On Feb 23, Guillermo J. Rozas wrote:
>
> On Feb 23, 2009, at 11:08 PM, Eli Barzilay wrote:
>
> > On Feb 23, Guillermo J. Rozas wrote:
> >>>> And why would I do that? Because, presumably, I don't want to
> >>>> re- type the definitions of the library that are already included
> >>>> in a .h file, and I'd rather write a tool that can be used and
> >>>> re-used as the .h file changes, than have to fix things by hand.
> >>>
> >>> (That is a perfectly fine job for a macro, BTW.)
> >>
> >> Parsing a .h file? Boy, I've written hairy macros in my life, but
> >> that's got to be a winner.
> >
> > I don't see why this would be hairier than writing code that parses a
> > header file... After all, this is Scheme, and macros are written in
> > Scheme. (Assuming that you're not restricted by a `syntax-rules'-only
> > implementation.)
>
> No. That's not the point. It's hiding a C parser in a macro that I
> find 'curious' to say the least.
>
> After all, just because you can do something doesn't mean that you
> should.
I don't see any fundamental difference between a "generator" and a
"macro", they both generate code,
> [...]
> And that is not an issue of safety, but of clarity of the code.
and since both produce code in the same way, they're both as clear.
(And BTW, we did do a couple of steps in the last decade. Macros
might still require a license, but they're much more well behaved.
This is regardless of the risk of making code more difficult to deal
with.)
> > Let me repeat it: the original bindings are "foo" and "Bar", since
> > this is all you have, you're likely to go for the simple
> > translation to `foo' and `bar'. Later on the library is extended
> > with a "FOO", and the produced code is no longer valid, since it's
> > missing a proper translation for an all-caps name. *Or* you make
> > the generator detect such cases and adapt -- in that case, the
> > generator saw no clashes before and gave you `foo' and `bar', and
> > now that there is one, it does some automatic tweaking -- thereby
> > breaking existing code.
>
> That assumes that the generator has no history.
>
> It is not hard to feed it its prior decisions, and only introduced
> oddities for new bindings, which, by definition, are not yet in use.
Ah, well you're right that this does solve the problem, but it does so
at the expense of complicating the framework to support it. The least
that you'll need (in practical cases at least) is to make sure that
this file is added to the repository, that the generator (macro or
not) will commit changes to the file when needed (which also implies
that everyone that uses this code better have the same version of the
library). It will also need to communicate with some human to update
the documentation (for example, send an email -- because the tool
might run as part of a nightly automated build) -- or alternatively it
will need to generate the required bits to be used by the
documentation.
That is a *lot* of effort, and in *my* opinion making the language
case sensitive is far easier and more robust (in all aspects). (And
by a lot of effort I mean a wart -- one that is bigger than the
possible wart-ness of case-sensitivity.)
[I expect your opinion to be different here. My guess is that you'll
be fine with all of the above since it deals with a corner case that
you're unlikely to encounter. In contrast, I'm not fine with all of
the above, since if that's the way to deal with foreign code, then I'm
likely to be one of the people who will need to actually implement,
maintain, and use the above mess.]
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
