[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Markus Mottl <mottl@m...> |
| Subject: | ocamlyacc and polymorphic variants |
Hello, I have just tried in how far it is possible to use ocamlyacc together with polymorphic variants. As it seems, this is a somewhat dangerous combination, because ocamlyacc-generated code requires Obj.magic internally to cast values to the appropriate type. I am not sure in which order the data constructors are generated, i.e. what internal representation the polymorphic variants get. I thought that they would be generated in order of appearance, but when I implemented the parser, the code behaved more than strangely, namely differently for byte- and native code. This is an indication that the returned values do not fully correspond to the type they are supposed to be of, possibly because the internal tags of the data constructors are not in the right order. The result type enumerated the data constructors exactly in the same order as they appeared in the parser specification, but this does not seem to work. Is it possible at all to return polymorphic variants from the parser? If yes, how do I have to specify the return type? A workaround would be to not use polymorphic variants in the parser and to use a conversion function outside to convert the "normal" into polymorphic ones. Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl