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.

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?

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

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

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...

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

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

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

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.

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

 A syntax like C# lambdas looks better, but I understand your points. func o fun or def may be used as shorter form of function.

Bye,
bearophile