typeRepToString changes in 1.5 (?)

[Steve Harris]

Hello,
it looks like the String representation of TypeReps have changed a
little with the Quark 1.5 release, and this is causing me problems so
I'm wondering if it was intentional.
For example, here's a type representing character large objects I have
defined in a Lobs module, which privately is implemented as a
java.sql.Clob:

///////////////////////////////////////////////
// Clob

data foreign unsafe import jvm private "java.sql.Clob"
public Clob
deriving Inputable, Outputable;

foreign unsafe import jvm "method length"
public clobLength :: Clob -> Long;

foreign unsafe import jvm "method getSubString"
public getClobSubString :: Clob -> Long -> Int -> String;

// Clob
///////////////////////////////////////////////

Then if I have an ICE session going in another module, and I do:
> let t = typeOf(undefined::Clob); in typeRepToString t

I get:
Output:
Lobs.Clob (interface java.sql.Clob)

Prior to the release of 1.5, this would have been just "Lobs.Clob".
So I'm wondering why the new "interface" part is present, which is not
valid source code and which exposes the private java implementation
class? I had been relying on typeRepToString to generate a valid
source code representation of the type (for code generation). Maybe
this approach is naive but it did work prior to 1.5. Any suggestions?

Steve

[jw]

Hi Steve,

Thanks for finding this problem. This is an inadvertent bug introduced
in our attempt to support exception-handling in CAL programs that are
packaged into standalone JARs. To fix it, find the following 2 lines
in the definition of Prelude.typeRepToString:

ForeignTypeRep {typeConsName, foreignClass} ->
concat [typeConsName, " (", class_toString foreignClass,
")"];

and replace them with:

ForeignTypeRep {typeConsName} ->
typeConsName;

We will fix this in the next release of Open Quark.

Hope this helps!

Joseph

[Steve Harris]

That fixes it for me.
Thank you!