www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Delight

reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
next sibling parent reply Mosfet <mosfet anonymous.org> writes:
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


Interesting!
Is there any performance loss from compared to D language ?
I can predict the following destiny to Delight Language, the main 
maintener of delight will create a good standard lib called Deimos but 
another developer not satisfied by the methods name will fork and create 
another one called Salsa.
Then Delight will evolve and there will be a Delight 1.0 and a Delight 
2.0 with incompatible code.
So poor developers will be lost and will keep on waiting for another 
language without all the issues.
Of course this scenario is pure fiction ;-)
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 25 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbg74u$1bom$1 digitalmars.com>, bearophileHUGS lycos.com 
says...

 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 ;-)


I'd like to look at some real-world example written in Delight.  I'm 
afraid that the lack of global state will result in either a huge amount 
of arguments passed to every function or huge ad-hoc interfaces grouping 
other interfaces just to pass some functionality up-stream.
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:

 I'd like to look at some real-world example written in Delight.


I have not tried to run it yet because it's for Linux for now.



 I'm afraid that the lack of global state will result in either a huge amount 
 of arguments passed to every function or huge ad-hoc interfaces grouping 
 other interfaces just to pass some functionality up-stream.


I agree, that's one of the main things I think have to be fixed in Delight,
having global vars (and maybe a global main function too).

The other main problem comes from the tabs as indents, this explains why it's
bad:
http://mail.python.org/pipermail/python-list/2003-January/183758.html

There are other problems in Delight, but I think they are minor.

There's a (for me) surprisingly large discussion on Reddit about Delight, 82
comments so far:
http://www.reddit.com/r/programming/comments/73d15/d_meets_python/

Bye,
bearophile
Sep 25 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
bearophile wrote:

 Sergey Gromov:

 I'd like to look at some real-world example written in Delight.


 
 I have not tried to run it yet because it's for Linux for now.
 
 

 I'm afraid that the lack of global state will result in either a
 huge amount of arguments passed to every function or huge ad-hoc
 interfaces grouping other interfaces just to pass some
 functionality up-stream.


 
 I agree, that's one of the main things I think have to be fixed in
 Delight, having global vars (and maybe a global main function too).


Could you explain why?
IMO, this is actually a good idea [not having global state]. it does
provide capability based security even if that wasn't the original goal.
I also liked the IoC built into the language.

 
 The other main problem comes from the tabs as indents, this explains
 why it's bad: 
 http://mail.python.org/pipermail/python-list/2003-January/183758.html
 


This is (for me) the most important reason why I won't use this language
(even though I like some of the ideas behind it). I hate Python syntax.
mainly because the indentation style is forced on the programmer. I do
recognize that there are use-cases for this style but I also think this
should not be forced for _all_ use-cases. Ruby, for example, provides
two ways (you can either use braces or the "end" keyword). IMHO, this
should be provided as a compiler option.

another example is Nemerle that provides "#pragma indent". see
http://nemerle.org/Indentation-based_syntax



 There are other problems in Delight, but I think they are minor.
 
 There's a (for me) surprisingly large discussion on Reddit about
 Delight, 82 comments so far: 
 http://www.reddit.com/r/programming/comments/73d15/d_meets_python/
 
 Bye, bearophile
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Yigal Chripun:


Could you explain why? IMO, this is actually a good idea [not having global
state]. it does provide capability based security even if that wasn't the
original goal.<


I have never programmed in a language without global state, so I presume I have
to try it before criticizing it.
I think of global vars like the "goto" in D: usually (for sizable programs) you
can do better without them, but once in a while they may help.
And I think in quick & dirty script-like programs 10-20 lines long that you
need to use few times global variables may speed up your programming.

And in D/Python modules I use global functions all the time, I don't use just
classes like in Java.

Bye,
bearophile
Sep 25 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
bearophile:

 I have never programmed in a language without global state,<


That's false, I have used Scheme for several months, without global state.

Bye,
bearophile
Sep 25 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
bearophile wrote:

 Yigal Chripun:
 

 Could you explain why? IMO, this is actually a good idea [not
 having global state]. it does provide capability based security
 even if that wasn't the original goal.<


 
 I have never programmed in a language without global state, so I
 presume I have to try it before criticizing it. I think of global
 vars like the "goto" in D: usually (for sizable programs) you can do
 better without them, but once in a while they may help. And I think
 in quick & dirty script-like programs 10-20 lines long that you need
 to use few times global variables may speed up your programming.
 
 And in D/Python modules I use global functions all the time, I don't
 use just classes like in Java.
 
 Bye, bearophile


From what I understood, global functions are allowed.
What is disallowed is global _state_ only.
regarding your goto example:
I agree that there are rare cases where unsafe features can be helpful
like goto statements. I like the D approach of being a practical
language and not force a religion on you. contrast that with Java where
goto is a reserved word specifically so you won't be able to use it.
however, I'd like to see a way to mark those features and separate them
from the regular safe code.

those dirty tricks are available to you and you can use them if, for
example, you just need to do a quick'n'dirty short script. However,
those dirty trick will be marked as such in large code-bases and would
be handled appropriately.
Also, the compiler could have a "safe" flag to disallow those features
and issue errors/warnings with info about lack of safety.
for example, static state breaks multi threaded code and all such state
should be either marked as thread local or synchronized. marking this as
"unsafe" will warn the programmer about such implications.
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Yigal Chripun:

 From what I understood, global functions are allowed.


