www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Archetype language

reply bearophile <bearophileHUGS lycos.com> writes:
Through I've found a link to a language I didn't know, named Archetype. This
blog post contains some pointers and references about the language:
http://dvanderboom.wordpress.com/2010/04/26/new-language-code-named-archetype/

Some comments and quotations and notes about the language. Some of the things I
write are already translated to a D-like syntax.

Archetype is far from being finished. It's built on top of C# and shares many
things with it. C# isn't a small language.

Archetype looks designed to make handy practical/industrial high level coding
with GUIs, databases, etc. Archetype seems to contain many pre-built high level
features, even more than C#. D seems to focus to lower level features, smaller
features that you combine in many more ways.

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

The idea of optional curly braces for functions with 1 expression inside (just
a return):
int foo(int x) return x * x;
Instead of:
int foo(int x) { return x * x; }

It is similar to a syntax like:
foreach (x; 0 .. 10) y *= x;
Instead of:
foreach (x; 0 .. 10) { y *= x; }

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

In Archetype (and maybe C# too) delegates support the + and += operators. When
you add two delegates, they get chained. When you call the result of the sum,
both get called, in sequence. Probably this is handy to attach chains of
callbacks to GUI elements.

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

Imports inside functions, etc.:

void foo(int x) {
    import std.stdio;
    writeln(x * x);
}

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

There is a very short syntax to perform the simplest loops, here translated to
D-like:

foreach(10) {
}

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

In Archetype, the exclamation point can be placed before the parentheses. It is
the only part of the condition that can appear outside the parentheses.

if !(expression)
    statement;

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

There is a form of pattern matching:


var x = 1;
var number = 4;
match (number) {
  x -> number += 3;
  3 | 5 -> number++;
  2 | 4 | 6..10 -> {
    number–;
    Log("Numbers are getting too big");
  }
}

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

In Archetype if you have an Color enum, in some situations you don't need to
write Color.Green, you are allowed to use just Green.

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

There are nullable types:

int? x = 4;
auto x? = 4;

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

There are tuples, used like this:

(int, int) getMouseLocation() {
    return (100, 50);
}


Or with named fields too:

(x int, y int) getMouseLocation() {
    return (100, 50);
}


At the call site:

auto (x, y) = getMouseLocation();

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

It has "Streams", that are iterators, very similar to the yield syntax sugar I
have suggested:
http://d.puremagic.com/issues/show_bug.cgi?id=5660


yield(int) Numbers() {
  yield 1, 2, 3;

}

Or even (I have kept the Archetype syntax here):

yield(int) Numbers() {
  yield 0..100 skip 5;
}

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

It has Pascal/Ada-style ranged numbers (I have kept the Archetype syntax here):

// an int that can only have a value from 0 to 105
type ValidAge int in [0..105];


An anonymous subrange type, when you don't need to define the type:
Age int in [0..105];

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

It has List Comprehensions (I have kept the Archetype syntax here):

var FirstHundred = [ 1..100 ];

var FirstHundred = from x in [ 1..100 ] where x*x > 3 select x*2;


In my opinion the map/filter/reduce of Phobos2 have almost failed because their
syntax is too much noisy and heavy, I don't want to see them used a lot in
production code. Even in Python code map/filter/reduce are uncommon. Modern
Python programmers use mostly lazy/eager sequence comprehensions. But I don't
like the List Comprehensions syntax of Archetype.

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

In Ruby arrays (lists) support the - infix operator too, to remove the first
item equal to the one given on the right of the minus sign (similar to the
list.remove() method in Python). But this operator is not present yet in
Archetype design.

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

A cute quote:

In my study of linguistics, I learned that legends like Noam Chomsky could
learn hundreds of langauges; the previous librarian at the Vatican could read
97.<

---------------------- There are ways to define infix binary operators (this is dangerous/troubled stuff): // "ABC" dup 3 == "ABCABCABC" binary dup string (left string, right int) return string.Repeat(left, right) Even infix spaces that mean something (there was a C++0x joke about this): // "123" "45" == "12345" binary adjacent string (left string, right string) return left + right; And just suffixes: // 12 minutes == TimeSpan.FromMinutes(12) unary suffix minutes TimeSpan (short, int) return TimeSpan.FromMinutes((int)value); ---------------------- If not specified there is a default constructor, ad in D structs: class Foo { string x; int y; } void main() { Foo f = new Foo("hello", 10); } Is this going to cause problems in D? ---------------------- I have omitted several other things. (Just to be sure: with this post I am not proposing to add all that stuff to D2/D3. I like only part of the things I've shown.) Bye, bearophile
Mar 20 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/20/11, bearophile <bearophileHUGS lycos.com> wrote:
 The idea of optional curly braces for functions with 1 expression inside
 (just a return):
 int foo(int x) return x * x;
 Instead of:
 int foo(int x) { return x * x; }

Cute. Nice reason to keep the semicolon.
 It is similar to a syntax like:
 foreach (x; 0 .. 10) y *= x;
 Instead of:
 foreach (x; 0 .. 10) { y *= x; }

Not so cute (to me). I'd prefer that syntax only in one-liner function definitions.
 In Archetype (and maybe C# too) delegates support the + and += operators.
 When you add two delegates, they get chained. When you call the result of
 the sum, both get called, in sequence. Probably this is handy to attach
 chains of callbacks to GUI elements.

How is this different from an array of delegates? void GUIDoSomething(int delegate(int, int) delegates[]) { int _x, _y; foreach (deleg; delegates) { deleg(_x, _y); } } void main() { int delegate(int x, int y)[] delegates; delegates ~= (int x, int y) { return x + y;}; delegates ~= (int x, int y) { return x - y;}; GUIDoSomething(delegates); } Granted you can't do `deleg1 ~ deleg2`. But a delegate should be a single quantity, not a hidden sequence of multiple delegates. That's what arrays are for (or even rages).
 Imports inside functions, etc.:

 void foo(int x) {
     import std.stdio;
     writeln(x * x);
 }

I think this would be a little cumbersome to maintain. Maybe it would even complicate the linking stage, but I'm not sure.
 In Archetype, the exclamation point can be placed before the parentheses. It
 is the only part of the condition that can appear outside the parentheses.

 if !(expression)
     statement;

This is nice. Currently I have to add another pair of parenthesis, and it doesn't look nice: if (!(isFile(name) && getExt(name) == "d")) continue; // not a file, or not a .d file vs. if !(isFile(name) && getExt(name) == "d") continue; // not a file, or not a .d file
 There are tuples, used like this:

 (int, int) getMouseLocation() {
     return (100, 50);
 }


 Or with named fields too:

 (x int, y int) getMouseLocation() {
     return (100, 50);
 }


 At the call site:

 auto (x, y) = getMouseLocation();

Maybe D3 would have these, who knows.. Do you use tuple return values often, e.g. in Python?
Mar 20 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Not so cute (to me). I'd prefer that syntax only in one-liner function
 definitions.

Of course. The example was just to show that with foreach you are allowed to spare the brackets. So in theory the same thing is doable with single-expression functions. And indeed Scala language too does this.
 But a delegate should be a
 single quantity, not a hidden sequence of multiple delegates. That's
 what arrays are for (or even rages).

This is your point of view. I presume Archetype designer (and maybe C# too) don't agree with you.
 Maybe D3 would have these, who knows..

Thinks don't just happen :-) If you want something, you have to work a lot, to grow enough consensus of people that like it, to design it well, find corner cases, and then implement it or find people willing to implment it, etc.
 Do you use tuple return values often, e.g. in Python?

Not in every line of code, but they are quite useful. Tuples are useful for other purposes too, like: for a,b in zip((1, 2, 3), "abc"): Here a,b is a 2-tuple that Python automatically unpack from the result of the zip, that in Python2 is a list (array) of 2-tuples. So there are some other usages of tuples beside the normal ones. Phobos already has a tuple type. It doesn't have syntax sugar for the unpacking (and maybe better syntax for the tuple literals, but this is less important). Bye, bearophile
Mar 20 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/20/2011 10:11 PM, bearophile wrote:
 Do you use tuple return values often, e.g. in Python?

Tuples are useful for other purposes too, like: for a,b in zip((1, 2, 3), "abc"): Here a,b is a 2-tuple that Python automatically unpack from the result of the zip, that in Python2 is a list (array) of 2-tuples.

Typical example, I guess: for line in File("contacts.dat"): (name,phone,email) = line.split(';') # process name,phone,email Denis -- _________________ vita es estrany spir.wikidot.com
Mar 20 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 03/20/2011 06:36 PM, bearophile wrote:
 Through I've found a link to a language I didn't know, named Archetype. This
blog post contains some pointers and references about the language:
 http://dvanderboom.wordpress.com/2010/04/26/new-language-code-named-archetype/

Very interesting!
 Some comments and quotations and notes about the language. Some of the things
I write are already translated to a D-like syntax.

 Archetype is far from being finished. It's built on top of C# and shares many
things with it. C# isn't a small language.

Too bad! A language built on top of a privative (proprietary) one, which itself targets a privative platform is definitely unusable for me. (This is not a joke.)
 Archetype looks designed to make handy practical/industrial high level coding
with GUIs, databases, etc. Archetype seems to contain many pre-built high level
features, even more than C#. D seems to focus to lower level features, smaller
features that you combine in many more ways.

... which does not exclude studying it and ripping good points and ideas ;-) (I also share your opinion that C# in better designed than its concurrents.)
 ----------------------------------

 The idea of optional curly braces for functions with 1 expression inside (just
a return):
 int foo(int x) return x * x;
 Instead of:
 int foo(int x) { return x * x; }

 It is similar to a syntax like:
 foreach (x; 0 .. 10) y *= x;
 Instead of:
 foreach (x; 0 .. 10) { y *= x; }

Very good. They should also let down ';' noise, like Go.
 ------------------------

 In Archetype (and maybe C# too) delegates support the + and += operators. When
you add two delegates, they get chained. When you call the result of the sum,
both get called, in sequence. Probably this is handy to attach chains of
callbacks to GUI elements.

Good idea, but (1) mostly imperative langs very rarely need func composition (2) '+' is a very bad choice of operator for this.
 ------------------------

 Imports inside functions, etc.:

 void foo(int x) {
      import std.stdio;
      writeln(x * x);
 }

Bad, imo. Imports should be obvious.
 ------------------------

 There is a very short syntax to perform the simplest loops, here translated to
D-like:

 foreach(10) {
 }

Only looks like nice. But in practice one often needs the index. Which leads to eg: foreach(i ; 10) {...} Then, one is close to D's: foreach(i ; 0..10) {...} which is more poweful by indicating start index.
 ------------------------

 In Archetype, the exclamation point can be placed before the parentheses. It
is the only part of the condition that can appear outside the parentheses.

 if !(expression)
      statement;

Nice, but introduces syntactic exception for rare cases.
 ------------------------

 There is a form of pattern matching:


 var x = 1;
 var number = 4;
 match (number) {
    x ->  number += 3;
    3 | 5 ->  number++;
    2 | 4 | 6..10 ->  {
      number–;
      Log("Numbers are getting too big");
    }
 }

May be good.
 ------------------------

 In Archetype if you have an Color enum, in some situations you don't need to
write Color.Green, you are allowed to use just Green.

Ditto.
 ------------------------

 There are nullable types:

 int? x = 4;
 auto x? = 4;

Great! Does this mean non-nullable is the standard case in Archetype?
 ------------------------

 There are tuples, used like this:

 (int, int) getMouseLocation() {
      return (100, 50);
 }


 Or with named fields too:

 (x int, y int) getMouseLocation() {
      return (100, 50);
 }


 At the call site:

 auto (x, y) = getMouseLocation();

Great as well!
 ------------------------

 It has "Streams", that are iterators, very similar to the yield syntax sugar I
have suggested:
 http://d.puremagic.com/issues/show_bug.cgi?id=5660


 yield(int) Numbers() {
    yield 1, 2, 3;

 }

 Or even (I have kept the Archetype syntax here):

 yield(int) Numbers() {
    yield 0..100 skip 5;
 }

Such things should not be a feature; instead be at the core of the language. Else, one ends up with "gas usine" messes like with D ranges (and their types) (and tons of required features around) (that end up with syntax blow-up).
 ----------------------

 It has Pascal/Ada-style ranged numbers (I have kept the Archetype syntax here):

 // an int that can only have a value from 0 to 105
 type ValidAge int in [0..105];


 An anonymous subrange type, when you don't need to define the type:
 Age int in [0..105];

I'm now shared on this point. Feels great when coding in Pascal or Module, but do we really miss it? ... even Oberon (of the Pascal line) let this feature down.
 ----------------------

 It has List Comprehensions (I have kept the Archetype syntax here):

 var FirstHundred = [ 1..100 ];

 var FirstHundred = from x in [ 1..100 ] where x*x>  3 select x*2;


 In my opinion the map/filter/reduce of Phobos2 have almost failed because
their syntax is too much noisy and heavy, I don't want to see them used a lot
in production code. Even in Python code map/filter/reduce are uncommon. Modern
Python programmers use mostly lazy/eager sequence comprehensions. But I don't
like the List Comprehensions syntax of Archetype.

Python's comprehension syntax is broken as well: # map & filter [expr for x in coll if cond] # map alone [expr for x in coll] # filter alone requires identity function as map! lol! [x for x in coll if cond] # should be [x in call if cond] # Logically, the following should produce a copy: [x in coll] # dont work This weirdness, because 'in' is also an operator, so that "x in call" would be misinterpreted by the parser. To save *one* keyword in the language, python's designers introduced a broken syntax for comprehensions. Funny, ain't it?
 ----------------------

 In Ruby arrays (lists) support the - infix operator too, to remove the first
item equal to the one given on the right of the minus sign (similar to the
list.remove() method in Python). But this operator is not present yet in
Archetype design.

Far too ambiguous. And exceptional.
 ----------------------

 A cute quote:

 In my study of linguistics, I learned that legends like Noam Chomsky could
learn hundreds of langauges; the previous librarian at the Vatican could read
97.<


???
 ----------------------

 There are ways to define infix binary operators (this is dangerous/troubled
stuff):

 // "ABC" dup 3 == "ABCABCABC"
 binary dup string (left string, right int)
 return string.Repeat(left, right)


 Even infix spaces that mean something (there was a C++0x joke about this):

 // "123" "45" == "12345"
 binary adjacent string (left string, right string)
 return left + right;


 And just suffixes:

 // 12 minutes == TimeSpan.FromMinutes(12)
 unary suffix minutes TimeSpan (short, int)
 return TimeSpan.FromMinutes((int)value);

Requires much care, thought, and design talent, to be well used. (Just like the talent of a PL designer, IMO)
 ----------------------

 If not specified there is a default constructor, ad in D structs:

 class Foo {
    string x;
    int y;
 }
 void main() {
    Foo f = new Foo("hello", 10);
 }

 Is this going to cause problems in D?

I want this for D!
 ----------------------

 I have omitted several other things.

 (Just to be sure: with this post I am not proposing to add all that stuff to
D2/D3. I like only part of the things I've shown.)

 Bye,
 bearophile

Thank for the info, Denis -- _________________ vita es estrany spir.wikidot.com
Mar 20 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 They should also let down ';' noise, like Go.

My experience so far has shown me that there are two options: 1) You design the whole language syntax on the fact that most times you don't use semicolons (see Python and Haskell. Or even Delight); 2) You keep the semicolons obligatory (see D). Most of the other options I've seen (JavaScript, Go) are train wrecks :-)
 Nice, but introduces syntactic exception for rare cases.

I agree. On the other hand it makes the code less noisy and its semantics is clear. So overall I'm weakly against it.
 May be good.

I think pattern matching was considered for D2 too. It introduces a significant amount of complexity, but it's also powerful (this shows one example: http://rosettacode.org/wiki/Pattern_matching ), expecially if you have algebraic data types. Scala language has a decent implementation of pattern matching, despite it's partiall an object oriented language.
 Ditto.

A related shortening feature for enums was proposed for D too.
 Great! Does this mean non-nullable is the standard case in Archetype?

I don't remember, but I presume so.
 Great as well!

Tuples are very useful.
 I'm now shared on this point. Feels great when coding in Pascal or Module, but
 do we really miss it? ... even Oberon (of the Pascal line) let this feature
down.

They are quite useful. Recently there was a discussion (coming from a type that's limited on the range of month days only) of an implementation in D of a ranged type (so not a built-in). Maybe a library implementation will be good enough, there's no need for lot of syntax here.
 Python's comprehension syntax is broken as well:

It's less "broken" than every other list comp syntax I've even seen, including Haskell one :-) In my opinion if you change it just a bit, you produce something significantly worse.
        # filter alone requires identity function as map! lol!
        [x for x in coll if cond]        # should be [x in call if cond]

Yes, for uniformity, this is not so bad.
        # Logically, the following should produce a copy:
        [x in coll]                        # dont work

Your logic is broken.
 This weirdness, because 'in' is also an operator, so that "x in call" would be
 misinterpreted by the parser. To save *one* keyword in the language, python's
 designers introduced a broken syntax for comprehensions. Funny, ain't it?

Nope, you are mistaken, I think.
 Far too ambiguous. And exceptional.

It's normal operator overloading, and there is no ambiguity. It has caused me no problems in the little amount of Ruby code I have written.
 I want this for D!

I am willing to write an enhancement request on this. But first I'd like to know about negative side effects of it.
 Thank for the info,

You are welcome. Bye, bearophile
Mar 20 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 Just replace 'in' by another keyword in the expression of 
 list comprehensions, and, I guess, you won't find it broken:
 	# filter only:
 	negs = [x across coll if x<1]

It increases language complexity for a minimal saving. Not good. Bye, bearophile
Mar 20 2011
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Mar 21, 11 05:21, spir wrote:
 On 03/20/2011 09:44 PM, bearophile wrote:
 They should also let down ';' noise, like Go.

1) You design the whole language syntax on the fact that most times you don't use semicolons (see Python and Haskell. Or even Delight); 2) You keep the semicolons obligatory (see D). Most of the other options I've seen (JavaScript, Go) are train wrecks :-)

You'd have to support such as assertion with some material, I guess ;-) Lua also lives very well without ';' (except, like Python & Go, for multi-statement lines).

Python is designed to use \n as the separator. I believe Lua too. D is not.
 And I don't see what your point 1) actually means. Ones just need to let
 down ';', e basta. There is no syntactic issue with treating newline as
 a statement separator or terminator in place of ';'.

 Denis

No, you may break existing code by replacing all \n with ; auto g = longExpression .readln(); // auto g = longExpression.readln(); ? // auto g = longExpression; .readln(); ? if (b) return a (c.methodPtr)(d); // if (b) return a; (c.methodPtr)(d); ? // if (b) return a(c.methodPtr)(d); ?
Mar 20 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/20/2011 11:56 PM, KennyTM~ wrote:
 On Mar 21, 11 05:21, spir wrote:
 On 03/20/2011 09:44 PM, bearophile wrote:
 They should also let down ';' noise, like Go.

1) You design the whole language syntax on the fact that most times you don't use semicolons (see Python and Haskell. Or even Delight); 2) You keep the semicolons obligatory (see D). Most of the other options I've seen (JavaScript, Go) are train wrecks :-)

