On Mar 21, 11 18:26, Daniel Gibson wrote:
Am 21.03.2011 11:09, schrieb KennyTM~:
On Mar 21, 11 16:17, Don wrote:
I agree. But unfortunately, the idea is a relatively complicated feature
with a lot of special cases. For example, this(this.bla, this.bla){}
'int f(int x, int x) {}' is a syntax
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
Don:
> 'pure', for example, is roughly the same level of
> implementation complexity as this feature.
If this is true, then this is amazing :-) Considering that pure is probably
about 60-70% implemented in D (no way to perform conditional purity, no good
management of special cases, your last
Daniel Gibson wrote:
Am 21.03.2011 11:09, schrieb KennyTM~:
On Mar 21, 11 16:17, Don wrote:
I agree. But unfortunately, the idea is a relatively complicated feature
with a lot of special cases. For example, this(this.bla, this.bla){}
'int f(int x, int x) {}' is a syntax error. So should 'this(
spir wrote:
On 03/21/2011 12:55 AM, bearophile wrote:
Among the things I've listed about Archetype there's one interesting
thing. Class instances aren't PODs, but sometimes I prefer reference
semantics and to populate fields in a plain way, expecially for simple
classes.
Time ago I and other
Am 21.03.2011 11:09, schrieb KennyTM~:
> On Mar 21, 11 16:17, Don wrote:
>>
>> I agree. But unfortunately, the idea is a relatively complicated feature
>> with a lot of special cases. For example, this(this.bla, this.bla){}
>
> 'int f(int x, int x) {}' is a syntax error. So should 'this(this.x,
>
On Mar 21, 11 16:17, Don wrote:
Daniel Gibson wrote:
Am 21.03.2011 00:55, schrieb bearophile:
Among the things I've listed about Archetype there's one interesting
thing. Class instances aren't PODs, but sometimes I prefer reference
semantics and to populate fields in a plain way, expecially for
On 03/21/2011 12:55 AM, bearophile wrote:
Among the things I've listed about Archetype there's one interesting thing.
Class instances aren't PODs, but sometimes I prefer reference semantics and to
populate fields in a plain way, expecially for simple classes.
Time ago I and other people have s
Am 21.03.2011 09:17, schrieb Don:
> Daniel Gibson wrote:
>> Am 21.03.2011 00:55, schrieb bearophile:
>>> Among the things I've listed about Archetype there's one interesting thing.
>>> Class instances aren't PODs, but sometimes I prefer reference semantics and
>>> to populate fields in a plain way,
Daniel Gibson wrote:
Am 21.03.2011 00:55, schrieb bearophile:
Among the things I've listed about Archetype there's one interesting
thing. Class instances aren't PODs, but sometimes I prefer reference
semantics and to populate fields in a plain way, expecially for simple
classes.
Time ago I a
Am 21.03.2011 00:55, schrieb bearophile:
Among the things I've listed about Archetype there's one interesting thing.
Class instances aren't PODs, but sometimes I prefer reference semantics and to
populate fields in a plain way, expecially for simple classes.
Time ago I and other people have su
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
Adam D. Ruppe:
> Have you tried doing this with a string mixin? It looks like
> it'd be trivial.
It's probably trivial with a string mixin, but no thanks. I don't like them a
lot.
Bye,
bearophile
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
Have you tried doing this with a string mixin? It looks like
it'd be trivial.
Among the things I've listed about Archetype there's one interesting thing.
Class instances aren't PODs, but sometimes I prefer reference semantics and to
populate fields in a plain way, expecially for simple classes.
Time ago I and other people have suggested a syntax like (this also to avoid a
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,
On 03/20/2011 10:11 PM, bearophile wrote:
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 th
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.
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
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.
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 Has
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
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
On 03/20/2011 09:44 PM, bearophile wrote:
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 ke
On 03/20/2011 09:44 PM, bearophile wrote:
> # Logically, the following should produce a copy:
> [x in coll]# dont work
Your logic is broken.
I don't think so ;-) This is something I discussed on Python's design mailing
list ("ideas"). The only reason
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 lang
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
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 com
On 3/20/11, bearophile 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
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 th
29 matches
Mail list logo