This is the (not nice to me) hello world:

import dlt.io

class Main:
	void main(Printer stdout):
		stdout("Hello World!\n")


So I presume you need a least one class into your code.

Bye,
bearophile
Sep 25 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
Content-Disposition: inline

On Fri, Sep 26, 2008 at 4:33 AM, bearophile <bearophileHUGS lycos.com>wrote:


 Yigal Chripun:

 From what I understood, global functions are allowed.


 This is the (not nice to me) hello world:

 import dlt.io

 class Main:
        void main(Printer stdout):
                stdout("Hello World!\n")


 So I presume you need a least one class into your code.


That surprised me too.  He's probably been drinking too much OO/Java
kool-aid.

--bb
Sep 25 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
bearophile wrote:

 Yigal Chripun:

 From what I understood, global functions are allowed.


 
 This is the (not nice to me) hello world:
 
 import dlt.io
 
 class Main:
 	void main(Printer stdout):
 		stdout("Hello World!\n")
 
 
 So I presume you need a least one class into your code.
 
 Bye,
 bearophile


You're confusing two separate issues.
see: http://delight.sourceforge.net/syntax.html
there _are_ top level functions in delight.

from what I understand the Main class is due to the IoC feature and the
fact that you want to pass "global" state to your program.
here's a snippet from the above link:


class Main:


	in Printer stdout

	void main():
		stdout(addNewline(greeting))

So you construct a Main instance and pass it all the needed outside
state, than you use the main method to start your program.
another option, as in your example from the "overview" page is to pass
the outside state directly as parameters to the main method.

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.
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Sep 28 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
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
Sep 28 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:


 There is no main module in D.  The main() function can be in any module.


This true for Python too. What I have named conventionally "main module" is the
module you call bud (or a saner D compiler able to find the necessary modules
by itself) with. If you call bud with another name, then the "main module"
becomes magically the new one.



 There are no specific privileges for the first module on the command 
 line except sometimes compiler derives an output name from it.


I think that's bad.



 Why don't you want to use versions instead?  For the module builders for 
 instance it could be:
 do unittests:
 bud builders -unittest -version=builders
 benchmark:
 bud builders -version=builders -version=benchmark


Don't you see something bad in what you have written? You have expressed the
name 'builders' two times in your command line.
So why can't the compiler, given the line:
dmd builders
define a compile variable that's true inside builders.d and false for all the
other modules.
While when you compile for example:
dmd foo
is true inside foo and false for all the other modules, including builders?

Bye,
bearophile
Sep 28 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 28 Sep 2008 19:34:25 -0400,
bearophile wrote:

 Sergey Gromov:
 

 There is no main module in D.  The main() function can be in any module.


 
 This true for Python too. What I have named conventionally "main
 module" is the module you call bud (or a saner D compiler able to find
 the necessary modules by itself) with. If you call bud with another
 name, then the "main module" becomes magically the new one.
 

 There are no specific privileges for the first module on the command 
 line except sometimes compiler derives an output name from it.


 
 I think that's bad.


What if a makefile builds all modules by "dmd -c module.d" and then 
links object files together?  That's how bud works.  Which module is 
"main" then?

I'll tell you, it's not the compiler's task.  Compiler is not a build 
system.  Recursive building is a special case for simple tools, and in a 
large project you do want an incremental build.

But a build system can definitely do that.  Bud could do that.  Bud 
could define a -version=builders, or define -version=mainmodule when 
compiling the first module in the chain.


 Why don't you want to use versions instead?  For the module builders for 
 instance it could be:
 do unittests:
 bud builders -unittest -version=builders
 benchmark:
 bud builders -version=builders -version=benchmark


 
 Don't you see something bad in what you have written? You have
 expressed the name 'builders' two times in your command line.


I'd definitely better specify a module name twice than modify module 
source every time I want to benchmark.
Sep 28 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:


 Recursive building is a special case for simple tools, and in a 
 large project you do want an incremental build.


This is true, but for small programs it seems bud (and another similar tool) is
enough (my experience with DMD shows that 'small' means up to more than 80000
lines of code). And putting that basic functionality into the compiler, that
already parses code, can probably bump that limit up a little higher.
So why not offer a handy feature for all the small cases, plus the capability
of using complex incremental builds for large programs?
Giving the programmer sensible "defaults" for simple very common cases (such
very common cases have to be found experimentally) sometimes makes the
difference between a handy computer language (or a handy technological system)
and a language that isn't nice at all (this is often one little secret of
scripting languages).
If D wants to be used for smaller programs too (see the other thread here about
people using D for scripting-like purposes of text processing) sensible
defaults and a handy building becomes important.
Do you know why DMD has the -run compilation flag, plus it accepts the shebang
syntax that you often find at the top of scripts like Perl/Python ones? It may
be of little use if you have to compile a large project, but for smaller
quicker things they are useful.



 But a build system can definitely do that.  Bud could do that.  Bud 
 could define a -version=builders, or define -version=mainmodule when 
 compiling the first module in the chain.


