November 02, 2010
Gary Whatmore:

> This is another one of those low priority issues. Never seen this kind of code in practice. These examples are highly synthetic and come from advocates of "clean" simple languages. "No corner cases" - does it matter if the language is full of broken corner cases if the practical real world code just works?

Yes, of course the number of broken corner cases matters a lot. Few corner cases are acceptable, too many and the language (es. Perl) becomes a mess that I will not use.

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

Andrei:

>Orthogonality has been long debated in the PL community. Clearly in reasonable quantities it's a desirable trait, but one must also know where to stop. There are many orthogonal languages that people didn't quite enjoy.<

I agree. Scheme is a very orthogonal language, but I don't like it. You have to build all things by yourself from the offered little (orthogonal) parts.


> My suggestion to address this issue was (and is) to make the assigned
> part of the function call:
> 
> int a, b;
> scatter(tuple(b, a), a, b);
> scatter(tuple(b, a + b), a, b);
> int[] arr = [0, 1, 2, 3, 4];
> int[] c;
> scatter(arr, a, b, c);

I have implemented something similar in dlibs1, but in practice I don't like to use that.
Tuples aren't something you use once in a while, if they are handy and good they become a fundamental language construct, I use them every few lines of code in Python, in every kind of Python programs I write. So they deserve a handy syntax. So it's a situation where some syntax sugar support is warmly encouraged. We may wait for D3, if necessary.

Bye,
bearophile
November 02, 2010
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

>> I believe it has been discussed numerous times before that the ?:
>> test should be used to find the element type - not sure why it
>> isn't.
>
> Looks like outdated documentation to me.

Well, it certainly doesn't behave as it should, if %u's post is
anything to go by. (and my testing of the same issue - it's not
just %u) Filed as 5156.


> This was already contributed to in Phobos (under a different syntax) but I rejected it on grounds of safety: the value built by "_" must escape addresses of all of its arguments, so it's not safe.

True. Bummer. Hm, now, the intent of _ is that the constructed type should
exist only as a temporary, I believe.

Maybe it is possible to do this in a safer way. I actually have a solution,
which I have posted here before, and I feel might be worthy of an
enhancement request: that templates may be used as pseudo-types, in that a
operator overloading should be allowed on non-type template instances:



import std.typecons;
import std.typetuple;
import dranges.templates;
import dranges.typetuple;

template _( T... ) if ( allSatisfy!( isAlias, T ) ) {
    Tuple!( StaticMap!( TypeOf, T ) ) opAssign( Tuple!( StaticMap!( TypeOf, T ) ) args ) {
        foreach ( i, e; T ) {
            e = args[i];
        }
        return args;
    }
}


unittest {
    int a = 1; b = 1;
    _!( a, b ) = tuple( b, a+b ); // Equivalent to _!( a, b ).opAssign( b, a+b );
}

Sadly, this currently does not work, not just due to the aforementioned
limitation, but also because the reassigned values are discarded as the
function returns. This latter part is confusing me. Is this intended
behavior?

A different solution might be @ephemeral, marking types that are not
supposed to be stored anywhere, and statically disallowing their use
as variables.


> My suggestion to address this issue was (and is) to make the assigned part of the function call:
>
> int a, b;
> scatter(tuple(b, a), a, b);
> scatter(tuple(b, a + b), a, b);
> int[] arr = [0, 1, 2, 3, 4];
> int[] c;
> scatter(arr, a, b, c);

That certainly works, but it is not as prettiful or straightforward.


-- 
Simen
November 02, 2010
Lutger <lutger.blijdestijn@gmail.com> wrote:

> It is stated in TDPL that the ?: test should be used, and it already works:
>
> auto a = [1,2,3.5];
> pragma(msg, typeof(a).stringof); // prints double[], not int[]

So it works for things that are not classes, then. That, to me, counts
as 'does not work correctly'. Filed as 5156.


-- 
Simen
November 02, 2010
Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> Sadly, this currently does not work, not just due to the aforementioned
> limitation, but also because the reassigned values are discarded as the
> function returns. This latter part is confusing me. Is this intended
> behavior?

Curiouser: T[i] = args[i]; works.


-- 
Simen
November 02, 2010
"%u" <user@web.news> wrote in message news:iap1l4$17hk$1@digitalmars.com...
>I found a slideshow called 'The Expressiveness of Go' recently. The conclusions are:
>
> * Go is not a small language but it is an expressive and comprehensible one.
>
> * Expressiveness comes from orthogonal composition of constructs.
>
> * Comprehensibility comes from simple constructs that interact in easily understood ways.
>
> * Build a language from simple orthogonal constructs and you have a language that will be easy and productive to use.
>
> * The surprises you discover will be pleasant ones.
>

I know how much the Unix creators (ie, Go creators) *love* taking orthogonality to extremes. I find that leads to puritanical languages that actively avoid pragmatism (ie, some of the worst kinds of languages). Orthogonality is good for *machines*, but not quite as much for humans (in moderation, yes, in large doses, no). Even programmers aren't as orthogonally-minded as we often think we are. It's a bad idea for them, and it's just gonna lead to another Java/Smalltalk/Haskel/etc, and we've already got a million of those, we certainly don't need yet another. I find it really odd that no matter how many times people keep trying that purity-not-pragmatic approach to language design and end up with junk, others still keep trying to make "better" languages by using the same damn ideology that led to the problems in the first place.


