Yeah, pretty much.  Just needs (initialization, syntax)

Sean

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b0gvuf$14u5$1@digitaldaemon.com...
> I think tuples are anonymous structs, and thus the syntax should be leaned on the structs, rather then on tuples in other languages. Anonymous structs with implicit underlying types. :/

"Scott Pigman" <scottpig1@attbi.com> writes:

>> But what if you use such a function in an expression - you get a real mess. Noone forces though.
>
> i don't think that's necessary - the expression would use only the first returned value.
>
> i think it'd go something like this:
>
> int,int,int foo()
> {
> 	return 1,2,3;
> }
>
> a,b,c = foo() // a == 1, b == 2, c == 3
> d = foo(); // d = 1, the second & third return values are lost
>
> x = foo()*foo() // x = 1 (1 * 1), the other values are ignored.
>
>
> hmmm, how about this construct?
> foreach x in foo(){ print x} // prints "1 2 3"

Looks nice.

You know, I've always wanted something like:

  foreach x in 2, 3, 5, 7 {
    do_something(x);
  }

The same should work for standard containers:

void f(IntSet set_of_ints, int[] int_array) {
  foreach x in setOfInts {
    bah(x);
  }

  foreach x in int_array {
    pfoo(x);
  }
}

While we're defining new syntax, this would be neat, too:

 foreach x in 1..100 {
   printLn(x);    // print numbers from 1 to 100
 }

 foreach x in 100..1 {
   // the same, backwards
 }

Of course, it would require some kind of syntax for ".." operator -- which could create an instance of struct Range, for example. (It might even fit the standard operator overloading framework.)

For a general foreach construct, I'd think that some kind of iterator concept would be fit the job. As in

interface TIterator {
  T get();
  void advance();
  bit valid();
}

and now "foreach x in y { foo(x); } " would translate to

  {
    T x;
    TIterator i = y.getIterator();
    while (i.valid()) {
      foo(i.get());
      i.advance();
    }
  }

I faintly remember Java having an iterator like this.  And y must have
member getIterator(). (Of the appropriate type, of course.)

But let's go back to tuples.  What if the elements of the tuple are of different types?

int, char, float f() { return 1, 'a', 3.14156; }

  foreach (x in f()) {
    ummagumma(x);
  }

..should this be unrolled to:

  ummagumma(1);
  ummagumma('a');
  ummagumma(3.14159);

??

Just the ideas of tonight,

Antti

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> writes:
> "Sean L. Palmer" <seanpalmer@directvinternet.com> escreveu na mensagem news:b0c76g$1nd8$1@digitaldaemon.com...
>> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:b0apv1$s9u$1@digitaldaemon.com...

>> > instance TArrays(int) arrays;
>> > const int[] numbers = ...;
>> > if (arrays.all(numbers, &isOdd)) { ...}
>> > if (arrays.any(numbers, &isOdd)) { ...}
>>
>> The function call to isOdd needs to be eliminated.  That's why closures and anonymous functions are so important, so stuff like this can be inlined.  The basic idea is to pass *the function*, or a reference to it, not a pointer to the function, as a parameter. Taking a pointer guarantees it must live at a memory address which is not what you want.

I might be nitpicking here, but I doubt it that it makes any difference if function's address is passed via pointer or via reference.  I hope that I'm not too optimistic when I think that a good compiler will inline the call even if the dreaded address-of operator is used to denote an indirection.

Actually, I don't think we should even be talking about pointers to functions.  Why not just call them what they are -- functions?  After all, they are not even created or stored dynamically, as ordinary objects are.  They cannot be used like other pointers (for example, accessing an array of function pointers via a pointer to a function? Surely you jest.)  Still we talk about pointers to functions -- but not pointers to objects, although objects are implemented as pointers.

A comment about coding style:
>> > public boolean isOdd(int n) {
>> >     return n % 2 != 0;
>> > }
>> Also I personally would replace return n % 2 != 0
>> with return (n & 1) != 0 so that you can be reasonably sure you'll
>> get the best performance possible.  Integer modulus can be very
>> slow.  Several orders of magnitude slower than binary and.

