January 04, 2017
On 12/31/16 9:43 AM, Timon Gehr wrote:
> On an unrelated note: I'm still not a fan of the with(import) syntax as
> it morally promotes a lack of turtles (even if not technically so).

Could you please provide more detail? Thanks! -- Andrei
January 05, 2017
On 05.01.2017 01:51, Andrei Alexandrescu wrote:
> On 12/31/16 9:43 AM, Timon Gehr wrote:
>> On an unrelated note: I'm still not a fan of the with(import) syntax as
>> it morally promotes a lack of turtles (even if not technically so).
>
> Could you please provide more detail? Thanks! -- Andrei

The declaration

with(import foo){ ... }

looks like an orthogonal combination of some import expression and the usual

with(foo){ ... }

statement. (This is true for all other statements and expressions with similar syntax.)

However, this is not in fact true here, the two constructs have different scoping rules.

Hence I think that the 'with(import foo){ ... }'-syntax would be better split into two orthogonal features:

1. allow 'import foo' as an expression that evaluates to the corresponding module symbol.

2. add 'static with' that is basically like 'with' but is a declaration and has different scoping rules.


I.e., my objection is that 'with' should not become 'static' just because it is applied to an import expression.
January 05, 2017
On Tuesday, 3 January 2017 at 20:07:59 UTC, Andrei Alexandrescu wrote:
>> Arguing that local imports have been successful so we should simply do
>> more of it is not a good argument, as there comes a point of diminishing
>> returns.  You need to show that there are still worthile gains to be
>> made from changing the language again, which is why I want to benchmark
>> this feature with Walter before deciding.
>
> You can be reasonably certain the benchmarks will improve as projected - starting in proportion to the the transitive fanout of top-level imports (10.5x for the standard library) and going down thereafter with the size, complexity, and actual dependencies of the module being compiled. All in all measurable but not dramatic. The same improvement will be brought about by lazy imports, and it won't be the deal maker/breaker. If you're waiting for the numbers to get convinced of anything, you already consider DIP1005 useless.

I don't need dramatic, a solid win is fine. A small 10% or less improvement in the speed of the import phase of compilation probably isn't worth it.

>> Rather, the
>> argument is that local imports mostly solved this problem, so why bother
>> adding new syntax for the dozen remaining symbols from 2-3 modules that
>> are commonly used in template constraints?
>
> I understand. It is my humble opinion that we are "mostly pregnant" for as long as we require top-level imports. The real change of phase occurs when there are ZERO imports at top level. That's the prize DIP1005 is after.

If you believe the benchmarks won't be dramatically different, I wonder why you think there will be a phase change.

>> In the end, this is a minor DIP that is easily bikeshedded, as everybody
>> can grasp it and have an opinion on it.  I have refrained from
>> commenting recently because I will let benchmarking settle it for me.
>> Obviously, that won't suffice for others.
>
> I do agree that if framed as a modest improvement in build economics, it is quite unimportant. But that's a problem with the DIP; its main strength is better encapsulation, which is no small thing.

Encapsulation is not an end in itself.  You have listed four main advantages of this change in the DIP.  I have noted that I don't find the first three relating to reasoning and refactoring worth adding syntax for, while admitting that may be subjective.  The fourth talks about scalability, which I interpreted as either compilation speed or some other measurable gain, hence my asking for benchmarks.

If scalability refers to something else- it can't be reasoning or refactoring as those are listed as separate advantages- I'd like to hear what it is.  If it's measurable, I'd like to measure it first.
17 18 19 20 21 22 23 24 25 26 27
Next ›   Last »