Archetype language

[spir]

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