You'd have to support such as assertion with some material, I guess ;-) Lua also lives very well without ';' (except, like Python & Go, for multi-statement lines).

Python is designed to use \n as the separator. I believe Lua too. D is not.
 And I don't see what your point 1) actually means. Ones just need to let
 down ';', e basta. There is no syntactic issue with treating newline as
 a statement separator or terminator in place of ';'.

 Denis

No, you may break existing code by replacing all \n with ; auto g = longExpression .readln();

Indeed, I don't mean you can replace ';' by newline in D without breaking code! Denis -- _________________ vita es estrany spir.wikidot.com
Mar 20 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/20/2011 09:44 PM, bearophile wrote:
          # Logically, the following should produce a copy:
          [x in coll]                        # dont work



I don't think so ;-) This is something I discussed on Python's design mailing list ("ideas"). The only reason why this is not possible to implement in python is that 'in' is also the membership operator. So that [x in coll] evaluates to [true] or [false]. Just replace 'in' by another keyword in the expression of list comprehensions, and, I guess, you won't find it broken: # filter only: negs = [x across coll if x<1] instead of # current syntax forces mapping with identity function # in addition to filter: negs = [x for x in coll if x<1] What's really weird is that mapping without filter is indeed possible; one is not forced to write: squares = [x*x for x in coll if true] lol! Denis -- _________________ vita es estrany spir.wikidot.com
Mar 20 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/20/2011 09:44 PM, bearophile wrote:
 They should also let down ';' noise, like Go.

