extent strings
Alastair Reid
reid at cs.utah.edu
Mon May 14 17:21:45 EDT 2001
As the extent strings acquire more structure, I'm starting to wonder
if encoding the information in strings is the right approach. What's
the advantage of putting the information in a string?
1) All Haskell parsers will be able to read any ffi-ified code even
if they don't support the language binding the ffi supports.
But what does this achieve if the compiler backend doesn't support
that ffi?
2) Avoids problems trying to forcefit Java/C/C++/... identifiers/keywords
into Haskell and avoid the (ever-growing) set of Haskell keywords.
But this could be done by using "" as an escape mechanism whenever
there's a conflict. For example, suppose I wanted to foreign import
a function called "class" using currently implemented ffi syntax.
I just put "" round the offending identifier and I'm done:
foreign import "class" clazz :: <whatever>
3) Might be easier to generate good error messages when the language
just isn't supported by that compiler.
As long as the "language/calling convention" keyword appears near
the start of the foreign decl, I think this is easy to do without
packing everything into strings.
What's the disadvantage of having highly structured strings as part of
the ffi spec? There's no big technical issue that I know of but as
the strings get more complex (i.e., as we start to write a grammar for
them), alarm bells start to go off in my head:
o Having a grammar for parsing strings seems to break the classic
language structure of:
lexical structure
context free syntax
static semantics
dynamic semantics
o Reminiscent of C++'s extern "C" declarations.
In itself this isn't necessarily bad - but every time I see
one of those decls, the word "ugly hack" springs to mind.
I suspect that making these strings even more structured would
make the hack look worse.
o It seems simpler to have just one grammar for Haskell rather than to
split it into two separate grammars. By this, I mean, two logically
separate grammars (as in the current proposed syntax) instead of two
physically separated grammar (as, for example, if someone were to
provide a grammar for the C++ ffi binding as appendix G to the
report).
Is anyone else concerned about this or am I just pissing in the wind?
--
Alastair Reid reid at cs.utah.edu http://www.cs.utah.edu/~reid/
More information about the FFI
mailing list