Re: A better way to deal with overloading?
On Saturday, 28 January 2017 at 01:55:10 UTC, Profile Anaysis
wrote:
On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter
wrote:
On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis
wrote:
[...]
It's funny (or sad) that C has compound types since C99 and
that they are good.
Your foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
of course, the lack of object orientation and other things
makes it easier in C.
Yeah, this seems similar to what I am saying. The only
difference is that the cast is not required because the types
can be deduced for functions. I don't see anything in the
spec(https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Compound-Literals.html) showing function calls using "compound literals though", which was my suggestion.
The typecast in the compound statement is required because the
initializer expression is ambiguous because of int promotion rules
struct aa { short a; char c; } and struct bb { int a; int b} have
exactly the same initializer but are completely different types.
{ 5, 41 } applies to both without problem. In C the cast is
required so that the compiler can generate the anonymous object
(object in th C standard sense) in the right type. When the
initialiser is used in an variable definition context then the
type is deduced from the definition itself (no auto type
deduction in C, so the type can be deduced).
In D the compound syntax doesn't exist, but it is not required,
because there is already a syntax for something very similar. The
type must be given explicitly for the same reason as in C as D
follows the same integer promotion rules.
Furthermore, in the context of a function call (which is only a
subpart of the more general creating/initialising of objects) D
adds a difficulty that C doesn't : overloads. Imagine a function
f with 2 overloads void f(struct aa); and void f(struct bb);
which one will be called if we use f({5, 41}); ? (pseudo syntax)
Templates take that issue to another level because there you
don't even see explicitely the overloads, they are generated
automagically by the compiler.
Conclusion: a new syntax is not necessary as the current way of
doing things is already minimal.
Re: A mini D book: Markdown or LaTeX?
On 1/27/2017 2:51 AM, Chris wrote: On Thursday, 26 January 2017 at 23:28:37 UTC, Walter Bright wrote: On 1/26/2017 7:02 AM, aberba wrote: I did this book: https://www.amazon.com/Historians-History-World-Vol-Prolegomena-ebook/dp/B00REVL4BC/ Is it the same as this: https://www.kobo.com/ie/en/ebook/the-historians-history-of-the-world-in-twenty-five-volumes-prolegomena-egypt-mesopotamia It's €3.99 there and only £1.50 (€1.76) on Amazon. However, I don't do kindle. I recently got interested in exactly this topic, especially Mesopotamia. Would it be a good introduction? Yes, it's the same book, but mine does a better job with the images and typography. Yes, it's a great introduction.
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter
wrote:
On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis
wrote:
[...]
It's funny (or sad) that C has compound types since C99 and
that they are good.
Your foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
of course, the lack of object orientation and other things
makes it easier in C.
Yeah, this seems similar to what I am saying. The only difference
is that the cast is not required because the types can be deduced
for functions. I don't see anything in the
spec(https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Compound-Literals.html) showing function calls using "compound literals though", which was my suggestion.
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 12:44:30 UTC, rjframe wrote: On Fri, 27 Jan 2017 10:38:53 +, Profile Anaysis wrote: Do you realize 1. That without change there can be no progress? ... If people with your mentality rules the world we would still be using sticks and stones. This is a fact... I won't argue whether it would be the best thing or not. Please argue for your proposal on its merit, not by criticizing the people who disagree. It can be difficult to communicate/work with strangers -- all we have is respect and the benefit of the doubt, and cannot afford to lose either. I can only argue on the merit when the criticism is of the actual problem, not of unrelated assumptions. e.g., How can you or Bauss argue against what I have said when I haven't said much. In fact, since Bauss was against it without even really hearing or understanding it(the syntax, since that is what he said he was against), and C99 already implements such a thing, it proves my point that he is just being a nay-Sayer. It's good enough for the c99 committee but not him? You are following in his shoes though. Instead of arguing on the actual concept proposed you are creating noise. All I can say, is take your own advice. You'd have a much better chance of getting a language change by a) getting a couple of people who agree with you to write a quality DIP, and b) listening to the criticism of those who disagree to refine the proposal (or in this specific case, find that it's not necessary (Alexandru Ermicioi's code)). Criticism must come from reason, not fear. Because you think such a syntax(one that hasn't even been created yet) will somehow be detrimental to your progress is insanity. 1. You have no way to judge the syntax since it hasn't been created yet. Hence you have to be against all syntactic sugar, which I already pointed out, is everything. Hence you are actually against progress in the big picture, including your own. A language is more than its feature set; language design is about balancing features and constraints. A language that tries to let you do anything and everything would make it too easy to create an unmaintainable mess (e.g., we need constraints either in the language or in the programmer). Yes, but you haven't said anything about the original concept. The above is obvious. Life is full of constraints in everything. You could say the same about banking, bout sex, about building a bridge, etc.
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 19:32:29 UTC, Jesse Phillips wrote: On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote: Many times we pass compound types(non-primitives) as arguments to functions. I don't understand what issue you are solving. I see an undefined syntax: foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) To replace an existing syntax: foo(T1(a,b,new X(c1,c2,c3)),T2(e),T3(f,g,c)); The primary difference I'm seeing is that the undefined syntax doesn't specify what type is being created. To this end the one time I recall desiring this is when using std.variant: The type is deduced from the function call. There is no need to specify it or specify new. This is why the syntax reduces the complexity(of course, at the cost of increase terseness) and lines. e.g., for your foo to be valid, it must have a declaration of foo(T1,T2,T3). So why should we have to specify that when the compiler can do it for us? The special syntax informs the compiler that we are initializing the types with the given arguments and it simply rewrites it in the long hand form. It can only be used when the type can be deduced.
Re: A better way to deal with overloading?
On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis
wrote:
Many times we pass compound types(non-primitives) as arguments
to functions.
I don't understand what issue you are solving. I see an undefined
syntax:
foo(|a,b,|c1,c2,3||,|e|,|f,g,c|)
To replace an existing syntax:
foo(T1(a,b,new X(c1,c2,c3)),T2(e),T3(f,g,c));
The primary difference I'm seeing is that the undefined syntax
doesn't specify what type is being created. To this end the one
time I recall desiring this is when using std.variant:
void foo(Variant v) { ... }
'foo' will now take anything, but I can't call it with anything,
instead I must call:
foo(Variant(3));
or
foo(Algebraic!(int, string, float)("hello"))
But this is a very special type.
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 12:59:54 UTC, Kagamin wrote:
On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter
wrote:
It's funny (or sad) that C has compound types since C99 and
that they are good.
Your foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
of course, the lack of object orientation and other things
makes it easier in C.
It's struct literals, a gcc extension, not in language.
No, they're named compound* literals and they are in the language
since C99.
https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Compound-Literals.html
* They can be used to initialise also unions and arrays. (int
[10]){0,2,[8]=2} is absolutely legal p.ex.
Re: Question about scope
On 1/27/2017 6:36 AM, Nemanja Boric wrote:
```
void bar(scope char** c, scope int* n) @trusted
{
}
void foo() @safe
{
char[100] buf;
char* c = &buf[0];
int n;
bar(&c, &n); // Error: cannot take address of scope local c in @safe
function foo
}
void main()
{
foo();
}
```
This doesn't compile even with dip1000, but does compile when `buf` is moved out
of the scope. Can somebody explain why it fails and what needs to be done with
it?
(I added in the error message to your example.)
Because 'buf' is local data, taking the address of 'buf' is 'scope', meaning it
must not escape foo(). This means that 'c' is also inferred to be 'scope'.
Taking the address of a 'scope' variable is not allowed because 'scope' is not
transitive and a 'scope pointer to a scope value' is not representable.
However, a 'ref' to a 'scope' is allowed, so your code can be written as:
```
void bar(ref scope char* c, scope int* n) @trusted
{
}
void foo() @safe
{
char[100] buf;
char* c = &buf[0];
int n;
bar(c, &n);
}
void main()
{
foo();
}
```
If you need to build more complex structures on the stack, and have them be
@safe, you'll need to encapsulate things with structs and ref counting.
Re: A mini D book: Markdown or LaTeX?
On Thursday, 26 January 2017 at 15:02:33 UTC, aberba wrote: Will most likely go with markdown and use other solutions for theming it. Then pandoc it to PDF Markdown is also supported by vibe.d's diet templates.
Re: A mini D book: Markdown or LaTeX?
On Friday, 27 January 2017 at 12:02:01 UTC, Chris wrote: Yes, you are right of course. In a perfect world we'd just write a text and give the odd reference. Unfortunately, anyone who writes an M.A., M.Sc. or Ph.D. thesis has to reference everything. Not even the most basic concept can be mentioned without referencing a book written by some professor(s). If a student writes "1 + 1 = 2" s/he has to reference it with a footnote à la "[1] Smith, T. & Wesson, J. Basic Concepts of Arithmetics - An Introduction. Cambridge, 2001." If you fail to do so, they will grill you. I know, it's ridiculous. Having said this, depending on the topic, you do need to insert footnotes - either to guide / help your readers or to shut up potential critics :-) Law articles are the worst with footnotes. Sometimes they'll have a whole page of footnotes with like one line of text at the top.
Question about scope
Taken from
https://github.com/dlang/druntime/pull/1750#discussion_r98181564:
```
void bar(scope char** c, scope int* n) @trusted
{
}
void foo() @safe
{
char[100] buf;
char* c = &buf[0];
int n;
bar(&c, &n);
}
void main()
{
foo();
}
```
This doesn't compile even with dip1000, but does compile when
`buf` is moved out of the scope. Can somebody explain why it
fails and what needs to be done with it?
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter
wrote:
It's funny (or sad) that C has compound types since C99 and
that they are good.
Your foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
of course, the lack of object orientation and other things
makes it easier in C.
It's struct literals, a gcc extension, not in language.
Re: A better way to deal with overloading?
On Fri, 27 Jan 2017 10:38:53 +, Profile Anaysis wrote: > Do you realize > > 1. That without change there can be no progress? > > ... > If people with your mentality rules the world we would still be using > sticks and stones. This is a fact... I won't argue whether it would be > the best thing or not. Please argue for your proposal on its merit, not by criticizing the people who disagree. It can be difficult to communicate/work with strangers -- all we have is respect and the benefit of the doubt, and cannot afford to lose either. You'd have a much better chance of getting a language change by a) getting a couple of people who agree with you to write a quality DIP, and b) listening to the criticism of those who disagree to refine the proposal (or in this specific case, find that it's not necessary (Alexandru Ermicioi's code)). > Because you think such a syntax(one that hasn't even been created yet) > will somehow be detrimental to your progress is insanity. > > 1. You have no way to judge the syntax since it hasn't been created yet. > Hence you have to be against all syntactic sugar, which I already > pointed out, is everything. Hence you are actually against progress in > the big picture, including your own. A language is more than its feature set; language design is about balancing features and constraints. A language that tries to let you do anything and everything would make it too easy to create an unmaintainable mess (e.g., we need constraints either in the language or in the programmer).
Re: A mini D book: Markdown or LaTeX?
On Friday, 27 January 2017 at 11:05:41 UTC, Kagamin wrote: On Thursday, 26 January 2017 at 10:26:25 UTC, Chris wrote: Er, yes. That's how it works. Always ask the publisher first. But that wasn't the question. The question was Markdown or LaTeX, and if you want to generate your own PDF for e.g. a M.A. or Ph.D., some people prefer LaTeX because of the fine grained control it offers. I don't know a single Ph.D. student who used Word who didn't have to fight with Word stubbornly restructuring the layout. The footnotes, the graphics ... a nightmare. I believe I just used the default Word style. It's a goddamned text, why it needs any sort of sophisticated layout aside from fitting the page? I had no problem with footnotes maybe because I believe they shouldn't exists in such documents in the first place: if you want to write something, just write it where it fits. It's baffling to see footnotes in ISO standards: if it's something important, write it where it belongs, W3C and IETF got it right, their documents have no footnotes. Yes, you are right of course. In a perfect world we'd just write a text and give the odd reference. Unfortunately, anyone who writes an M.A., M.Sc. or Ph.D. thesis has to reference everything. Not even the most basic concept can be mentioned without referencing a book written by some professor(s). If a student writes "1 + 1 = 2" s/he has to reference it with a footnote à la "[1] Smith, T. & Wesson, J. Basic Concepts of Arithmetics - An Introduction. Cambridge, 2001." If you fail to do so, they will grill you. I know, it's ridiculous. Having said this, depending on the topic, you do need to insert footnotes - either to guide / help your readers or to shut up potential critics :-)
Re: A better way to deal with overloading?
On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis
wrote:
auto t1 = T1(a,b,new X(c1,c2,c3));
auto t2 = T2(e);
auto t3 = T3(f,g,c);
and then f(t1,t2,t3);
or other wise simply inline the above.
This also cuts down on constructor overloading.
This is sort of liked named parameters but the idea is that the
compiler simply constructs the type internally as it knows what
type to expect and the grouping symbols allow one to specify
the contents unambiguously.
You can init structs, and classes inside the function call. Ex:
import std.stdio;
struct T1 {
int a;
int b;
int c;
}
struct T2 {
int b;
string a;
T1 t;
}
class T3 {
int z;
int m;
this(int z, int m) {
this.z = z;
this.m = m;
}
}
void foo(T1, T2, T3) {
}
void main() {
foo(
T1(1, 2, 3), // arguments are passed as rvalues to func.
T2(2, "tested",T1(1, 2, 3)), // compound struct
new T3(10, 20)
);
}
If new is not desired to be in your code, it's possible to use
opCall overload to mimic structs initialization, for classes.
Alexandru.
Re: A better way to deal with overloading?
On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis
wrote:
Many times we pass compound types(non-primitives) as arguments
to functions.
e.g.,
void foo(T1 t1, T2 t2, T3, t3);
But to call foo with new variables we have to create the
arguments. This usually requires extra code to simply
initialize the variables. (imagine foo being a constructor).
It may be better to use a recursive process where we can
specify all the values of the arguments inline.
e.g.,
foo(|a,b,c|,|e|,|f,g,c|).
(I am using | but any type of symbolic notation could be used)
would be equivalent to
foo(T1(a,b,c),T2(e),T3(f,g,c)).
When the T's are structs(other wise maybe new, or we can imply
new for classes to make it uniform).
If T1 has a compound type for the 3rd parameter, we can then
call it like
foo(|a,b,|c1,c2,3||,|e|,|f,g,c|).
this avoids having to do things like
auto t1 = T1(a,b,new X(c1,c2,c3));
auto t2 = T2(e);
auto t3 = T3(f,g,c);
and then f(t1,t2,t3);
or other wise simply inline the above.
This also cuts down on constructor overloading.
This is sort of liked named parameters but the idea is that the
compiler simply constructs the type internally as it knows what
type to expect and the grouping symbols allow one to specify
the contents unambiguously.
It's funny (or sad) that C has compound types since C99 and that
they are good.
Your foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
of course, the lack of object orientation and other things makes
it easier in C.
Re: A mini D book: Markdown or LaTeX?
On Thursday, 26 January 2017 at 10:26:25 UTC, Chris wrote: Er, yes. That's how it works. Always ask the publisher first. But that wasn't the question. The question was Markdown or LaTeX, and if you want to generate your own PDF for e.g. a M.A. or Ph.D., some people prefer LaTeX because of the fine grained control it offers. I don't know a single Ph.D. student who used Word who didn't have to fight with Word stubbornly restructuring the layout. The footnotes, the graphics ... a nightmare. I believe I just used the default Word style. It's a goddamned text, why it needs any sort of sophisticated layout aside from fitting the page? I had no problem with footnotes maybe because I believe they shouldn't exists in such documents in the first place: if you want to write something, just write it where it fits. It's baffling to see footnotes in ISO standards: if it's something important, write it where it belongs, W3C and IETF got it right, their documents have no footnotes.
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 10:57:41 UTC, Russel Winder wrote: Asciidoc (and it's continuation Asciidoctor) was invented to be a human usable front end to the DocBook/XML toolchain – and it still works for this. Humans should not have to write XML. Hence Asciidoctor. DocBook FTW, other magical formats are beyond pathetic. What? Asccidoc, Asciidoctor, Markdown, SO Markdown, GH Markdown, this Markdown, that Markdown, Restructured text, yaml, TeX, LaTeX, XeLaTeX, people invented tons of formats just to markup text for books and tons of their clones, extensions and incompatibilities, it's just laughable. Guess what % character means it those magical languages, or why Markdown chose an opposite approach to BBcode for square brackets, because it's more fun this way? XML is one uniform regular readable syntax for everything, it consists of only tags, attributes and comments, no arbitrary magical special characters for god only knows what.
Re: A mini D book: Markdown or LaTeX?
On Thursday, 26 January 2017 at 23:28:37 UTC, Walter Bright wrote: On 1/26/2017 7:02 AM, aberba wrote: I did this book: https://www.amazon.com/Historians-History-World-Vol-Prolegomena-ebook/dp/B00REVL4BC/ Is it the same as this: https://www.kobo.com/ie/en/ebook/the-historians-history-of-the-world-in-twenty-five-volumes-prolegomena-egypt-mesopotamia It's €3.99 there and only £1.50 (€1.76) on Amazon. However, I don't do kindle. I recently got interested in exactly this topic, especially Mesopotamia. Would it be a good introduction?
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 09:47:48 UTC, Bauss wrote: On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote: Many times we pass compound types(non-primitives) as arguments to functions. [...] This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me. Do you realize 1. That without change there can be no progress? 2. Everything is syntactic sugar. The only way to increase efficiency is to create higher level abstractions. If people with your mentality rules the world we would still be using sticks and stones. This is a fact... I won't argue whether it would be the best thing or not. At any point in the progress of humans people can say and do say what effectively what you are saying. Without people ignoring you and pushing the boundaries humanity would not be where it is at. e.g., "I disagree, punch cards are all we need.". "Tubes can do anything. There is no use in trying to control them with automation, we have hands for that". "The stone wheel has served us for centuries, it has proven reliability. There is no need to try to make it better". Because you think such a syntax(one that hasn't even been created yet) will somehow be detrimental to your progress is insanity. 1. You have no way to judge the syntax since it hasn't been created yet. Hence you have to be against all syntactic sugar, which I already pointed out, is everything. Hence you are actually against progress in the big picture, including your own. 2. You are not forced to use syntax extensions. If you are able to continue doing exactly what you did before there should be no need to be against it. It's like saying you are against cars because you want to walk. Well, no one is stopping you from walking by them having a car. [Your only argument is that the syntax(e.g., the car) is detrimental to you in some innate way that it's mere existence forces you to be have in an undesirable way. This isn't an argument though as I could use the reverse for my side. (e.g., I need a car to do things I need to do)].
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 09:47:48 UTC, Bauss wrote: On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote: Many times we pass compound types(non-primitives) as arguments to functions. [...] This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me. Out of interest what syntactic sugar would you remove?
Re: A better way to deal with overloading?
On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote: Many times we pass compound types(non-primitives) as arguments to functions. [...] This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me.