November 02, 2010
== Quote from Nick Sabalausky (a@a.a)'s article
> "%u" <user@web.news> wrote in message news:iap1l4$17hk$1@digitalmars.com...
> >I found a slideshow called 'The Expressiveness of Go' recently. The conclusions are:
> >
> > * Go is not a small language but it is an expressive and comprehensible one.
> >
> > * Expressiveness comes from orthogonal composition of constructs.
> >
> > * Comprehensibility comes from simple constructs that interact in easily understood ways.
> >
> > * Build a language from simple orthogonal constructs and you have a language that will be easy and productive to use.
> >
> > * The surprises you discover will be pleasant ones.
> >
> I know how much the Unix creators (ie, Go creators) *love* taking orthogonality to extremes. I find that leads to puritanical languages that actively avoid pragmatism (ie, some of the worst kinds of languages). Orthogonality is good for *machines*, but not quite as much for humans (in moderation, yes, in large doses, no). Even programmers aren't as orthogonally-minded as we often think we are. It's a bad idea for them, and it's just gonna lead to another Java/Smalltalk/Haskel/etc, and we've already got a million of those, we certainly don't need yet another. I find it really odd that no matter how many times people keep trying that purity-not-pragmatic approach to language design and end up with junk, others still keep trying to make "better" languages by using the same damn ideology that led to the problems in the first place.

The big problem with an excessive focus on orthogonality is that you lose the ability to program at a wide range of abstraction levels in the same language, because the different levels will inevitably clash in some odd corner cases. IMHO, though, these corner cases are worth having in exchange for the ability to program at a variety of abstraction levels in one language.
November 02, 2010
Tue, 02 Nov 2010 17:00:06 -0400, Nick Sabalausky wrote:

> "%u" <user@web.news> wrote in message news:iap1l4$17hk$1@digitalmars.com...
>>I found a slideshow called 'The Expressiveness of Go' recently. The conclusions are:
>>
>> * Go is not a small language but it is an expressive and comprehensible one.
>>
>> * Expressiveness comes from orthogonal composition of constructs.
>>
>> * Comprehensibility comes from simple constructs that interact in easily understood ways.
>>
>> * Build a language from simple orthogonal constructs and you have a language that will be easy and productive to use.
>>
>> * The surprises you discover will be pleasant ones.
>>
>>
> I know how much the Unix creators (ie, Go creators) *love* taking orthogonality to extremes. I find that leads to puritanical languages that actively avoid pragmatism (ie, some of the worst kinds of languages). Orthogonality is good for *machines*, but not quite as much for humans (in moderation, yes, in large doses, no). Even programmers aren't as orthogonally-minded as we often think we are. It's a bad idea for them, and it's just gonna lead to another Java/Smalltalk/Haskel/etc, and we've already got a million of those, we certainly don't need yet another. I find it really odd that no matter how many times people keep trying that purity-not-pragmatic approach to language design and end up with junk, others still keep trying to make "better" languages by using the same damn ideology that led to the problems in the first place.

I don't know/like Go that much, but I think the bugs %u listed had some merit. Even if they are compiler bugs, they add inconsistensies to the language. I don't know about the tuple stuff.. having _(...) on the left hand side and tuple(...) on the right hand side seems unlogical, but if that's the way it works, it's a simple rule.

All kinds of extremes are bad. Scheme, Io, Unlambda, Intercal, Whitespace, .. all have a over simplistic syntax. It restricts way too much. APL, OTOH, has too much syntax for general purpose work. Same thing with type systems. Untyped or very weakly typed languages are dangerous. Extremely strongly typed languages make it challenging to write anything that compiles.
November 02, 2010
Nick Sabalausky Wrote:

> I know how much the Unix creators (ie, Go creators) *love* taking orthogonality to extremes. I find that leads to puritanical languages that actively avoid pragmatism (ie, some of the worst kinds of languages). Orthogonality is good for *machines*, but not quite as much for humans (in moderation, yes, in large doses, no). Even programmers aren't as orthogonally-minded as we often think we are. It's a bad idea for them, and it's just gonna lead to another Java/Smalltalk/Haskel/etc, and we've already got a million of those, we certainly don't need yet another. I find it really odd that no matter how many times people keep trying that purity-not-pragmatic approach to language design and end up with junk, others still keep trying to make "better" languages by using the same damn ideology that led to the problems in the first place.

If find that how people classify whether something is orthogonal to be completely inconsistent. For example it could be said that 'static if' is not orthogonal because you can't do static else or static foreach. But the feature isn't 'static' it is 'static if' and 'static if foreach' doesn't make sense.

I can't say being orthogonal is a bad thing, but if it is the only reason not to add a feature then reason is no longer part of the discussion making. I found this interesting piece on type inference of C#.

Type inference will work on a lambda but not when overload resolution of methods might happen at some point.

http://blogs.msdn.com/b/ericlippert/archive/2007/11/05/c-3-0-return-type-inference-does-not-work-on-member-groups.aspx

D takes the approach of only complaining when two matches are equal or come from separate modules.
1 2 3
Next ›   Last »