Archetype language

[bearophile]

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