1) You design the whole language syntax on the fact that most times you don't use semicolons (see Python and Haskell. Or even Delight); 2) You keep the semicolons obligatory (see D). Most of the other options I've seen (JavaScript, Go) are train wrecks :-)

You'd have to support such as assertion with some material, I guess ;-) Lua also lives very well without ';' (except, like Python & Go, for multi-statement lines). And I don't see what your point 1) actually means. Ones just need to let down ';', e basta. There is no syntactic issue with treating newline as a statement separator or terminator in place of ';'. Denis -- _________________ vita es estrany spir.wikidot.com
Mar 20 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 21, 11 01:36, bearophile wrote:
 Through I've found a link to a language I didn't know, named Archetype. This
blog post contains some pointers and references about the language:
 http://dvanderboom.wordpress.com/2010/04/26/new-language-code-named-archetype/

 Some comments and quotations and notes about the language. Some of the things
I write are already translated to a D-like syntax.

 Archetype is far from being finished. It's built on top of C# and shares many
things with it. C# isn't a small language.

 Archetype looks designed to make handy practical/industrial high level coding
with GUIs, databases, etc. Archetype seems to contain many pre-built high level
features, even more than C#. D seems to focus to lower level features, smaller
features that you combine in many more ways.

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

 The idea of optional curly braces for functions with 1 expression inside (just
a return):
 int foo(int x) return x * x;
 Instead of:
 int foo(int x) { return x * x; }

 It is similar to a syntax like:
 foreach (x; 0 .. 10) y *= x;
 Instead of:
 foreach (x; 0 .. 10) { y *= x; }

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

 In Archetype (and maybe C# too) delegates support the + and += operators. When
you add two delegates, they get chained. When you call the result of the sum,
both get called, in sequence. Probably this is handy to attach chains of
callbacks to GUI elements.

This is a standard CLI feature. It supports -= also. No + is not supported.
 ------------------------

 Imports inside functions, etc.:

 void foo(int x) {
      import std.stdio;
      writeln(x * x);
 }

I don't think such fine-grained level of import scoping would bring many benefits. Module-level import is good enough. Well maybe allow import inside unittest{} block, but we have version(unittest).
 ------------------------

 There is a very short syntax to perform the simplest loops, here translated to
D-like:

 foreach(10) {
 }

Cute, but 'foreach(_; 0..10)' isn't really that long. And this change makes integers look like they are iterable, like map!"a*a"(10) should work?!
 ------------------------

 In Archetype, the exclamation point can be placed before the parentheses. It
is the only part of the condition that can appear outside the parentheses.

 if !(expression)
      statement;

This makes 'if' looks like a template :p.
 ------------------------

 There is a form of pattern matching:


 var x = 1;
 var number = 4;
 match (number) {
    x ->  number += 3;
    3 | 5 ->  number++;
    2 | 4 | 6..10 ->  {
      number–;
      Log("Numbers are getting too big");
    }
 }

This is not pattern matching. This is only a regular 'switch' that does not fall-through. switch(number) { default: number += 3; break; case 3, 5: number ++; break; case 2, 4: case 6: .. case 9: number --; Log("Numbers are getting too big"); break; } Functional language's pattern matching is useful because of built-in algebraic types, and that they fill in the fields for you.
 ------------------------

 In Archetype if you have an Color enum, in some situations you don't need to
write Color.Green, you are allowed to use just Green.

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

 There are nullable types:

 int? x = 4;
 auto x? = 4;

In C# (and Archetype too, since it says 'The nullable type operator converts a type T to Nullable<T>, the same as in C#.'), Nullable is only useful for value types to provide an extra value, 'null'. Reference types can take 'null' no matter that '?' is present or not. This is just the same situation in D where structs are non-nullable.
 ------------------------

 There are tuples, used like this:

 (int, int) getMouseLocation() {
      return (100, 50);
 }


 Or with named fields too:

 (x int, y int) getMouseLocation() {
      return (100, 50);
 }


 At the call site:

 auto (x, y) = getMouseLocation();

Yeah this was tried once and becomes a mess in detail :) http://www.digitalmars.com/d/archives/digitalmars/D/Re_Tuple_literal_syntax_Tuple_assignment_118601.html So how Archetype deals with 0 and 1-tuple?
 ------------------------

 It has "Streams", that are iterators, very similar to the yield syntax sugar I