I see :-) Well, this solution of yours is better than nothing. I don't know if
bud is updated still.
But the name of the constant you have to use into the code is is different for
each module, it's not a standard one like I have suggested. So your solution is
worse still.

Bye,
bearophile
Sep 28 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 28 Sep 2008 20:40:53 -0400,
bearophile wrote:

 Sergey Gromov:
 

 Recursive building is a special case for simple tools, and in a 
 large project you do want an incremental build.


 
 So why not offer a handy feature for all the small cases, plus the
 capability of using complex incremental builds for large programs?


Well, the "give me all source on the command line" thing is a C legacy 
where compiler simply couldn't deduce the files required to build the 
project.  In D it's possible and there probably should be an -auto 
option in DMD.  Maybe -version=auto could be defined for the first 
module then.  I'm not sure.


 But a build system can definitely do that.  Bud could do that.  Bud 
 could define a -version=builders, or define -version=mainmodule when 
 compiling the first module in the chain.


 
 I see :-) Well, this solution of yours is better than nothing. I don't
 know if bud is updated still.


Bud supports D2.  This means it's being maintained.


 But the name of the constant you have to use into the code is is
 different for each module, it's not a standard one like I have
 suggested. So your solution is worse still.


Please read again:


 or define -version=mainmodule when compiling the first module in the
 chain.




It's completely up to the build system which way to go, it has all the 
flexibility.
Sep 28 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Sergey Gromov" <snake.scaly gmail.com> wrote in message 
news:MPG.234a6d462c08ea3198971e news.digitalmars.com...

 or define -version=mainmodule when compiling the first module in the
 chain.




 It's completely up to the build system which way to go, it has all the
 flexibility.


Flexibility can be nice, but for something like what's being discussed here 
I think I'd prefer a language-wide standard.
Sep 28 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:


 Please read again:

 or define -version=mainmodule when compiling the first module in the
 chain.






You are right, I am sorry for missing that.

-----------

Nick Sabalausky:


Flexibility can be nice, but for something like what's being discussed here I
think I'd prefer a language-wide standard.<


I agree.

Bye and thanks for the interesting discussion,
bearophile
Sep 28 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
bearophile wrote:

 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


In a perfect world, I'd want a different solution:
the _linker_ needs to have a command line flag that tells it what
compilation unit contains the main function. (i.e. what's the "main"
module).
the compiler can safely compile the main function in each module so all
object files can contain main functions, but at link time the linker
will use only the main function in the specified module.
No need for anything in the code such as a a version block or an if
statement.

this solution does require to change the linker though, and mark "main"
functions with a marker of some sort to be recognized by the linker.

I know that Walter is unlikely to make any changes to the liker though :(

build tools like rebuild do parse the code so maybe they can implement
the above instead of the linker. another possibility is to have an
_implicit_ version block with the name of the module defined for each
module.

your code is:

module A;
...code...
void main() {..code..}

the compiler treats it as:

module A;
...code...
version A {
    void main() {..code..}
}

on the command-line you'd use it as:
dmd source_files -version=A
(or maybe define a different name like --main=A)
Sep 28 2008
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
bearophile wrote:

 Sergey Gromov:

 I'd like to look at some real-world example written in Delight.


 
 I have not tried to run it yet because it's for Linux for now.
 
 

 I'm afraid that the lack of global state will result in either a huge amount 
 of arguments passed to every function or huge ad-hoc interfaces grouping 
 other interfaces just to pass some functionality up-stream.


 
 I agree, that's one of the main things I think have to be fixed in Delight,
having global vars (and maybe a global main function too).
 
 The other main problem comes from the tabs as indents, this explains why it's
bad:
 http://mail.python.org/pipermail/python-list/2003-January/183758.html
 
 There are other problems in Delight, but I think they are minor.
 
 There's a (for me) surprisingly large discussion on Reddit about Delight, 82
comments so far:
 http://www.reddit.com/r/programming/comments/73d15/d_meets_python/
 
 Bye,
 bearophile


I disagree.  I always use tabs.  This allows me to adjust the 
indentation width on the fly and as needed, which spaces would not allow.

OTOH, I do agree that a mixture of spaces and tabs should be forbidden 
in any language where indentation level is syntactically meaningful, and 
probably also in any language where it's semantically meaningful.
Sep 25 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Charles Hixson:

 I disagree.  I always use tabs.  This allows me to adjust the 
 indentation width on the fly and as needed, which spaces would not allow.


You can use a little regex to replace the leading spaces, to increase or
decrease them at will. Your disadvantage is nothing compared to the problems
shown in that post I have linked.

Eggs should be broken from big end, everyone knows it ;-)

Bye,
bearophile
Sep 25 2008
parent Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:

 Charles Hixson:

 I disagree.  I always use tabs.  This allows me to adjust the 
 indentation width on the fly and as needed, which spaces would not allow.


 
 You can use a little regex to replace the leading spaces, to increase or
decrease them at will. Your disadvantage is nothing compared to the problems
shown in that post I have linked.


This is not an option if you use a source control system -- you'll 
change every line of the file with each revision.
Sep 25 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
Content-Disposition: inline

