In another thread the idea was discussed of using [x] for template arguments.

The main objection to this was that it would be ambiguous with array indexing.
I know [x] has meant array indexing for a long time, but I think
there's not really any longstanding connection between that and any
math notation that existed previously.
In fact (x) is arguably a more mathematical way to index an array.  An
array is just a function that given some input returns some output.
So array(i) actually makes a lot of sense.

This is actually how Matlab behaves, in fact.   In Matlab you don't index with [i] you index with (i).

There's no reason as far as I can tell that [i] needs to mean array indexing.

So if you change array indexing to (i) (both std arrays and AAs) then
you can use [x] for template syntax.

I think the ambiguity between arrays and functions that would result is a non-issue.  An array is a kind of function so there's no real issue.  In fact in Matlab you have exactly that ambiguity and it works just fine.  In fact it's even more natural since it allows you to replace an array with a function any time your app's needs grow beyond the simple mapping function provided by the array.


Ok, it's probably totally unpalatable to anyone who has ever programmed in a C family language, but I think it could work if we had the stomach to do it.

--bb

Bill Baxter wrote:
> In another thread the idea was discussed of using [x] for template arguments.
> 
> The main objection to this was that it would be ambiguous with array indexing.
> I know [x] has meant array indexing for a long time, but I think
> there's not really any longstanding connection between that and any
> math notation that existed previously.
> In fact (x) is arguably a more mathematical way to index an array.  An
> array is just a function that given some input returns some output.
> So array(i) actually makes a lot of sense.
> 
> This is actually how Matlab behaves, in fact.   In Matlab you don't
> index with [i] you index with (i).
> 
> There's no reason as far as I can tell that [i] needs to mean array indexing.
> 
> So if you change array indexing to (i) (both std arrays and AAs) then
> you can use [x] for template syntax.
> 
> I think the ambiguity between arrays and functions that would result
> is a non-issue.  An array is a kind of function so there's no real
> issue.  In fact in Matlab you have exactly that ambiguity and it works
> just fine.  In fact it's even more natural since it allows you to
> replace an array with a function any time your app's needs grow beyond
> the simple mapping function provided by the array.
> 
> 
> Ok, it's probably totally unpalatable to anyone who has ever
> programmed in a C family language, but I think it could work if we had
> the stomach to do it.
> 
> --bb

Its also the way ADA worked.  It was a great feature because it made programming more generic.  Imagine being able to use an array in the same template without having to write a wrapper function (and visa versa).  Sadly I don't think D will ever adopt this as its a pretty radical change from C and D.  Also it means all the libs would have to be re-written to work with this when they get ported to D 2 or 3.

-Joel

On Thu, Oct 23, 2008 at 2:36 PM, Janderson <ask@me.com> wrote:
> Bill Baxter wrote:
>>
> Its also the way ADA worked.  It was a great feature because it made programming more generic.  Imagine being able to use an array in the same template without having to write a wrapper function (and visa versa).  Sadly I don't think D will ever adopt this as its a pretty radical change from C and D.  Also it means all the libs would have to be re-written to work with this when they get ported to D 2 or 3.

For the most part an automatic tool that changed !() to [] and [] to
() would work, but any class or struct that has both opIndex and
opCall would need to be redesigned.

So yeh, it would be a difficult transition.   I guess I'll just jot it down as a reminder in case I ever decided to implement my own language some day. :-)


--bb

Bill Baxter wrote:
> In another thread the idea was discussed of using [x] for template arguments.
> 
> The main objection to this was that it would be ambiguous with array indexing.
> I know [x] has meant array indexing for a long time, but I think
> there's not really any longstanding connection between that and any
> math notation that existed previously.
> In fact (x) is arguably a more mathematical way to index an array.  An
> array is just a function that given some input returns some output.
> So array(i) actually makes a lot of sense.
> 
> This is actually how Matlab behaves, in fact.   In Matlab you don't
> index with [i] you index with (i).
> 
> There's no reason as far as I can tell that [i] needs to mean array indexing.
> 
> So if you change array indexing to (i) (both std arrays and AAs) then
> you can use [x] for template syntax.
> 
> I think the ambiguity between arrays and functions that would result
> is a non-issue.  An array is a kind of function so there's no real
> issue.  In fact in Matlab you have exactly that ambiguity and it works
> just fine.  In fact it's even more natural since it allows you to
> replace an array with a function any time your app's needs grow beyond
> the simple mapping function provided by the array.
> 
> 
> Ok, it's probably totally unpalatable to anyone who has ever
> programmed in a C family language, but I think it could work if we had
> the stomach to do it.
> 
> --bb