have suggested:
 http://d.puremagic.com/issues/show_bug.cgi?id=5660


 yield(int) Numbers() {
    yield 1, 2, 3;

 }

 Or even (I have kept the Archetype syntax here):

 yield(int) Numbers() {
    yield 0..100 skip 5;
 }

'yield' is gogreatod. Most of the time an input range is sufficient, where a generator expresses it very nicely. Not sure about the comprehensive version in Archetype though. This can be easily rewritten to foreach(i; 0..100 skip 5) yield i; Often you can yield an unmodified list comprehension, you could just return it. There isn't much benefit in complicating the 'yield' syntax.
 ----------------------

 It has Pascal/Ada-style ranged numbers (I have kept the Archetype syntax here):

 // an int that can only have a value from 0 to 105
 type ValidAge int in [0..105];


 An anonymous subrange type, when you don't need to define the type:
 Age int in [0..105];

This could be a library type (as proposed before?) alias Bounded!(0, 105, int) ValidAge; the problem is to let the compiler knows the value-range in the propagation.
 ----------------------

 It has List Comprehensions (I have kept the Archetype syntax here):

 var FirstHundred = [ 1..100 ];

 var FirstHundred = from x in [ 1..100 ] where x*x>  3 select x*2;


 In my opinion the map/filter/reduce of Phobos2 have almost failed because
