Re: the best language I have ever met(?)
On Friday, 25 November 2016 at 19:16:43 UTC, ketmar wrote: On Friday, 25 November 2016 at 14:27:39 UTC, Igor Shirkalin wrote: On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote: We can define static array without counting the elements as following: enum array_ = [1u,2,3,4]; uint[array_.length] static_array = array_; there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-) I think you may write it (I mean actual D) with using some template like this: yeah. but i'm not Andrei, i don't believe that the only compiler task is to resolve templated code. ;-) i.e. Andrei believes that everything (and more) should be moved out of compiler core and done with library templates. Andrei is genius, for sure, but he is living somewhere in future, where our PCs are not bound by memory, CPU, and other silly restrictions. ;-) tl;dr: using template for this sux. I just don't understand how is it worth to add to a language that instead of typing someArray.length you can just type $ but it is not ok to add to the language the same thing for static array size...
Re: the best language I have ever met(?)
On Friday, 25 November 2016 at 19:16:43 UTC, ketmar wrote: yeah. but i'm not Andrei, i don't believe that the only compiler task is to resolve templated code. ;-) i.e. Andrei believes that everything (and more) should be moved out of compiler core and done with library templates. Andrei is genius, for sure, but he is living somewhere in future, where our PCs are not bound by memory, CPU, and other silly restrictions. ;-) tl;dr: using template for this sux. Nice to meet you, Andrei! Yes, in mathematics we are more servants than gentlemen (Charles Hermite).
Re: the best language I have ever met(?)
On Monday, 5 December 2016 at 17:27:21 UTC, Igor Shirkalin wrote: On Monday, 5 December 2016 at 16:39:33 UTC, eugene wrote: On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote: I didnt count, but its about ten thousend a year, i.e. nothing. if you earned nothing using D language why do you recommend it?))) People usually earn money using programming langs. some people have nothing about science. Some of them are god's addicted. I don't think D is here. We are out of here. We should go to facebook and keep here if you take it. that's it. I think we have to stop.
Re: the best language I have ever met(?)
On Monday, 5 December 2016 at 16:39:33 UTC, eugene wrote: On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote: I didnt count, but its about ten thousend a year, i.e. nothing. if you earned nothing using D language why do you recommend it?))) People usually earn money using programming langs. some people have nothing about science. Some of them are god's addicted. I don't think D is here. We are out of here. We should go to facebook and keep here if you take it. that's it.
Re: the best language I have ever met(?)
On Monday, 5 December 2016 at 16:07:41 UTC, Igor Shirkalin wrote: I didnt count, but its about ten thousend a year, i.e. nothing. if you earned nothing using D language why do you recommend it?))) People usually earn money using programming langs.
Re: the best language I have ever met(?)
On Saturday, 3 December 2016 at 15:02:35 UTC, eugene wrote: On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote: That was preface. Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used. I have the same text in russian, but who has bothered russian(s)? The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it. p.s. I'm excused for my primitive english. how much money did you earn using D language? I didnt count, but its about ten thousend a year, i.e. nothing. You earn ten times more of me. Ask me enything more.
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote: That was preface. Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used. I have the same text in russian, but who has bothered russian(s)? The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it. p.s. I'm excused for my primitive english. how much money did you earn using D language?
Re: the best language I have ever met(?)
On Monday, 28 November 2016 at 16:15:23 UTC, Jonathan M Davis wrote: That's what pragma(inline, true) is for. And if someone wants a different solution that's completely compile-time and doesn't work with variables, then fine. I'm talking about adding something to the standard library, and for that, I think that a solution that is as close as possible to being identical to simply declaring the static array with the length is what would be appropriate. ... I'm not married to the syntax. I tried that syntax, but I couldn't figure out how to get it to work with runtime values. Can I insert my own opinion about static arrays with programmers' unknown size? Being the practical developer I can't imagine the situation where it is really needed. I hope D is not for theoretical goals only but for practical ones first. If we know the size of our future array we tell that to the compiler. If we don't know the size of our future static array we write an external generator to produce that. I really don't know places where I want static array to be unknown size inline (perhaps, except for debugging purposes). Concluding, the designer knows he's achived the perfection if there is nothing to remove, but not to add. Igor Shirkalin
Re: the best language I have ever met(?)
On Saturday, November 26, 2016 00:43:04 Artur Skawina via Digitalmars-d-
learn wrote:
> IOW you want to improve IFTI, so that `n` is inferred from the
> length of the passed argument. That would indeed work for array
> literals and CTFE-able expressions. Any improvement to IFTI is a
> good thing, but the RT cost of this helper could be high if it ever
> doesn't get inlined and completely optimized away.
That's what pragma(inline, true) is for. And if someone wants a different
solution that's completely compile-time and doesn't work with variables,
then fine. I'm talking about adding something to the standard library, and
for that, I think that a solution that is as close as possible to being
identical to simply declaring the static array with the length is what would
be appropriate.
> If the cost isn't an issue and a different syntax is acceptable
> then this should already work:
>
>template staticArray(T, E...) {
> T[E.length] staticArray() @property { return [E]; }
>}
>template staticArray(E...) {
> typeof([E][0])[E.length] staticArray() @property { return [E]; }
>}
>
>ubyte a;
>auto sa = staticArray!(ubyte, 1, 2, 3, 4, a);
>auto sb = staticArray!(1, 2, 3, 4, a);
I'm not married to the syntax. I tried that syntax, but I couldn't figure
out how to get it to work with runtime values. The closest that I could come
up with was what I showed before, and the fact that IFTI wasn't smart enough
with VRP was the only blocker. It looks like you've found a way to do it
with all template arguments though, which is fine with me.
- Jonathan M Davis
Re: the best language I have ever met(?)
On 11/25/16 18:33, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Friday, November 25, 2016 18:20:11 Artur Skawina via Digitalmars-d-learn
> wrote:
>> On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote:
>>> On Friday, November 25, 2016 17:03:32 Artur Skawina via
enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
auto arr = staticArray!(ubyte, [1, 2, 3, 4]);
>>>
>>> That won't work with variables. e.g.
>>>
>>> ubyte a;
>>> auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);
>>>
>>> would fail to compile. It only works when all of the values are known at
>>> compile time, whereas
>>>
>>> ubyte a;
>>> ubyte[5] arr = [1, 2, 3, 4, a];
>>>
>>> would compile just fine.
>>
>> Now you're trying to change the scope. Of course this is a hack,
>> that's only useful in certain contexts, such as initializing static
>> arrays with known values, which this subthread is about.
>
> How is it changing the scope? What has been asked for on several occasions -
> and what int[$] was supposed to fix - was the ability to intialize a static
> array while inferring its size.
It's a known language limitation, which can be worked around using
hacks such as the one I showed, that help in the very common cases
that appeared in this thread, add zero RT costs and work with VRP.
I didn't realize you were suggesting to use the function helper
route for the general case - no scope change, sorry.
> ubyte a;
> ubyte[5] arr = [1, 2, 3, 4, a];
>
> is a perfectly legitimate example of initializing a static array, and
> there's no reason why it shouldn't be a goal to have it work with a function
> that infers the size of the static array.
The problem with such a function is that, just like every other function,
it's type can not depend on RT data, and that `typeof([1,a])` is `int[]`.
The information is lost at the function boundary. So the possible
improvements are a) changing the array literal semantics, and b)
improving IFTI.
> We'd actually have it right now with
>
> T[n] staticArray(T, size_t n)(auto ref T[n] arr)
> {
> return arr;
> }
>
> except that VRP only works right now if no inferrence is done when
> instantiating the template.
>
> auto sa = staticArray!(ubyte, 4)([1, 2, 3, 4]);
>
> compiles just fine, but that obviously defeats the purpose of the template.
> If the compiler is improved so that
>
> auto sa = staticArray!ubyte([1, 2, 3, 4]);
>
> also works with VRP, then everything works just like it would with
>
> ubyte a;
> ubyte[5] arr = [1, 2, 3, 4, a];
>
> except that with the function, the size would be inferred.
>
> ubyte a;
> auto arr = staticArray!ubyte([1, 2, 3, 4, a]);
IOW you want to improve IFTI, so that `n` is inferred from the
length of the passed argument. That would indeed work for array
literals and CTFE-able expressions. Any improvement to IFTI is a
good thing, but the RT cost of this helper could be high if it ever
doesn't get inlined and completely optimized away.
If the cost isn't an issue and a different syntax is acceptable
then this should already work:
template staticArray(T, E...) {
T[E.length] staticArray() @property { return [E]; }
}
template staticArray(E...) {
typeof([E][0])[E.length] staticArray() @property { return [E]; }
}
ubyte a;
auto sa = staticArray!(ubyte, 1, 2, 3, 4, a);
auto sb = staticArray!(1, 2, 3, 4, a);
artur
Re: the best language I have ever met(?)
On Friday, 25 November 2016 at 14:27:39 UTC, Igor Shirkalin wrote: On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote: We can define static array without counting the elements as following: enum array_ = [1u,2,3,4]; uint[array_.length] static_array = array_; there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-) I think you may write it (I mean actual D) with using some template like this: yeah. but i'm not Andrei, i don't believe that the only compiler task is to resolve templated code. ;-) i.e. Andrei believes that everything (and more) should be moved out of compiler core and done with library templates. Andrei is genius, for sure, but he is living somewhere in future, where our PCs are not bound by memory, CPU, and other silly restrictions. ;-) tl;dr: using template for this sux.
Re: the best language I have ever met(?)
On Friday, November 25, 2016 18:20:11 Artur Skawina via Digitalmars-d-learn
wrote:
> On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Friday, November 25, 2016 17:03:32 Artur Skawina via
> >>enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS;
> >>auto arr = staticArray!(ubyte, [1, 2, 3, 4]);
> >
> > That won't work with variables. e.g.
> >
> > ubyte a;
> > auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]);
> >
> > would fail to compile. It only works when all of the values are known at
> > compile time, whereas
> >
> > ubyte a;
> > ubyte[5] arr = [1, 2, 3, 4, a];
> >
> > would compile just fine.
>
> Now you're trying to change the scope. Of course this is a hack,
> that's only useful in certain contexts, such as initializing static
> arrays with known values, which this subthread is about.
How is it changing the scope? What has been asked for on several occasions -
and what int[$] was supposed to fix - was the ability to intialize a static
array while inferring its size.
ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];
is a perfectly legitimate example of initializing a static array, and
there's no reason why it shouldn't be a goal to have it work with a function
that infers the size of the static array.
> It actually makes the source code (look) worse; having to use lots of
> such module- or project-local hacks doesn't scale, and is a symptom
> of language problems.
>
> The point, however, was that that is the only way to get VRP - the
> values must be available at CT for VRP to work effectively.
> Your suggestion to "fix" VRP would break CTFE (different implicit
> conversions would be allowed at CT and RT) and could result in
> code compiling or not depending on the function arguments used,
> possibly in a very unintuitive way (eg depending on if the function
> args values happened to be CTFE-able).
We'd actually have it right now with
T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
return arr;
}
except that VRP only works right now if no inferrence is done when
instantiating the template.
auto sa = staticArray!(ubyte, 4)([1, 2, 3, 4]);
compiles just fine, but that obviously defeats the purpose of the template.
If the compiler is improved so that
auto sa = staticArray!ubyte([1, 2, 3, 4]);
also works with VRP, then everything works just like it would with
ubyte a;
ubyte[5] arr = [1, 2, 3, 4, a];
except that with the function, the size would be inferred.
ubyte a;
auto arr = staticArray!ubyte([1, 2, 3, 4, a]);
And until
https://issues.dlang.org/show_bug.cgi?id=16779
is fixed, the above definition of staticArray works perfectly fine except
for the fact that you lose out on VRP. And once 16779 is fixed, we have a
complete solution, whereas any solution that would currently work with VRP
permanently loses out on being able to have any variables used in
initializing the array.
- Jonathan M Davis
Re: the best language I have ever met(?)
On 11/25/16 17:30, Jonathan M Davis via Digitalmars-d-learn wrote: > On Friday, November 25, 2016 17:03:32 Artur Skawina via Digitalmars-d-learn > wrote: >> On 11/25/16 15:51, Jonathan M Davis via Digitalmars-d-learn wrote: >>> On Friday, November 25, 2016 14:27:39 Igor Shirkalin via >>> Digitalmars-d-learn> >>> wrote: I think you may write it (I mean actual D) with using some template like this: auto array = static_array!uint(1, 2, 3, 4) Could you please help to writeown this template in the best and clear manner? >>> >>> That's easy. The problem is if you want it to have the same semantics as >>> >>> uint[4] arr = [1, 2, 3, 4]; >>> >>> In particular, VRP (Value Range Propagation) is a problem. This compiles >>> >>> ubyte[4] arr = [1, 2, 3, 4]; >>> >>> because each of the arguments is known to fit in a ubyte. However, >>> making >>> >>> auto arr = staticArray!ubyte(1, 2, 3, 4); >>> >>> do the same without forcing a cast is difficult. [...] >> >>enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS; >>auto arr = staticArray!(ubyte, [1, 2, 3, 4]); > > That won't work with variables. e.g. > > ubyte a; > auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]); > > would fail to compile. It only works when all of the values are known at > compile time, whereas > > ubyte a; > ubyte[5] arr = [1, 2, 3, 4, a]; > > would compile just fine. Now you're trying to change the scope. Of course this is a hack, that's only useful in certain contexts, such as initializing static arrays with known values, which this subthread is about. It actually makes the source code (look) worse; having to use lots of such module- or project-local hacks doesn't scale, and is a symptom of language problems. The point, however, was that that is the only way to get VRP - the values must be available at CT for VRP to work effectively. Your suggestion to "fix" VRP would break CTFE (different implicit conversions would be allowed at CT and RT) and could result in code compiling or not depending on the function arguments used, possibly in a very unintuitive way (eg depending on if the function args values happened to be CTFE-able). artur
Re: the best language I have ever met(?)
On Friday, November 25, 2016 08:26:11 Jonathan M Davis via Digitalmars-d- learn wrote: > and opening an enhancement request to make the compiler smart enough that > > auto arr = staticArray!ubyte([1, 2, 3, 4]); > > would work. Opened: https://issues.dlang.org/show_bug.cgi?id=16779 And regardless of this particular use case, it's something that arguably should work. - Jonathan M Davis
Re: the best language I have ever met(?)
On Friday, November 25, 2016 17:03:32 Artur Skawina via Digitalmars-d-learn wrote: > On 11/25/16 15:51, Jonathan M Davis via Digitalmars-d-learn wrote: > > On Friday, November 25, 2016 14:27:39 Igor Shirkalin via > > Digitalmars-d-learn> > > wrote: > >> I think you may write it (I mean actual D) with using some > >> template like this: > >> > >> auto array = static_array!uint(1, 2, 3, 4) > >> > >> Could you please help to write down this template in the best and > >> clear manner? > > > > That's easy. The problem is if you want it to have the same semantics as > > > > uint[4] arr = [1, 2, 3, 4]; > > > > In particular, VRP (Value Range Propagation) is a problem. This compiles > > > > ubyte[4] arr = [1, 2, 3, 4]; > > > > because each of the arguments is known to fit in a ubyte. However, > > making > > > > auto arr = staticArray!ubyte(1, 2, 3, 4); > > > > do the same without forcing a cast is difficult. [...] > >enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS; >auto arr = staticArray!(ubyte, [1, 2, 3, 4]); That won't work with variables. e.g. ubyte a; auto arr = staticArray!(ubyte, [1, 2, 3, 4, a]); would fail to compile. It only works when all of the values are known at compile time, whereas ubyte a; ubyte[5] arr = [1, 2, 3, 4, a]; would compile just fine. - Jonathan M Davis
Re: the best language I have ever met(?)
On Friday, November 25, 2016 15:59:48 Igor Shirkalin via Digitalmars-d-learn
wrote:
> On Friday, 25 November 2016 at 14:51:52 UTC, Jonathan M Davis
> > auto arr = staticArray!ubyte([1, 2, 3, 4]);
> >
> > doesn't compile either. The most straightforward
> > implementations are something like
>
> Why? Is it since [1, 2, 3, 4] is int[4] by default?
It's because [1, 2, 3, 4] is inferred to be int[], and _then_ the compiler
tries to instantiate the templated function, whereas with
ubyte[4] = [1, 2, 3, 4];
the compiler looks at is one thing and determines that the array literal can
be ubyte[], and it works. And if staticArray is a variadic template instead
of taking an array literal, e.g.
auto arr = staticArray!ubyte(1, 2, 3, 4);
then the values all get inferred to be int, and when it tries to assign the
arguments to the ubyte[4], it doesn't compile, because they're int and not
ubyte, which then means that you're forced to either cast the elements to
ubyte at the call site
auto arr = staticArray!ubyte(cast(ubyte)1,
cast(ubyte)2,
cast(ubyte)3,
cast(ubyte)4);
or staticArray itself has to do the cast, but if staticArray itself does the
cast, then something like
auto arr = staticArray!ubyte(1, 2, 900);
would compile without error, and you'd end up with whatever cast(ubyte)900
is. I'd _like_ to be able to find a way to make it so that the semantics of
the staticArray function are identical to
ubyte[4] = [1, 2, 3, 4];
except that the length is inferred, and I'm coming to the conclusion that
it's not possible. That being the case, I'm leaning towards going with
T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
return arr;
}
and opening an enhancement request to make the compiler smart enough that
auto arr = staticArray!ubyte([1, 2, 3, 4]);
would work. I don't see
auto arr = staticArray!ubyte(1, 2, 3, 4);
ever working unless the symbols being passed in could be examined at compile
time, and I don't think that they can be - just their types.
- Jonathan M Davis
Re: the best language I have ever met(?)
On 11/25/16 15:51, Jonathan M Davis via Digitalmars-d-learn wrote: > On Friday, November 25, 2016 14:27:39 Igor Shirkalin via Digitalmars-d-learn > wrote: >> I think you may write it (I mean actual D) with using some >> template like this: >> >> auto array = static_array!uint(1, 2, 3, 4) >> >> Could you please help to write down this template in the best and >> clear manner? > > That's easy. The problem is if you want it to have the same semantics as > > uint[4] arr = [1, 2, 3, 4]; > > In particular, VRP (Value Range Propagation) is a problem. This compiles > > ubyte[4] arr = [1, 2, 3, 4]; > > because each of the arguments is known to fit in a ubyte. However, making > > auto arr = staticArray!ubyte(1, 2, 3, 4); > > do the same without forcing a cast is difficult. [...] enum T[N] staticArray(T, alias ELS, size_t N=ELS.length) = ELS; auto arr = staticArray!(ubyte, [1, 2, 3, 4]); artur
Re: the best language I have ever met(?)
On Friday, 25 November 2016 at 07:17:18 UTC, MGW wrote: On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin wrote: Igor, is the good Russian-speaking forum https://vk.com/vk_dlang. There are articles on GUI and other aspects of dlang. Thank you, I'll tale a look at it for sure.
Re: the best language I have ever met(?)
On Friday, 25 November 2016 at 14:51:52 UTC, Jonathan M Davis
wrote:
I think you may write it (I mean actual D) with using some
template like this:
auto array = static_array!uint(1, 2, 3, 4)
Could you please help to write down this template in the best
and clear manner?
That's easy. The problem is if you want it to have the same
semantics as
uint[4] arr = [1, 2, 3, 4];
In particular, VRP (Value Range Propagation) is a problem. This
compiles
ubyte[4] arr = [1, 2, 3, 4];
because each of the arguments is known to fit in a ubyte.
However, making
auto arr = staticArray!ubyte(1, 2, 3, 4);
do the same without forcing a cast is difficult. And if you
force the cast, then it's not equivalent anymore, because
something like
ubyte[4] arr = [1, 2, 3, 900];
would not compile. And surprisingly, having the function take a
dynamic array doesn't fix that problem (though maybe that's
something that we could talk the dmd devs into improving). e.g.
To mine mind it is not a problem because when you write you think
what you write (or you are right). Morover compiler will always
tell you are wrong if you make 256 to be ubyte implicity.
auto arr = staticArray!ubyte([1, 2, 3, 4]);
doesn't compile either. The most straightforward
implementations are something like
Why? Is it since [1, 2, 3, 4] is int[4] by default?
T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
return arr;
}
or
auto staticArray(Args...)(Args args)
{
CommonType!Args[Args.length] arr = [args];
return arr;
}
Great! Thank you. I should take more precise look at std.traits
but I don't know if the VRP problem is solvable or not without
some compiler improvements. If there's a clever enough
implementation to get VRP with a function like this with the
current language, I haven't figured it out yet.
- Jonathan M Davis
As I noticed, to my mind it is not a hindrance to write
deliberate things.
- Igor Shirkalin
Re: the best language I have ever met(?)
On Friday, November 25, 2016 14:27:39 Igor Shirkalin via Digitalmars-d-learn
wrote:
> On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote:
> >> We can define static array without counting the elements as
> >> following:
> >>
> >>
> >> enum array_ = [1u,2,3,4];
> >> uint[array_.length] static_array = array_;
> >
> > there are workarounds, of course. yet i'll take mine `uint[$] a
> > = [1u,2,3,4];` over that quoted mess at any time, without
> > second thought. ;-)
>
> I think you may write it (I mean actual D) with using some
> template like this:
>
> auto array = static_array!uint(1, 2, 3, 4)
>
> Could you please help to write down this template in the best and
> clear manner?
That's easy. The problem is if you want it to have the same semantics as
uint[4] arr = [1, 2, 3, 4];
In particular, VRP (Value Range Propagation) is a problem. This compiles
ubyte[4] arr = [1, 2, 3, 4];
because each of the arguments is known to fit in a ubyte. However, making
auto arr = staticArray!ubyte(1, 2, 3, 4);
do the same without forcing a cast is difficult. And if you force the cast,
then it's not equivalent anymore, because something like
ubyte[4] arr = [1, 2, 3, 900];
would not compile. And surprisingly, having the function take a dynamic
array doesn't fix that problem (though maybe that's something that we could
talk the dmd devs into improving). e.g.
auto arr = staticArray!ubyte([1, 2, 3, 4]);
doesn't compile either. The most straightforward implementations are
something like
T[n] staticArray(T, size_t n)(auto ref T[n] arr)
{
return arr;
}
or
auto staticArray(Args...)(Args args)
{
CommonType!Args[Args.length] arr = [args];
return arr;
}
but I don't know if the VRP problem is solvable or not without some compiler
improvements. If there's a clever enough implementation to get VRP with a
function like this with the current language, I haven't figured it out yet.
- Jonathan M Davis
Re: the best language I have ever met(?)
On Wednesday, 23 November 2016 at 18:58:55 UTC, ketmar wrote: We can define static array without counting the elements as following: enum array_ = [1u,2,3,4]; uint[array_.length] static_array = array_; there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-) I think you may write it (I mean actual D) with using some template like this: auto array = static_array!uint(1, 2, 3, 4) Could you please help to write down this template in the best and clear manner?
Re: the best language I have ever met(?)
On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin wrote: Igor, is the good Russian-speaking forum https://vk.com/vk_dlang. There are articles on GUI and other aspects of dlang.
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 17:54:52 UTC, Igor Shirkalin wrote: The simpler - the better. After reading "D p.l." by A.Alexandrescu two years ago I have found my past dream. It's theory to start with. That book should be read at least two times especially if you have asm/c/c++/python3/math/physics background, and dealt with Watcom/Symantec C/C++ compilers (best to Walter Bright) with very high optimization goal. No stupid questions, just doing things. That was preface. Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used. I have the same text in russian, but who has bothered russian(s)? The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it. [...] My English is Bad than yours. I am mot russian(s)、、、I am Chinese.
Re: the best language I have ever met(?)
On Wednesday, 23 November 2016 at 19:15:52 UTC, Jonathan M Davis wrote: It's nice, but it's non-standard. So, it seems to me that using it is just going to lead to problems like you ran into in this thread where you posted an example that wasn't valid D, and it'll make you that much more annoyed when you have to write code that _is_ standard D and can't use your enhancements. So, I really think that it would be better if you just used standard D, but obviously, that's up to you. for me, it is easier to "vanilize" the code later (if i need to, at all). yeah, sometimes non-vanilla code sneaks to where it doesn't belong, but it is rare, and doesn't invalidate the things that makes my life easier while i developing my projects. ;-) as i am unemployed now, i don't care if somebody is able to compile my code anymore.
Re: the best language I have ever met(?)
On Wednesday, November 23, 2016 18:58:55 ketmar via Digitalmars-d-learn wrote: > On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin > > wrote: > > On Tuesday, 22 November 2016 at 00:08:05 UTC, ketmar wrote: > >> On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote: > >>> Though I would argue that it's better to use '_' instead of > >>> '$' to denote deduced fixed size, it seems more obvious to me: > >>> > >>> int[_] array = [ 1, 2, 3 ]; > >> > >> alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is > >> perfectly valid. dollar is simply most logical non-identifier > >> character. > > > > We can define static array without counting the elements as > > following: > > > > > > enum array_ = [1u,2,3,4]; > > uint[array_.length] static_array = array_; > > there are workarounds, of course. yet i'll take mine `uint[$] a = > [1u,2,3,4];` over that quoted mess at any time, without second > thought. ;-) It's nice, but it's non-standard. So, it seems to me that using it is just going to lead to problems like you ran into in this thread where you posted an example that wasn't valid D, and it'll make you that much more annoyed when you have to write code that _is_ standard D and can't use your enhancements. So, I really think that it would be better if you just used standard D, but obviously, that's up to you. We really should add a helper for this to std.typecons though. Maybe I'll try and do something for it this holidy weekend... - Jonathan M Davis
Re: the best language I have ever met(?)
On Wednesday, 23 November 2016 at 18:54:35 UTC, Igor Shirkalin wrote: On Tuesday, 22 November 2016 at 00:08:05 UTC, ketmar wrote: On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote: Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ]; alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character. We can define static array without counting the elements as following: enum array_ = [1u,2,3,4]; uint[array_.length] static_array = array_; there are workarounds, of course. yet i'll take mine `uint[$] a = [1u,2,3,4];` over that quoted mess at any time, without second thought. ;-)
Re: the best language I have ever met(?)
On Tuesday, 22 November 2016 at 00:08:05 UTC, ketmar wrote: On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote: Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ]; alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character. We can define static array without counting the elements as following: enum array_ = [1u,2,3,4]; uint[array_.length] static_array = array_;
Re: the best language I have ever met(?)
Dne 21.11.2016 v 13:44 Jonathan M Davis via Digitalmars-d-learn napsal(a): ... it's easy enough to just create a template to do the same thing, it's not worth adding to the language. That's a problem. I belive there is a lot of things which are easy to add by some kind of magic (template or mixins or some combination). But until this is add to standard library and doc, there is no way for other people to know about it. Even when there is a way (in standard library) it is not helpful. Many people (like me) will start learning language from specs. So if there see something like: int[$] x = [1, 2, 3]; // make static array, this make sense but x = [1, 2, 3]; // make dynamic array ,does not make sense
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature. exactly. it is the old patch from Kenji. the patch even survived C++ -> D transition, 'cause i love it so much. ;-)
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote: Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ]; alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character.
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis That's definitely what Walter would say. But I think it shouldn't be the only argument to not add a feature to the language itself: if some pattern is useful/frequent, and users implement it themselves every time, it should be either implemented in the compiler or in the standard library. Besides that, it just seems inconsistent that D lacks this particular feature: fixed-sized arrays are there, type deduction is there, so where's type deduction for fixed-sized arrays? Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ];
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:42:34 UTC, ZombineDev wrote: That was a proposal for D that was rejected in the last moment by Andrei. My guess is that ketmar's modified dmd has that feature implemented. exactly. it is handy feature, so i used to it. and it slept into code (i usually test my code with rdmd before posting, but this time i forgot to specify --vanilla flag ;-).
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: On Monday, November 21, 2016 12:08:30 Patric Dexheimer via Digitalmars-d- learn wrote: No. D doesn't have that, though it's easy enough to do the same thing with a helper template. However, Ketmar seems to like to use his own fork of dmd where he made changes to the language based on his preferences. IIRC, it was proposed at one point that $ be used in this manner to create a static array while inferring its size (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature. But for better or worse, it's not standard D, and if the PR was rejected like I think it was, then it likely never will become standard D. Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis https://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
Re: the best language I have ever met(?)
On Monday, November 21, 2016 12:08:30 Patric Dexheimer via Digitalmars-d- learn wrote: > On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: > > On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch > > > > wrote: > >> Please don't post non-d. > > > > it slipped accidentally, sorry. ;-) > > > > for OP: `uint[2] a = [42, 69];` is the correct syntax. > > "uint[$] a = [42, 69];" > > haha for a moment I thought that this was the way of D to create > a fixed-size array without explicit setting the size (like what u > can do in c++ :)) No. D doesn't have that, though it's easy enough to do the same thing with a helper template. However, Ketmar seems to like to use his own fork of dmd where he made changes to the language based on his preferences. IIRC, it was proposed at one point that $ be used in this manner to create a static array while inferring its size (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature. But for better or worse, it's not standard D, and if the PR was rejected like I think it was, then it likely never will become standard D. Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:08:30 UTC, Patric Dexheimer wrote: On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote: Please don't post non-d. it slipped accidentally, sorry. ;-) for OP: `uint[2] a = [42, 69];` is the correct syntax. "uint[$] a = [42, 69];" haha for a moment I thought that this was the way of D to create a fixed-size array without explicit setting the size (like what u can do in c++ :)) That was a proposal for D that was rejected in the last moment by Andrei. My guess is that ketmar's modified dmd has that feature implemented.
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote: Please don't post non-d. it slipped accidentally, sorry. ;-) for OP: `uint[2] a = [42, 69];` is the correct syntax. "uint[$] a = [42, 69];" haha for a moment I thought that this was the way of D to create a fixed-size array without explicit setting the size (like what u can do in c++ :))
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 20:54:32 UTC, ketmar wrote:
On Saturday, 19 November 2016 at 17:12:13 UTC, Igor Shirkalin
wrote:
string s = "%(%s, %)".format(a);
writefln(s);
}
Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
no. it's a leftover from the code without format. it originally
was `writefln("%(%s, %)", a);`, but i wanted to show `format`
function too, and forgot to remove `f`. actually, it is a BUG
to call `writefln` here, 'cause who knows, `s` may contain '%',
and then boom! all hell broke loose. ;-)
Got it! Thanks.
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 17:12:13 UTC, Igor Shirkalin
wrote:
string s = "%(%s, %)".format(a);
writefln(s);
}
Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
no. it's a leftover from the code without format. it originally
was `writefln("%(%s, %)", a);`, but i wanted to show `format`
function too, and forgot to remove `f`. actually, it is a BUG to
call `writefln` here, 'cause who knows, `s` may contain '%', and
then boom! all hell broke loose. ;-)
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote:
import std.stdio;
import std.format;
void main () {
uint[$] a = [42, 69];
string s = "%(%s, %)".format(a);
writefln(s);
}
Please don't post non-d.
People might use it an then complain that it does not work.
Let these people to complain. ;)
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 21:28:44 UTC, ketmar wrote:
On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin
wrote:
After 2 hours of brain breaking (as D newbie) I have come to:
uint_array.map!(v=>"%x".format(v)).join(", ")
Why 2 hours? Because I have started with 'joiner' function and
aftewords found out the 'join'.
To my mind there is more simple form for this task in D (about
formatting).
sure ;-)
import std.stdio;
import std.format;
void main () {
uint[$] a = [42, 69];
string s = "%(%s, %)".format(a);
writefln(s);
}
Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote: Please don't post non-d. it slipped accidentally, sorry. ;-) for OP: `uint[2] a = [42, 69];` is the correct syntax.
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 21:28:44 UTC, ketmar wrote:
On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin
wrote:
After 2 hours of brain breaking (as D newbie) I have come to:
uint_array.map!(v=>"%x".format(v)).join(", ")
Why 2 hours? Because I have started with 'joiner' function and
aftewords found out the 'join'.
To my mind there is more simple form for this task in D (about
formatting).
sure ;-)
import std.stdio;
import std.format;
void main () {
uint[$] a = [42, 69];
string s = "%(%s, %)".format(a);
writefln(s);
}
Please don't post non-d.
People might use it an then complain that it does not work.
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin wrote:
After 2 hours of brain breaking (as D newbie) I have come to:
uint_array.map!(v=>"%x".format(v)).join(", ")
Why 2 hours? Because I have started with 'joiner' function and
aftewords found out the 'join'.
To my mind there is more simple form for this task in D (about
formatting).
sure ;-)
import std.stdio;
import std.format;
void main () {
uint[$] a = [42, 69];
string s = "%(%s, %)".format(a);
writefln(s);
}
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 19:47:17 UTC, H. S. Teoh wrote: On Fri, Nov 18, 2016 at 11:43:49AM -0800, H. S. Teoh via Digitalmars-d-learn wrote: [...] Yes, I meant 'sentiments' as in опыта, not as in сентметальность. :-) [...] Sorry, typo. I meant сентиментальности. But I think you understand what I mean. :-) T I Think there's a bug. When I'm answerring a message, and if my recipient send me the message, and after I press 'send' button, my message is duplicated. Simple bug to repare.
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 19:47:17 UTC, H. S. Teoh wrote: Yes, I meant 'sentiments' as in опыта, not as in сентметальность. :-) [...] Sorry, typo. I meant сентиментальности. But I think you understand what I mean. :-) Oh, I think you understand what you think what I mean :)
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 19:43:49 UTC, H. S. Teoh wrote:
I was a little bit afraid of my missunderstanding in terms of
sentiments. You've got me right (I don't quite feel the
meaning of that in these non-cyrillic letters:). But what I
understand is the path you have walked and what I have in my
mind.
Yes, I meant 'sentiments' as in опыта, not as in
сентметальность. :-)
I used to mean 'sentiments' as "сентиметальность", but "опыт -
сын ошибок трудных" (Пушкин) is what realy in behind :)
Simple example about D: I spent two hours to write a line
(borrowed from Python), related with lazy calculations, but
finally I got it with deep great thinking, and it was like
understanding of Moon alienation from Earth.
Great! Would you like to share the code snippet?
Sure. Let we have a uint_array of values. And we need to get a
string of these values in hex separated with ','. In Python it
looks like
', '.join(map(hex, uint_array))
After 2 hours of brain breaking (as D newbie) I have come to:
uint_array.map!(v=>"%x".format(v)).join(", ")
Why 2 hours? Because I have started with 'joiner' function and
aftewords found out the 'join'.
To my mind there is more simple form for this task in D (about
formatting).
What is your using of D?
Sadly, I have not been able to use D in a professional
capacity. My coworkers are very much invested into C/C++ and
have a very high level of skepticism to anything else, in
addition to resistance to adding new toolchains (much less
languages) to the current projects. So my use of D has mainly
been in personal projects. I do contribute to Phobos (the
Same here.
But my coworkers are not addicted to programming at all :)
standard library) every now and then, though. It's my way of
"contributing to the cause" in the hopes that one day D may be
more widespread and accepted by the general programming
community.
I don't hope about "D some day", I'm sure about that (5 to 30
years).
The idea is "I D", not "I C++" :)
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 19:43:49 UTC, H. S. Teoh wrote:
I was a little bit afraid of my missunderstanding in terms of
sentiments. You've got me right (I don't quite feel the
meaning of that in these non-cyrillic letters:). But what I
understand is the path you have walked and what I have in my
mind.
Yes, I meant 'sentiments' as in опыта, not as in
сентметальность. :-)
I used to mean 'sentiments' as "сентиметальность", but "опыт -
сын ошибок трудных" (Пушкин) is what realy in behind :)
Simple example about D: I spent two hours to write a line
(borrowed from Python), related with lazy calculations, but
finally I got it with deep great thinking, and it was like
understanding of Moon alienation from Earth.
Great! Would you like to share the code snippet?
Sure. We have an array of uint. And we need to get a string of
these values in hex separated with ','. In Python it looks like
', '.join(map(hex, array))
array.map!(v=>"%x".format(v)).join(", ")
[...]
What is your using of D?
For me it is tool to develope other tools.
[...]
Sadly, I have not been able to use D in a professional
capacity. My coworkers are very much invested into C/C++ and
have a very high level of skepticism to anything else, in
addition to resistance to adding new toolchains (much less
languages) to the current projects. So my use of D has mainly
been in personal projects. I do contribute to Phobos (the
standard library) every now and then, though. It's my way of
"contributing to the cause" in the hopes that one day D may be
more widespread and accepted by the general programming
community.
T
Re: the best language I have ever met(?)
On Fri, Nov 18, 2016 at 11:43:49AM -0800, H. S. Teoh via Digitalmars-d-learn wrote: [...] > Yes, I meant 'sentiments' as in опыта, not as in сентметальность. :-) [...] Sorry, typo. I meant сентиментальности. But I think you understand what I mean. :-) T -- The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Re: the best language I have ever met(?)
On Fri, Nov 18, 2016 at 07:26:56PM +, Igor Shirkalin via Digitalmars-d-learn wrote: > On Friday, 18 November 2016 at 18:14:41 UTC, H. S. Teoh wrote: > > Welcome, Igor! > Hello, Teoh! > > > > Your sentiments reflect mine years ago when I first discovered D. I > > came from a C/C++/Perl background. It was also Andrei's book that > > got me started; in those early days documentation was scant and I > > didn't know how to write idiomatic D code. But after I found TDPL, > > the rest was history. :-) > I was a little bit afraid of my missunderstanding in terms of > sentiments. You've got me right (I don't quite feel the meaning of > that in these non-cyrillic letters:). But what I understand is the > path you have walked and what I have in my mind. Yes, I meant 'sentiments' as in опыта, not as in сентметальность. :-) > Simple example about D: I spent two hours to write a line (borrowed > from Python), related with lazy calculations, but finally I got it > with deep great thinking, and it was like understanding of Moon > alienation from Earth. Great! Would you like to share the code snippet? [...] > What is your using of D? > For me it is tool to develope other tools. [...] Sadly, I have not been able to use D in a professional capacity. My coworkers are very much invested into C/C++ and have a very high level of skepticism to anything else, in addition to resistance to adding new toolchains (much less languages) to the current projects. So my use of D has mainly been in personal projects. I do contribute to Phobos (the standard library) every now and then, though. It's my way of "contributing to the cause" in the hopes that one day D may be more widespread and accepted by the general programming community. T -- By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 18:14:41 UTC, H. S. Teoh wrote: Welcome, Igor! Hello, Teoh! Your sentiments reflect mine years ago when I first discovered D. I came from a C/C++/Perl background. It was also Andrei's book that got me started; in those early days documentation was scant and I didn't know how to write idiomatic D code. But after I found TDPL, the rest was history. :-) I was a little bit afraid of my missunderstanding in terms of sentiments. You've got me right (I don't quite feel the meaning of that in these non-cyrillic letters:). But what I understand is the path you have walked and what I have in my mind. Simple example about D: I spent two hours to write a line (borrowed from Python), related with lazy calculations, but finally I got it with deep great thinking, and it was like understanding of Moon alienation from Earth. We have a few Russians on this forum, and I can understand some Russian too. Though on this mailing list English is the language to use. Sure, I don't have any doubt of it. I hope to be one of russian understandables here:) Your English is understandable. That's good enough, I think. :-) Thank you, Teoh. That is very important for me to hear. What is your using of D? For me it is tool to develope other tools. Igor
Re: the best language I have ever met(?)
On Fri, Nov 18, 2016 at 05:54:52PM +, Igor Shirkalin via Digitalmars-d-learn wrote: > The simpler - the better. > After reading "D p.l." by A.Alexandrescu two years ago I have found my > past dream. It's theory to start with. That book should be read at > least two times especially if you have asm/c/c++/python3/math/physics > background, and dealt with Watcom/Symantec C/C++ compilers (best to > Walter Bright) with very high optimization goal. No stupid questions, > just doing things. > That was preface. > Now I have server written in D for C++ pretty ancient client. Most > things are three times shorter in size and clear (@clear? suffix). All > programming paradigms were used. Welcome, Igor! Your sentiments reflect mine years ago when I first discovered D. I came from a C/C++/Perl background. It was also Andrei's book that got me started; in those early days documentation was scant and I didn't know how to write idiomatic D code. But after I found TDPL, the rest was history. :-) > I have the same text in russian, but who has bothered russian(s)? We have a few Russians on this forum, and I can understand some Russian too. Though on this mailing list English is the language to use. > The meaning of all of that is: powerfull attractive language with > sufficient infrastructure with future. Just use it. Yes, I agree! > p.s. I'm excused for my primitive english. [...] Your English is understandable. That's good enough, I think. :-) T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
the best language I have ever met(?)
The simpler - the better. After reading "D p.l." by A.Alexandrescu two years ago I have found my past dream. It's theory to start with. That book should be read at least two times especially if you have asm/c/c++/python3/math/physics background, and dealt with Watcom/Symantec C/C++ compilers (best to Walter Bright) with very high optimization goal. No stupid questions, just doing things. That was preface. Now I have server written in D for C++ pretty ancient client. Most things are three times shorter in size and clear (@clear? suffix). All programming paradigms were used. I have the same text in russian, but who has bothered russian(s)? The meaning of all of that is: powerfull attractive language with sufficient infrastructure with future. Just use it. p.s. I'm excused for my primitive english.
