Started a new thread, in case there is even more interest ;)

Brad Anderson wrote:
> Ant wrote:
>
>> On Sun, 25 Jul 2004 18:29:41 -0700, stonecobra wrote:
>>> mechanical java -> D translation process,
>>
>> can you share that!?
>>
>> I started that translation but got lost on workarounds for
>> dmd (mine) problems.
>>
>> I believe the DWT project should use a mechanical java -> D.
>>
> I've heard rumors of this tool, with the XML intermediate language, and
> am looking forward to putting SWT code through it.  Scott, let me know
> when it's ready, or if you want someone to kick the tires.  And if
> Walter fixes the FRef bug with your example, we may get somewhere with
> DWT...

The rumors are true.  I currently can translate most class/interface stuff, and I am currently focusing on the translations between Java's String and D's char[].  The fact that one is an object makes it a wee bit difficult :)

There will still be some hand fixup after the fact I'm afraid, because of things like not being able to tell the types that are put into a HashMap, for example.

It does use an XML intermediate language, but I believe it is still lacking certain things.  To get the intermediate language, I use jikes patched with JavaML (http://www.cs.washington.edu/homes/gjb/JavaML/) which tells jikes to spit out its debug info in XML.

I then have an XSLT stylesheet that runs over this xml output and starts writing D files.  I am trying to port SAX from java to D right now, and I am getting pretty close (string issues and such).

I will release it, I just worry about releasing something that doesn't even work.  Are any of you willing to help me make it better?

The big help I would like is various changes to jikes to do more with the information it has (like fully package named types in output), etc.

I think I've got a lot of the stylesheet stuff under control, but if there were more/better output to work on, that would be SWEEET!

Any more thoughts?

Scott

stonecobra wrote:

> 
> The rumors are true.  I currently can translate most class/interface stuff, and I am currently focusing on the translations between Java's String and D's char[].  The fact that one is an object makes it a wee bit difficult :)

I have a feeling that D will eventually have a String class of its
own as it currently has no String functionality at all. Since the
char and wchar types are UTF a function finding the Nth character
in the array would have to decode the array for each call. A String
class implementation will allow certain assumptions that from
eliminate the requirement of parsing UTF.

> 
> There will still be some hand fixup after the fact I'm afraid, because of things like not being able to tell the types that are put into a HashMap, for example.

As it happens I have just been working with a HashTable... I
assume you are writing this in Java? Hashtable has the same values()
function as HashMap so... I am also assuming you are not familiar
with java.lang.Object.getClass()?
================================================================
import java.nio.charset.*;
import java.util.*;
public class Test {
    public static void main( String[] args ) throws Exception {
        Hashtable table = new Hashtable(Charset.availableCharsets());
        Iterator i = table.values().iterator();
        Object tableValueObject;
        Class tableValueClass;
        while( i.hasNext() ) {
            tableValueObject = i.next();
            tableValueClass = tableValueObject.getClass();
            System.out.print( tableValueClass );
            System.out.print( " extends " );
            System.out.print( tableValueClass.getSuperclass() );
            System.out.println();
        }
    }
}
================================================================
class sun.nio.cs.ISO_8859_9 extends class java.nio.charset.Charset
class sun.nio.cs.ext.ISO_8859_8 extends class java.nio.charset.Charset
   ... (40+ lines removed for your reading pleasure)
class sun.nio.cs.UTF_16BE extends class java.nio.charset.Charset
================================================================

> 
> I will release it, I just worry about releasing something that doesn't even work.  Are any of you willing to help me make it better?
> 
> The big help I would like is various changes to jikes to do more with the information it has (like fully package named types in output), etc.
> 
> I think I've got a lot of the stylesheet stuff under control, but if there were more/better output to work on, that would be SWEEET!

I would love to help but I am currently trying to find my way around the
D compiler. Good luck.

In article <ce6elp$2jmu$1@digitaldaemon.com>, parabolis says...

>I have a feeling that D will eventually have a String class of its own as it currently has no String functionality at all.

I believe Hauke is working on that string class.

"no String functionality at all" is a bit of an exageration though, since std.string has certainly got a non-zero amount of funtionality. What kind of functionality are you looking for?


>Since the
>char and wchar types are UTF a function finding the Nth character
>in the array would have to decode the array for each call.

which is easy, even with char[] and wchar[]. But, better still, a dchar[] array is strictly one character per element.