their syntax is too much noisy and heavy, I don't want to see them used a lot
in production code. Even in Python code map/filter/reduce are uncommon. Modern
Python programmers use mostly lazy/eager sequence comprehensions. But I don't
like the List Comprehensions syntax of Archetype.

Yes. Maybe the Python/Javascript 1.7-like syntax a = (f(x,y,z) foreach(x,y; it) if(cond(x,y)) foreach(z; it2) ...) we also need to be careful not to turn an invalid statement to valid. v = f(1,2,3) // <-- foreach(x, y; it); // <-- perform(x,y);
 ----------------------

 In Ruby arrays (lists) support the - infix operator too, to remove the first
item equal to the one given on the right of the minus sign (similar to the
list.remove() method in Python). But this operator is not present yet in
Archetype design.

Since this is an O(N) operation I don't see any reason an operator-based syntax will be allowed, given 'in' is rejected for this reason.
 ----------------------

 A cute quote:

 In my study of linguistics, I learned that legends like Noam Chomsky could
learn hundreds of langauges; the previous librarian at the Vatican could read
97.<


Hundreds could be >> 100 :)
 ----------------------

 There are ways to define infix binary operators (this is dangerous/troubled
stuff):

 // "ABC" dup 3 == "ABCABCABC"
 binary dup string (left string, right int)
 return string.Repeat(left, right)


 Even infix spaces that mean something (there was a C++0x joke about this):

 // "123" "45" == "12345"
 binary adjacent string (left string, right string)
 return left + right;


 And just suffixes:

 // 12 minutes == TimeSpan.FromMinutes(12)
 unary suffix minutes TimeSpan (short, int)
 return TimeSpan.FromMinutes((int)value);