On Fri, Sep 26, 2008 at 4:24 AM, Charles Hixson <charleshixsn earthlink.net>
wrote:

 bearophile wrote:

 Sergey Gromov:

 I'd like to look at some real-world example written in Delight.


 I have not tried to run it yet because it's for Linux for now.



 I'm afraid that the lack of global state will result in either a huge
 amount of arguments passed to every function or huge ad-hoc interfaces
 grouping other interfaces just to pass some functionality up-stream.


 I agree, that's one of the main things I think have to be fixed in
 Delight, having global vars (and maybe a global main function too).

 The other main problem comes from the tabs as indents, this explains why
 it's bad:
 http://mail.python.org/pipermail/python-list/2003-January/183758.html

 There are other problems in Delight, but I think they are minor.

 There's a (for me) surprisingly large discussion on Reddit about Delight,
 82 comments so far:
 http://www.reddit.com/r/programming/comments/73d15/d_meets_python/

 Bye,
 bearophile


 I disagree.  I always use tabs.  This allows me to adjust the indentation
 width on the fly and as needed, which spaces would not allow.


Did you even read the doc Bearophile posted?  If so try rebutting the
arguments there. That point is specifically addressed in the thing he linked
to.

--bb
Sep 25 2008
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Bill Baxter wrote:

 On Fri, Sep 26, 2008 at 4:24 AM, Charles Hixson 
 <charleshixsn earthlink.net <mailto:charleshixsn earthlink.net>> wrote:
  > bearophile wrote:
  >>
  >> Sergey Gromov:
  >>>
  >>> I'd like to look at some real-world example written in Delight.
  >>
  >> I have not tried to run it yet because it's for Linux for now.
  >>
  >>
  >>> I'm afraid that the lack of global state will result in either a huge
  >>> amount of arguments passed to every function or huge ad-hoc interfaces
  >>> grouping other interfaces just to pass some functionality up-stream.
  >>
  >> I agree, that's one of the main things I think have to be fixed in
  >> Delight, having global vars (and maybe a global main function too).
  >>
  >> The other main problem comes from the tabs as indents, this explains why
  >> it's bad:
  >> http://mail.python.org/pipermail/python-list/2003-January/183758.html
  >>
  >> There are other problems in Delight, but I think they are minor.
  >>
  >> There's a (for me) surprisingly large discussion on Reddit about 
 Delight,
  >> 82 comments so far:
  >> http://www.reddit.com/r/programming/comments/73d15/d_meets_python/
  >>
  >> Bye,
  >> bearophile
  >
  > I disagree.  I always use tabs.  This allows me to adjust the indentation
  > width on the fly and as needed, which spaces would not allow.
 
 Did you even read the doc Bearophile posted?  If so try rebutting the 
 arguments there. That point is specifically addressed in the thing he 
 linked to.
 
 --bb


OK, I'll try to do it point by point.  (I first read this years ago when 
it came out on the python list.)
1) >> All tabs works fine regardless of editor tab stops. All spaces works

 fine. Mixed spaces and tabs is deadly.




Agreed.

2) So is the use of tabs in certain contexts; in particular any attempt

 to e-mail a python source to someone using Outlook Express. OE
 has this nasty habit of ignoring leading tabs.


Sorry, I'm not going to let MS shape my preferences.  Nor some other 
silly editors that also automatically convert tabs to spaces, not other 
silly editors that presume that a tab must equal 8 spaces.

3) long example is mixing tabs and spaces by invoking two different 
programmers.  This is, indeed, bad, but tabs and spaces are equally 
good/bad in this context.  (And yes, I've been bitten...and due to that 
I really despise spaces as linguistic separators.)

4) "The second argument (tabs mean everyone can use their favorite
indentation) sounds nice at first, but simply doesn't work in the real
world. It inevitably, and I do mean *inevitably*, leads to ugly
space-tab mixing. Even code written by only one author using one text
editor won't be able to avoid it!"
Now that's *REALLY* stupid and false to boot.  I only ever use spaces 
when I'm reformatting my code for use externally, and that's just 
because of people/applications who are equally .... I can't think of a 
polite adjective that's accurate.

5) "I don't like tab characters. I wish they would go away ..."
That's his only real argument, but at least he's eventually honest 
enough to come out with it.

--------------------------------------------------------
As I said, I first read this years ago.  Since that time my opinions on 
the matter have become more convinced.  I have never seen any evidence 
that on honest examination didn't boil down to "I don't like tabs".  So 
I kludge when I must exchange code with such people/applications, and 
when I receive code that uses space for indentation, I laboriously 
remedy the problem.  But I don't think there was was better.  (Actually, 
it's not usually all that laborious, but it's extra work that I despise 
having to do.)
Sep 25 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <gbgs5p$26n$1 digitalmars.com>, charleshixsn earthlink.net 
says...

 As I said, I first read this years ago.  Since that time my opinions on 
 the matter have become more convinced.  I have never seen any evidence 
 that on honest examination didn't boil down to "I don't like tabs".  So 
 I kludge when I must exchange code with such people/applications, and 
 when I receive code that uses space for indentation, I laboriously 
 remedy the problem.  But I don't think there was was better.  (Actually, 
 it's not usually all that laborious, but it's extra work that I despise 
 having to do.)


To myself, I've reduced the spaces/tabs cons to the following:

If you use strictly spaces, you must negotiate indentation width for a 
project, you must cope with the chosen indentation width if you don't 
like it, and you'll probably want to switch between different widths if 
you work on many external projects, though nothing bad happens if you 
forget.

If you use strictly tabs, you must never, ever, align things in columns 
except by the means of indentation, and therefore you can have only one 
aligned column.

That's it.  The rest is a matter of personal choice.  There is only one 
con for tabs, and if you consider it minor, then tabs are for you.
Sep 25 2008
next sibling parent reply e-t172 <e-t172 akegroup.org> writes:
Sergey Gromov a =E9crit :

 If you use strictly tabs, you must never, ever, align things in columns=


=20

 except by the means of indentation, and therefore you can have only one=


=20

 aligned column.


Tabs are not meant to align things. Spaces are used for that. You indent =

with tabs, and align with spaces. For example (___> means tab, . means=20
space):

no indentation
___>indentation
___>|.column 1.|.column 2.|.column.3.|
___>|.field.1..|.field.2..|.field.3..|
___>|.field.4..|.field.5..|.field.6..|

If you only align with space, there will not be any problem regarding=20
different "tabwidths", ever.

--=20
Etienne Dechamps / e-t172 - AKE Group

Website: http://www.e-t172.net/
Contact: e-t172 akegroup.org

Phone: +33547414942
Sep 25 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
In article <mailman.251.1222378060.19733.digitalmars-d-
announce puremagic.com>, e-t172 akegroup.org says...

 Sergey Gromov a ecrit :

 If you use strictly tabs, you must never, ever, align things in columns 
 except by the means of indentation, and therefore you can have only one 
 aligned column.


 
 Tabs are not meant to align things. Spaces are used for that. You indent
 with tabs, and align with spaces. For example (___> means tab, . means 
 space):
 
 no indentation
 ___>indentation
 ___>|.column 1.|.column 2.|.column.3.|
 ___>|.field.1..|.field.2..|.field.3..|
 ___>|.field.4..|.field.5..|.field.6..|
 
 If you only align with space, there will not be any problem regarding 
 different "tabwidths", ever.


You use a mixture of tabs and spaces.  Now you must carefully attend to 
what you are typing and which key you use to make a certain part of 
white space.  Especially if you're re-aligning things.  This approach is 
error-prone, and once in a while you *will* put a space or a tab 
somewhere it doesn't belong, annoying your colleagues and introducing 
indentation errors in your Python code.

Of course you can have whitespace always visible, or use a very smart 
editor.  But even the smartest editor will fail sometimes.
Sep 25 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:

 You use a mixture of tabs and spaces.  Now you must carefully attend to 
 what you are typing and which key you use to make a certain part of 
 white space.  Especially if you're re-aligning things.  This approach is 
 error-prone, and once in a while you *will* put a space or a tab 
 somewhere it doesn't belong, annoying your colleagues and introducing 
 indentation errors in your Python code.


Oh, here there are no problems: Python 3 forbids mixing tabs and spaces in the
same module ^_^ So it doesn't even run ;-)

Bye,
bearophile
Sep 25 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Sep 26, 2008 at 6:03 AM, Sergey Gromov <snake.scaly gmail.com> wrote:

 In article <gbgs5p$26n$1 digitalmars.com>, charleshixsn earthlink.net
 says...

 As I said, I first read this years ago.  Since that time my opinions on
 the matter have become more convinced.  I have never seen any evidence
 that on honest examination didn't boil down to "I don't like tabs".  So
 I kludge when I must exchange code with such people/applications, and
 when I receive code that uses space for indentation, I laboriously
 remedy the problem.  But I don't think there was was better.  (Actually,
 it's not usually all that laborious, but it's extra work that I despise
 having to do.)


 To myself, I've reduced the spaces/tabs cons to the following:

 If you use strictly spaces, you must negotiate indentation width for a
 project, you must cope with the chosen indentation width if you don't
 like it, and you'll probably want to switch between different widths if
 you work on many external projects, though nothing bad happens if you
 forget.

 If you use strictly tabs, you must never, ever, align things in columns
 except by the means of indentation, and therefore you can have only one
 aligned column.

 That's it.  The rest is a matter of personal choice.  There is only one
 con for tabs, and if you consider it minor, then tabs are for you.


My version of it is:

Pro tabs argument:  "Assuming everyone uses a perfect text editor that
handles tabs flawlessly at all times, then tabs are great!"    Bzzzt!
fail on underpinning assumption.  This is the Idealist's argument.

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.

So it is pragmatist vs idealist in the end.  I agree that in a perfect
world every editor would handle tabs perfectly and we'd all work
together for the common good and no one would ever be hungry or
overweight or sick.  But that's not the world we live in.

--bb
Sep 25 2008
parent reply 0ffh <frank youknow.what.todo.interNETz> writes:
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
Sep 25 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
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
Sep 26 2008
parent 0ffh <frank youknow.what.todo.interNETz> writes:
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
Sep 26 2008
prev sibling next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
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);

my experience from java is that not getting access to the index can be a
real problem.

Looks good overall thou I'm particularly curious about how the dependency
injection will turn out. It feels slightly similar to pure in an object
oriented way :)

/Johan Granberg
Sep 25 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Johan Granberg wrote:

 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);
 
 my experience from java is that not getting access to the index can be a
 real problem.



