Re: D vs Go on reddit

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ij3iru$k6k$2...@digitalmars.com...
> Am 09.02.2011 23:56, schrieb Ulrik Mikaelsson:
>> Maybe it's [JavaScript] the ASM of next decade.
>
> Bringing the performance of the second last decades systems to hardware of 
> the
> next decade.
> Hooray \o/
>

Not to mention the reliability of 90's desktops.

Re: Stupid little iota of an idea

[Nick Sabalausky]

"Andrej Mitrovic"  wrote in message 
news:mailman.1524.1297475525.4748.digitalmar...@puremagic.com...
> On 2/12/11, Walter Bright  wrote:
>> Andrei Alexandrescu wrote:
>>> Not all users dislike iota, and besides arguments ad populum are
>>> fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
>>> a better name for iota comes about.
>>
>>
>> delta
>>
>
> Now that's sexy. Makes me feel like a commander when coding D.
>
> In fact, let me dust off my old C&C cd's, I'm in the mood for some RTS.

I was just thinking Delta Force. Sniping 6-pixel-tall soldiers from across a 
voxel canyon == amazingly fantastic eye-straining fun :) Bravo team, do you 
read me?!?

Heh, speaking of great military fun:
http://unconventional-airsoft.com/2003/01/15/hand-signals-defined/

Re: Stupid little iota of an idea

[Brad Roberts]

On 2/11/2011 4:07 PM, Andrei Alexandrescu wrote:
> On 2/11/11 8:32 AM, Daniel Gibson wrote:
>> Am 10.02.2011 12:40, schrieb spir:
>>>
>>> Certainly, because it's /highly/ important for a community of programmers to
>>> share the same "culture". And names are the main support&  vehicle for this
>>> culture.
>>>
>>> Denis
>>>
>>> (For this reason, I stoppped aliasing size_t and size_diff_t to Ordinal and
>>> Cardinal ;-) I use uint everywhere)
>>>
>>
>> This will cause trouble on 64bit systems, because there size_t is ulong.
>>
>> Cheers,
>> - Daniel
> 
> Yah... big problems on Phobos' 64-bit port.
> 
> Andrei

There were a lot of places that needed to change from uint to size_t, yes.  But 
bugs by the use of unsigned.. a rather
small number.  Considering that I did the majority of the d2 64 bit work, I 
think I can say that with confidence in it's
accuracy.

Later,
Brad

Re: Stupid little iota of an idea

[Jonathan M Davis]

On Friday 11 February 2011 20:01:23 spir wrote:
> On 02/12/2011 03:05 AM, Jonathan M Davis wrote:
> > While iota isn't clear, it _does_ have the advantage that you're
> > not going to _mis_understand
> 
> Maybe you say this because iota does not mean anything for you (?). I can
> easily imagine various appropriate uses of iota in a PL, like:
> 
> * smallest representable value in a given numeric format
> * threshold over which some measure should be taken into account
> * threshold under which some difference should be ignored
> * range for approximate equality (approxEquals: |x - y| < iota)
> * tolerance interval of technical measures (similar)
> * ...what else?
> 
> (I would be surprised if actual uses of iota in english do not point toward
> this kind of senses.)

iota is almost entirely unused in English. You might say something like "that 
doesn't make an iota of sense," but it's pretty rare. And even if you do, it's 
an iota of _something_, so something like |x - y| < iota would be just plain 
weird. Regardless, iota would be a weird name to use for _anything_ when naming 
variables or functions. It just isn't used much in English. And there are 
pretty 
much always going to be better names for the function or variable if you're 
trying to use iota for something similar to its actual meaning. If anyone tried 
to use iota to actually mean something as a variable or function name, I'd be 
suggesting that they pick a better nam.

- Jonathan M Davis

Re: Stupid little iota of an idea

[Daniel Gibson]

Am 12.02.2011 04:49, schrieb spir:
> On 02/12/2011 02:36 AM, Daniel Gibson wrote:
>> Am 12.02.2011 02:25, schrieb bearophile:
>>> Michel Fortin:
>>>
 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
 how do you rewrite this using the new proposed syntax:

 auto aa = [iota(a, b, c): 1, iota(d, e): 2];
>>>
>>> Right, that's why in another post I have said that syntax replaces most iota
>>> usages. There are some situations where you can't use it well. This is
>>> another situation I've shown in the enhancement request:
>>> iota(10.,20.)
>>> Writing it like this is not sane:
>>>   10...20.
>>>
>>>
 Interval is clear only as long as there's no step value mentioned.
 Having a step value is quite a stretch from the usual notion of an
 interval.
>>>
>>> Right, but I think it's acceptable still, and better than iota.
>>>
>>>
 I like a lot so's suggestion "walk". I'm not sure it's much clearer
 than iota though.
>>>
>>> It's better than iota, but not by much.
>>>
>>> Bye,
>>> bearophile
>>
>> I think it's much better. Even having "steps" (or a stepsize) is obvious with
>> walk.
>>
>> iota only makes sense when you know this from other languages/libraries or if
>> your native spoken language has a similar word that can be somehow connected.
>> http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
>> English->German dictionaries I've checked don't either - one only listed 
>> iota as
>> the greek letter, the other had mentions about something tiny) - it's just
>> something small like that greek i-without-a-dot letter.
>> There's nothing that connects it to a range of values with a fixed step size.
> 
> That page looks listing various meanings in foreign languages, but mostly
> stincks with the greek letter; it does not mention any sense everday sense 
> iota
> actually has. Example fro fr.wiktionary:
> 
> # Nom de ι, Ι, neuvième lettre et quatrième voyelle de l’alphabet grec.
> Équivalent du i latin.
> # Petite quantité négligeable, presque rien.
> 
> Free translation: little negligible quantity, nearly nothing.
> There are good chances iota has a similar meaning in numerous languages,
> especially romance ones. Bearophile, Andrei?
> 
> Denis

I don't think a iota representing something small is too helpful.
iota() produces a (possibly very long) range of values with a possibly huge step
size (but even with a fixed step size of one it wouldn't make much sense to me).

Cheers,
- Daniel

Re: Stupid little iota of an idea

[spir]

On 02/12/2011 03:05 AM, Jonathan M Davis wrote:

While iota isn't clear, it _does_ have the advantage that you're
not going to _mis_understand


Maybe you say this because iota does not mean anything for you (?). I can 
easily imagine various appropriate uses of iota in a PL, like:


* smallest representable value in a given numeric format
* threshold over which some measure should be taken into account
* threshold under which some difference should be ignored
* range for approximate equality (approxEquals: |x - y| < iota)
* tolerance interval of technical measures (similar)
* ...what else?

(I would be surprised if actual uses of iota in english do not point toward 
this kind of senses.)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[spir]

On 02/12/2011 02:36 AM, Daniel Gibson wrote:

Am 12.02.2011 02:25, schrieb bearophile:

Michel Fortin:


No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
how do you rewrite this using the new proposed syntax:

auto aa = [iota(a, b, c): 1, iota(d, e): 2];


Right, that's why in another post I have said that syntax replaces most iota 
usages. There are some situations where you can't use it well. This is another 
situation I've shown in the enhancement request:
iota(10.,20.)
Writing it like this is not sane:
  10...20.



Interval is clear only as long as there's no step value mentioned.
Having a step value is quite a stretch from the usual notion of an
interval.


Right, but I think it's acceptable still, and better than iota.



I like a lot so's suggestion "walk". I'm not sure it's much clearer
than iota though.


It's better than iota, but not by much.

Bye,
bearophile


I think it's much better. Even having "steps" (or a stepsize) is obvious with 
walk.

iota only makes sense when you know this from other languages/libraries or if
your native spoken language has a similar word that can be somehow connected.
http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
English->German dictionaries I've checked don't either - one only listed iota as
the greek letter, the other had mentions about something tiny) - it's just
something small like that greek i-without-a-dot letter.
There's nothing that connects it to a range of values with a fixed step size.


That page looks listing various meanings in foreign languages, but mostly 
stincks with the greek letter; it does not mention any sense everday sense iota 
actually has. Example fro fr.wiktionary:


# Nom de ι, Ι, neuvième lettre et quatrième voyelle de l’alphabet grec. 
Équivalent du i latin.

# Petite quantité négligeable, presque rien.

Free translation: little negligible quantity, nearly nothing.
There are good chances iota has a similar meaning in numerous languages, 
especially romance ones. Bearophile, Andrei?


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[spir]

On 02/12/2011 01:55 AM, bearophile wrote:

4) My fourth choice is "iota". It's short and it sticks in mind.


'Ψ' "psi" (beeing the forelast letter of the alphabet, just before omega, as 
everyone knows) would nicely suggest we're dealing with intervals half-open on 
the right-hand side.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[spir]

On 02/12/2011 01:46 AM, so wrote:

atob(1, 6) // easy to mix things like atoi
ptoq(1, 6) // rocks imo!


walk(1, 6) // now you have admit this is the best.


Not bad, after all walk is a series of steps ;-)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go

[Jonathan M Davis]

On Friday, February 11, 2011 17:01:31 bearophile wrote:
> Andrei:
> > Now we have a unified way of referring to elements in ranges. Walter's
> > excellent follow-up is that the compiler could use lowering such that
> > you don't even need to use first and last. You'd just use r[0] and r[$ -
> > 1] and the compiler would take care of handling these special cases.
> 
> Nice. Now you just need to lower the syntax  a~b  to mean chain(a,b) for
> lazy ranges, and we are starting to use ranges well enough, as lists in
> functional languages :-)

Except that then you get the issue of eager vs lazy concatenation. chain is 
lazy 
whereas ~ is eager, so that wouldn't fly.

Regardless, it sounds like it would be an idea best suited to D3 if there ever 
is one. It doesn't add enough value to be worth the breakage that it would 
cause 
(which appears to be Walter and Andrei's conclusion).

- Jonathan M Davis

Re: Stupid little iota of an idea

[Jonathan M Davis]

On Friday, February 11, 2011 17:02:18 Michel Fortin wrote:
> On 2011-02-11 19:55:05 -0500, bearophile  said:
> > I am not going to invent a new wonderful name for it, sorry :-) My
> > votes, in decreasing order of preference:
> > 1) By far, a syntax like a..b:c, or missing that, a syntax like a..b
> 
> No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
> how do you rewrite this using the new proposed syntax:
> 
>   auto aa = [iota(a, b, c): 1, iota(d, e): 2];
> 
> > 3) If you refuse the word "range", then my third choice is "interval".
> > It's as cleas as range, but it's a bit worse because it's longer.
> 
> Interval is clear only as long as there's no step value mentioned.
> Having a step value is quite a stretch from the usual notion of an
> interval.
> 
> I like a lot so's suggestion "walk". I'm not sure it's much clearer
> than iota though.

