has anyone mentioned that the color scheme of the page comes straight outa the 70's?

Maybe it's just me...



Sorry, now, I'll continue reading :)

(or perhaps other possible inspirations could have been UNO the card game or Iberia Airlines)


bearophile wrote:
> D1 + Tango with a different Python-inspired syntax; close to my ideal language:
> 
> http://delight.sourceforge.net/
> 
> There are just few things I don't like, but they are generally minor, and maybe the author can change some of them still.
> 
> Bye,
> bearophile

Bill Baxter wrote:
> Pro spaces argument: "You have to modify the file to reindent, but at
> least everyone sees the same thing and there are no surprises".   The
> Pragmatist's argument.

Well, yes, it just works! I've done the odd bit of coding in Python, and the
first thing I learned was never touch anybode elses code before first doing
a "convert tabs to spaces" and then activate "insert spaces for tabs".
And I did never, ever again have any trouble with indentation whatsoever.

regards, frank

Denis Koroskin wrote:
> On Fri, 26 Sep 2008 00:28:02 +0400, Charles Hixson <charleshixsn@earthlink.net> wrote:
> 
>> Nick Sabalausky wrote:
>>> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:gbg5hu$189f$1@digitalmars.com...
>>>> D1 + Tango with a different Python-inspired syntax; close to my ideal language:
>>>>
>>>> http://delight.sourceforge.net/
>>>>
>>>> There are just few things I don't like, but they are generally minor, and maybe the author can change some of them still.
>>>>
>>>> Bye,
>>>> bearophile
>>>  "Python-like syntax"
>>> "Delight is intended for large projects with many developers."
>>>  Now that's hilarious. Good luck to him on that...he'll need it.
>> It looks like a very nice language, and there's nothing about Python syntax that makes it unsuitable for large projects.  But it does depend on GDC, which has appeared moribund for well over a year.
> 
>


> I believe GDC can be replaced with LLVMDC when it matures.
That's the problem, I don't think LLVMDC will support as many target as GCC does. For instance I am interested by ARM platforms, does LLVMDC support it ?

Mosfet wrote:
...
>> I believe GDC can be replaced with LLVMDC when it matures.
> That's the problem, I don't think LLVMDC will support as many target as GCC does. For instance I am interested by ARM platforms, does LLVMDC support it ?

LLVM does, see: http://llvm.cs.uiuc.edu/

"...static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha, SPARC, MIPS and CellSPU architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors, and an emitter for MSIL."

0ffh wrote:
> Bill Baxter wrote:
>> Pro spaces argument: "You have to modify the file to reindent, but at
>> least everyone sees the same thing and there are no surprises".   The
>> Pragmatist's argument.
> 
> Well, yes, it just works! I've done the odd bit of coding in Python, and the
> first thing I learned was never touch anybode elses code before first doing
> a "convert tabs to spaces" and then activate "insert spaces for tabs".
> And I did never, ever again have any trouble with indentation whatsoever.
> 
> regards, frank

The trouble with that is, if you work on a team, and you check your changes back into the repository, you'll generate a lot of worthless diffs, and people will have a more difficult time following the revision history.

When I work on a team with other people, I always adapt my indentation and bracing style to the code I'm currently working on. And I never change a line of code someone else wrote, unless I'm making a semantic change.

My own modules are written with my favorite coding style, but I don't mind slumming in someone else's style for the sake of consistency.

I used to work with a guy who regularly checked out the whole source tree, ran it through a pretty-printer, with his favorite code style, and then checked the changes back in. His stupid reformatting projects drove pretty much everyone crazy, since we had a hell of a time making sense of our diffs.

--benji

Benji Smith wrote:
> The trouble with that is, if you work on a team [...]

OCTAOE. That was not the use case I had in mind.
But I would try to avoid working in a team on a
Python project without clear rules of indentation.

regards, frank

Nick Sabalausky wrote:
> "Python-like syntax"
> "Delight is intended for large projects with many developers."
> 
> Now that's hilarious. Good luck to him on that...he'll need it. 

AFAIK, Google writes quite a few of their "large projects with many developers" in Python.

Johan Granberg, el 25 de septiembre a las 22:33 me escribiste:
> bearophile wrote:
> 
> > Mosfet:
> >> Is there any performance loss from compared to D language ?
> > 
> > No, it's just D1 resyntaxed. That is, it generally improves on the old-school syntax of D ;-)
> > 
> > Bye,
> > bearophile
> 
> How complet is the page? From wath I read there was several good features missing from D1 and if it's just a resyntax thats a shame :)
> 
> The most notisable was that I found no mention of an equvivalent to this
> 
> foreach(i,x;collection)
>         doSuff(i,x);