Java chars are D wchars, of course, since Java has no 32-bit-wide dchar, and so
Java strings are /also/ UTF-16. The way I read it, java.lang.String.charAt()
just counts UTF-16 fragments - same for length(), indexOf(), etc.

Me again

On Tue, 27 Jul 2004 16:41:14 -0700, parabolis wrote:

> stonecobra wrote:
> 
>> 
>> The rumors are true.  I currently can translate most class/interface stuff, and I am currently focusing on the translations between Java's String and D's char[].  The fact that one is an object makes it a wee bit difficult :)
> 
> I have a feeling that D will eventually have a String class of its own as it currently has no String functionality at all.

And by that you mean a String class in phobos, yes?  There is a String class (I believe Walter links to it somewhere off the D website) already, but since it's not in phobos, I find it to be virtually useless.  But that's probably because I'm writing libraries right now.  If we're going to use a String class, it's important for it to be a part of phobos (and thus standard), or at least to implement a standard interface in phobos.

A lack of a standard String class is somethat that's actually kind of irked be about D (really phobos I guess), and I think it should be a high enough priority that it should be pre-1.0 thing.  Anyone else agree, or am I the only one not happy with char[] and free floating methods?

John

parabolis wrote:

> stonecobra wrote:
> 
>>
>> The rumors are true.  I currently can translate most class/interface stuff, and I am currently focusing on the translations between Java's String and D's char[].  The fact that one is an object makes it a wee bit difficult :)
> 
> 
> I have a feeling that D will eventually have a String class of its
> own as it currently has no String functionality at all. Since the
> char and wchar types are UTF a function finding the Nth character
> in the array would have to decode the array for each call. A String
> class implementation will allow certain assumptions that from
> eliminate the requirement of parsing UTF.

I have been avoiding writing my own String call for this purpose.  For example the java code:
  foo.indexOf("bar")
translates into:
  std.string.find(foo, "bar")

It's just a helper method instead of a class method of an object. Simple, but tedious for translation ;)

> 
>>
>> There will still be some hand fixup after the fact I'm afraid, because of things like not being able to tell the types that are put into a HashMap, for example.
> 
> 
> As it happens I have just been working with a HashTable... I
> assume you are writing this in Java? Hashtable has the same values()
> function as HashMap so... I am also assuming you are not familiar
> with java.lang.Object.getClass()?
> ================================================================
> import java.nio.charset.*;
> import java.util.*;
> public class Test {
>     public static void main( String[] args ) throws Exception {
>         Hashtable table = new Hashtable(Charset.availableCharsets());
>         Iterator i = table.values().iterator();
>         Object tableValueObject;
>         Class tableValueClass;
>         while( i.hasNext() ) {
>             tableValueObject = i.next();
>             tableValueClass = tableValueObject.getClass();
>             System.out.print( tableValueClass );
>             System.out.print( " extends " );
>             System.out.print( tableValueClass.getSuperclass() );
>             System.out.println();
>         }
>     }
> }
> ================================================================
> class sun.nio.cs.ISO_8859_9 extends class java.nio.charset.Charset
> class sun.nio.cs.ext.ISO_8859_8 extends class java.nio.charset.Charset
>    ... (40+ lines removed for your reading pleasure)
> class sun.nio.cs.UTF_16BE extends class java.nio.charset.Charset
> ================================================================

I am not writing this in Java, actually.  It is an XSLT stylesheet transforming XML data that represents java source code.

I am familiar with java.lang.Object.getClass(), but then my translator would be a runtime introspection translator, instead of the source level translator that I described it as.  It is a flaw in my scheme, I understand that, but I am still going forward with it.

>>
>> I will release it, I just worry about releasing something that doesn't even work.  Are any of you willing to help me make it better?
>>
>> The big help I would like is various changes to jikes to do more with the information it has (like fully package named types in output), etc.
>>
>> I think I've got a lot of the stylesheet stuff under control, but if there were more/better output to work on, that would be SWEEET!
> 
> 
> I would love to help but I am currently trying to find my way around the
> D compiler. Good luck.

Funny that, I am too :)

Scott

> The rumors are true.  I currently can translate most class/interface stuff, and I am currently focusing on the translations between Java's String and D's char[].  The fact that one is an object makes it a wee bit difficult :)

what are the difficulties you are referring to?

Ben Hinkle wrote:

>>The rumors are true.  I currently can translate most class/interface
>>stuff, and I am currently focusing on the translations between Java's
>>String and D's char[].  The fact that one is an object makes it a wee
>>bit difficult :)
> 
> 
> what are the difficulties you are referring to?
> 

Maybe difficulties is too strong a word, merely translating an object.method(param) call to helpermethod.method(object, param) call. Tedious hand coding of mappings between string methods and std.string methods.

See also my response to parabolis.

Scott

stonecobra wrote:

> Ben Hinkle wrote:
> 
>>> The rumors are true.  I currently can translate most class/interface
>>> stuff, and I am currently focusing on the translations between Java's
>>> String and D's char[].  The fact that one is an object makes it a wee
>>> bit difficult :)
>>
>>
>>
>> what are the difficulties you are referring to?
>>
> 
> Maybe difficulties is too strong a word, merely translating an object.method(param) call to helpermethod.method(object, param) call. Tedious hand coding of mappings between string methods and std.string methods.
> 
> See also my response to parabolis.

There is a scary, undocumented wrinkle in the language where, if you have a function of the form

T foo(Array[] an_array, ... arguments) { ... }

The expression

    my_array.foo(...);

is equivalent to:

    foo(my_array, ...);

This only works if the first argument is an array type. (any type of array will work, though)

I don't know if it's supposed to be there, why it's there to begin with, or if it's going to stick around, though. :)

 -- andy

Arcane Jill wrote:

> In article <ce6elp$2jmu$1@digitaldaemon.com>, parabolis says...
> 
> 
>>I have a feeling that D will eventually have a String class of its
>>own as it currently has no String functionality at all.
> 
> 
> I believe Hauke is working on that string class.

This could be good to hear.

> 
> "no String functionality at all" is a bit of an exageration though, since
> std.string has certainly got a non-zero amount of funtionality. What kind of
> functionality are you looking for?

Some fundamentals like length and substring would be a good start. See my post in Re: OT - scanf in Java

> 
> 
> 
>>Since the
>>char and wchar types are UTF a function finding the Nth character
>>in the array would have to decode the array for each call.
> 
> 
> which is easy, even with char[] and wchar[]. But, better still, a dchar[] array
> is strictly one character per element.

Perhaps easy but a class or interface solution can perform length-querry and substring operations in constant time. Parsing UTF and counting the characters would take N time in all cases. The substring

> 
> Java chars are D wchars, of course, since Java has no 32-bit-wide dchar, and so
> Java strings are /also/ UTF-16. The way I read it, java.lang.String.charAt()
> just counts UTF-16 fragments - same for length(), indexOf(), etc.
> 

True but java.lang.Character and java.lang.String are classes and will be much more easily extended than a primitive type.
(Just ask sun for unsigned primitives ;))

parabolis wrote:

> Arcane Jill wrote:
> 
>> In article <ce6elp$2jmu$1@digitaldaemon.com>, parabolis says...
>> 
>> 
>>>I have a feeling that D will eventually have a String class of its own as it currently has no String functionality at all.
>> 
>> 
>> I believe Hauke is working on that string class.
> 
> This could be good to hear.

I don't know if archives of the old newsgroup are around but I recall a long thread about string classes back then (at least I think it was on the old newsgroup). It might be worth looking at those posts. Personally I think char[]/std.string is better than a class and is certainly better to choose one or the other but not both.

>> 
>> "no String functionality at all" is a bit of an exageration though, since std.string has certainly got a non-zero amount of funtionality. What kind of functionality are you looking for?
> 
> Some fundamentals like length and substring would be a good start. See my post in Re: OT - scanf in Java
> 
>> 
>> 
>> 
>>>Since the
>>>char and wchar types are UTF a function finding the Nth character
>>>in the array would have to decode the array for each call.
>> 
>> 
>> which is easy, even with char[] and wchar[]. But, better still, a dchar[] array is strictly one character per element.
> 
> Perhaps easy but a class or interface solution can perform length-querry and substring operations in constant time. Parsing UTF and counting the characters would take N time in all cases. The substring
> 
>> 
>> Java chars are D wchars, of course, since Java has no 32-bit-wide dchar,
>> and so Java strings are /also/ UTF-16. The way I read it,
>> java.lang.String.charAt() just counts UTF-16 fragments - same for
>> length(), indexOf(), etc.
>> 
> 
> True but java.lang.Character and java.lang.String are classes and will be much more easily extended than a primitive type. (Just ask sun for unsigned primitives ;))