Honestly, I'd prefer iota to walk or interval. I see walk and I think about 
walkLength. It certainly isn't enough to tell me what the function does. 
interval is slightly better, but as you mention, the step value muddles that 
abstraction. While iota isn't clear, it _does_ have the advantage that you're 
not going to _mis_understand what it does based on its name, and it is _highly_ 
memorable. It's also short, which is nice. genSequence is pretty much the only 
thing that I've been able to think of that I like at all, but I'm perfectly 
fine 
with keeping iota, honestly. It's short, and I'll actually remember it, even if 
I don't use it all of the time.

The thing about this kind of voting though is that it's likely that all of the 
folks who dislike the status quo will comment/complain and vote, whereas the 
people who don't really care or who actually really like the status quo mostly 
probably already stop reading this thread and won't say anything. So, it will 
look like the consensus is that the status quo is bad even if the majority 
actually don't agree. So, if we want to actually vote on this, then we should 
come up with a set of suggestions for the name and then start a new thread vote 
the vote. Personally, I'd just as soon leave iota as-is.

- Jonathan M Davis

Re: Stupid little iota of an idea

[Andrej Mitrovic]

On 2/12/11, Walter Bright  wrote:
> Andrei Alexandrescu wrote:
>> Not all users dislike iota, and besides arguments ad populum are
>> fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
>> a better name for iota comes about.
>
>
> delta
>

Now that's sexy. Makes me feel like a commander when coding D.

In fact, let me dust off my old C&C cd's, I'm in the mood for some RTS.

Re: Stupid little iota of an idea

[Walter Bright]

foobar wrote:

Ary Manzana Wrote:
According to the book "The Design of Everyday Things" the design of that 
function name is wrong, it's not your fault and it's not because it was 
3am. When many people make mistakes with regards to the design of 
something it's *always* the design's fault, never the human's fault.




Thanks for this, I'm adding this book to my read list. :)



Every engineer and designer should read it. It's a classic, and a quick read.

The irony of it is, of course, everyone agrees with it, laughs at the stupid 
designs shown in the book, and then goes right out and create their own equally 
stupid designs.


Making designs that are intuitively obvious is amazingly difficult.

Re: Stupid little iota of an idea

[Walter Bright]

Andrei Alexandrescu wrote:
Not all users dislike iota, and besides arguments ad populum are 
fallacious. Iota rocks. But have at it - vote away, and I'll be glad if 
a better name for iota comes about.



delta

Re: Stupid little iota of an idea

[Daniel Gibson]

Am 12.02.2011 02:25, schrieb bearophile:
> Michel Fortin:
> 
>> No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
>> how do you rewrite this using the new proposed syntax:
>>
>>  auto aa = [iota(a, b, c): 1, iota(d, e): 2];
> 
> Right, that's why in another post I have said that syntax replaces most iota 
> usages. There are some situations where you can't use it well. This is 
> another situation I've shown in the enhancement request:
> iota(10.,20.)
> Writing it like this is not sane:
>  10...20.
> 
> 
>> Interval is clear only as long as there's no step value mentioned. 
>> Having a step value is quite a stretch from the usual notion of an 
>> interval.
> 
> Right, but I think it's acceptable still, and better than iota.
> 
> 
>> I like a lot so's suggestion "walk". I'm not sure it's much clearer 
>> than iota though.
> 
> It's better than iota, but not by much.
> 
> Bye,
> bearophile

I think it's much better. Even having "steps" (or a stepsize) is obvious with 
walk.

iota only makes sense when you know this from other languages/libraries or if
your native spoken language has a similar word that can be somehow connected.
http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
English->German dictionaries I've checked don't either - one only listed iota as
the greek letter, the other had mentions about something tiny) - it's just
something small like that greek i-without-a-dot letter.
There's nothing that connects it to a range of values with a fixed step size.

Cheers,
- Daniel

Re: Stupid little iota of an idea

[bearophile]

Michel Fortin:

> No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
> how do you rewrite this using the new proposed syntax:
> 
>   auto aa = [iota(a, b, c): 1, iota(d, e): 2];

Right, that's why in another post I have said that syntax replaces most iota 
usages. There are some situations where you can't use it well. This is another 
situation I've shown in the enhancement request:
iota(10.,20.)
Writing it like this is not sane:
 10...20.


> Interval is clear only as long as there's no step value mentioned. 
> Having a step value is quite a stretch from the usual notion of an 
> interval.

Right, but I think it's acceptable still, and better than iota.


> I like a lot so's suggestion "walk". I'm not sure it's much clearer 
> than iota though.

It's better than iota, but not by much.

Bye,
bearophile

Re: inlining or not inlining...

[so]

Register allocation is far more important than inlining. Why not give  
information about why a variable was not enregistered?


I am sorry Walter but your stance on this more politic than a practical  
fact, it is not you, sounds like you secured a professorship!. :)


Now i started to see the reasons of your stance, reading some of the old  
posts about this you are right directing them to asm output.
Because what they ask is doesn't make sense, this is a low level  
optimization/query and if they can't even find out from asm output (also  
this is something needs to be queried that way), this is the last of their  
concerns.


Again, you are absolutely right if your reasoning is that things like  
@can_inline @please_tell_me_if_you_can is just nonsense.


Real issue pops up when you know if compiler is inlining or not but have  
no say in the decision process.
You simply need a mechanism to sometimes state, "i need all i can get  
here, i know what i am doing, inline and save me a function call cost."
And unlike many other low level optimizations this is something we can  
control.


If you are against this reasoning, i don't have any idea why D has inline  
assembly, which again targets a very small audience.

Re: Stupid little iota of an idea

[Daniel Gibson]

Am 12.02.2011 01:46, schrieb so:
>> atob(1, 6) // easy to mix things like atoi
>> ptoq(1, 6) // rocks imo!
> 
> walk(1, 6) // now you have admit this is the best.

Hmm I do kind of like it.

Re: Stupid little iota of an idea

[Michel Fortin]

On 2011-02-11 19:55:05 -0500, bearophile  said:

I am not going to invent a new wonderful name for it, sorry :-) My 
votes, in decreasing order of preference:

1) By far, a syntax like a..b:c, or missing that, a syntax like a..b


No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
how do you rewrite this using the new proposed syntax:


auto aa = [iota(a, b, c): 1, iota(d, e): 2];


3) If you refuse the word "range", then my third choice is "interval". 
It's as cleas as range, but it's a bit worse because it's longer.


Interval is clear only as long as there's no step value mentioned. 
Having a step value is quite a stretch from the usual notion of an 
interval.


I like a lot so's suggestion "walk". I'm not sure it's much clearer 
than iota though.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Stupid little iota of an idea

[spir]

On 02/12/2011 01:26 AM, so wrote:

Not all users dislike iota, and besides arguments ad populum are fallacious.
Iota rocks. But have at it - vote away, and I'll be glad if a better name for
iota comes about.

Andrei


You asked for it!

atob(1, 6) // easy to mix things like atoi
ptoq(1, 6) // rocks imo!


alias retro!iota atoi;

Actually, I like the term iota very much; would enjoy finding a good use for 
it. Something related to tolerance interval, for instance, like in production 
of mechanical parts. Really fits the notion of "a difference small enough to 
make no difference".


Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go

[bearophile]

Andrei:

> Now we have a unified way of referring to elements in ranges. Walter's 
> excellent follow-up is that the compiler could use lowering such that 
> you don't even need to use first and last. You'd just use r[0] and r[$ - 
> 1] and the compiler would take care of handling these special cases.

Nice. Now you just need to lower the syntax  a~b  to mean chain(a,b) for lazy 
ranges, and we are starting to use ranges well enough, as lists in functional 
languages :-)

Bye,
bearophile

Re: Stupid little iota of an idea

[bearophile]

Andrei:

> Not all users dislike iota,

A poll will tell how much this statement is true :-)


> and besides arguments ad populum are fallacious.

That's true for scientific and engineering (or medical, etc) things but names 
are not a science. The process of choosing names is part of ergonomics, it must 
deal with what people, with what they find closer to their mind, culture, 
brain. Python developers discuss carefully about naming, and indeed, Python 
names are sometimes better than Phobos ones. One of the problems here is that 
the mind of every person, you, me, Walter's has "quirks", that is mind 
processes not shared by most other people. So if a single person chooses names, 
those quirks come out, and the names are uniform (because they are chosen using 
the same strategy, and this is positive), but sometimes they also reflect those 
quirks. The only way I know to avoid this problem is to design names using 
polls :-)


> Iota rocks. But have at it - vote away, and I'll be glad if 
> a better name for iota comes about.

I am not going to invent a new wonderful name for it, sorry :-) My votes, in 
decreasing order of preference:
1) By far, a syntax like a..b:c, or missing that, a syntax like a..b
2) If first class interval syntax is really not possible, then my second choice 
is a function named "range". This is what Python uses, it's natural, short 
enough, and good.
3) If you refuse the word "range", then my third choice is "interval". It's as 
cleas as range, but it's a bit worse because it's longer.
4) My fourth choice is "iota". It's short and it sticks in mind.

Bye,
bearophile

Re: Stupid little iota of an idea

[so]

atob(1, 6) // easy to mix things like atoi
ptoq(1, 6) // rocks imo!


walk(1, 6) // now you have admit this is the best.

Re: Unilink - alternative linker for win32/64, DMD OMF extensions?

[Dmitry Olshansky]

On 12.02.2011 3:13, Andrei Alexandrescu wrote:

On 2/11/11 12:56 PM, Dmitry Olshansky wrote:

Ok, bumping this up with the latest news from UniLink developers:


Ok, we release it's as D extension in next release.

Best regards,
UniLink



That's just plain awesome ;)



Is UniLink working with 64 bits?

Andrei


Yes, that's actually one of it's benefits, as I told somewhere along the 
thread.

To be 101% sure I just linked a simple 'hello x64' program.

--
Dmitry Olshansky

Re: Stupid little iota of an idea

[spir]

On 02/12/2011 12:55 AM, Andrei Alexandrescu wrote:

Not all users dislike iota, and besides arguments ad populum are fallacious.
Iota rocks. But have at it - vote away, and I'll be glad if a better name for
iota comes about.