"ABC".dup(3) 12.minutes // with UFCS (Well the did author said by defining these tokens as unary suffix operators, we can eliminate even the dot operator and make it that much more fluent and natural to type (without losing any syntactic precision). I don't think it matters.)
 ----------------------

 If not specified there is a default constructor, ad in D structs:

 class Foo {
    string x;
    int y;
 }
 void main() {
    Foo f = new Foo("hello", 10);
 }

 Is this going to cause problems in D?

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

 I have omitted several other things.

 (Just to be sure: with this post I am not proposing to add all that stuff to
D2/D3. I like only part of the things I've shown.)

 Bye,
 bearophile

Mar 20 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:

 And this change makes integers look like they are iterable,

That's not so good, I agree :-)
 This makes 'if' looks like a template :p.

I agree, that may cause troubles in D. Not good.
 Yeah this was tried once and becomes a mess in detail :)

I remember part of the discussion, and I think it's a not so messy situation. I think it's doable.
 So how Archetype deals with 0 and 1-tuple?

I don't know, I presume as Python. In that discussion I said to Walter than the 1-tuple cause problems in Python. In the meantime I have changed my mind a bit: 1-tuple syntax in Python is not great, but it's much better than not having tuple syntax :-)
 'yield' is gogreatod.

I have no idea what 'gogreatod' means, sorry :-)
 This could be a library type (as proposed before?)