much as 95%.

That still means I have to turn 1 out of every 20 loops into:
int i = 0;
foreach (Type var in collection)
{
	// do stuff, and then...
	i++;
}
Sep 25 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
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:


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


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


for i, x in ["red", "green", "blue"]:



for key, value in dictionary:
	stdout.formatln("{} -> {}", key, value)


for (int i = 1; i < 10; i++):
	stdout.formatln("i = {}", i)


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
Sep 27 2008
prev sibling parent reply Thomas Leonard <talex5+d gmail.com> writes:
On Thu, 25 Sep 2008 22:33:54 +0200, Johan Granberg wrote:


 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 :)


It's now based on D2. The main problem was that Tango's D2 branch doesn't 
work with GDC, so I had to switch to Phobos instead.

Pretty much all D syntax has a direct equivalent in Delight. The main 
missing things are:

- labels (and therefore goto). They might come back later (with a new 
  syntax, since colon is used for indented blocks).

- anonymous functions are limited to expressions (as in Python).

In addition, these things are only available to modules in the dlt.* 
namespace:

- module level variables
- static variables
- extern

This is to encourage external libraries to be wrapped, since they 
generally don't fit in with the style the language is experimenting with.


 Looks good overall thou I'm particularly curious about how the
 dependency injection will turn out. It feels slightly similar to pure in
 an object oriented way :)
Oct 09 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Oct 9, 2008 at 8:06 PM, Thomas Leonard <talex5+d gmail.com> wrote:

 - labels (and therefore goto). They might come back later (with a new
  syntax, since colon is used for indented blocks).


Is there any syntactic requirement for colons on blocks as in Python?
At least when I've used Python I've done nothing but curse and swear
profusely when I forget a colon where it's completely obvious what my
intent is.  Couldn't they be eliminated?
Oct 09 2008
next sibling parent reply Thomas Leonard <talex5+d gmail.com> writes:
On Thu, 09 Oct 2008 20:40:57 +0200, Jarrett Billingsley wrote:


 On Thu, Oct 9, 2008 at 8:06 PM, Thomas Leonard <talex5+d gmail.com>
 wrote:

 - labels (and therefore goto). They might come back later (with a new
  syntax, since colon is used for indented blocks).


 
 Is there any syntactic requirement for colons on blocks as in Python? At
 least when I've used Python I've done nothing but curse and swear
 profusely when I forget a colon where it's completely obvious what my
 intent is.  Couldn't they be eliminated?


I don't think so. For example:

  if a .b .c

could mean

  if a: .b.c

or

  if a.b: .c

Probably removing the : would require () around the condition.
Oct 10 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Oct 10, 2008 at 9:33 PM, Thomas Leonard <talex5+d gmail.com> wrote:


 I don't think so. For example:


Well in that case, couldn't they be required if there's code on the
same line, and optional otherwise?  That is, a newline followed by an
indent is a perfectly clear indication that a block is beginning.
It's redundant (and ugly) to force the colon at the end of a line.
Oct 10 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 11 Oct 2008 06:01:18 +0200,
Jarrett Billingsley wrote:

 On Fri, Oct 10, 2008 at 9:33 PM, Thomas Leonard <talex5+d gmail.com> wrote:
 

 I don't think so. For example:


 
 Well in that case, couldn't they be required if there's code on the
 same line, and optional otherwise?  That is, a newline followed by an
 indent is a perfectly clear indication that a block is beginning.
 It's redundant (and ugly) to force the colon at the end of a line.


How do you wrap a long expression?
Oct 10 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:

 Is there any syntactic requirement for colons on blocks as in Python?


People have performed an usability survey, and they have seen that in Python
code colons improve code readability there. So removing them is bad.
(Performing such studies is light years ahead to the way D syntax currently
develops).