Proposed "interval" (which I understand as a quasi-synonym of range, apart from 
D's use of the term). 1-2 more people seemed to find it appropriate. Bearophile 
argued interval is ok but too long for such a common (?)(*) feature. What do 
you think?


Denis

(*) The notion is indeed somewhat common in code, but we have i..j for the most 
common cases, by far. iota() is only for when we need an assignable value 
representing an interval.

--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[so]

Not all users dislike iota, and besides arguments ad populum are  
fallacious. Iota rocks. But have at it - vote away, and I'll be glad if  
a better name for iota comes about.


Andrei


You asked for it!

atob(1, 6) // easy to mix things like atoi
ptoq(1, 6) // rocks imo!

Re: inlining or not inlining...

[so]

All of this is hardly related to the simple feature I initially asked  
for:


string escString (string s) @tellmeifnotinlined {
s2 = s.replace("\n","\\n");
s2 = s.replace("\t","\\t");
 return s2;
 }
void show (X x) {
// ... use escString ...
 }
==>
	Warning: function 'escString' in module 'foo' (line 123) was not  
inlined.

(or else it was actually inlined)

Which (I guess) is not that a big deal since the compiler needs to  
decide anyway. I just wish to be informed of the result of the decision  
procedure, only in case of 'no'.


Denis


Guys, i don't know what are you trying or why you simply seem to avoid my  
reasoning on this, if you don't need this (and you all seem not use it)  
why are you trying to find solutions for the problems that doesn't affect  
you directly? :)


Unline a few of you said this is not a complex problem and actually it  
hasn't been complex in C++ either for again, practical purposes.


Standard C++ says:
For class/struct methods, compiler inlines things and it is aware of most  
of them wrappers so you don't need "inline" keyword there.
But still it does have this keyword as a hint to use other methods. This  
has never been enough and all major compilers now have forced inlines.  
(always_inline, __forceinline...)
What they do is forcing to compiler inline a function and if compiler  
won't do it it issues an error to state why.


All is needed is just i said in another post:
@inline // inline or issue and error why you won't.

- simple
- serves practical purposes rather than fiction
- it does no harm to anyone
- so easy to implement
- it is sometimes advanced but still something controllable

Now please what is wrong here someone enlighten me.

Thanks.

Re: Unilink - alternative linker for win32/64, DMD OMF extensions?

[Andrei Alexandrescu]

On 2/11/11 12:56 PM, Dmitry Olshansky wrote:

Ok, bumping this up with the latest news from UniLink developers:


Ok, we release it's as D extension in next release.

Best regards,
UniLink



That's just plain awesome ;)



Is UniLink working with 64 bits?

Andrei

Re: std.xml should just go

[Andrei Alexandrescu]

On 2/11/11 8:31 AM, Bruno Medeiros wrote:

On 04/02/2011 16:14, Eric Poggel wrote:

On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:

At this point there is no turning back from ranges, unless we come about
with an even better idea (I discussed one with Walter but we're not
pursuing it yet).


Care to elaborate on the new idea? Or at least a quick summary so we're
not all left wondering?


That comment left me curious as well...


The discussed idea went as follows.

Currently we have r.front and r.back for accessing the first and last 
element, and r[n] for an arbitrary element.


Plus, r[n] is extremely flexible (opIndex, opIndexAssign, 
opIndexOpAssign... awesome level of control... just perfect). So then I 
thought, how about unifying everything?


Imagine we gave up on r.front and r.back. Poof. They disappeared. Now we 
define two entities "first" and last" such that r[first] and r[last] 
refer the first and last elements in the range. Now we have the situ:


- Input and forward ranges statically allow only r[first]

- Bidirectional ranges allow r[first] and r[last]

- Random-access ranges allow r[first], r[last], and r[n] for integrals n

Now we have a unified way of referring to elements in ranges. Walter's 
excellent follow-up is that the compiler could use lowering such that 
you don't even need to use first and last. You'd just use r[0] and r[$ - 
1] and the compiler would take care of handling these special cases.


Advantages: unified syntax, increased flexibility with opIndexAssign and 
opIndexOpAssign. Disadvantages: breaks all range-oriented code out there.



Andrei

Re: Stupid little iota of an idea

[Andrei Alexandrescu]

On 2/11/11 8:32 AM, Daniel Gibson wrote:

Am 10.02.2011 12:40, schrieb spir:


Certainly, because it's /highly/ important for a community of programmers to
share the same "culture". And names are the main support&  vehicle for this
culture.

Denis

(For this reason, I stoppped aliasing size_t and size_diff_t to Ordinal and
Cardinal ;-) I use uint everywhere)



This will cause trouble on 64bit systems, because there size_t is ulong.

Cheers,
- Daniel


Yah... big problems on Phobos' 64-bit port.

Andrei

Re: inlining or not inlining...

[so]

Register allocation is far more important than inlining. Why not give  
information about why a variable was not enregistered?


I am sorry Walter but your stance on this more politic than a practical  
fact, it is not you, sounds like you secured a professorship!. :)

Re: Stupid little iota of an idea

[Andrei Alexandrescu]

On 2/11/11 7:07 AM, foobar wrote:

Andrei Alexandrescu Wrote:



I don't find the name "iota" stupid.

Andrei


Of course _you_ don't. However practically all the users _do_ find it
poorly named, including other developers in the project.. This is the
umpteenth time this comes up in the NG and incidentally this is the
only reason I know what the function does.

If the users think the name is stupid than it really is. That's how
usability works and the fact the you think otherwise or that it might
be more accurate mathematically is really not relevant. If you want
D/Phobos to be used by other people besides yourself you need to
cater for their requirements.


Not all users dislike iota, and besides arguments ad populum are 
fallacious. Iota rocks. But have at it - vote away, and I'll be glad if 
a better name for iota comes about.


Andrei

Re: new documentation format for std.algorithm

[Andrej Mitrovic]

On 2/2/11, Andrei Alexandrescu  wrote:
> Following ideas and advice from this newsgroup, I have a draft at
>
> http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html
> Andrei
>

You know, we could use the same thing for the language reference. E.g.:

http://www.digitalmars.com/d/2.0/template.html

We could have a table at the top linking to these sections:
Explicit Template Instantiation
Instantiation Scope
Argument Deduction
Template Type Parameters
Specialization
Template This Parameters
Template Value Parameters
Template Alias Parameters
Template Tuple Parameters
Template Parameter Default Values
Implicit Template Properties
Template Constructors
Class Templates
Struct, Union, and Interface Templates
Function Templates
Function Templates with Auto Ref Parameters
Recursive Templates
Template Constraints
Limitations

That is a lot of sections, and they're not being linked to right now
so they're hard to find without a search.

Re: Stupid little iota of an idea

[Andrei Alexandrescu]

On 2/11/11 2:46 AM, Jacob Carlborg wrote:

On 2011-02-10 23:05, Andrei Alexandrescu wrote:

On 2/10/11 9:47 AM, spir wrote:

Even then, noone forces D2 to blindly reproduce stupid naming from
APL/C++, I guess. Or what?


I don't find the name "iota" stupid.

Andrei


Of course you don't think it's stupid, you named it. It starts to look
more and more that you are the only one that likes it. How about we vote
about it ?



Sure. Have at it! I'll be glad to comply with the vote.

Andrei

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Bruno Medeiros wrote:
but seriously, even if I am 
connected to the Internet I cannot code with my laptop only, I need it 
connected to a monitor, as well as a mouse, (and preferably a keyboard 
as well).


I found I can't code on my laptop anymore; I am too used to and needful of a 
large screen.

Re: inlining or not inlining...

[Walter Bright]

bearophile wrote:

There are two groups of register allocation algorithms. The very
fast ones, and the more precise ones. You even have perfect ones. Experience
has shown that the difference in runtime performance between the precise
algorithm and the perfect ones is often about 5% (this measured on LLVM(.
This means that with LLVM you will probably never see a significant
improvement of automatic register allocation, because it's as good as it
gets, it's kind of a solved problem.


I've seen those papers on "precise" or even "perfect" register allocation. 
They're only precise within a certain set of assumptions the compiler makes 
about usage patterns. Those assumptions are, just that, assumptions. For 
example, assumptions are made about how many times this loop executes relative 
to that loop.


An asm programmer who knows his salt can do a better job, because he knows what 
the usage patterns are. Of course it's only rarely worth his while to do so, but 
nevertheless, calling such an algorithm "perfect" is misleading.

Re: 0nnn octal notation considered harmful

[spir]

On 02/11/2011 10:54 PM, Nick Sabalausky wrote:

"spir"  wrote in message
news:mailman.1504.1297453559.4748.digitalmar...@puremagic.com...

Hello,

Just had a strange bug --in a test func!-- caused by this notation. This
is due in my case to the practice (common, I guess) of "pretty printing"
int numbers using %0nd or %0ns format, to get a nice alignment. Then, if
one feeds back results into D code, they are interpreted as octal...
Now, i know it: will pad with spaces instead ;-)

Copying a string'ed integer is indeed not the only this notation is
bug-prone: prefixing a number with '0' should not change its value (!).
Several programming languages switched to another notation; like 0onnn,
which is consistent with common hex&  bin notations and cannot lead to
misinterpretation. Such a change would be, I guess, backward compatible;
and would not be misleading for C coders.



Yea, octal!"nnn" has already made the exceedingly rare uses of octal
literals completely obsolete *long* ago. I know I for one am getting really
tired of this completely unnecessary landmine in the language continuing to
exist. The heck with std.xml, if anything, *this* needs nuked. If silently
changed behavior is a problem, then just make it an error. Done. Minefield
cleared.


Thanks you (and Bearohile, IIRC) for the tip about octal!"nnn". Useless for me, 
unfortunately, since my problem (as you suggest) is not with how to write them, 
but the sheer existence of this $%*£µ#! notation ;-) What we need is a time 
bomb sent to ~ 1973.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: inlining or not inlining...

[Walter Bright]

spir wrote:

On 02/11/2011 08:11 PM, Walter Bright wrote:

bearophile wrote:
While in isolation that's a good idea, how far should it be taken? 
Should

the compiler emit information on which variables wound up in which
registers, and why? What about other of the myriad of compiler 
optimizations?


Inlining is an important optimization, so give this information to the
programmer is a good start.


Register allocation is far more important than inlining. Why not give
information about why a variable was not enregistered?


Because we do not ask for it ;-)


Actually, that is a good reason.

Joke apart, I would love that too, on tiny test apps indeed. Why not? 
Since the decision-taking exist (and is certainly well structured around 
its criteria), why not allow it writing out its "reasoning"?