Right.
 the problem is to let the compiler knows the value-range in the propagation.

Right...
 Yes. Maybe the Python/Javascript 1.7-like syntax
      a = (f(x,y,z) foreach(x,y; it) if(cond(x,y)) foreach(z; it2) ...)

Yes please. Plus the eager version too that produces an array: [f(x,y,z) foreach(x,y; it) if(cond(x,y)) foreach(z; it2) ...]
 Since this is an O(N) operation I don't see any reason an operator-based
 syntax will be allowed, given 'in' is rejected for this reason.

I don't agree. "in" was refused for the linear search because elsewhere the D "in" is known to be O(1). But D operators are generally allowed to perform O(n) operations too, think about the "a[]-10" vector operation.
 Hundreds could be >> 100 :)

Noam Chomsky is a genius and you must listen to him even when he's drunk :-) Bye, bearophile
Mar 20 2011
parent KennyTM~ <kennytm gmail.com> writes:
On Mar 21, 11 07:41, bearophile wrote:
 KennyTM~:

 And this change makes integers look like they are iterable,

That's not so good, I agree :-)
 This makes 'if' looks like a template :p.

I agree, that may cause troubles in D. Not good.
 Yeah this was tried once and becomes a mess in detail :)

I remember part of the discussion, and I think it's a not so messy situation. I think it's doable.
 So how Archetype deals with 0 and 1-tuple?

I don't know, I presume as Python. In that discussion I said to Walter than the 1-tuple cause problems in Python. In the meantime I have changed my mind a bit: 1-tuple syntax in Python is not great, but it's much better than not having tuple syntax :-)

I agree.
 'yield' is gogreatod.

I have no idea what 'gogreatod' means, sorry :-)

An attempt to replace 'good' with 'great' which failed ;)
 This could be a library type (as proposed before?)

Right.
 the problem is to let the compiler knows the value-range in the propagation.

Right...
 Yes. Maybe the Python/Javascript 1.7-like syntax
       a = (f(x,y,z) foreach(x,y; it) if(cond(x,y)) foreach(z; it2) ...)

Yes please. Plus the eager version too that produces an array: [f(x,y,z) foreach(x,y; it) if(cond(x,y)) foreach(z; it2) ...]
 Since this is an O(N) operation I don't see any reason an operator-based
 syntax will be allowed, given 'in' is rejected for this reason.

I don't agree. "in" was refused for the linear search because elsewhere the D "in" is known to be O(1). But D operators are generally allowed to perform O(n) operations too, think about the "a[]-10" vector operation.

Though they have a [] to signify it's a vectorized operation. I mean bare operation like 'a - 1'. (Also, using '-' makes it confusable with 'a[] - 1', the reason why '~' was created instead of overloading '+')
 Hundreds could be>>  100 :)

Noam Chomsky is a genius and you must listen to him even when he's drunk :-) Bye, bearophile

Mar 20 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.03.2011 18:36, schrieb bearophile:
 It has List Comprehensions (I have kept the Archetype syntax here):

 var FirstHundred = [ 1..100 ];

 var FirstHundred = from x in [ 1..100 ] where x*x>  3 select x*2;

Isn't this plain LINQ like in C#? Maybe the [1..100] is new, but the rest isn't, I think.
 In my opinion the map/filter/reduce of Phobos2 have almost failed because
their syntax is too much noisy and heavy, I don't want to see them used a lot
in production code. Even in Python code map/filter/reduce are uncommon. Modern
Python programmers use mostly lazy/eager sequence comprehensions. But I don't
like the List Comprehensions syntax of Archetype.

Having something like LINQ as syntactic sugar for (algorithms on) Ranges in D would be cool. Cheers, - Daniel
Mar 20 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-03-20 18:36, bearophile wrote:
 Through I've found a link to a language I didn't know, named Archetype. This
