Oh, a quick comment on loops, since the article mentions those as well.  Here is the Lisp code:

    (loop for word in (gethash n *dict*) do


His C++ version:
    for (HashMap::iterator i = gDict.equal_range(n).begin();
         i != gDict.equal_range(n).end(); i++)

In D, if the words were stored in a sorted array, I would write:

    foreach( word; dict[lowerBound(n) .. upperBound(n)] )


And if they were in an AA (char[][][int] dict):

    foreach( word; dict[n] )

Note that this expects the lookup for n to succeed or the current AA code will throw an exception.  A more robust version:

    char[][]* list = n in dict;
    if( list ) foreach( word; *list )

seems unnecessarily wordy and somewhat unreadable.  It would be nice if AAs had some lookup method that returned a default value on failure instead of requiring the pointer check above.


Sean

Walter Bright wrote:
> Josh Stern wrote:
>> This old blog doesn't mention D, but I think it is good and really
>> relevant anyway:
>>
>> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
>>

I see the dictionary and input files at the link below, but can't find the mappings.txt file used in the C++ version... Am I just missing it?

Thanks.

>> IMO, it points to a set of issues that relate to how D (and its libraries)
>> have the potential to allow developers to be a lot more productive than
>> they are with C++.   Particularly relevant D features related to
>> the points mentioned there include but are not limited to  GC, mixins,
>> regex, and elimination of header/instantiation separation.   The point
>> about the productivity benefits of creating interfaces that return the
>> most interesting value (maybe alongside the interface that allows the
>> greatest efficiency when optimizing) is a good one to remember in practice.
> 
> 
> It is a very interesting article for anyone wanting to carefully look at language differences. Anyone care to try a D version following the original challenge?
> 
>    http://www.flownet.com/ron/papers/lisp-java/
> 

Sean Kelly wrote:
> Oh, a quick comment on loops, since the article mentions those as well.  Here is the Lisp code:
> 
>     (loop for word in (gethash n *dict*) do
> 
> 
> His C++ version:
>     for (HashMap::iterator i = gDict.equal_range(n).begin();
>          i != gDict.equal_range(n).end(); i++)
> 
> In D, if the words were stored in a sorted array, I would write:
> 
>     foreach( word; dict[lowerBound(n) .. upperBound(n)] )
> 
> 
> And if they were in an AA (char[][][int] dict):
> 
>     foreach( word; dict[n] )
> 
> Note that this expects the lookup for n to succeed or the current AA code will throw an exception.  A more robust version:
> 
>     char[][]* list = n in dict;
>     if( list ) foreach( word; *list )
> 
> seems unnecessarily wordy and somewhat unreadable.  It would be nice if AAs had some lookup method that returned a default value on failure instead of requiring the pointer check above.

Perhaps foreach could always check for 'null' if you pass it a pointer to an array.

L.

On Wed, 11 Oct 2006 10:55:35 -0700, Walter Bright wrote:

> D just needs a foreach_reverse statement.

Ain't that the truth!

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Walter Bright wrote:
> Sean Kelly wrote:
>> I believe that D has a definite opportunity to do better than C++ in code clarity and ease of programming, but I'm not sure the library is sufficient quiet yet.  The C++ algorithm/iterator model is extremely powerful and D's foreach and delegates aren't enough by themselves.  For example, writing the code snippet above in D would be much more like the original C++ version than my rewrite.  For D to be great, I think it will need an standard algorithm-oriented library that exploits D's unique language features.  DTL seemed a likely candidate, but development on it stalled ages ago.  But perhaps it contains ideas worth pursuing.  I'll admit it's been so long that I've forgotten a lot of the details of how it works.
> 
> D just needs a foreach_reverse statement.

old thread on the subject: http://www.digitalmars.com/d/archives/digitalmars/D/17320.html

How does the speed stack up with the C++ version?

Walter Bright wrote:
> 
> How does the speed stack up with the C++ version?

My version in D seems more straightforward than either C++ version on that site, so they can't really be compared. I'd have to port my D version to C++, but I don't know enough STL and am reluctant to learn it.

Doing the task in D was just incredible easy and straightforward. And the result runs faster than that C++ version, which is not really saying much about D, knowing the excess string conversions in the C++ version.

L.

While trying to understand the c++ implementation, I found out what the problem was. The c++ version does not allow a digit at position k if there's a word in the dictionary that matches the digits at k..n, even if that word cannot actually be used in the encoding because of a mismatch anywhere after n.

For example 30694, there IS a word matching "306", "sei" and therefor, the result "3-/0--69-4: 3 echt" is not considered..

L.

Lionello Lunesu wrote:
> While trying to understand the c++ implementation, I found out what the problem was. The c++ version does not allow a digit at position k if there's a word in the dictionary that matches the digits at k..n, even if that word cannot actually be used in the encoding because of a mismatch anywhere after n.
> 
> For example 30694, there IS a word matching "306", "sei" and therefor, the result "3-/0--69-4: 3 echt" is not considered..
> 
> L.

So the C++ version wasn't merely more complicated and slower than D, it was also wrong??

"Dave" <Dave_member@pathlink.com> wrote in message news:egk0jk$2d59$1@digitaldaemon.com...
> Walter Bright wrote:
>> Josh Stern wrote:
>>> This old blog doesn't mention D, but I think it is good and really relevant anyway:
>>>
>>> http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
>>>
>
> I see the dictionary and input files at the link below, but can't find the mappings.txt file used in the C++ version... Am I just missing it?

Ah, I could have posted that file, sorry.. Don't have it here, but it's just a txt file with "e 0\nE 0\n"... etc. I made it myself using the table from the original task description.

L.