About inline, note that no-one asks for information on every potentially 
inlinable func, blindly. But having a way to know that about /this/ func 
one is wondering about would be great: just append @inline to it, 
recompile, et voilà! you know :-) (provided you can interpret the 
output, but it's another story)



If I were a compiler writer, no doubt my code would hold snippets 
dedicated to spitting out such information, on need. For myself, as a 
testing tool to check the code really does what I mean. This is integral 
part of my coding style. Else, how can I know? Checking the ASM indeed 
can tell you, but it seems to me far more heavy & complicated than 
following the trace of a "reasoning", and tells nothing about 
where/why/how the encoded logic fails.

Then, if this can be useful to users...


Denis

Re: Should we have an Unimplemented Attribute?

[Simen kjaeraas]

Bruno Medeiros  wrote:


I think he means that any use of an @unimplemented class should give a
warning/error/other message.



I think you definitely get an error when trying to use a commented out  
class/struct... :)


Absolutely. But such a class/struct would also not show up in
documentation, allMembers, and the like. Not that I mind, just saying
it's not quite the same.

--
Simen

Re: Purity

[Simen kjaeraas]

Bruno Medeiros  wrote:

In this code sample if the optimization is applied on the second call to  
func, it would cause different code with be executed: the else clause  
instead of the then clause. Obviously this is not acceptable for an  
optimization, even if such code would be rare in practice.


Ah yes, I see now. I could argue that 'is' is cheating. :p

I believe actually, that pure is only said to promise that the returned
values should be such that func(args) == func(args), not accounting for
overloaded operators.

--
Simen

Re: 0nnn octal notation considered harmful

[Tomek Sowiński]

spir napisał:

> Just had a strange bug --in a test func!-- caused by this notation. This is 
> due 
> in my case to the practice (common, I guess) of "pretty printing" int numbers 
> using %0nd or %0ns format, to get a nice alignment. Then, if one feeds back 
> results into D code, they are interpreted as octal...
> Now, i know it: will pad with spaces instead ;-)
> 
> Copying a string'ed integer is indeed not the only this notation is 
> bug-prone: 
> prefixing a number with '0' should not change its value (!). Several 
> programming languages switched to another notation; like 0onnn, which is 
> consistent with common hex & bin notations and cannot lead to 
> misinterpretation. Such a change would be, I guess, backward compatible; and 
> would not be misleading for C coders.

This has been discussed before. There's octal!123 in Phobos if you don't like 
these confusing literals but they stay because Walter likes them. 

-- 
Tomek

Re: Stupid little iota of an idea

[foobar]

Ary Manzana Wrote:

> On 2/11/11 12:15 AM, Nick Sabalausky wrote:
> > "Andrej Mitrovic"  wrote in message
> > news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...
> >> What the hell does "to!" have to do with anything. Disregard my last
> >> post, it's obviously 3 AM and I'm talking gibberish.
> >>
> >
> > I just meant that "iota" looks a lot like (spaces added for clarity) "i   to
> > a". In other words, the first time I ever saw "iota", I confused it for the
> > old C function that converts an integer to an ASCII string. It may very well
> > have been 3am for me at the time ;)
> 
> You are the second one who confuses iota with itoa. Actually, the third, 
> I confused it too.
> 
> According to the book "The Design of Everyday Things" the design of that 
> function name is wrong, it's not your fault and it's not because it was 
> 3am. When many people make mistakes with regards to the design of 
> something it's *always* the design's fault, never the human's fault.
> 

Thanks for this, I'm adding this book to my read list. :)

Re: Stupid little iota of an idea

[Nick Sabalausky]

"foobar"  wrote in message news:ij3cal$cee$1...@digitalmars.com...
> Andrei Alexandrescu Wrote:
>
>>
>> I don't find the name "iota" stupid.
>>
>> Andrei
>
> Of course _you_ don't. However practically all the users _do_ find it 
> poorly named, including other developers in the project..
> This is the umpteenth time this comes up in the NG and incidentally this 
> is the only reason I know what the function does.
>
> If the users think the name is stupid than it really is. That's how 
> usability works and the fact the you think otherwise or that it might be 
> more accurate mathematically is really not relevant. If you want D/Phobos 
> to be used by other people besides yourself you need to cater for their 
> requirements.
>

I'd bet that most of the people looking at D's "filtering even numbers" 
example over at ( https://gist.github.com/817504 ) are thinking, "WTF is 
'iota'?"  (Either that or "What the hell is he converting to ASCII for?")

Re: Stupid little iota of an idea

[Nick Sabalausky]

"Steven Schveighoffer"  wrote in message 
news:op.vqrewtcfeav7ka@steve-laptop...
> On Fri, 11 Feb 2011 17:03:13 -0500, Nick Sabalausky  wrote:
>
>> "Steven Schveighoffer"  wrote in message
>> news:op.vqqsdxcaeav7ka@steve-laptop...
>>>
 According to the book "The Design of Everyday Things" the design of 
 that
 function name is wrong, it's not your fault and it's not because it was
 3am. When many people make mistakes with regards to the design of
 something it's *always* the design's fault, never the human's fault.
>>>
>>> I love that book, I wish more software engineers used it.  One of my
>>> favorite classes at college.
>>>
>>
>> I probably would have liked that class if my college hadn't degenerated 
>> it
>> into nothing more than "group VB6 project". Bleh. I always hated group
>> projects.  /me "Does not play well with others."
>
> From what I can remember, I did not have to write any code in that class. 
> I had to pick an item in my household and write a paper on what features 
> were well designed and which ones were poor.  I have a feeling you would 
> have loved that ;)
>

lol, that's a good point, I probably could have had a lot of fun with that 
:)

Re: Stupid little iota of an idea

[bearophile]

Nick Sabalausky:

> I really should actually read that book.

Donald Norman is not a genius, he seems to lack both in engineering knowledge 
and classic literary culture, but despite this he has the right mindset to 
explore the world and he does look a lot at the world and its things, so he 
ends saying many interesting things. I suggest to read all books written by him 
:-) 

Bye,
bearophile

Re: Stupid little iota of an idea

[Steven Schveighoffer]

On Fri, 11 Feb 2011 17:03:13 -0500, Nick Sabalausky  wrote:


"Steven Schveighoffer"  wrote in message
news:op.vqqsdxcaeav7ka@steve-laptop...


According to the book "The Design of Everyday Things" the design of  
that

function name is wrong, it's not your fault and it's not because it was
3am. When many people make mistakes with regards to the design of
something it's *always* the design's fault, never the human's fault.


I love that book, I wish more software engineers used it.  One of my
favorite classes at college.



I probably would have liked that class if my college hadn't degenerated  
it

into nothing more than "group VB6 project". Bleh. I always hated group
projects.  /me "Does not play well with others."


From what I can remember, I did not have to write any code in that class.   
I had to pick an item in my household and write a paper on what features  
were well designed and which ones were poor.  I have a feeling you would  
have loved that ;)


-Steve

Re: inlining or not inlining...

[spir]

On 02/11/2011 10:08 PM, bearophile wrote:

spir:


About inline, note that no-one asks for information on every potentially
inlinable func, blindly. But having a way to know that about /this/ func one is
wondering about would be great: just append @inline to it, recompile, et voilà!
you know :-) (provided you can interpret the output, but it's another story)


If that's your purpose then I suggest a name as @isInlinable  :-)


Fine :-)

denis
--
_
vita es estrany
spir.wikidot.com

Re: inlining or not inlining...

[spir]

On 02/11/2011 10:22 PM, Christopher Nicholson-Sauls wrote:

On 02/11/11 14:26, Jim wrote:

Jim Wrote:


bearophile Wrote:

The LLVM back-end of LDC is able to inline much more, but even here a list of 
inlined/not inlined functions helps. D is almost a system language, so 
sometimes you need to go lower level (or you just need a program that's not too 
much slow).



If forced inlining is to be supported I think it would be good idea to also let 
the _caller_ decide whether to inline a function. The compiler could simply 
find the function definition, perhaps parameterize it, and then insert it. 
Should it not be able to inline almost any function if asked to?



Just had another idea..
A function would know statically whether it has been inlined or not. If inlined 
it could choose to propagate this attribute to any of its own callees. Not sure 
it would be useful though, just thinking aloud..


And at this point what once seemed a simple thing starts to show its
complexity teeth.  Suddenly there are all this adjunct features to be
provided in order to make it properly useful.

Don't get me wrong, I'd actually like having all this... but I'm not
sure of the cost in compiler complexity (and likely slowdown) and
language bloat.

But, here's some notions:

== I really want foo() to be inlined, if even remotely possible! ==

pragma( inline )
int foo () { ... }

== I'll be calling foo(), and I'd like it inlined if possible ==

int bar () {
   pragma( inline, foo );
   // ...
   auto x = foo();
}

== I'm foo(), and I'd like to know if I am being inlined ==

int foo () {
   pragma( inline, true ) {
 // inline code
   }
   pragma( inline, false ) {
 // ordinary code
   }
}

-- or if we ever get that 'meta' namespace some of us want --

int foo () {
   static if ( meta.inlined ) {
 // inline code
   }
   else {
 // ordinary code
   }
}

My chief complaint with my own notions is that 'pragma(inline' ends up
with three different forms.  This just isn't typical of a pragma.

-- Chris N-S


All of this is hardly related to the simple feature I initially asked for:

string escString (string s) @tellmeifnotinlined {
s2 = s.replace("\n","\\n");
s2 = s.replace("\t","\\t");
return s2;
}
void show (X x) {
// ... use escString ...
}
==>
Warning: function 'escString' in module 'foo' (line 123) was not 
inlined.
(or else it was actually inlined)

Which (I guess) is not that a big deal since the compiler needs to decide 
anyway. I just wish to be informed of the result of the decision procedure, 
only in case of 'no'.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[Nick Sabalausky]

"bearophile"  wrote in message 
news:ij473k$1tfn$1...@digitalmars.com...
> Andrei:
>
>> Aside from the fact that "range" has another meaning in D, the word does
>> not convey the notion that iota adds incremental steps to move from one
>> number to another. "Iota" does convey that notion.
>
> I have accepted  the "iota" name, it's short, easy to remember, it has one 
> historical usage in APL, and "Range" has another meaning in D (but it's 
> weird, and it's something you need to learn, it's not something a newbie 
> is supposed to know before reading D2 docs well. The name "interval" is 
> better, simpler to understand, but it's longer for a so common function).
>
> But this answer of yours is stepping outside the bounds of reasonableness 
> :-) If you ask a pool of 20 programmers what range(10,20) or iota(10,20) 
> means, I'm sure more people will guess range() correctly than iota(). The 
> word range() do convey a complete enumeration of values in an interval. 
> iota() does not convey that.
>
> Said all this, I suggest to introduce the first-class a..b interval syntax 
> in D (or even a..b:c), this is able to remove most (all?) usage of iota().
>