blog post contains some pointers and references about the language:
 http://dvanderboom.wordpress.com/2010/04/26/new-language-code-named-archetype/

 Some comments and quotations and notes about the language. Some of the things
I write are already translated to a D-like syntax.

 Archetype is far from being finished. It's built on top of C# and shares many
things with it. C# isn't a small language.

 Archetype looks designed to make handy practical/industrial high level coding
with GUIs, databases, etc. Archetype seems to contain many pre-built high level
features, even more than C#. D seems to focus to lower level features, smaller
features that you combine in many more ways.

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

 The idea of optional curly braces for functions with 1 expression inside (just
a return):
 int foo(int x) return x * x;
 Instead of:
 int foo(int x) { return x * x; }

Like it.
 It is similar to a syntax like:
 foreach (x; 0 .. 10) y *= x;
 Instead of:
 foreach (x; 0 .. 10) { y *= x; }

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

 In Archetype (and maybe C# too) delegates support the + and += operators. When
you add two delegates, they get chained. When you call the result of the sum,
both get called, in sequence. Probably this is handy to attach chains of
callbacks to GUI elements.

As far as I know, in C#, this is only for events and not plain delegates.
 ------------------------

 Imports inside functions, etc.:

 void foo(int x) {
      import std.stdio;
      writeln(x * x);
 }

Like it.
 ------------------------

 There is a very short syntax to perform the simplest loops, here translated to
D-like:

 foreach(10) {
 }

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

 In Archetype, the exclamation point can be placed before the parentheses. It
is the only part of the condition that can appear outside the parentheses.

 if !(expression)
      statement;

Weird.
 ------------------------

 There is a form of pattern matching:


 var x = 1;
 var number = 4;
 match (number) {
    x ->  number += 3;
    3 | 5 ->  number++;
    2 | 4 | 6..10 ->  {
      number–;
      Log("Numbers are getting too big");
    }
 }

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

 In Archetype if you have an Color enum, in some situations you don't need to
write Color.Green, you are allowed to use just Green.

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

 There are nullable types:

 int? x = 4;
 auto x? = 4;

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

 There are tuples, used like this:

 (int, int) getMouseLocation() {
      return (100, 50);
 }


 Or with named fields too:

 (x int, y int) getMouseLocation() {
      return (100, 50);
 }

Like it.
 At the call site:

 auto (x, y) = getMouseLocation();

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

 It has "Streams", that are iterators, very similar to the yield syntax sugar I
have suggested:
 http://d.puremagic.com/issues/show_bug.cgi?id=5660


 yield(int) Numbers() {
    yield 1, 2, 3;

 }

 Or even (I have kept the Archetype syntax here):

 yield(int) Numbers() {
    yield 0..100 skip 5;
 }

Like it.
 ----------------------

 It has Pascal/Ada-style ranged numbers (I have kept the Archetype syntax here):

 // an int that can only have a value from 0 to 105
 type ValidAge int in [0..105];


 An anonymous subrange type, when you don't need to define the type:
 Age int in [0..105];

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

 It has List Comprehensions (I have kept the Archetype syntax here):

 var FirstHundred = [ 1..100 ];

 var FirstHundred = from x in [ 1..100 ] where x*x>  3 select x*2;


 In my opinion the map/filter/reduce of Phobos2 have almost failed because
their syntax is too much noisy and heavy, I don't want to see them used a lot
in production code. Even in Python code map/filter/reduce are uncommon. Modern
Python programmers use mostly lazy/eager sequence comprehensions. But I don't
like the List Comprehensions syntax of Archetype.

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

 In Ruby arrays (lists) support the - infix operator too, to remove the first
item equal to the one given on the right of the minus sign (similar to the
list.remove() method in Python). But this operator is not present yet in
Archetype design.

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

 A cute quote:

 In my study of linguistics, I learned that legends like Noam Chomsky could
learn hundreds of langauges; the previous librarian at the Vatican could read
97.<

---------------------- There are ways to define infix binary operators (this is dangerous/troubled stuff): // "ABC" dup 3 == "ABCABCABC" binary dup string (left string, right int) return string.Repeat(left, right) Even infix spaces that mean something (there was a C++0x joke about this): // "123" "45" == "12345" binary adjacent string (left string, right string) return left + right; And just suffixes: // 12 minutes == TimeSpan.FromMinutes(12) unary suffix minutes TimeSpan (short, int) return TimeSpan.FromMinutes((int)value); ---------------------- If not specified there is a default constructor, ad in D structs: class Foo { string x; int y; } void main() { Foo f = new Foo("hello", 10); } Is this going to cause problems in D? ---------------------- I have omitted several other things. (Just to be sure: with this post I am not proposing to add all that stuff to D2/D3. I like only part of the things I've shown.) Bye, bearophile

-- /Jacob Carlborg
Mar 21 2011