Bye,
bearophile
Oct 11 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Few comments on Delight:
- The string type is used quite commonly, so it may be named 'str' instead.
- The syntax for "new" may be improved
- "in" syntax for arrays may be added.
- I can offer code for set() compatible with Python (currently missing a couple
of methods still, I'm finishing it still).
- Time ago I have sent an email to Thomas Leonard regarding Delight,
unanswered. But I haven't used that talex5+d at gmail dot com address, is
talex5+d... usable?

Bye,
bearophile
Oct 11 2008
parent reply Thomas Leonard <talex5+d gmail.com> writes:
On Sat, 11 Oct 2008 10:34:44 -0400, bearophile wrote:


 Few comments on Delight:
 - The string type is used quite commonly, so it may be named 'str'
 instead.


I might rename some other types too. e.g.

  int16, int32, int64
  uint16, uint32, uint64

The only reason to use short or long is because you care about the size, 
so might as well make it explicit.


 - The syntax for "new" may be improved


How? It could be removed, I suppose, as in Python.


 - "in" syntax for arrays may be added.


Like this?

  if ':' in aString: ...

  if "seq" in aString: ...

Would be nice. Any chance of getting this in D?


 - I can offer code for set() compatible with Python
 (currently missing a couple of methods still, I'm finishing it still).


Likewise.


 - Time ago I have sent an email to Thomas Leonard regarding Delight,
 unanswered. But I haven't used that talex5+d at gmail dot com address,
 is talex5+d... usable?


Ah. I found some messages about it in my spam folder today. Let me know 
if you still didn't get a reply...
Oct 11 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Thomas Leonard:


 I might rename some other types too. e.g.
   int16, int32, int64
   uint16, uint32, uint64


I don't like to type "int32" all the time, so I think "int" and "long" may be
better.

An intermediate solution of mine that allows for shorter names is to use the
number of bytes instead:

int1, int2, int4, int8, uint1, uint2, uint4, uint8
float4, float8, float10
int uint (they are ssize_t/size_t, that is the signed/unsigned size_t).

But maybe keeping the current D names may be better...



 - The syntax for "new" may be improved


 How? It could be removed, I suppose, as in Python.


I don't know. Maybe the D syntax:
new Classname

May become as in Ruby:
Classname.new



 Like this?
   if ':' in aString: ...
   if "seq" in aString: ...
 Would be nice.


Yes, like that.



 Any chance of getting this in D?


I think Walter doesn't like that in D.

But I think your "compiler" may translate this Delight code:
if ':' in aString: ...

into the equivalent of the following D:
if isIn(':', aString) { ...

You can find the isIn() function template is in my libs. Tango probably has a
similar function.



 Likewise.


It's just a module of mine, so (once it's complete) you can add it to the
stanrdard modules of Delight... You may even load it by default, but Delight
isn't Python, so adding an import when you want to use sets seems acceptable.
(If necessary, it's probably easy to translate my "sets" module into Delight
code).



 Let me know if you still didn't get a reply...<


I have received it now (generally I don't want to disturb, so I didn't press
myself in other ways, thinking you were uninterested in my comments).

I suggest you to add few more examples of small Delight programs in your site,
plus if you want a few benchmarks to compare it with D/Python (benchmarks can
be found here:  http://shootout.alioth.debian.org/gp4/index.php), so you can
give put some numbers behind your statement that performance is sometimes one
advantage of Delight over Python (but not in everything, for example Python
dicts are often faster, etc).

Bye,
bearophile
Oct 11 2008
parent reply Thomas Leonard <talex5+d gmail.com> writes:
On Sat, 11 Oct 2008 13:33:15 -0400, bearophile wrote:

 Thomas Leonard:
 

 I might rename some other types too. e.g.
   int16, int32, int64
   uint16, uint32, uint64


 
 I don't like to type "int32" all the time, so I think "int" and "long"
 may be better.


"int" would still be available as an alias (probably to int64).


 - The syntax for "new" may be improved


 How? It could be removed, I suppose, as in Python.


 
 I don't know. Maybe the D syntax:
 new Classname


Doesn't that work at the moment?


 Like this?
   if ':' in aString: ...
   if "seq" in aString: ...


 

 Any chance of getting this in D?


 
 I think Walter doesn't like that in D.


Ah, OK. It's pretty useful, so I might add it anyway.

[sets] 

 It's just a module of mine, so (once it's complete) you can add it to
 the stanrdard modules of Delight... You may even load it by default, but
 Delight isn't Python, so adding an import when you want to use sets
 seems acceptable. (If necessary, it's probably easy to translate my
 "sets" module into Delight code).


No need. Delight can parse D code too. The only problem is D code doesn't 
indicate whether pointers can be null or not. I might add a "notnull" 
type modifier to the D parser so that D interfaces can be modified easily 
without changing their whole syntax.


 I suggest you to add few more examples of small Delight programs in your
 site,


There's a simple web server here, for a slightly longer example:

  http://delight.sourceforge.net/examples.html
Oct 12 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Thomas Leonard:


"int" would still be available as an alias (probably to int64).


That may cause troubles because in D int is 32 bit.
So it may be an alias to the signed size_t, or of the 32 bit int...



Doesn't that work at the moment?<


I don't see the Ruby-like syntax in your site.



There's a simple web server here, for a slightly longer example:<


I did see that. But I think few more mixed little examples are can be really
useful. Look at the code of the Shootout, because it's useful as "rosetta code"
too, not just for its original benchmarking purposes.

Look in your filtered emails again :-)

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

More things from the site:


- anonymous functions work ("function(int x): x + 1"). This is like


lambda in Python.<

Note that D1 and D2 already support this syntax:
(int x, float y) { return x+y; }


For Delight a little shorter syntax may be adopted, for example:
(int x, float y): x+y
Or:
lambda int x, float y: x+y
Or:
fun int x, float y: x+y
Or:
int x, float y => x+y



- any object can be implicitly cast to Object (D doesn't allow this)<


Is this good? (just asking)



Statements end at the end of a line. Semi-colons are not required.<


Is the \ syntax possible for too much long lines, as in Python?



(the author is arguing for spaces, but the main point is consistency).<


Nope, the main point was to not use tabs to indent code in Python. You can't
miss a "detail" as important as this in such post.



Anonymous functions cannot access variables in their containing function, but
you can use a delegate for that:<


When not specified you can use a delegate by default (as D does inside
functions).



These are D/Java style try/catch/finally syntax:<


The semantics of D exceptions is quite different from the Java one.

Bye,
bearophile
Oct 12 2008
parent reply Thomas Leonard <talex5+d gmail.com> writes:
On Sun, 12 Oct 2008 09:56:56 -0400, bearophile wrote:

 More things from the site:



 Thomas Leonard:

- anonymous functions work ("function(int x): x + 1"). This is like


 lambda in Python.<
 
 Note that D1 and D2 already support this syntax: (int x, float y) {
 return x+y; }


Unfortunately, the corresponding syntax is ambiguous:

  while 1 + (something): ...

Is something an expression or a list of arguments? D just looks after the 
closing ) and sees that the next character is a block start, but that 
only works because it always has an extra outer pair of ().

We could do something like:

  map( (int x) -> x + 1, [1,2,3])

But I don't really like having to look ahead to work out what it is. 
Having 'function' or 'delegate' come first makes parsing easier (e.g. for 
syntax highlighters, etc).


- any object can be implicitly cast to Object (D doesn't allow this)<


 
 Is this good? (just asking)


I've now adding a 'linkage' field to interfaces. You can cast any 
interface to Object iff it has D linkage. So COM objects can't be 
accidentally treated as D objects again, but it's still convenient
in the common case.

I don't use COM, but I needed this when adding GObject linkage:

  http://delight.sourceforge.net/gtk.html
 

Statements end at the end of a line. Semi-colons are not required.<


 
 Is the \ syntax possible for too much long lines, as in Python?


Currently you need some kind of brackets, but I'll add \ at some point.
Oct 26 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Thomas Leonard:

 Having 'function' or 'delegate' come first makes parsing easier (e.g. for 
 syntax highlighters, etc).



fun or def may be used as shorter form of function.

Bye,
bearophile
Oct 26 2008
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Thursday, 25 September 2008 at 14:27:42 UTC, 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


"Improves" is pretty subjective...
Jan 02 2014
prev sibling next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
bearophile schrieb:

 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


Good to see another BOO.
bearophile, if you hate D that much : write a Python compiler.
Bjoern
Sep 25 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
BLS:

 bearophile, if you hate D that much : write a Python compiler.


You are silly, I like D.
And I have already done that (I have given help):
http://code.google.com/p/shedskin/

Bye,
bearophile
Sep 25 2008
parent BLS <nanali nospam-wanadoo.fr> writes:
bearophile schrieb:

 BLS:

 bearophile, if you hate D that much : write a Python compiler.


 
 You are silly, I like D.
 And I have already done that (I have given help):
 http://code.google.com/p/shedskin/
 
 Bye,
 bearophile


To me it seems to be silly to compare Python and D.
Bjoern
PS / I know that you are a D Enthusiast. But  Sometimes I wonder why.
Sep 25 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Sep 25 2008
next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
Sep 25 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
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.
Sep 25 2008
parent reply Mosfet <mosfet anonymous.org> writes:
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 ?
Sep 26 2008
parent Lutger <lutger.blijdestijn gmail.com> writes:
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."
Sep 26 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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.
Sep 27 2008
prev sibling next sibling parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
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


So -- this is like a preprocessor for D??  :->
Sep 25 2008
parent "Nick Sabalausky" <a a.a> writes:
"Paul D. Anderson" <paul.d.removethis.anderson comcast.andthis.net> wrote in 
message news:gbh5dn$knc$1 digitalmars.com...

 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


 So -- this is like a preprocessor for D??  :->


You know, the irony I see with this language is that I've personally been 
very tempted to write a preprocessor for Python that gives it C-style (or 
maybe Basic/Perl-style) scope blocks (instead of indentation) and manditory 
explicit variable declarations.
Sep 25 2008
prev sibling next sibling parent Kenny B <funisher gmail.com> writes:
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
Sep 25 2008
prev sibling next sibling parent reply "pplantinga" <plantinga.peter gmail.com> writes:
On Thursday, 25 September 2008 at 14:00:30 UTC, 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


It's close to my ideal language as well, which is why I've 
decided to take up the cause again. Unfortunately the last 
changes to the code were 5 years ago, and D has progressed since 
then. So I'm going to start over with the same ideals in mind. If 
anyone wants to contribute, the code will be hosted at 
http://github.com/pplantinga/delight

So I have what is probably a noob question: is there any way for 
me to compile the generated D code without packaging an entire D 
compiler?
Dec 30 2013
parent Parke <parke.nexus gmail.com> writes:
 On Thursday, 25 September 2008 at 14:00:30 UTC, bearophile wrote:

 D1 + Tango with a different Python-inspired syntax; close to my ideal
 language:
 http://delight.sourceforge.net/




On Mon, Dec 30, 2013 at 6:31 PM, pplantinga <plantinga.peter gmail.com> wrote:

 It's close to my ideal language as well, which is why I've decided to take
 up the cause again. Unfortunately the last changes to the code were 5 years
 ago, and D has progressed since then. So I'm going to start over with the
 same ideals in mind. If anyone wants to contribute, the code will be hosted
 at http://github.com/pplantinga/delight


If anyone is interested, I was recently working on an indentation
based "alternative syntax" for D, which I have named Finesse.  Finesse
is written in Lua and outputs D source code.

https://github.com/parke/finesse

-Parke
Dec 31 2013
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Thursday, 25 September 2008 at 14:00:30 UTC, 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


Thank you for telling that it has "Python-inspired" syntax, so I 
save myself time by avoiding the project...
Jan 02 2014