I like "interval", too.

I do think the name "iota" is a nice extra reason to just use a..b or a..b:c 
like you say. It also makes it clear that it's a series of discrete values 
rather than a true mathematical range, since that's exactly how foreach 
already uses a..b: as a series of discrete values.

Re: More on Rust

[Andrej Mitrovic]

On 2/11/11, Christopher Nicholson-Sauls  wrote:
>
> Even better:
>
> switch( funcall() ) {
> case "foo", "bar", "foobar", "barfoo": {
> // complex code
> break;
> }
>
> case "blue", "green": {
> // complex code
> break;
> }
>
> default:
> // do nothing -- i like to comment defaults
> }
>
> Also often forgotten, that 'case' clauses take an argument list, not
> just an expression.  And yeah, in this case at least... it still fits in
> 80 columns.  (I prefer 90 myself, but it's moot.)
>
> -- Chris N-S
>

Damn I didn't know that! Thanks.

Re: inlining or not inlining...

[spir]

On 02/11/2011 09:49 PM, bearophile wrote:

Jim:


If forced inlining is to be supported


spir was asking for a list of functions that the compiled has inlined, not for 
a forced inlining functionality.


You are (nearly) right, Bearophile. More precisely, I rather wish @inline on a 
given func to output a compiler message if said func is *not* inlined, due to 
some criterion the compiler uses to decide; at best, some hint about said 
criterion.
I certainly do /not/ ask for forced inlining. (But others take the thread and 
speak of what they wish...)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[Nick Sabalausky]

"Steven Schveighoffer"  wrote in message 
news:op.vqqsdxcaeav7ka@steve-laptop...
>
>> According to the book "The Design of Everyday Things" the design of that 
>> function name is wrong, it's not your fault and it's not because it was 
>> 3am. When many people make mistakes with regards to the design of 
>> something it's *always* the design's fault, never the human's fault.
>
> I love that book, I wish more software engineers used it.  One of my 
> favorite classes at college.
>

I probably would have liked that class if my college hadn't degenerated it 
into nothing more than "group VB6 project". Bleh. I always hated group 
projects.  /me "Does not play well with others."

I really should actually read that book. I've heard a lot about what it 
says, and I like everything I've heard. Even without having read it, it's 
still influenced me a fair amount.

Re: 0nnn octal notation considered harmful

[Nick Sabalausky]

"spir"  wrote in message 
news:mailman.1504.1297453559.4748.digitalmar...@puremagic.com...
> Hello,
>
> Just had a strange bug --in a test func!-- caused by this notation. This 
> is due in my case to the practice (common, I guess) of "pretty printing" 
> int numbers using %0nd or %0ns format, to get a nice alignment. Then, if 
> one feeds back results into D code, they are interpreted as octal...
> Now, i know it: will pad with spaces instead ;-)
>
> Copying a string'ed integer is indeed not the only this notation is 
> bug-prone: prefixing a number with '0' should not change its value (!). 
> Several programming languages switched to another notation; like 0onnn, 
> which is consistent with common hex & bin notations and cannot lead to 
> misinterpretation. Such a change would be, I guess, backward compatible; 
> and would not be misleading for C coders.
>

Yea, octal!"nnn" has already made the exceedingly rare uses of octal 
literals completely obsolete *long* ago. I know I for one am getting really 
tired of this completely unnecessary landmine in the language continuing to 
exist. The heck with std.xml, if anything, *this* needs nuked. If silently 
changed behavior is a problem, then just make it an error. Done. Minefield 
cleared.

Re: inlining or not inlining...

[Christopher Nicholson-Sauls]

On 02/11/11 14:26, Jim wrote:
> Jim Wrote:
> 
>> bearophile Wrote:
>>> The LLVM back-end of LDC is able to inline much more, but even here a list 
>>> of inlined/not inlined functions helps. D is almost a system language, so 
>>> sometimes you need to go lower level (or you just need a program that's not 
>>> too much slow).
>>
>>
>> If forced inlining is to be supported I think it would be good idea to also 
>> let the _caller_ decide whether to inline a function. The compiler could 
>> simply find the function definition, perhaps parameterize it, and then 
>> insert it. Should it not be able to inline almost any function if asked to?
> 
> 
> Just had another idea..
> A function would know statically whether it has been inlined or not. If 
> inlined it could choose to propagate this attribute to any of its own 
> callees. Not sure it would be useful though, just thinking aloud..

And at this point what once seemed a simple thing starts to show its
complexity teeth.  Suddenly there are all this adjunct features to be
provided in order to make it properly useful.

Don't get me wrong, I'd actually like having all this... but I'm not
sure of the cost in compiler complexity (and likely slowdown) and
language bloat.

But, here's some notions:

== I really want foo() to be inlined, if even remotely possible! ==

pragma( inline )
int foo () { ... }

== I'll be calling foo(), and I'd like it inlined if possible ==

int bar () {
  pragma( inline, foo );
  // ...
  auto x = foo();
}

== I'm foo(), and I'd like to know if I am being inlined ==

int foo () {
  pragma( inline, true ) {
// inline code
  }
  pragma( inline, false ) {
// ordinary code
  }
}

-- or if we ever get that 'meta' namespace some of us want --

int foo () {
  static if ( meta.inlined ) {
// inline code
  }
  else {
// ordinary code
  }
}

My chief complaint with my own notions is that 'pragma(inline' ends up
with three different forms.  This just isn't typical of a pragma.

-- Chris N-S

Re: inlining or not inlining...

[bearophile]

spir:

> About inline, note that no-one asks for information on every potentially 
> inlinable func, blindly. But having a way to know that about /this/ func one 
> is 
> wondering about would be great: just append @inline to it, recompile, et 
> voilà! 
> you know :-) (provided you can interpret the output, but it's another story)

If that's your purpose then I suggest a name as @isInlinable  :-)

Bye,
bearophile

Re: unsigned < 0

[bearophile]

Iain Buclaw:

> You also need to watch out for code like this too:
> if (T.min < 0) { ...
> As that could possibly trigger off unsigned < 0 warnings too.

I was not talking about warnings. I was talking about changing the D language, 
turning that into a _error_ if x is unsigned.

Bye,
bearophile

Re: inlining or not inlining...

[bearophile]

Walter:

> bearophile wrote:
> >> While in isolation that's a good idea, how far should it be taken? Should 
> >> the 
> >> compiler emit information on which variables wound up in which registers, 
> >> and 
> >> why? What about other of the myriad of compiler optimizations?
> > 
> > Inlining is an important optimization, so give this information to the 
> > programmer is a good start.
> 
> Register allocation is far more important than inlining. Why not give 
> information about why a variable was not enregistered?

Some answers:
- I am not asking for this information because it is harder to use for me. If a 
function was inlined or not is simpler to use for me.
- In my D1 code I have found two or more problems caused by failed inlining. So 
this is of my interest.
- If you want to optionally give the register information to the programmer, 
then do it. I am not going to stop you :-) Some people need this information, 
like when you implement the little kernels of a very fast FFT.
- Register allocation on 32 bit CPUs is not the same as on 64 bit ones. On 64 
bit you have many more registers (and you have SSE registers, and now AVX too), 
so in many situations the register pressure is lower.
- There are two groups of register allocation algorithms. The very fast ones, 
and the more precise ones. You even have perfect ones. Experience has shown 
that the difference in runtime performance between the precise algorithm and 
the perfect ones is often about 5% (this measured on LLVM(. This means that 
with LLVM you will probably never see a significant improvement of automatic 
register allocation, because it's as good as it gets, it's kind of a solved 
problem. In JITs like in the JavaVM you have register allocation algorithms 
that are less precise but faster. Here there is space for possible future 
improvements. And then, there are the special situations, like implementing 
those little FFT kernels, or when you want to compile a functional language 
like Haskell into assembly. In such situations even the very good automatic 
register allocation algorithms are not good enough. In this case information 
about register allocation is useful, but this is a very specialized usage.!
  The need to know about inlining is in my opinion more common.

Bye,
bearophile

Re: More on Rust

[Christopher Nicholson-Sauls]

On 02/10/11 13:49, Andrej Mitrovic wrote:
> On 2/10/11, Walter Bright  wrote:
>> auto x = (localtime().hours >= 8) ? "awake!" : "asleep, go away.";
> 
> Aye, a one liner!
> 
> I hate seeing things like this:
> if (funcall())
> {
> var = "foo";
> }
> else
> {
> var = "bar";
> }
> 
> So much clutter instead of using the simple:
> var = funcall() ? "foo" : "bar";
> 
> I also see this sometimes:
> 
> auto var = funcall();
> if (var == "foo" || var == "bar" || var == "foobar" || var == "barfoo")
> {
> // some complex code
> }
> else if (var == "blue" || var == "green")
> {
> // some complex code
> }
> else if ()// more and more code..
> { }
> 
> But not many people seem to know that D supports strings in case statements:
> switch(funcall())
> {
> case "foo":
> case "bar":
> case "foobar":
> case "barfoo":
> {
> // complex code
> }
> break;
> case "blue":
> case "green":
> {
>// complex code
> }
> break;
> default:
> }
> 

Even better:

switch( funcall() ) {
case "foo", "bar", "foobar", "barfoo": {
// complex code
break;
}

case "blue", "green": {
// complex code
break;
}

default:
// do nothing -- i like to comment defaults
}

Also often forgotten, that 'case' clauses take an argument list, not
just an expression.  And yeah, in this case at least... it still fits in
80 columns.  (I prefer 90 myself, but it's moot.)

-- Chris N-S

Re: inlining or not inlining...

[bearophile]

Jim:

> If forced inlining is to be supported

spir was asking for a list of functions that the compiled has inlined, not for 
a forced inlining functionality.

Bye,
bearophile

Re: Stupid little iota of an idea

[bearophile]

Andrei:

> Aside from the fact that "range" has another meaning in D, the word does 
> not convey the notion that iota adds incremental steps to move from one 
> number to another. "Iota" does convey that notion.

I have accepted  the "iota" name, it's short, easy to remember, it has one 
historical usage in APL, and "Range" has another meaning in D (but it's weird, 
and it's something you need to learn, it's not something a newbie is supposed 
to know before reading D2 docs well. The name "interval" is better, simpler to 
understand, but it's longer for a so common function).

But this answer of yours is stepping outside the bounds of reasonableness :-) 
If you ask a pool of 20 programmers what range(10,20) or iota(10,20) means, I'm 
sure more people will guess range() correctly than iota(). The word range() do 
convey a complete enumeration of values in an interval. iota() does not convey 
that.

Said all this, I suggest to introduce the first-class a..b interval syntax in D 
(or even a..b:c), this is able to remove most (all?) usage of iota().

Bye,
bearophile

Re: 0nnn octal notation considered harmful

[bearophile]

spir:

> like 0onnn, which is 
> consistent with common hex & bin notations and cannot lead to 
> misinterpretation. Such a change would be, I guess, backward compatible; and 
> would not be misleading for C coders.

The 0nnn octal syntax is bug-prone, and not explicit, it's out of place in a 
language like D that's designed to be a bit safer than C.
The 0onnn syntax adopted by Python3 is safer, more explicit, it's good enough. 
But the leading zero syntax can't be kept in D for backwards C compatibility, 
so it needs to be just disallowed statically...

Walter likes the C octal syntax as a personal thing. Andrei prefers a syntax 
like octal! that's less compact, even more explicit, library-defined, and 
it has a corner case (when numbers become very large you need a string):
http://www.digitalmars.com/d/2.0/phobos/std_conv.html#octal

Bye,
bearophile

Re: 0nnn octal notation considered harmful

[Adam Ruppe]

We actually have a library replacement for octal literals:

http://dpldocs.info/octal

But until the C style syntax is disallowed, it doesn't change
anything. But, Walter is resistant to the change, last I knew.

Re: Stupid little iota of an idea

[bearophile]

Jim:

> bearophile Wrote:
> > Then in D2 for those use an int. Unsigned values are _very_ bug-prone in D2.
> 
> May I ask why?

Because:
- D unsigned numbers are fixed-sized bitfields, they overflow. (Multi-precision 
values are not built-in, they are currently slow if you need a 30 or 50 or 70 
bit long value, and generally they feel like grafted on the language).
- There are no run-time overflow errors, as in C#/Delphi/etc (this is 
ridiculous for any language that hopes to make safety one of its strong points. 
Delphi has this feature since ages ago. Not having this in D is like going back 
to 1980 or before. It gives a peculiar stone-age style to the whole D language).
- D copies the weird/bad C signed-unsigned conversion rules, that cause plenty 
of troubles.
- D doesn't have warnings like GCC that give a bit of help against the C 
signed-unsigned conversion rules, nor against things like unsigned<0.

In Delphi using unsigned numbers is safer, but in D it's actually safer to use 
signed values :-)
All this is compound with the design choice of using signed values for arrays 
and indexes in D.

One even less bright design decision was to use unsigned longs for array 
positions, etc:
http://d.puremagic.com/issues/show_bug.cgi?id=5452

Generally in the current D the best advice is to limit the usage of unsigned 
values as much as possible, and use them only in the uncommon situations where 
they are needed, like:
- When you need the full range of 8, 16, 32 or 64 bits. This is uncommon, but 
it happens. Example: you really want to save memory to store indexes and you 
need you will have no more than about 40_000 items. Then use an ushort.
- To store bitfields, like an array of 50_000 bits, to implement a bit set, 
some kind of bitmap, bloom filter, etc.
- When you need to deserialize or receive data from some channel or memory, 
that you know is for example a 32 unsigned int or 16 bit unsigned int, a 
unsigned 8 bit digital signal from some instrument, etc.

In most other cases it's better to use signed values, for example you will 
avoid several bugs if in your code you use lines of code like:
int len = array.length;
and then you use len in the rest of your function.

Bye,
bearophile

Re: inlining or not inlining...

[Jim]

Jim Wrote:

> bearophile Wrote:
> > The LLVM back-end of LDC is able to inline much more, but even here a list 
> > of inlined/not inlined functions helps. D is almost a system language, so 
> > sometimes you need to go lower level (or you just need a program that's not 
> > too much slow).
> 
> 
> If forced inlining is to be supported I think it would be good idea to also 
> let the _caller_ decide whether to inline a function. The compiler could 
> simply find the function definition, perhaps parameterize it, and then insert 
> it. Should it not be able to inline almost any function if asked to?


Just had another idea..
A function would know statically whether it has been inlined or not. If inlined 
it could choose to propagate this attribute to any of its own callees. Not sure 
it would be useful though, just thinking aloud..

Re: 0nnn octal notation considered harmful

[Jim]

spir Wrote:

> Hello,
> 
> Just had a strange bug --in a test func!-- caused by this notation. This is 
> due 
> in my case to the practice (common, I guess) of "pretty printing" int numbers 
> using %0nd or %0ns format, to get a nice alignment. Then, if one feeds back 
> results into D code, they are interpreted as octal...
> Now, i know it: will pad with spaces instead ;-)
> 
> Copying a string'ed integer is indeed not the only this notation is 
> bug-prone: 
> prefixing a number with '0' should not change its value (!). Several 
> programming languages switched to another notation; like 0onnn, which is 
> consistent with common hex & bin notations and cannot lead to 
> misinterpretation. Such a change would be, I guess, backward compatible; and 
> would not be misleading for C coders.

Fine with me. I've never used octal numbers (intently!). I guess some notation 
is needed for them, if not for historical reasons.

Re: inlining or not inlining...

[spir]

On 02/11/2011 08:11 PM, Walter Bright wrote:

bearophile wrote:

While in isolation that's a good idea, how far should it be taken? Should
the compiler emit information on which variables wound up in which
registers, and why? What about other of the myriad of compiler optimizations?


Inlining is an important optimization, so give this information to the
programmer is a good start.


Register allocation is far more important than inlining. Why not give
information about why a variable was not enregistered?


Because we do not ask for it ;-)
Joke apart, I would love that too, on tiny test apps indeed. Why not? Since the 
decision-taking exist (and is certainly well structured around its criteria), 
why not allow it writing out its "reasoning"?


About inline, note that no-one asks for information on every potentially 
inlinable func, blindly. But having a way to know that about /this/ func one is 
wondering about would be great: just append @inline to it, recompile, et voilà! 
you know :-) (provided you can interpret the output, but it's another story)



If I were a compiler writer, no doubt my code would hold snippets dedicated to 
spitting out such information, on need. For myself, as a testing tool to check 
the code really does what I mean. This is integral part of my coding style. 
Else, how can I know? Checking the ASM indeed can tell you, but it seems to me 
far more heavy & complicated than following the trace of a "reasoning", and 
tells nothing about where/why/how the encoded logic fails.

Then, if this can be useful to users...


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[Jim]

bearophile Wrote:
> Then in D2 for those use an int. Unsigned values are _very_ bug-prone in D2.

May I ask why?

Re: inlining or not inlining...

[Jim]

bearophile Wrote:
> The LLVM back-end of LDC is able to inline much more, but even here a list of 
> inlined/not inlined functions helps. D is almost a system language, so 
> sometimes you need to go lower level (or you just need a program that's not 
> too much slow).


If forced inlining is to be supported I think it would be good idea to also let 
the _caller_ decide whether to inline a function. The compiler could simply 
find the function definition, perhaps parameterize it, and then insert it. 
Should it not be able to inline almost any function if asked to?

0nnn octal notation considered harmful

[spir]

Hello,

Just had a strange bug --in a test func!-- caused by this notation. This is due 
in my case to the practice (common, I guess) of "pretty printing" int numbers 
using %0nd or %0ns format, to get a nice alignment. Then, if one feeds back 
results into D code, they are interpreted as octal...

Now, i know it: will pad with spaces instead ;-)

Copying a string'ed integer is indeed not the only this notation is bug-prone: 
prefixing a number with '0' should not change its value (!). Several 
programming languages switched to another notation; like 0onnn, which is 
consistent with common hex & bin notations and cannot lead to 
misinterpretation. Such a change would be, I guess, backward compatible; and 
would not be misleading for C coders.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[Andrej Mitrovic]

On 2/11/11, Andrei Alexandrescu  wrote:
> On 2/10/11 8:28 PM, Andrej Mitrovic wrote:
>> What the hell does "to!" have to do with anything. Disregard my last
>> post, it's obviously 3 AM and I'm talking gibberish.
>>
>> In any case,
>> alias iota range;
>>
>> Problem solved for me!
>
> Aside from the fact that "range" has another meaning in D, the word does
> not convey the notion that iota adds incremental steps to move from one
> number to another. "Iota" does convey that notion.
>
> Andrei
>

So why does Python use it?

It seems Go uses iota, but for something different:
http://golang.org/doc/go_spec.html#Iota

That's rather ugly imo. But that's Go. :)

Re: unsigned < 0

[Iain Buclaw]

== Quote from bearophile (bearophileh...@lycos.com)'s article
> > To avoid troubles in generic code you need a little workaround:
> > if (__traits(isUnsigned, x) || x >= 0) { ...
> That's not good enough yet. The first part of the test needs to be done in a
static if.
> Bye,
> bearophile

You also need to watch out for code like this too:
if (T.min < 0) { ...
As that could possibly trigger off unsigned < 0 warnings too.

Regards
Iain

Re: Unilink - alternative linker for win32/64, DMD OMF extensions?

[Daniel Gibson]

Am 11.02.2011 19:56, schrieb Dmitry Olshansky:
> Ok, bumping this up with the latest news from UniLink developers:
> 
> 
> Ok, we release it's as D extension in next release.
> 
> Best regards,
>  UniLink
> 
> 
> 
> That's just plain awesome ;)
> 

Great :)

Re: D vs Go on reddit

[Walter Bright]

Jeff Nowakowski wrote:
1.5 was when Java got foreach, generics, and enum. I don't think there 
were any syntactical language changes before that. Previous version 
updates were mostly about libraries and frameworks.


Inner classes were added earlier.

Re: inlining or not inlining...

[Walter Bright]

bearophile wrote:
While in isolation that's a good idea, how far should it be taken? Should the 
compiler emit information on which variables wound up in which registers, and 
why? What about other of the myriad of compiler optimizations?


Inlining is an important optimization, so give this information to the 
programmer is a good start.


Register allocation is far more important than inlining. Why not give 
information about why a variable was not enregistered?

Re: Unilink - alternative linker for win32/64, DMD OMF extensions?

[Dmitry Olshansky]

Ok, bumping this up with the latest news from UniLink developers:


Ok, we release it's as D extension in next release.

Best regards,
 UniLink



That's just plain awesome ;)

--
Dmitry Olshansky

Re: Stupid little iota of an idea

[Andrei Alexandrescu]

On 2/10/11 8:28 PM, Andrej Mitrovic wrote:

What the hell does "to!" have to do with anything. Disregard my last
post, it's obviously 3 AM and I'm talking gibberish.

In any case,
alias iota range;

Problem solved for me!


Aside from the fact that "range" has another meaning in D, the word does 
not convey the notion that iota adds incremental steps to move from one 
number to another. "Iota" does convey that notion.


Andrei

Re: Stupid little iota of an idea

[Andrei Alexandrescu]

On 2/10/11 5:29 PM, Sean Kelly wrote:

Andrei Alexandrescu Wrote:


I don't find the name "iota" stupid.


I never entirely understood the name choice.  I suppose "iota" could be related to a 
"small step" so iota(1,5) is a series of small steps from 1 to 5?


Pretty much, with the note that the smallest nondegenerated integral 
step is 1 :o).


