In article <b84083$1gh0$1@digitaldaemon.com>, Mark Evans says...
>
>
>Functional application requires neither anonymous functions nor list reversal. You can use named functions.
>
>If D now offers first-class functions then it should support the functional idiom.  Map is a higher-order function of two arguments, a function and a list. The output is a new list.  You can also define a scan which does identical list walking, but returns void, i.e. list modification in place.
>
>Mark
>
>

I've worked with 'map' before in my foray with ColdC servers, along with 'hash', 'find', and 'filter' which all work in more or less the same way.  I think it would be nice to have their equivelant(s) in D.

(For more info on ColdC's map/hash/find/filter expressions:) http://ice.cold.org:1180/bin/help?node=$help_coldc_loop_expr

-- C. Sauls

>C#
>
>Interstingly, C# provides their own syntax somewhere between your example and python's:
>
>        int [] arr = new int [] {1,2,3}
>        foreach (int i in arr)
>        {
>                ...
>        }
>

C# foreach syntax looks pretty clean to me (I don't use C# either)

We mustn't forget that 'in' is an operator in D.
If we use it in the foreach construct it would be misleading to those who
read the code,
especially in particularly involuted espression.

I prefer a sintax like:
    char[][] blah;
    foreach(char[] a; blah) {}
which Thomas D. Marsh proposed.

Anyway, there are other construct which we have to think about.
For example, something like:
    char[] A, B;
    foreach(char a; A)(char b; B)
        A = B;
Which would be equivalent to:
    char[] A, B;
    assert(A.length == B.length);
    for(int i; i < A.length; i++)
        A[i] = B[i];

What D needs is an intuitive sintax which would be able to replace the C
'for' sintax
in all (or almost all) its uses. (To be sincere, I wish D will drop the ugly
'for' construct
in the future.)

Dario

Hello Dario,

Credit where credit is due: the foreach example you gave was Chris Sauls' example. I think the in operator having dual purpose is possible, though, arguably, may lead to confusion. Python for example has:

        for x in list:
                foobar(x)

as well as

        if x in list:
                ...

with different meaning in each context. It doesn't really matter to the compiler as it has to treat looping expressions specially anyhow. I haven't heard about any complaints in my time with python regarding the dual use of the 'in' keyword in this case.

Just to throw some more syntactic variety out there, we'll take your example with a C#-ish syntax:

        char[] A, B;

        foreach (char a in A, char b in B)
        {
        }

Or what about this:

        foreach (char a in A reverse, char b in B)
        {
        }

in the case of reverse iteration?

--thomas

Dario wrote:

> We mustn't forget that 'in' is an operator in D.
> If we use it in the foreach construct it would be misleading to those who
> read the code,
> especially in particularly involuted espression.
> 
> I prefer a sintax like:
>     char[][] blah;
>     foreach(char[] a; blah) {}
> which Thomas D. Marsh proposed.
> 
> Anyway, there are other construct which we have to think about.
> For example, something like:
>     char[] A, B;
>     foreach(char a; A)(char b; B)
>         A = B;
> Which would be equivalent to:
>     char[] A, B;
>     assert(A.length == B.length);
>     for(int i; i < A.length; i++)
>         A[i] = B[i];
> 
> What D needs is an intuitive sintax which would be able to replace the C
> 'for' sintax
> in all (or almost all) its uses. (To be sincere, I wish D will drop the
> ugly 'for' construct
> in the future.)
> 
> Dario

-- 
All power corrupts, but we need electricity.

While the semantics is different, the "meaning" probably isn't.

If "in" means testing whether the value is contained in a set, then it would apply both to "foreach (x in set)", and to "if (x in set)". Note that foreach acts so, as if it would go and test every possible x whether it belongs to the set, which boils down to the same semantics as "if (x in set)". Obviously, this would be a wrong guide for an implementation, but it feels right as a mnemonic. Thinking out new and unnatural keywords for every single case isn't a solution either... That's also the justification for function overloading.

How about handling different types as sets, not only associative arrays?
How about associative arrays with no value associated, which would be so to say pure sets then?

How about a completely alternative for syntax:

for (type a = 1 to x) {}
for (type a = 1 to x step c) {}
for (type a = 1 downto x step c) {}
for (type a in s) {}

"type" is obviously only requiered to create new variables.
If someone would call it keyword abuse, you can also rename these "for" into the more verbose "foreach". This would also make sure that noone ocassionally confuses it with "if(...in...)", although i somehow consider plain "for" more appropriate.

-i.


Thomas D. Marsh wrote:
> Hello Dario,
> 
> Credit where credit is due: the foreach example you gave was Chris Sauls'
> example. I think the in operator having dual purpose is possible, though,
> arguably, may lead to confusion. Python for example has:
> 
>         for x in list:
>                 foobar(x)
> 
> as well as
> 
>         if x in list:
>                 ...
> 
> with different meaning in each context. It doesn't really matter to the
> compiler as it has to treat looping expressions specially anyhow. I haven't
> heard about any complaints in my time with python regarding the dual use of
> the 'in' keyword in this case.
> 
> Just to throw some more syntactic variety out there, we'll take your example
> with a C#-ish syntax:
> 
>         char[] A, B;
> 
>         foreach (char a in A, char b in B)
>         {
>         }
> 
> Or what about this:
> 
>         foreach (char a in A reverse, char b in B)
>         {
>         }
> 
> in the case of reverse iteration?
> 
> --thomas
> 
> Dario wrote:
> 
> 
>>We mustn't forget that 'in' is an operator in D.
>>If we use it in the foreach construct it would be misleading to those who
>>read the code,
>>especially in particularly involuted espression.
>>
>>I prefer a sintax like:
>>    char[][] blah;
>>    foreach(char[] a; blah) {}
>>which Thomas D. Marsh proposed.
>>
>>Anyway, there are other construct which we have to think about.
>>For example, something like:
>>    char[] A, B;
>>    foreach(char a; A)(char b; B)
>>        A = B;
>>Which would be equivalent to:
>>    char[] A, B;
>>    assert(A.length == B.length);
>>    for(int i; i < A.length; i++)
>>        A[i] = B[i];
>>
>>What D needs is an intuitive sintax which would be able to replace the C
>>'for' sintax
>>in all (or almost all) its uses. (To be sincere, I wish D will drop the
>>ugly 'for' construct
>>in the future.)
>>
>>Dario
> 
> 

> Credit where credit is due: the foreach example you gave was Chris Sauls' example.
Ops, I apologize.

> I think the in operator having dual purpose is possible, though, arguably, may lead to confusion.
Yes, it can be used in the foreach construct, but I think it's better not to
assign more
meaning to the in operator. Not only it would lead to confusion in
expressions like
    foreach(char[] a in b in c ? c : d) ...
but maybe it would result in a more complex compiler implementation too.

"Thomas D. Marsh" <thomas.marsh@seznam.cz> wrote in message news:b7m2jr$ei0$1@digitaldaemon.com...
> Walter, have you been watching the discussion, and do you have any
opinions?

Yes. I decided long ago that D needed a foreach, I just haven't implemented it yet.

> Yes. I decided long ago that D needed a foreach, I just haven't
implemented
> it yet.

Good to hear!  Though I'd like to retract a point of my own.. I remember suggesting key->value pair iterators via a syntax such as:

    int[char[]] array;
    ...
    char[] key;
    int value;
    for (array; key:value)
    { ... }

But after thinking about it a little I realize that its not really necessary since we can just:

    int[char[]] array;
    ...
    char[][] keys = array.keys;
    char[] key;
    int value;
    for (keys; key)
    { ... }

Doesn't seem that much worse to me.

--C. Sauls

"C. Sauls" <ibisbasenji@yahoo.com> escreveu na mensagem news:ba3k1v$1hlj$1@digitaldaemon.com...
> > Yes. I decided long ago that D needed a foreach, I just haven't
> implemented
> > it yet.
>
> Good to hear!  Though I'd like to retract a point of my own.. I remember suggesting key->value pair iterators via a syntax such as:
>
>     int[char[]] array;
>     ...
>     char[] key;
>     int value;
>     for (array; key:value)
>     { ... }
>
> But after thinking about it a little I realize that its not really
necessary
> since we can just:
>
>     int[char[]] array;
>     ...
>     char[][] keys = array.keys;
>     char[] key;
>     int value;
>     for (keys; key)
>     { ... }
>
> Doesn't seem that much worse to me.
>
> --C. Sauls
>

    Hi,

    It can be really worse. Compare these:


foreach (key, value in dict) { // O(N) complexity or something like that
    printf("%.*s => %.*s\r\n", key.toString(), value.toString());
}

foreach (key in dict) { // O(N) complexity or something like that
    printf("%.*s => %.*s\r\n", key.toString(),
           dict[key]    // must lookup key again in container, we hope it's
O(1)
           .toString());
}


    The lookup complexity may be O(1), O(log(N)) or even O(N * N) (I don't
know may be some bizarre kind of datastructure, who knows). But it'll
probably be some kind of performance leak. We could get away with other
syntax:


template TEntry(T, U) {
    struct Entry {
        T key;
        U value;
    }
}

instance TEntry(A,B).Entry entry;
foreach (entry in dict.entries) {
    printf("%.*s => %.*s\r\n", entry.key.toString(),
entry.value.toString());
}


    But we need this idiom. There are a bunch of sites talking about how
people keep iterating like this (using foreach with the keys, then looking
up the values) in Perl and Python, getting lousy performance because of this
"simple" idiom.

    Best regards,
    Daniel Yokomiso.


"My opinions may have changed, but not the fact that I am right."
 - Ashleigh Brilliant


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 13/5/2003

Point made entirely.

-- C. Sauls