Loops

There are various different constructs for loops:

# Iterate over a sequence
for x in ["red", "green", "blue"]:
	stdout.formatln("Next is {}", x)

# Iterate over a sequence backwards
for x in ["red", "green", "blue"] reversed:
	stdout.formatln("Next backwards is {}", x)

# Get the index as well as the value
for i, x in ["red", "green", "blue"]:
	stdout.formatln("Item #{} = {}", i, x)

# Get all key/value pairs from an associative array
for key, value in dictionary:
	stdout.formatln("{} -> {}", key, value)

# A C-style for loop
for (int i = 1; i < 10; i++):
	stdout.formatln("i = {}", i)

# A C-style while loop
int j = 10
while j > 0:
	stdout.formatln("j = {}", j)
	j--

(http://delight.sourceforge.net/syntax.html)


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Con todas las manos que me acogotan, no puedo respirar
Con todos sus dedos me haría una torta, para festejar
Que no me estoy yendo solo de este lugar

Sorry for my answering delay, I was busy.

Yigal Chripun:

>Java is similar with this since it has dynamic class-loading - i.e. all your classes can define a main function and you specify to the JVM which class to load. this has other problems in java but the general idea (not the specific java implementation) is a good thing. if you try a similar thing in D - compile two D files which both define main - you'll get an error.<

I see. In Python this problem is solved with this not nice syntax:

code
if __name__ == "__main__":
    more_code

The 'code' is run when you import that module. But the more_code is run only when you run that module as main module. So every module can have that if __name__==... part, so every module can be run both stand alone (for example to run a little demo of its purpose, or to run just its own tests), or imported like a normal module.

Time ago in one of my lists of improvements I have asked to have something similar (with a different syntax, a better syntax too) in D.

At the moment lot of the D modules I write have a structure like this:


const bool do_benchmarks = false;

void foo() {
    ...
}

unittest { // unittest of function foo
    ...
}

void bar() {
    ...
}

unittest { // unittest of function bar
}

static if (do_benchmarks) {
    import d.time: clock;

    void benchmark1() {
        ...
    }

    void benchmark2() {
        ...
    }
}

unittest { printf(__FILE__ " unittest performed.\n"); }

static if (0) {
    void main() {
        static if (do_benchmarks) {
            putr("\nSome benchmarks:");
            benchmark1();
            benchmark2();
        }
    }
}

So when I want to test it I replace the 0 with a 1 at the end and I add -unittest to the command line of the 'bud' tool. When I want to test the performance I also set do_benchmarks to true.

With a syntax to denote if a module is run as main the code can become simpler, for example:

mainmodule {
    void main() {
        static if (do_benchmarks) {
            putr("\nSome benchmarks:");
            benchmark1();
            benchmark2();
        }
    }
}

Or even adding just a compile-time constant to D (that is true only for the main module) may suffice:

static if (mainmodule) {
    void main() {
        static if (do_benchmarks) {
            putr("\nSome benchmarks:");
            benchmark1();
            benchmark2();
        }
    }
}

Do you like?

------------------------------

Johan Granberg:

>How complet is the page? From wath I read there was several good features missing from D1 and if it's just a resyntax thats a shame :)<

I think the language is just born, so more things will be added in the future. Probably the purpose is to support all D.

Bye,
bearophile

Sun, 28 Sep 2008 18:04:08 -0400,
bearophile wrote:
> static if (mainmodule) {
>     void main() {
>         static if (do_benchmarks) {
>             putr("\nSome benchmarks:");
>             benchmark1();
>             benchmark2();
>         }
>     }
> }
> 
> Do you like?

There is no main module in D.  The main() function can be in any module. There are no specific privileges for the first module on the command line except sometimes compiler derives an output name from it.

Why don't you want to use versions instead?  For the module builders for instance it could be:

version (builders) {
  version (benchmark) {
    import d.time: clock;
    benchmark1() {...}
    benchmark2() {...}
  }
}

version (builders) {
  void main() {
    version (benchmark) {
      putr("\nSome benchmarks:");
      benchmark1();
      benchmark2();
    }
  }
}

do unittests:
bud builders -unittest -version=builders
benchmark:
bud builders -version=builders -version=benchmark