The name "iota" makes perfect sense to me, I knew what it does in the 
STL from its signature before reading its definition. There are people 
who don't like it, there are people who do, and there are people who 
simply pick up the name and use it. I don't see how to improve global 
happiness.



Andrei

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Michel Fortin]

On 2011-02-11 08:05:27 -0500, Bruno Medeiros 
 said:



On 09/02/2011 14:27, Michel Fortin wrote:

On 2011-02-09 07:49:31 -0500, Bruno Medeiros
 said:


I was about to say "Cool!", but then I checked the doc on that link
and it says:
"A shallow repository has a number of limitations (you cannot clone or
fetch from it, nor push from nor into it), but is adequate if you are
only interested in the recent history of a large project with a long
history, and would want to send in fixes as patches. "
So it's actually not good for what I meant, since it is barely usable
(you cannot push from it). :(


Actually, pushing from a shallow repository can work, but if your
history is not deep enough it will be a problem when git tries determine
the common ancestor. Be sure to have enough depth so that your history
contains the common ancestor of all the branches you might want to
merge, and also make sure the remote repository won't rewrite history
beyond that point and you should be safe. At least, that's what I
understand from:



Interesting. 


But it still feels very much like a second-class functionality, not 
something they really have in mind to support well, at least not yet.


Ideally, if one wants to do push but the ancestor history is 
incomplete, the VCS would download from the central repository whatever 
revision/changeset information was missing.


Actually, there's no "central" repository in Git. But I agree with your 
idea in general: one of the remotes could be designated as being a 
source to look for when encountering a missing object, probably the one 
from which you shallowly cloned from. All we need is someone to 
implement that.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: inlining or not inlining...

[spir]

On 02/11/2011 07:08 PM, bearophile wrote:

Jim:


I rarely need to go that low-level.


Two times I have had D1 code that was too much slow compared to equivalent C 
code. After profiling and some changes I have understood that the cause was an 
important missing inline. With a list of the inlined functions (as done by 
CommonLisp some compilers, see the enhancement request in Bugzilla), this 
search becomes quicker.



My hope is that the compiler will sort this out in the end. Give it some time, 
or effort to have these optimizations implemented in the compiler.


The LLVM back-end of LDC is able to inline much more, but even here a list of 
inlined/not inlined functions helps. D is almost a system language, so 
sometimes you need to go lower level (or you just need a program that's not too 
much slow).


To me the relevant aspect is not that much practical effect, but understanding 
how/why/what is inlined by (hopefully good) compilers. Learning about that, 
even if not much put in practice (I don't intend to write the next big 
language's compiler ;-) can only improve coding skills and, say... help and 
stop shooting in the dark.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Stupid little iota of an idea

[bearophile]

spir:

> But for 99% uses of cardinals and ordinals uint is by far big enough.

Then in D2 for those use an int. Unsigned values are _very_ bug-prone in D2.

Bye,
bearophile

Re: inlining or not inlining...

[bearophile]

Jim:

> I rarely need to go that low-level.

Two times I have had D1 code that was too much slow compared to equivalent C 
code. After profiling and some changes I have understood that the cause was an 
important missing inline. With a list of the inlined functions (as done by 
CommonLisp some compilers, see the enhancement request in Bugzilla), this 
search becomes quicker.


> My hope is that the compiler will sort this out in the end. Give it some 
> time, or effort to have these optimizations implemented in the compiler.

The LLVM back-end of LDC is able to inline much more, but even here a list of 
inlined/not inlined functions helps. D is almost a system language, so 
sometimes you need to go lower level (or you just need a program that's not too 
much slow).

Bye,
bearophile

Re: Stupid little iota of an idea

[spir]

On 02/11/2011 03:32 PM, Daniel Gibson wrote:

Am 10.02.2011 12:40, schrieb spir:


Certainly, because it's /highly/ important for a community of programmers to
share the same "culture". And names are the main support&  vehicle for this
culture.

Denis

(For this reason, I stoppped aliasing size_t and size_diff_t to Ordinal and
Cardinal ;-) I use uint everywhere)



This will cause trouble on 64bit systems, because there size_t is ulong.


Yes and No. For pointers and mem diffs, yes. But for 99% uses of cardinals and 
ordinals uint is by far big enough.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Purity

[bearophile]

Bruno Medeiros:

> Hum, it might still be useful to have something like a compiler switch 
> that disables pure altogether, then people could use I/O and other 
> non-pure operations for debugging purposes. One could wrap such code 
> with a version statement:
> 
> void myPurefunc(Foo foo) pure {
>version(pure_disabled) {
>  writeln("some debug info: ", foo);
>}
>//...

This seems an interesting idea to help debug pure functions.

Bye,
bearophile

Re: std.regex

[spir]

On 02/11/2011 03:05 PM, jovo wrote:

Recently I tried std.regex, and must say I’m very satisfied with new interface.
Just one small objection, I think captures range don’t need match.hit at front.


???

Denis
--
_
vita es estrany
spir.wikidot.com

Re: D vs Go on reddit

[Jeff Nowakowski]

On 02/10/2011 10:08 PM, Nick Sabalausky wrote:


Regarding Java 1.3/1.4: They may very well have been closer to 1.2 than they
were to 1.5/1.6 (I wouldn't know), but IIRC 1.3 was when it finally started
to give people little bits of suger (ex: foreach).


1.5 was when Java got foreach, generics, and enum. I don't think there 
were any syntactical language changes before that. Previous version 
updates were mostly about libraries and frameworks.

Re: D vs Go on reddit

[Daniel Gibson]

Am 09.02.2011 23:56, schrieb Ulrik Mikaelsson:
> Maybe it's [JavaScript] the ASM of next decade.

Bringing the performance of the second last decades systems to hardware of the
next decade.
Hooray \o/

Re: std.xml should just go

[Michel Fortin]

On 2011-02-11 09:29:03 -0500, Bruno Medeiros 
 said:



On 11/02/2011 13:48, Steven Schveighoffer wrote:

I think D can do it without copying out of the buffer. You just have to
avoid using immutable strings.

-Steve


The data that you want to keep afterwards you will have to copy, that 
much is obvious.


In fact, if the amount of data you want to keep is greater than the one 
you want to throw away, it might be better to make the buffer immutable 
and allocate new buffers as you go forward. One allocation per buffer 
is likely going to be less wasteful than one allocation + one copy per 
string (+ some space wasted after each memory block).


If you don't intend to keep most of the data after parsing however, 
then you should go for a mutable buffer and copy what you need.


What I like very much about Andrei's proposal for a buffered input 
range is that it makes it supports equally well mutable and immutable 
buffers.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: std.xml should just go

[Bruno Medeiros]

On 04/02/2011 16:14, Eric Poggel wrote:

On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:

At this point there is no turning back from ranges, unless we come about
with an even better idea (I discussed one with Walter but we're not
pursuing it yet).


Care to elaborate on the new idea? Or at least a quick summary so we're
not all left wondering?


That comment left me curious as well...

--
Bruno Medeiros - Software Engineer

Re: Stupid little iota of an idea

[Daniel Gibson]

Am 10.02.2011 12:40, schrieb spir:
> 
> Certainly, because it's /highly/ important for a community of programmers to
> share the same "culture". And names are the main support & vehicle for this
> culture.
> 
> Denis
> 
> (For this reason, I stoppped aliasing size_t and size_diff_t to Ordinal and
> Cardinal ;-) I use uint everywhere)
> 

This will cause trouble on 64bit systems, because there size_t is ulong.

Cheers,
- Daniel

Re: std.xml should just go

[Bruno Medeiros]

On 11/02/2011 13:48, Steven Schveighoffer wrote:

On Fri, 11 Feb 2011 08:19:51 -0500, Bruno Medeiros
 wrote:


On 04/02/2011 21:07, Steven Schveighoffer wrote:

On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski 
wrote:


On 02/03/2011 10:07 PM, Walter Bright wrote:


The way to get a high performance string parser in D is to take
advantage of one of D's unique features - slices. Java, C++, C#, etc.,
all rely on copying strings. With D you can just use slices into the
original XML source text. If you're copying the text, you're doing it
wrong.


Java's substring() does not copy the text, at least in the official
JDK implementation. Unfortunately, it doesn't specify this behavior as
part of the String API.


Yes, but Java's strings are immutable. Typically a buffered I/O stream
has a mutable buffer used to read data. This necessitates a copy. At the
very least, you need to continue allocating more memory to hold all the
strings.

-Steve


True, but in this case you will have the exact same problem with any
other language as well. So it doesn't seem like D will have any
particular advantage over Java, with regards to slicing and strings.



I think D can do it without copying out of the buffer. You just have to
avoid using immutable strings.

-Steve


The data that you want to keep afterwards you will have to copy, that 
much is obvious.
As for the data you don't want to keep (but just guide you through the 
parsing), yes in D you can look at it without copying it out of the 
buffer. But you can do the same in Java, there is this core interface 
CharSequence that is roughly equivalent to a D slice for chars 
(http://download.oracle.com/javase/1.4.2/docs/api/java/lang/CharSequence.html)


--
Bruno Medeiros - Software Engineer

Re: Stupid little iota of an idea

[Steven Schveighoffer]

On Fri, 11 Feb 2011 09:06:06 -0500, Ary Manzana   
wrote:



On 2/11/11 12:15 AM, Nick Sabalausky wrote:

"Andrej Mitrovic"  wrote in message
news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...

What the hell does "to!" have to do with anything. Disregard my last
post, it's obviously 3 AM and I'm talking gibberish.



I just meant that "iota" looks a lot like (spaces added for clarity)  
"i   to
a". In other words, the first time I ever saw "iota", I confused it for  
the
old C function that converts an integer to an ASCII string. It may very  
well

have been 3am for me at the time ;)


You are the second one who confuses iota with itoa. Actually, the third,  
I confused it too.


Me 2.

According to the book "The Design of Everyday Things" the design of that  
function name is wrong, it's not your fault and it's not because it was  
3am. When many people make mistakes with regards to the design of  
something it's *always* the design's fault, never the human's fault.


I love that book, I wish more software engineers used it.  One of my  
favorite classes at college.


-Steve

Re: Stupid little iota of an idea

[Steven Schveighoffer]

On Fri, 11 Feb 2011 09:06:06 -0500, Ary Manzana   
wrote:



On 2/11/11 12:15 AM, Nick Sabalausky wrote:

"Andrej Mitrovic"  wrote in message
news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...

What the hell does "to!" have to do with anything. Disregard my last
post, it's obviously 3 AM and I'm talking gibberish.



I just meant that "iota" looks a lot like (spaces added for clarity)  
"i   to
a". In other words, the first time I ever saw "iota", I confused it for  
the
old C function that converts an integer to an ASCII string. It may very  
well

have been 3am for me at the time ;)