>     The remark about using (n & 1) != 0 instead is flawed in my opinion. Of
> course in a simple code snippet it can be clear, but these kind of things
> are likely premature optimization and may lead to highly obfuscated code.
> IMO a better code would read "return n.isDivisibleBy(2);" using an OOish
> syntax, or even "return 2.divides(n);". If we have a language with different

IMHO, the function's name says it all.  While the efficiency should not be the utmost concern in programming, neither should readability. Both concerns should show where they matter - namely, interfaces should be as readable as possible and the implementation efficient.. Like it was in Sean's example.  And everybody's happy.  Anyway, that's why we like abstraction so much, right? :-)

A.

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:b0btch$1ev5$1@digitaldaemon.com...
>     AFAIK it's not necessary but Lisp people like having the compiler
> available at runtime. I would like that too ;-)

I've been thinking of making DMDScript available at runtime for D programs.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b0du7h$2k6i$1@digitaldaemon.com...
> And of
> course we have to use fmod for floats; God evidently forbade use of the
same
> operator for both integer and floating point division or modulus!

There is special dispensation for D, which supports % for floats.

Awesome!

"Walter" <walter@digitalmars.com> wrote in message news:b2rgk2$1hdn$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b0du7h$2k6i$1@digitaldaemon.com...
> > And of
> > course we have to use fmod for floats; God evidently forbade use of the
> same
> > operator for both integer and floating point division or modulus!
>
> There is special dispensation for D, which supports % for floats.

Walter wrote:
> I've been thinking of making DMDScript available at runtime for D programs.

This is a very cool idea! To have optional scripting support available at runtime would enable D to be used to more easily develop innovative applications that are outside the usual domain of a pure systems language or a pure scripting language.

A variant on the idea would be to make D runtime scriptable by any scripting language that supports a particular set of interfaces. Most people use Java/ECMA/DMDScript only because they have to, not because they want to. The scripters of the world seem to truly love Perl, Python, and Ruby. And the esoteric scripters have the script children of Smalltalk and Lisp.

It's a big feature, though, which will cost a good chunk of time.

--ms

Hmmm... that might mean that other implementors would also have to hack some implementation together...

BTW, how come that Netscape implementation is so damn slow? Where does that difference of an order of magnitude compared to the next faster implementation come from?

Walter wrote:
> I've been thinking of making DMDScript available at runtime for D programs.

"Michael Slater" <mail@effectivity.com> wrote in message news:b2rrlm$1sb1$1@digitaldaemon.com...
> Walter wrote:
> > I've been thinking of making DMDScript available at runtime for D
programs.
> This is a very cool idea! To have optional scripting support available at runtime would enable D to be used to more easily develop innovative applications that are outside the usual domain of a pure systems language or a pure scripting language.

Lots of apps need a built in language, so why not provide one? (For example, the lithp interpreter found in EMACS text editors.)

> A variant on the idea would be to make D runtime scriptable by any scripting language that supports a particular set of interfaces. Most people use Java/ECMA/DMDScript only because they have to, not because they want to. The scripters of the world seem to truly love Perl, Python, and Ruby. And the esoteric scripters have the script children of Smalltalk and Lisp.

The factors driving DMDScript as the scripting language to use in
conjunction with D would be:
1) ECMAscript is popular and well known
2) I know ECMAscript
3) ECMAscript syntax is derived from C, so is not hopelessly dissimilar to D
syntax
4) I have a fully implemented and debugged implementation of ECMAScript

> It's a big feature, though, which will cost a good chunk of time.

Not that much. It's mostly translating the code.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b2rs64$1squ$1@digitaldaemon.com...
> Hmmm... that might mean that other implementors would also have to hack some implementation together...

I think something could be worked out. Also, the DMDScript would not be part of the D language, it would just be part of the Digital Mars implementation.

> BTW, how come that Netscape implementation is so damn slow? Where does that difference of an order of magnitude compared to the next faster implementation come from?

I don't know. I haven't studied the source code to Netscape. Perhaps it's because I have a better profiler <g>.