Hum, that's a hard break from the C language family. Too much of a break I think.

Hum, on a side note, that makes me think how it would be like for a language like D, with the same semantics as D, but having a completely redesigned syntax, from the grounds up. I wonder if there could be significant advantages in such a language (in clarity, consistency, expressiveness, etc).
Because it is the case that D is continuously getting new additions in syntax and semantics. But while semantics are generally easier to change and refactor, because there is an infinite "domain space" for semantics, the "domain space" for (reasonable) syntax is limited, as we saw recently with the desire in the new template instantiation discussions about a new kind of brackets. And refactoring/restructuring the syntax of a language to accommodate such changes is such a breaking change that is nearly impractical without creating a new language.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Fri, Oct 24, 2008 at 9:19 AM, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
> Hum, on a side note, that makes me think how it would be like for a language like D, with the same semantics as D, but having a completely redesigned syntax, from the grounds up. I wonder if there could be significant advantages in such a language (in clarity, consistency, expressiveness, etc).

Delight is partly there.  http://delight.sourceforge.net/

Jarrett Billingsley wrote:
> On Fri, Oct 24, 2008 at 9:19 AM, Bruno Medeiros
> <brunodomedeiros+spam@com.gmail> wrote:
>> Hum, on a side note, that makes me think how it would be like for a language
>> like D, with the same semantics as D, but having a completely redesigned
>> syntax, from the grounds up. I wonder if there could be significant
>> advantages in such a language (in clarity, consistency, expressiveness,
>> etc).
> 
> Delight is partly there.  http://delight.sourceforge.net/

Interesting (even though it has Python indentation :P ). But does it have all D features? Can a D program be automatically translated to a Delight program?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros:
> Interesting (even though it has Python indentation :P ).

I think giving it a Python-style syntax is the main (and in the beginning almost only) purpose of Delight. So if you don't like that thing, then probably Delight isn't for you.


> But does it have all D features?

Once debugged I think it will have all features of D2, minus few things left out on purpose, like global variables.

Note that Delight adds some other things, fixes some of the glaring holes of D2 (like in its module system), adds a built-in log system, nullable types, and I'm discussing with the author regarding other small things to add, like a "in" lookup for arrays, OpCmp and opEquals among AAs, lazy/nonlazy list comps syntax copied exactly from Python, a set data type, etc.
The hope is to produce a language nicer to program, more concise, and a little less bug prone than D. I don't know if it will succeed.


> Can a D program be automatically translated to a Delight program?

Why do you want to do this?
I think that in most cases a translation can be quite mechanical, the translator can automatically add a class to store the global variables used in the D program...

Bye,
bearophile

On Sat, 25 Oct 2008 20:05:48 +0100, Bruno Medeiros wrote:

> Jarrett Billingsley wrote:
>> On Fri, Oct 24, 2008 at 9:19 AM, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
>>> Hum, on a side note, that makes me think how it would be like for a language like D, with the same semantics as D, but having a completely redesigned syntax, from the grounds up. I wonder if there could be significant advantages in such a language (in clarity, consistency, expressiveness, etc).
>> 
>> Delight is partly there.  http://delight.sourceforge.net/
> 
> Interesting (even though it has Python indentation :P ). But does it have all D features? Can a D program be automatically translated to a Delight program?

Almost. Just change the header generation functions to output in Delight syntax instead of D syntax. I used this to compile Phobos at one point.

But that meant I could never make Delight smaller than D, since I had to support every feature of D, so I changed the compiler to allow parsing both D and Delight code. The things I've removed are listed here in the "D" section:

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

If anything else doesn't work, it's a bug ;-)

bearophile wrote:
> Bruno Medeiros:
>> Can a D program be automatically translated to a Delight program?
> 
> Why do you want to do this?
> I think that in most cases a translation can be quite mechanical, the translator can automatically add a class to store the global variables used in the D program...
> 

It's not that I want to do that, it was just a question to see if all D feature were available in Delight (if not, a direct translation might be difficult or impossible)


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

bearophile wrote:
> Bruno Medeiros:
>> Interesting (even though it has Python indentation :P ).
> 
> I think giving it a Python-style syntax is the main (and in the beginning almost only) purpose of Delight. So if you don't like that thing, then probably Delight isn't for you.
> 
> 

It may not be exactly what I was thinking then. I was thinking of a completely new syntax design, so as to be able to be fully "optimized" for efficiency/productivity.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D