You are the second one who confuses iota with itoa. Actually, the third,  
I confused it too.


According to the book "The Design of Everyday Things" the design of that  
function name is wrong, it's not your fault and it's not because it was  
3am. When many people make mistakes with regards to the design of  
something it's *always* the design's fault, never the human's fault.


Also, C code is callable from D.  consider a seasoned d coder who sees  
code like:


auto x = itoa(5);

what is he going to thing x is?

-Steve

Re: Stupid little iota of an idea

[Ary Manzana]

On 2/11/11 12:15 AM, Nick Sabalausky wrote:

"Andrej Mitrovic"  wrote in message
news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...

What the hell does "to!" have to do with anything. Disregard my last
post, it's obviously 3 AM and I'm talking gibberish.



I just meant that "iota" looks a lot like (spaces added for clarity) "i   to
a". In other words, the first time I ever saw "iota", I confused it for the
old C function that converts an integer to an ASCII string. It may very well
have been 3am for me at the time ;)


You are the second one who confuses iota with itoa. Actually, the third, 
I confused it too.


According to the book "The Design of Everyday Things" the design of that 
function name is wrong, it's not your fault and it's not because it was 
3am. When many people make mistakes with regards to the design of 
something it's *always* the design's fault, never the human's fault.

std.regex

[jovo]

Recently I tried std.regex, and must say I’m very satisfied with new interface.
Just one small objection, I think captures range don’t need match.hit at front.

But I can live with it :)

Re: Purity

[Bruno Medeiros]

On 18/12/2010 12:46, Don wrote:

spir wrote:

On Sat, 18 Dec 2010 01:08:20 -0800
Jonathan M Davis  wrote:

Thank you for the explanation about strongly pure funcs calling weakly
pure ones --this fully makes sense.


I would like weakly pure to include output funcs, and exclude all
possibilities to modify (non-local) state.

The problem is that output is accessing global variables - which
weakly pure functions _cannot_ do.


Why? What is the rationale for excluding output (I don't mean I/O,
only O)?


You're correct in saying that it doesn't affect the operation of the
program. But in practice, program output is almost always important.

For example, suppose we allowed output to be pure. Then consider:

writeln("Hello, world!");

Since it returns nothing, and has no influence on the future execution
of the program, the writeln can be dropped from the program.

Hmmm



Hum, it might still be useful to have something like a compiler switch 
that disables pure altogether, then people could use I/O and other 
non-pure operations for debugging purposes. One could wrap such code 
with a version statement:


void myPurefunc(Foo foo) pure {
  version(pure_disabled) {
writeln("some debug info: ", foo);
  }
  //...


--
Bruno Medeiros - Software Engineer

Re: std.xml should just go

[Steven Schveighoffer]

On Fri, 11 Feb 2011 08:19:51 -0500, Bruno Medeiros  
 wrote:



On 04/02/2011 21:07, Steven Schveighoffer wrote:

On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski 
wrote:


On 02/03/2011 10:07 PM, Walter Bright wrote:


The way to get a high performance string parser in D is to take
advantage of one of D's unique features - slices. Java, C++, C#, etc.,
all rely on copying strings. With D you can just use slices into the
original XML source text. If you're copying the text, you're doing it
wrong.


Java's substring() does not copy the text, at least in the official
JDK implementation. Unfortunately, it doesn't specify this behavior as
part of the String API.


Yes, but Java's strings are immutable. Typically a buffered I/O stream
has a mutable buffer used to read data. This necessitates a copy. At the
very least, you need to continue allocating more memory to hold all the
strings.

-Steve


True, but in this case you will have the exact same problem with any  
other language as well. So it doesn't seem like D will have any  
particular advantage over Java, with regards to slicing and strings.




I think D can do it without copying out of the buffer.  You just have to  
avoid using immutable strings.


-Steve

Re: Purity

[Bruno Medeiros]

On 01/02/2011 14:15, Simen kjaeraas wrote:

Bruno Medeiros  wrote:


But for immutable data (like the contents of the elements of a
string[]),
that doesn't matter, does it?



Maybe it won't matter for the *contents of the elements* of the string
array, but the whole result value has to be /the same/ as if the
optimization was not applied. Otherwise the optimization is invalid,
even if for most uses of the result value it would not make a
difference for the program.


I admit to still not understanding this.

The data can't be changed, so the contents do not matter. The array structs
(prt/length) would not be the same as those fed to the function in any
case,
so I really cannot see how those would matter.

If others do understand, please elucidate.



Here is a synthetic example:

  string[] func(string arg) pure {
string elem2 = "blah".idup;
return [ arg, elem2 ];
  }

  string str = "blah";
  string[] result1 = func(str);
  string[] result2 = func(str);

  if(result2[0] is str) {
// then
  } else {
// else
  }


In this code sample if the optimization is applied on the second call to 
func, it would cause different code with be executed: the else clause 
instead of the then clause. Obviously this is not acceptable for an 
optimization, even if such code would be rare in practice.



--
Bruno Medeiros - Software Engineer

Re: inlining or not inlining...

[Jim]

spir Wrote:

> On 02/11/2011 09:33 AM, Jim wrote:
> >> Regardless, I would _hope_ that the compiler would be smart enough to make
> >> >  intelligent choices about inlining. That's probably one of those areas 
> >> > that can
> >> >  always be improved however.
> >
> > I also think that this decision should be left to the compiler.
> >
> > The inline keyword was deemed useful for the same reason that symbols had 
> > to be declared before their use (causing the C/C++ header hell) -- it's 
> > easier to implement such a compiler.
> 
> Agreed; but what about having the compiler tell you, on demand, "func 'f' at 
> line #l in module 'm' was not inlined" ?

I rarely need to go that low-level. My hope is that the compiler will sort this 
out in the end. Give it some time, or effort to have these optimizations 
implemented in the compiler.

Re: std.xml should just go

[Bruno Medeiros]

On 06/02/2011 21:30, Jacob Carlborg wrote:

On 2011-02-06 20:59, Walter Bright wrote:

Jacob Carlborg wrote:

On 2011-02-04 20:33, Walter Bright wrote:

so wrote:

It doesn't matter what signature you use for the function, compiler is
aware and will output an error when you do the opposite of the
signature. If this is the case, why do we need that signature?



Examine the API of a function in a library. It says it doesn't modify
anything reachable through its arguments, but is that true? How would
you know? And how would you know if the API doc doesn't say?

You'd fall back to const by convention, and that is not reliable and
does not scale.


This is quite interesting, I generally agree with this but on the
other hand Ruby on Rails is basically built on conventions, it works
out very well and I love it.


I'm not tapped into the ruby community, but I've heard some scuttlebutt
that usage of ruby is declining in large systems because ruby seems to
have problems with large systems due to "monkey patching" and other
cowboying that ruby encourages.


Maybe, I have no idea. Although I noticed myself that I wanted to have
static typing in Ruby a couple of times.



Problems with large systems? Wanting to use static typing?

Well, there is a solution to that, but it is even a more radical kind of 
a monkey patch: basically you remove 100% of the Ruby runtime and 
install and use Java and Java frameworks instead... ;)


--
Bruno Medeiros - Software Engineer

Re: More on Rust

[Jim]

spir Wrote:

> On 02/11/2011 08:39 AM, Jim wrote:
> > Jacob Carlborg Wrote:
> >
> >> On 2011-02-10 20:15, Walter Bright wrote:
> >>> Nick Sabalausky wrote:
>  "bearophile"  wrote in message
>  news:iivb5n$na3$1...@digitalmars.com...
> > auto x;
> > if (localtime().hours>= 8) {
> > x = "awake!"
> > } else {
> > x = "asleep, go away."
> > }
> > log "I'm " + x;
> >
> 
>  That would be really nice to have in D.
> >>>
> >>>
> >>> auto x = (localtime().hours>= 8) ? "awake!" : "asleep, go away.";
> >>
> >> For this simple if statement it works but as soon you have a few lines
> >> in the if statement it will become really ugly. But one could wrap the
> >> if statement in a function instead. In other languages where statements
> >> really are expressions this works:
> >>
> >> auto x = if (localtime().hours>= 8)
> >>   "awake!";
> >>else
> >>   "asleep, go away.";
> >>
> >> log "I'm " + x;
> >
> >
> >
> > Other languages may have bloated syntaxes, with no particular benefit.
> >
> >
> > auto x = localtime().hours>= 8 ?
> > "awake!"
> > :
> > "asleep, go away.";
> >
> > log( "I'm " ~ x );
> >
> >
> > If the expressions are complex I put them in functions.
> > 1) It hides and isolates details, which allows you to focus on the more 
> > abstract aspects.
> > 2) It gives the expression a name and facilitates reuse.
> 
> Agreed.
> But in practice I often end up beeing dubious about seemingly nice features 
> like, precisely, the ternary operator. In languages that do not have such a 
> nicety people end up writng eg:
>  if (localtime().hours>= 8) x = awake;
>  else x = "asleep, go away.";
> Apart from the very mild annoyance, I guess, of writing twice "x =", this is 
> all gain: code is both more compact and legible.
> Precisely, because the ternary operator is a bit weird syntactically (and not 
> that commonly needed and used in real code), people feel, just like you, the 
> need to clarify it in code, finally using more vertical space. Note that the 
> case here is the simplest possible, expressions being plain literal 
> constants. 
> I personly only consume 3 lines:
>  auto x = (localtime().hours>= 8)
>  ? "awake!"
>  : "asleep, go away.";
> What do you think?


I always make a conscious effort to write succinct expressions. My rule is to 
only use the ternary operator when it actually makes the code cleaner.

Why?

Branches should be conspicuous because they increase the number of code paths. 
Exceptions are the other big source of code paths. This is, btw, why I think 
that scope statements in D are just superb.