Home » forums » LtU Forum

Type Mapping in Source-To-Source Translation

I'm in the middle of writing an Object-Pascal-to-Java translator. One interesting aspect is the mapping between source and target types. Is anybody aware of literature about this topic, books, papers, etc.?

I would be interested in things like rules for "widening" a target type over the source type; constraints that must hold on operations applied in the target language so that the result complies with the result in the source language; maybe a formalism where you could even show (prove) that, given some sets of types and operations; etc.

I do not aim to set things up this way, but would enjoy reading some theoretical material about what I'm doing. Is there serious research in the area of source translation, anyway?

By thomash at 2019-10-22 20:32 | LtU Forum | previous forum topic | next forum topic | other blogs | 3815 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Several ways to approach the problem

1. Mapping types is only half the battle. You also have to map execution sequence / evaluation order of expressions, to ensure minimal side effects in source-to-source translatin.
2. In general, you can think of Wadler's Blame Calculus as a formalism for any source-to-source translation. You should really read A complement to blame by Wadler. He and his students have examined this problem from many angles, and its probably the best work on the subject.
3. With Java, the portability and meaning of "int" and various types is fortunately robust**, so having it as a translation target makes life a whole lot easier. Especially if yout "ToTarget" is Java. Because you can reasonably say your Java program is more precisely typed since its types are environment agnostic. This alleviates the need for any preprocessor macros or compile switches to determine the meaning of a type.

** I lied. In Java 1.5, they changed the serialization of BigDecimal, such that from one Java version to another, the persistence of a BigDecimal is different depending on the precision required of the underlying number. :( Similarly, you may have issues with things like mapping DateTime literal values. For example, what do you do if Object Pascal disallows constructing dates for ambiguous or "skipped hours"? You could do a meta-mapping and first mandate that all Object Pascal times are in GMT.

4. You can also think of Lenses as a way to map types, at least syntactically. This won't handle things like idiosyncrasies between how java and Object Pascal evaluate statements, but it's a start. You simply assume that if you can generate a bidirectional map and either source or target can be source or target, you're good to go.

5. You may also run into issues around different treatment of name shadowing. Buyer beware. Frequent problem in any lift-and-shift.

By Z-Bo at Mon, 2019-10-28 23:05 | login or register to post comments

[deleteme]

[deleteme]

By thomash at Tue, 2019-10-29 17:19 | login or register to post comments

Great, thanks for the hints,

Great, thanks for the hints, part. the Wadler paper. Fortunately, Object Pascal and Java are close enough in spirit so for many constructs, part. control flow, there is little to no mismatch between the two. The type dimension is more challenging.

As for lenses (which I know little about) I suppose they would be a way to encode such type mapping, but they wouldn't help to find suitable mappings in the first place, would they?!

By thomash at Tue, 2019-10-29 17:23 | login or register to post comments