Re: Simple GEdit .lang github color scheme
Le 23/09/2012 07:40, F i L a écrit : deadalnix wrote: Sound nice. How can I use that on my computer ? What do I do with the files ? You need to move the files into their 'gtksourceview-3.0' folders. On Linux (and other OS's should be similar), do: 1. find or create the following user directories: ~/.local/share/gtksourceview-3.0/styles ~/.local/share/gtksourceview-3.0/language-specs 2. Move the downloaded files into their respective folders, 'D.lang' to 'language-specs' and 'github.xml' to 'styles'. (Note, the download already contains this hierarchy) Alternatively (although I don't recommend it), you can move the files to: /usr/share/gtksourceview-3.0/... (overwriting the existing D.lang file) which will change it for all users. Hope that helps. Let me know if you have any problems, or find any highlighting bugs. Thanks. Great ! That worked perfectly. Thank you very much.
Re: DIL v2.000 release
On Sunday, 23 September 2012 at 21:21:06 UTC, Walter Bright wrote: May I suggest that you put it on github? The sources actually are on GitHub already: https://github.com/azizk/dil David
Re: DIL v2.000 release
On 9/23/2012 12:53 PM, Aziz K. wrote: I'm very excited to present to you the very first release of my D compiler written entirely in D2. Very nice! May I suggest that you put it on github?
Re: DIL v2.000 release
On 9/23/2012 2:24 PM, David Nadlinger wrote: On Sunday, 23 September 2012 at 21:21:06 UTC, Walter Bright wrote: May I suggest that you put it on github? The sources actually are on GitHub already: https://github.com/azizk/dil Great!
Re: DIL v2.000 release
Congrats, Aziz! :D
Re: reference to 'self' inside a function
string scopeName()
{
return q{__traits(identifier, __traits(parent, {}))};
}
void main()
{
writeln(mixin(scopeName()));
}
That should be quite usable, except if the user forgets the
mixin() part - unfortunately that potential bug seems to be
statically undetectable.
Thanks, for comming up with this clever solution, it's the best
one so far, and I will likely be using it.
The real problem of course is that there is no simple or obvious
solution to what is a very basic requirment - to inspect
information about a calling function, and/or execute it
recursively without having to re-specify the function explicitly.
Don't get me wrong, I am very much impressed with D, but the
reflection component in D should be made a real part of the
language, and really ought to be made more generalized (elegant).
It is interesting that both classes and structs are able to refer
to themselves through this, so that's a hint that there may be
some more use to the idea of self-referencing elsewhere. For
example, the ctors and dtors refer back to this, hinting that
functions should be able to do the same thing for recursive calls.
--rt
Re: LDC blacklisted in Ubuntu
On 22/09/12 11:13, Russel Winder wrote: Perhaps even better talk with the Debian people to find a route into the Debian repository, which then automatically gets to be part of Ubuntu and Mint. In the bigger picture yes, but as in this case it's Ubuntu that's blacklisted the package, probably best to go straight to them. There may also be a benefit in having a direct relationship with Ubuntu because their more frequent release cycle may make it easier to ensure the most up-to-date package is out there. IIRC their relationship with most packages in Debian is to take a snapshot of Sid at a particular point in time, so if you've got a new release of LDC after that snapshot is taken, it may be passed over unless you go to Ubuntu directly.
Re: Review of Andrei's std.benchmark
On 22/09/12 07:10, Nick Sabalausky wrote: I think this entire discussion serves as evidence that, at the very least, it needs to communicate that scope/methodology/rationale better that it currently does. If all of us are having trouble getting it, then others certainly will too. My feeling is that even with a good explanation in the docs, you're _still_ going to have a regular stream of people showing up on the mailing lists going, Hey, why can't I get my preferred metric with std.benchmark??!! So, even if there's good reason to think their preferences are daft, it might be worth supporting what they want to do, just to avoid that continuous stream of requests. Aside from that, there's the second key issue: whether the current intended scope is sufficient. Should it be more general in scope and not so specialized? Personally, I would tend to think do, and I think that seems to the the popular notion. But I don't know for sure. If it should be more generalized, than does it need to be so for the first iteration, or can it be done later after being added to phobos? That, I have no idea. This is what I was wondering, whether it's possible to take the current functionality but leave the door open to extending it with a different choice of metrics. Under the extended version, the default metric would be as it is currently, the docs would explain why this default makes sense and the caveats related to other metrics, but ultimately if the user wanted to use them, they'd be available. But I'd only like to see that happening if there is a natural path to the extended version rather than breaking changes or significant rewrites.
Re: 2.060 deb package on Linux Mint 13
Al 23/09/12 07:38, En/na Jason Spencer ha escrit: Though Mint 13 is very similar to ubuntu 12, I cannot seem to get the deb package to install. I get dependency errors on gcc, gcc-mulitlib, and xdg-utils. apt-get assures me these are all the latest version. Still, dpkg won't install dmd2. LinuxMint do not only uses the same Debian/Ubuntu packaging system (apt), it even uses the Ubuntu's repositories. dpkg command do not install dependencies, and apt-get command do not install local deb packages. There is a tool that install local deb packages, including its dependencies: gdebi $ sudo apt-get install gdebi to install dmd2 on LinuxMint: $ sudo gdebi dmd_2.060-0_amd64.deb If you get some problem with the installed (but still not configured) dmd deb package, remove it first: $ sudo dpkg -P dmd Best regards, -- Jordi Sayol
Re: Extending unittests [proposal] [Proof Of Concept]
On 2012-09-22 19:43, Jens Mueller wrote: What does it mean to make no distinction in RSpec? Both should be reported. In D you just see either an AssertError or SomeException. Test-unit would report something like this: 5 tests, 2 failures, 1 error Failures would be asserts that triggered, errors would be thrown exceptions. Rspec on the other hand would report: 5 examples, 3 failures It doesn't care if a failure is due to a thrown exception or a failed assert. Both of these also show a form of stack trace if an exception has been thrown. -- /Jacob Carlborg
Re: Extending unittests [proposal] [Proof Of Concept]
Jacob Carlborg wrote: On 2012-09-22 19:43, Jens Mueller wrote: What does it mean to make no distinction in RSpec? Both should be reported. In D you just see either an AssertError or SomeException. Test-unit would report something like this: 5 tests, 2 failures, 1 error Failures would be asserts that triggered, errors would be thrown exceptions. Rspec on the other hand would report: 5 examples, 3 failures It doesn't care if a failure is due to a thrown exception or a failed assert. I see. Thanks for giving this example. Both of these also show a form of stack trace if an exception has been thrown. How is the stack trace provided? Do you get a stack trace for each failure/error? Because that may clutter up the output. Maybe they stop at a predefined stack trace length. Jens
[OT] C# scores again for game development
Since this is one area where D could eventually replace C++, I've decided to post it here. So after Sony decided to make use of C#/Mono for the PS Vita SDK, Nintendo has decided to do the same by supporting Unity for the new Wii U. http://www.marketwire.com/press-release/unity-technologies-enters-extensive-agreement-with-nintendo-to-support-wii-u-1703600.htm -- Paulo
Re: [OT] C# scores again for game development
On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote: Since this is one area where D could eventually replace C++, I've decided to post it here. So after Sony decided to make use of C#/Mono for the PS Vita SDK, Nintendo has decided to do the same by supporting Unity for the new Wii U. http://www.marketwire.com/press-release/unity-technologies-enters-extensive-agreement-with-nintendo-to-support-wii-u-1703600.htm Note that it is only the scripting part of Unity that is C#/Mono. The core engine and editor is C++. /Jonas
Re: [OT] C# scores again for game development
On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen wrote: On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote: Since this is one area where D could eventually replace C++, I've decided to post it here. So after Sony decided to make use of C#/Mono for the PS Vita SDK, Nintendo has decided to do the same by supporting Unity for the new Wii U. http://www.marketwire.com/press-release/unity-technologies-enters-extensive-agreement-with-nintendo-to-support-wii-u-1703600.htm Note that it is only the scripting part of Unity that is C#/Mono. The core engine and editor is C++. /Jonas I know.
Re: reference to 'self' inside a function
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
On 23/09/2012 09:58, Rob T wrote:
string scopeName()
{
return q{__traits(identifier, __traits(parent, {}))};
}
void main()
{
writeln(mixin(scopeName()));
}
That should be quite usable, except if the user forgets the mixin()
part - unfortunately that potential bug seems to be statically
undetectable.
Thanks, for comming up with this clever solution, it's the best one so
far, and I will likely be using it.
The real problem of course is that there is no simple or obvious
solution to what is a very basic requirment - to inspect information
about a calling function, and/or execute it recursively without having
to re-specify the function explicitly. Don't get me wrong, I am very
much impressed with D, but the reflection component in D should be made
a real part of the language, and really ought to be made more
generalized (elegant).
It is interesting that both classes and structs are able to refer to
themselves through this, so that's a hint that there may be some more
use to the idea of self-referencing elsewhere. For example, the ctors
and dtors refer back to this, hinting that functions should be able to
do the same thing for recursive calls.
--rt
GetStockObject -- symbol undefined error
This win API call generates fatal error. Is there a fix?
Re: ref, safety, and warnings (was: ref and out required for function calls)
On 9/7/12, Kevin McTaggart kevin.mctagg...@drdc-rddc.gc.ca wrote:
snip
There's one thing nobody mentioned yet, and that is that we're already
using this syntax in the language -- in foreach loops:
struct Foo { int x; }
Foo[] arr = [{4}, {5}, {6}];
foreach (idx, ref val; arr)
{
val.x = idx;
}
However I'd like to see a custom compiler warning switch that would
warn me if I tried to call opAssign on a fundamental or struct type in
a foreach loop with a non-ref foreach parameter:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've had *numerous* occasions over the last few years where I've had
this bug happen to me. Structs and classes have different semantics
and when you're working in a large codebase that uses a combination of
classes and structs it's too easy to forget to add 'ref' to a foreach
parameter because you're looping over struct instances of some range
rather than class references.
I'd rather this be a special warning since enabling it by default
might be annoying if you really want to opAssign to temporaries.
I think the current mechanism we have (shove all warnings into the
-w switch and offer no customization) is lacking. I'd propose we
kept the current '-w' switch but also added options only enable or
disable specific warnings, e.g.:
dmd -we001 -we002 - only enable warnings 001 and 002
dmd -w -wd001 -wd002 - enable all warnings, except 001 and 002 which
are disabled
Then we could keep a list of warnings on dlang.org and provide helpful
info on when these warnings occur and what the user can do to fix his
code. For example look at how empty the warnings page is now:
http://dlang.org/warnings.html
I'd be willing to help out write the new warnings page.
Re: GetStockObject -- symbol undefined error
On 9/23/12, correspondent ethicalb...@hotmail.com wrote: This win API call generates fatal error. Is there a fix? The gdi32.lib import library DMD distributes is outdated. You can use this one: https://github.com/AndrejMitrovic/DWinProgramming/raw/master/gdi32.lib Pass it to DMD's command line when compiling. There's a bug open on this: http://d.puremagic.com/issues/show_bug.cgi?id=6625 Unfortunately the import libs are not on github so I have no idea how Walter packs these, otherwise I'd do a pull request ages ago.
Re: 2.060 deb package on Linux Mint 13
On Sunday, 23 September 2012 at 14:16:45 UTC, Jordi Sayol wrote:
to install dmd2 on LinuxMint:
$ sudo gdebi dmd_2.060-0_amd64.deb
Even gdebi's not happy. I removed dmd:i386 and started fresh.
Here's a transcript:
jason ~/Downloads $ sudo apt-get install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no
longer required:
g++-4.6 libstdc++6-4.6-dev
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 61 not upgraded.
{ I judged these to be harmless to the state of things, so left
them there.}
jason ~/Downloads $ sudo gdebi dmd_2.060-0_i386.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done
Building data structures... Done
This package is uninstallable
Cannot install 'gcc:i386'
jason ~/Downloads $ apt-cache showpkg gcc:i386
Package: gcc:i386
Versions:
4:4.6.3-1ubuntu5
(/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise_main_binary-i386_Packages)
Description Language:
File:
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise_main_binary-amd64_Packages
MD5: c7efd71c7c651a9ac8b2adf36b137790
Description Language: en
File:
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise_main_i18n_Translation-en
MD5: c7efd71c7c651a9ac8b2adf36b137790
Reverse Depends:
dmd:i386,gcc:i386
varnish:i386,gcc:i386 3.3
build-essential:i386,gcc:i386 4:4.4.3
mythbuntu-desktop:i386,gcc:i386
lmbench:i386,gcc:i386
xubuntu-desktop:i386,gcc:i386
varnish:i386,gcc:i386 3.3
ubuntustudio-desktop:i386,gcc:i386
simgrid:i386,gcc:i386
sfront:i386,gcc:i386
prayer-templates-dev:i386,gcc:i386
pmk:i386,gcc:i386
pari-gp2c:i386,gcc:i386
octave3.2-headers:i386,gcc:i386
nypatchy:i386,gcc:i386
nana:i386,gcc:i386
mlton-compiler:i386,gcc:i386
lsb-build-cc3:i386,gcc:i386
lisaac:i386,gcc:i386 4.1
libdmalloc5:i386,gcc:i386
ksplice:i386,gcc:i386
intercal:i386,gcc:i386
ikiwiki-hosting-web:i386,gcc:i386
ichthux-desktop:i386,gcc:i386
goo:i386,gcc:i386
gobjc++:i386,gcc:i386 4:4.6.3-1ubuntu5
gnome-speech-swift:i386,gcc:i386
gnome-speech-dectalk:i386,gcc:i386
ghc:i386,gcc:i386 4:4.2
gcl:i386,gcc:i386
gccgo:i386,gcc:i386 4:4.6.3-1ubuntu5
gap-dev:i386,gcc:i386
frama-c-base:i386,gcc:i386
flex-old:i386,gcc:i386
faucc:i386,gcc:i386
f2c:i386,gcc:i386
ecl:i386,gcc:i386
cython-dbg:i386,gcc:i386
cython:i386,gcc:i386
cxref:i386,gcc:i386
cwebx:i386,gcc:i386
cpushare:i386,gcc:i386
cproto:i386,gcc:i386
codelite:i386,gcc:i386
codeblocks:i386,gcc:i386
ccontrol:i386,gcc:i386
cbmc:i386,gcc:i386
bochs:i386,gcc:i386
binfmtc:i386,gcc:i386
apt-build:i386,gcc:i386
anjuta:i386,gcc:i386
acovea:i386,gcc:i386
ubuntu-desktop:i386,gcc:i386
python-numpy:i386,gcc:i386
ocaml-nox:i386,gcc:i386
ocaml-native-compilers:i386,gcc:i386
libtool:i386,gcc:i386
libc6-dev:i386,gcc:i386
iconc:i386,gcc:i386
hardening-wrapper:i386,gcc:i386
gobjc:i386,gcc:i386 4:4.6.3-1ubuntu5
gfortran:i386,gcc:i386 4:4.6.3-1ubuntu5
gcc-multilib:i386,gcc:i386 4.6.1-2ubuntu5
gcc-multilib:i386,gcc:i386 4:4.6.3-1ubuntu5
gcc-doc:i386,gcc:i386 4:4.6.3-1ubuntu5
gcc,gcc:i386
g++:i386,gcc:i386 4:4.6.3-1ubuntu5
flex:i386,gcc:i386
cmake:i386,gcc:i386
build-essential:i386,gcc:i386 4:4.4.3
gcc-multilib,gcc:i386 4.6.1-2ubuntu5
gcc-4.6-doc,gcc:i386 2.7.2.3-4.3
gcc-4.5-doc,gcc:i386 2.7.2.3-4.3
gcc-4.4-doc,gcc:i386 2.7.2.3-4.3
virtualbox-4.1:i386,gcc:i386
Dependencies:
4:4.6.3-1ubuntu5 - cpp:i386 (2 4:4.6.3-1ubuntu5) gcc-4.6:i386 (2
4.6.3-1~) gcc-multilib:i386 (0 (null)) make:i386 (0 (null))
manpages-dev:i386 (0 (null)) autoconf:i386 (0 (null))
automake1.9:i386 (0 (null)) libtool:i386 (0 (null)) flex:i386 (0
(null)) bison:i386 (0 (null)) gdb:i386 (0 (null)) gcc-doc:i386 (0
(null)) libc6-dev:i386 (16 (null)) libc-dev:i386 (0 (null))
gcc-doc (3 1:2.95.3) gcc-doc:i386 (3 1:2.95.3) gcc (0 (null))
Provides:
4:4.6.3-1ubuntu5 - c-compiler:i386
Reverse Provides:
So gcc seems to be installed right (indeed, I use it regularly),
but for some reason, the package dependencies or particulars
don't wire up right. Other ideas?
Jason
Re: 2.060 deb package on Linux Mint 13
Al 23/09/12 19:57, En/na Jason Spencer ha escrit: On Sunday, 23 September 2012 at 14:16:45 UTC, Jordi Sayol wrote: [...] 0 upgraded, 0 newly installed, 0 to remove and 61 not upgraded. first of all, upgrade your system $ sudo apt-get update $ sudo apt-get dist-upgrade jason ~/Downloads $ sudo gdebi dmd_2.060-0_i386.deb Why did you try to install 32-bit dmd deb package on a 64-bit system? You MUST install dmd_2.060-0_amd64.deb on a 64-bit system, like yours. Then, if you want to compile to 32-bit, just add -m32 to dmd command. -- Jordi Sayol
Re: ref, safety, and warnings
Andrej Mitrovic:
However I'd like to see a custom compiler warning switch that
would
warn me if I tried to call opAssign on a fundamental or struct
type in
a foreach loop with a non-ref foreach parameter:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've had *numerous* occasions over the last few years where
I've had this bug happen to me.
The same for me. Most people seem to not care for this problem, I
don't understand why. But I think it's a common source for bugs
in D programs. D design must take in account not just error-prone
features inherited from C, but also to avoid bug-prone situations
created by D-specific features.
C# designers have avoided this problem:
http://msdn.microsoft.com/en-us/library/04t3s14w.aspx
A possible solution is to require an explicit annotation if you
want to modify just the copy:
foreach (idx, @copy val; arr)
val.x = idx;
But maybe better is to do as in C# and turn val (and idx!) into
a const on default, and require an annotation if you want to
modify the copy:
foreach (idx, @mutable val; arr)
val.x = idx;
Bye,
bearophile
Re: ref, safety, and warnings
Andrej Mitrovic:
However I'd like to see a custom compiler warning switch that
would
warn me if I tried to call opAssign on a fundamental or struct
type in
a foreach loop with a non-ref foreach parameter:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've had *numerous* occasions over the last few years where
I've had this bug happen to me.
The same for me. Most people seem to not care for this problem, I
don't understand why. But I think it's a common source for bugs
in D programs. D design must take in account not just error-prone
features inherited from C, but also to avoid bug-prone situations
created by D-specific features.
C# designers have avoided this problem:
http://msdn.microsoft.com/en-us/library/04t3s14w.aspx
A possible solution is to require an explicit annotation if you
want to modify just the copy:
foreach (idx, @copy val; arr)
val.x = idx;
But maybe better is to do as in C# and turn val (and idx!) into
a const on default, and require an annotation if you want to
modify the copy:
foreach (idx, @mutable val; arr)
val.x = idx;
Bye,
bearophile
Re: LDC blacklisted in Ubuntu
On 9/20/2012 1:08 PM, Jonas Drewsen wrote: On Thursday, 20 September 2012 at 18:03:18 UTC, David Nadlinger wrote: On Thursday, 20 September 2012 at 17:26:25 UTC, Joseph Rushton Wakeling wrote: Some rather urgent news: LDC has just been blacklisted in Ubuntu. It would be great if somebody from the D community experienced in packaging could jump in to help us on this front. I've done some debs before and might be able to find some time to do it depending on how complex the package is. I haven't tried LDC before though. Can you provide some info on how to get started with the LDC building/packaging? Perhaps the deb building script written by Jordi for dmd can be helpful as a guide? https://github.com/D-Programming-Language/installer
Re: ref, safety, and warnings
On Sunday, 23 September 2012 at 18:43:08 UTC, bearophile wrote:
foreach (idx, val; arr)
{
val.x = idx; // clearly a bug, but lacks warning
}
I've had *numerous* occasions over the last few years where
I've had this bug happen to me.
The same for me. Most people seem to not care for this problem,
I
don't understand why. But I think it's a common source for bugs
in D programs. D design must take in account not just
error-prone
features inherited from C, but also to avoid bug-prone
situations
created by D-specific features.
Me too. I think this is the most common bug in my programs caused
by the language.
Re: ref, safety, and warnings (was: ref and out required for function calls)
On 09/23/2012 07:37 PM, Andrej Mitrovic wrote:
On 9/7/12, Kevin McTaggart kevin.mctagg...@drdc-rddc.gc.ca wrote:
snip
There's one thing nobody mentioned yet, and that is that we're already
using this syntax in the language -- in foreach loops:
struct Foo { int x; }
Foo[] arr = [{4}, {5}, {6}];
foreach (idx, ref val; arr)
{
val.x = idx;
}
...
That is not true. The only 'ref' in that code is a declaration site
annotation.
Re: reference to 'self' inside a function
On Sun, Sep 23, 2012 at 7:16 PM, Ben Davis ent...@cantab.net wrote:
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
Oh, you're using {} as a local block (or anonymous delegate), right?
That's a nice trick.
I even works at the module level, nice one!
DIP19: Remove comma operator from D and provision better syntactic support for tuples
I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated. Thanks, Andrei
Re: [OT] C# scores again for game development
On Sun, 23 Sep 2012 19:08:16 +0200 Paulo Pinto pj...@progtools.org wrote: On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen wrote: On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote: Since this is one area where D could eventually replace C++, I've decided to post it here. So after Sony decided to make use of C#/Mono for the PS Vita SDK, Nintendo has decided to do the same by supporting Unity for the new Wii U. http://www.marketwire.com/press-release/unity-technologies-enters-extensive-agreement-with-nintendo-to-support-wii-u-1703600.htm Note that it is only the scripting part of Unity that is C#/Mono. The core engine and editor is C++. /Jonas I know. I didn't. That's very interesting to hear.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu
wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them syntactically
are marred with unexpected problems. Nevertheless, I sure have
missed aspects all over, so contributions are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't
for (int i, j; cond; i++, j++) {}
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 About the (,) problem, what about using (void)? It's longer to type but it might be easier to humanly decode than trying to count lone commas. ((1, ), (,)) ((1, void), void, (void))
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei
Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them syntactically
are marred with unexpected problems. Nevertheless, I sure have
missed aspects all over, so contributions are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't assign
the value of the expression.
for (int i, j; cond; i++, j++) {}
I'd suggest looking at functional implementations such as ML or
Haskel for more inspiration.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:00:39 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei
Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them
syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so
contributions are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't assign
the value of the expression.
for (int i, j; cond; i++, j++) {}
I'd suggest looking at functional implementations such as ML or
Haskel for more inspiration.
urg.. .Sorry for the double posting..
Also, I want to add that type declarations should be changed from
statements to expressions so that we could do:
auto tup = (3, hello);
(int num, string s) = tup; // num == 3, s == hello
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 23/09/2012 22:40, Andrei Alexandrescu a écrit : I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated. Thanks, Andrei This is a problem I think about for a while, and coding for SDC + studying how it is done in other languages has enlightened me on some points. I all for deprecating the comma operator. You have my full support on that point. As well as you have it for the « for » construct update. However, I'm not sure about everything you propose to implement tuples. I could discuss idea about 1 element tuples, or other tricky cases that deserve discussion (and I'm sure they will). But first, let me digress. D is already a really good language. One of its main flaw is the lack of 3rd party tools. The way new feature are implemented is a real problem for 3rd party tool developers. In other terms, the arm done by adding new feature is greater than any benefit new feature can bring us. Additionally, we have some open mess that need to be closed. Think about the -property madness, the holes in const/immutable transitivity, or other half buggy features. I consider that , operator should be deprecated then removed ASAP. It will limit the amount of code possibly broken in the future. But let's not introduce any new feature before at least introducing a versioning scheme that allow user to keep the version without the feature.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
I'm not for removing the comma operator, but it occurs to me we
could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
Re: reference to 'self' inside a function
On 23/09/2012 20:58, Philippe Sigaud wrote:
On Sun, Sep 23, 2012 at 7:16 PM, Ben Davis ent...@cantab.net wrote:
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
Oh, you're using {} as a local block (or anonymous delegate), right?
That's a nice trick.
I even works at the module level, nice one!
Actually I stole the {} from Nick's suggestion. My suggestion was using
a mixin template instead of a string mixin, making it harder to screw up
invoking the mixin :)
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/23/2012 10:58 PM, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples. Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions
are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct.
If so, it should be the same as int.
I don't see what's confusing about that.
Those are currently both valid and give the same result:
int.max
(int).max
Anyway, the tuple type should resemble the tuple expression
syntactically.
I also am opposed to the idea to limit
tuples to 2 or more elements. On the contrary, I root for the clean
semantics of having a proper unit type represented as () instead of the
horrible C semantics of the 'void' type. Just make void an alias to ()
for backwards compatibility.
You mean, alias () to 'void' for backwards compatibility. How would
that give 'clean semantics'? It's just syntax. Or is it about void
supporting 'expand'? I don't think that makes sense.
void foo(){}
void main(){
void[] x = new int[42];
foo(x[0].expand); // whut?
}
Also, why the need to special case the for loop? the increment part can
be a regular tuple since the for loop doesn't assign the value of the
expression. for (int i, j; cond; i++, j++) {}
I assume Andrei intends the enclosing parens to be mandatory.
I'd suggest looking at functional implementations such as ML or Haskel[l] for
more inspiration.
They just do the two most obvious things. (well, Haskell has to answer
some questions related to the evaluation model that are irrelevant for
D.)
Neither one has a syntactic construct for building a single element tuple.
Also, I want to add that type declarations should be changed from statements to
expressions so that we could do:
auto tup = (3, hello);
(int num, string s) = tup; // num == 3, s == hello
I'd support the addition of declaration expressions (mainly for using
them in conjuncts of if conditions), but this is not necessary to
enable what you show above.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Ok, here's a crazy idea: Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those... Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes 1 vs =1. Well, *mechanically* yes, but consider this: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. That means (at least I think it means) that things like () or (1) or ((1)) require no way to disambiguate between tuple and expression, because either way they're the same thing (or at least freely convertible).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 23/09/2012 23:52, Nick Sabalausky a écrit : Ok, here's a crazy idea: Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those... Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes1 vs=1. Well, *mechanically* yes, but consider this: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. My reflection on the subject for the past month lead me to the same conclusion. That means (at least I think it means) that things like () or (1) or ((1)) require no way to disambiguate between tuple and expression, because either way they're the same thing (or at least freely convertible). Exactly.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
This is a complex topic, and in this post I am not able to
discuss everything that needs to be discussed. So I will discuss
only part of the story.
First: tuples are important enough. I think they should be
built-in in a modern language, but maybe having them as
half-built-in will be enough in D. Currently in D we have
(deprecated) built-in complex numbers that I use only once in a
while, and half-usable library defined tuples that I use all the
time.
Second: removing comma operator from D has some advantages
unrelated to tuple syntax. Even disallowing bad looking C-like
code that uses commas is an improvement by itself (but maybe it's
not a big enough improvement...).
Third: replacing the packing syntax tuple(x,y) with (x,y) is nice
and maybe even expected in a partially functional language as D,
but that's _not_ going to improve D usability a lot. What I am
asking for is different: I'd like D tuples to support handy
unpacking syntax:
1) In function signatures;
2) In foreach;
3) At assignment points;
4) In switch cases.
Note: in the examples below I have used the tuple(x,y) syntax for
simplicity, feel free to replace it with a shorter (x,y) syntax
if you want.
---
1) This tuple unpacking use case is important, and it's not what
you argue against in the DIP:
int f(tuple(int x, int y)) { return x + y; }
auto pairs = zip([10, 20], [2, 3]);
map!f(pairs)
This is different from what you are arguing against because this
f is not accepting two normal ints, it accepts a tuple made of
two ints, and names them x and y on the fly.
---
2)
auto pairs = zip([10, 20], [2, 3]).array();
foreach (i, tuple(x, y); pairs) {}
---
3) This is probably the most common use case:
auto foo() { return tuple(10, 20); }
auto tuple(x, y) = foo(); // bad syntax
auto (x, y) = foo(); // better syntax
void main() {
auto a = tuple(1, 2);
auto tuple(x1, x2) = a; // bad syntax
auto (y1, y2) = a; // better syntax
}
---
4) This looks simple, but allows things like using BigInt in
switch cases, implementing a very simple but quite handy
pattern-matching, etc:
auto v = tuple(10, 20);
final switch (v) {
case tuple(5, y): { x in scope... } break; // y is not a
global
case tuple(x, y): { ... } break; // this covers all cases
}
---
There are other usage patterns that are handy, but in my opinion
the four I have shown here are the most commonly useful ones. See
also Bugzilla issues 6365 and 6367, they shows some other cases
and ideas and problems.
---
Tuple singletons: using (1,) as in Python is acceptable. using
(1) is not acceptable in my opinion, too much dangerous. tuple(1)
is also acceptable, it's longer, but it's not commonly used, so
it's OK.
Empty tuples: the (,) syntax proposed in the DIP is not nice, it
seems to have one invisible item, but maybe it's acceptable.
tuple() is also acceptable, it's longer, but it's not commonly
used, so it's OK.
In the end tuples with 0 and 1 items are sometimes useful, but
they are not nearly as useful as supporting well tuples with 2 or
more items. Scala language agrees with this.
---
Tuple slicing: it's not a fundamental operation, but it's nice to
try to make it work correctly :-) I think not even Haskell does
this well.
---
Summary:
- I think (1,2) is nicer and better than tuple(1,2), and I'd like
to have such syntax, but it's not a large improvement and it's
not what I am asking for now (less priority).
- Supporting tuples with 0 and 1 items is sometimes handy but I
think it's not essential.
- On the other hand syntax to unpack/destructure tuples in many
situations is important for allowing a proper and handy use of
tuples in D.
Bye,
bearophile
Re: [OT] C# scores again for game development
On Sunday, 23 September 2012 at 20:49:54 UTC, Nick Sabalausky wrote: On Sun, 23 Sep 2012 19:08:16 +0200 Paulo Pinto pj...@progtools.org wrote: On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen wrote: On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto wrote: Since this is one area where D could eventually replace C++, I've decided to post it here. So after Sony decided to make use of C#/Mono for the PS Vita SDK, Nintendo has decided to do the same by supporting Unity for the new Wii U. http://www.marketwire.com/press-release/unity-technologies-enters-extensive-agreement-with-nintendo-to-support-wii-u-1703600.htm Note that it is only the scripting part of Unity that is C#/Mono. The core engine and editor is C++. /Jonas I know. I didn't. That's very interesting to hear. The core engine is C++. Mono takes care of allowing any .NET language to be used as scripting language, with C#, JavaScript and Boo having the main roles, while compiling them AOT to native code as well.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 22:29:31 UTC, jerro wrote:
On Sunday, 23 September 2012 at 21:37:06 UTC, Adam D. Ruppe
wrote:
I'm not for removing the comma operator, but it occurs to me
we could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
If D is like C in this regard, then the function above cannot
replace comma operator, because the order of evaluation is
defined for comma operator, but not for function parameters.
You could use something like that, though:
Sorry about the You could use something like that, though part.
I realized something like that wouldn't work either, but forgot
to delete that text.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:37:06 UTC, Adam D. Ruppe wrote:
I'm not for removing the comma operator, but it occurs to me we
could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
If D is like C in this regard, then the function above cannot
replace comma operator, because the order of evaluation is
defined for comma operator, but not for function parameters. You
could use something like that, though:
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 00:30:27 jerro wrote: If D is like C in this regard, then the function above cannot replace comma operator, because the order of evaluation is defined for comma operator, but not for function parameters. I believe that it's currently undefined for D, but Walter wants to define it so that it's left-to-right in an effort to eliminate bugs resulting from the varying order of function argument evaluation. He just hasn't gotten around to doing it yet. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/23/2012 10:40 PM, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples.
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,3);
(auto a, string b) = (1, 3);
BTW: the following works
Tuple!(int, string) t2 = t1[0 .. 2];
because of this:
= (alias this)
Tuple!(int, string) t2; t2._fields = t1[0 .. 2];
= (tuple assignment)
Tuple!(int, string) t2; t2._fields[0]=t1[0]; t2._fields[1]=t1[1];
Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions are
appreciated.
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
- How do we expand a sequence into a tuple?
= (Seq!(1,2,3),)
- What is the calling convention used for passing built-in tuples to
and from functions?
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 5:57 PM, deadalnix wrote: Le 23/09/2012 23:52, Nick Sabalausky a écrit : Ok, here's a crazy idea: Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those... Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes1 vs=1. Well, *mechanically* yes, but consider this: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. My reflection on the subject for the past month lead me to the same conclusion. This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. Also, having no integrated notion of a zero-element tuple would again mess with the algebra as much as the absence of 0 would hurt numbers. It's just troublesome. I appreciate the attraction of this idea, but again I think it's safe to just not even discuss it. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 12:11 AM, bearophile wrote:
...
Second: removing comma operator from D has some advantages unrelated to
tuple syntax. Even disallowing bad looking C-like code that uses commas
is an improvement by itself (but maybe it's not a big enough
improvement...).
I would think that it isn't an improvement at all. Disallowing some
construct always will also disallow 'bad looking' code that uses it.
...
4) This looks simple, but allows things like using BigInt in switch
cases, implementing a very simple but quite handy pattern-matching, etc:
auto v = tuple(10, 20);
final switch (v) {
case tuple(5, y): { x in scope... } break; // y is not a global
case tuple(x, y): { ... } break; // this covers all cases
}
...
cases already introduce their own scopes in D, but switch cannot be
extended well to serve such use cases.
I agree with all the other points.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 12:40 AM, Jonathan M Davis wrote: On Monday, September 24, 2012 00:30:27 jerro wrote: If D is like C in this regard, then the function above cannot replace comma operator, because the order of evaluation is defined for comma operator, but not for function parameters. I believe that it's currently undefined for D, but Walter wants to define it so that it's left-to-right in an effort to eliminate bugs resulting from the varying order of function argument evaluation. He just hasn't gotten around to doing it yet. - Jonathan M Davis I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,3);
(auto a, string b) = (1, 3);
I meant to mention that but forgot. The interesting thing about this is
that, if we decide it's the main issue with today's tuples, we pull
Kenji's patch and close the case.
BTW: the following works
Tuple!(int, string) t2 = t1[0 .. 2];
because of this:
= (alias this)
Tuple!(int, string) t2; t2._fields = t1[0 .. 2];
= (tuple assignment)
Tuple!(int, string) t2; t2._fields[0]=t1[0]; t2._fields[1]=t1[1];
Yah, I thought the writeup clarified that.
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
Then what are the old tuples?
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
There's already intensive use of parens in D. I predict there's going to
be big trouble with () even assuming it's not technical ambiguous, for
example a lambda that returns an empty tuple would be ()() {...} and
all that jazz.
- How do we expand a sequence into a tuple?
= (Seq!(1,2,3),)
I think we're discussing different things - the above seems to deal with
expression/alias tuples. DIP19 discusses strictly runtime value tuples.
- What is the calling convention used for passing built-in tuples to
and from functions?
I don't know. The current approach with .expand is nothing special - as
if the programmer wrote the expansion by hand.
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
I find that sugar gratuitous.
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
I kinda got lost around all that.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. Also, having no integrated notion of a zero-element tuple would again mess with the algebra as much as the absence of 0 would hurt numbers. It's just troublesome. I appreciate the attraction of this idea, but again I think it's safe to just not even discuss it. I'm not sure I want to answer that, so I wont.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 12:57 AM, Andrei Alexandrescu wrote:
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
Actually that is mostly unrelated to the comma operator. Apologies.
auto (a,b) = (1,3);
(auto a, string b) = (1, 3);
I meant to mention that but forgot. The interesting thing about this is
that, if we decide it's the main issue with today's tuples, we pull
Kenji's patch and close the case.
Imho, it certainly is the main issue.
...
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
Then what are the old tuples?
Instances of TypeTuples, eg:
template Seq(T...){ alias T Seq; }
Seq!(int, double) foo(){ }
= Error: functions cannot return a tuple
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
There's already intensive use of parens in D. I predict there's going to
be big trouble with () even assuming it's not technical ambiguous,
Well, (,) cannot help with that.
for
example a lambda that returns an empty tuple would be ()() {...} and
all that jazz.
Well, it would be ()=() or delegate()()=(), but is it even reasonable
to use the second form?
- How do we expand a sequence into a tuple?
= (Seq!(1,2,3),)
I think we're discussing different things - the above seems to deal with
expression/alias tuples. DIP19 discusses strictly runtime value tuples.
I am discussing the interplay of the two features. Sequences are
auto-expanded in all contexts where it makes sense (except if they
happen to be the second argument to a comma expression, then they are
not, but I assume that is a bug.)
I expect the following to be equivalent:
(Seq!(1,2,3),)
and
(1,2,3)
- What is the calling convention used for passing built-in tuples to
and from functions?
I don't know. The current approach with .expand is nothing special - as
if the programmer wrote the expansion by hand.
Not sure we are on the same page. I meant the calling convention at the
ABI level.
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
I find that sugar gratuitous.
You find built-in tuples gratuitous in general. :o)
Anyway, it certainly is not necessary.
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
I kinda got lost around all that.
I assume named tuple fields are not a problem?
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like.
template Foo((U...,)){ alias (U,) Foo; }
void main(){
(int, double) x;
Foo!(typeof(x)) y;
static assert(is(typeof(x)==typeof(y)));
}
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 01:08 AM, deadalnix wrote: Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. Also, having no integrated notion of a zero-element tuple would again mess with the algebra as much as the absence of 0 would hurt numbers. It's just troublesome. I appreciate the attraction of this idea, but again I think it's safe to just not even discuss it. I'm not sure I want to answer that, so I wont. I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Andrei Alexandrescu: The interesting thing about this is that, if we decide it's the main issue with today's tuples, we pull Kenji's patch and close the case. As I have tried to explain in my precedent post, Kenji's patch covers about 1/4 of the most important use cases. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr: cases already introduce their own scopes in D, Thank you, I didn't remember this. but switch cannot be extended well to serve such use cases. Please explain, as I am not able to see the problems. I have discussed that topic a little here: http://d.puremagic.com/issues/show_bug.cgi?id=596 Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 01:36 AM, bearophile wrote: Timon Gehr: cases already introduce their own scopes in D, Thank you, I didn't remember this. but switch cannot be extended well to serve such use cases. Please explain, as I am not able to see the problems. Switch is syntax sugar for jump tables. An adequate pattern matching construct would not require explicit control flow statements, and it would be an expression of arbitrary type. I have discussed that topic a little here: http://d.puremagic.com/issues/show_bug.cgi?id=596 Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr: Switch is syntax sugar for jump tables. An adequate pattern matching construct would not require explicit control flow statements, and it would be an expression of arbitrary type. Introducing a good pattern matching syntax in D requires the introduction of a good amount of complexity. This idea was discussed few times in past. D switches also work on strings, wstrings, dstrings, so the idea of extending them to work on small array is not too much different. I think that switching on structs, and tuples with auto-assignment of variables for tuple fields, is enough to extend the usefulness of D switches significantly, while it introduces no new keywords, and not a lot of complexity for both the compiler and the programmer that has to learn D language. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 01:23, Timon Gehr a écrit :
I assume named tuple fields are not a problem?
I'm not sure it is really usefull.
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like.
template Foo((U...,)){ alias (U,) Foo; }
void main(){
(int, double) x;
Foo!(typeof(x)) y;
static assert(is(typeof(x)==typeof(y)));
}
The template syntax seems weird. Why do you want Foo((U...,)) when
Foo(U) could do it ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 01:34, bearophile a écrit : Andrei Alexandrescu: The interesting thing about this is that, if we decide it's the main issue with today's tuples, we pull Kenji's patch and close the case. As I have tried to explain in my precedent post, Kenji's patch covers about 1/4 of the most important use cases. It would be great if we stopped to base design reflection on actual implementations we have somewhere.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 02:00 AM, deadalnix wrote: Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing. Well, I do not want parentheses to randomly hide members. (a ~ b).length
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 02:21, Timon Gehr a écrit : On 09/24/2012 02:00 AM, deadalnix wrote: Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing. Well, I do not want parentheses to randomly hide members. (a ~ b).length Then it easy to add a comma to create a one element tuple. IE: (a ~ b).length == a.length + b.length (a ~ b,).length == 1
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 02:28 AM, deadalnix wrote: Le 24/09/2012 02:21, Timon Gehr a écrit : On 09/24/2012 02:00 AM, deadalnix wrote: Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing. Well, I do not want parentheses to randomly hide members. (a ~ b).length Then it easy to add a comma to create a one element tuple. IE: (a ~ b).length == a.length + b.length (a ~ b,).length == 1 The motivation for having these conversions was syntactic ambiguity. If there is none, just do it like this: (create_tuple,) get_value[0]
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 7:08 PM, deadalnix wrote: Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. The example came from min() applied to built-in T... tuples. I've implemented it a few times, and I recall at some point there was a compiler bug related to zero-length tuples. It was rather awkward to address. But there are many other cases. In my opinion, introducing a change of phase at length=1 is just causing trouble. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:08 PM, deadalnix wrote: Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. The example came from min() applied to built-in T... tuples. I've implemented it a few times, and I recall at some point there was a compiler bug related to zero-length tuples. It was rather awkward to address. But there are many other cases. In my opinion, introducing a change of phase at length=1 is just causing trouble. Andrei I understand the trouble here. But why divide and conquer is preferable here over a static foreach over the tuple ? Additionally, what lead me to think the idea is good is how tuple can be used to call function, or to extend the opDispatch feature to templated calls. I didn't wanted to go into such details, because I wanted to test several idea before doing a proposal. A lot of options are possible here, and interaction with other part of the language are everywhere.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 02:44, Timon Gehr a écrit : The motivation for having these conversions was syntactic ambiguity. If there is none, just do it like this: (create_tuple,) get_value[0] As I answered to Andrei, my motivation isn't related to syntax ambiguity, and I actually don't care what the syntax is as long as it isn't terribly twisted.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 03:31:08 deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side. It's function arguments that should be evaluated left-to-right. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote: On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is this documented anywhere?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 03:41 AM, Jonathan M Davis wrote: On Monday, September 24, 2012 03:31:08 deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side. Of course it does. Some values are returned by dereferencing a hidden argument. It's function arguments that should be evaluated left-to-right. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 04:27 AM, Timon Gehr wrote: On 09/24/2012 03:41 AM, Jonathan M Davis wrote: On Monday, September 24, 2012 03:31:08 deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side. Of course it does. Some values are returned by dereferencing a hidden argument. Nevermind. In the general case, a temporary still has to be generated because of aliasing issues. It's function arguments that should be evaluated left-to-right. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 9:27 PM, deadalnix wrote: I understand the trouble here. But why divide and conquer is preferable here over a static foreach over the tuple ? There are fewer data dependencies, which results on faster execution on today's CPUs. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 9:31 PM, deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like: int[int] stuff; stuff[42] = stuff.length; Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 10:15 PM, Timon Gehr wrote: On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote: On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is this documented anywhere? Not to the best of my knowledge. I'm not even sure it's always the case. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote: I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 +1 to getting rid of the comma operator. (OK, just deprecation, but that's a good step.) I always felt it's one of those unnecessary holdovers from C. We don't need a comma operator. The only use cases I've ever seen of it is in specific contexts (such as for-loops) where suitable, relatively confined, syntax extensions would take care of everything without the invasiveness of having an entire operator. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sun, 23 Sep 2012 21:30:08 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote: I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 +1 to getting rid of the comma operator. (OK, just deprecation, but that's a good step.) I always felt it's one of those unnecessary holdovers from C. We don't need a comma operator. The only use cases I've ever seen of it is in specific contexts (such as for-loops) where suitable, relatively confined, syntax extensions would take care of everything without the invasiveness of having an entire operator. I saw it once in an earlier revision of RDMD from about a year ago. It was an awkward usage (IMO) and isn't there anymore. So basically, I agree that it's not particularly useful ;)
Re: reference to 'self' inside a function
On Sun, Sep 23, 2012 at 11:45 PM, Ben Davis ent...@cantab.net wrote:
Actually I stole the {} from Nick's suggestion. My suggestion was using a
mixin template instead of a string mixin, making it harder to screw up
invoking the mixin :)
Ah, OK :) I actually just skimmed the entire thread :) I think self
should be in Phobos, that's something I had to re-implement many
times. And I never thought of using {}.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sun, 23 Sep 2012 18:48:22 -0400 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. I think one of us is missing something, and I'm not entirely sure who. As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case? I think it's safe to just not even discuss it. A nice way to put it :/ Part politician perhaps? ;)
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Glad to hear that comma operator won't be depreciated.
Re: [OT] Was: totally satisfied :D
On Sat, Sep 22, 2012 at 03:48:49AM -0400, Nick Sabalausky wrote:
On Fri, 21 Sep 2012 15:37:46 -0700
H. S. Teoh hst...@quickfur.ath.cx wrote:
The sad part is that so many of the commenters have no idea that
adjacent C literals are concatenated at compile-time. It's a very
nice way to put long strings in code and have it nicely indented,
something that is sorely lacking in most languages. But regardless,
why are they posting if they clearly don't know C that well?!
Heh, actually I didn't even know about it until I learned it from D
and then learned that D got it from C (does D still do it, or is that
one of those to be deprecated things?)
Heh. I suppose in any language complex enough to be interesting there
are always some things that you don't know about until a long time
later. :) So maybe I was a bit harsh on the commenters. But still, they
should've checked before they posted (but then I'm guilty of that one
too).
But then dealing with strings is something I generally tried to avoid
in C anyway ;)
Yeah... D is just so much more comfortable to write when dealing with
strings. With std.regex in Phobos now, writing string-processing code in
D is almost as comfortable as Perl, and probably performs better too.
Note also that the ' ...code here and ' ...more code here
sections were typically HUGE.
Speaking of 1000-line functions... yeah I routinely work with those
monsters.
*cough* DMD's main() *cough* ;)
Although it's actually, surprisingly, not too bad in DMD's case, all
things considered. Took me by surprise at first though, I really
wasn't expecting it.
I haven't followed this rule to the letter all the time, but usually I
consider that if a function doesn't read like pseudo-code, then you're
doing something wrong. What I mean is, it should read like steps of an
algorithm that makes sense when you read it, for example, initialize
data structure X to empty, loop over input items, transform data and
store in X, return result should map to something like:
Result func(Input input) {
auto result = X();
foreach (item; input) {
auto x = transform(item);
result.add(x);
}
return result;
}
That is, the detailed steps in transform() shouldn't pollute the main
code in func(), but should remain as a separate function. Ditto with
X.add(), which may involve a complicated series of steps.
As soon as you start having a whole bunch of code at different levels of
abstraction mixed together, you know it's time to split them up into
separate functions, 'cos chances are you'll need to use each piece
independently one day.
[...]
I have seen code whose function names are along the lines of
do_it() and do_everything(). As well as do_main() and
${program_name}_main() in addition to main().
What really gets me is that these are the sorts of things that are
harped on in chapter 1 of just about any decent intro to programming
book. So where did these people even learn to code in the first place?
Probably from a youtube video on how to write your own lame Flash game.
:-P OK, I'm being a bit harsh. But it's hard not to be cynical when
you've seen the kind of code that passes for enterprise software these
days.
Heck, back in college, I used to be a CS tutor for first semester
programming students. Even *they* wrote better code, no exaggeration.
Totally. I've been a teaching assistant before, and we made sure to
drill sound programming practices into the students early, and often.
Makes me wonder where all these students went after they graduated, 'cos
the people writing code in the workforce don't seem to be the same
people who attended these courses. Strange.
(Well, except for the handful of students, and I could always tell
which ones they were, who were from the class of Mrs. Let's Teach OOP
*Before* Basic Flow Of Execution. Those poor students couldn't write
*any* code, let alone good or bad code. I felt bad for them.)
Speaking of students who couldn't code... I used to give out sympathy
marks for struggling students. Y'know, their code was so bad, like code
that obviously didn't compile or work, or code with comments written in
a way that suggested the student thought that if they pleaded hard
enough verbally the computer might *just* do what they wanted it to do
-- they had to get a failing mark, but I tried to find excuses to not
give them an outright zero. But one time, after marking a bunch of 15-20
page assignments (complete with intro, description, code, test results,
etc.), I came across a submission consisting of a single sheet of paper
*hand-written* on a single side. I was boggled for a good moment. It
was like... I was trying not to give anyone an outright zero but she
gave me no choice, y'know? What was the point of handing that piece of
paper if she wasn't even going to make the effort of using the lab
Re: Testing for template argument being result of takeExactly
On Sun, Sep 23, 2012 at 1:54 AM, Jonathan M Davis jmdavisp...@gmx.com wrote:
I'm trying to test whether a template argument is the type returned by
takeExactly, and I haven't been able to sort out the template voodoo required
yet. It would be a lot easier if I had a variable to work with, but I just
have the type, and the fancy is expression required to pull it off is fancy
enough that I haven't been able to sort it out yet.
Seeing that takeExactly returns itself when its input is a
takeExactly, I used this:
import std.range;
import std.stdio;
template Hello(R)
{
static if (is(typeof(R._input)) // Is using R._input OK?
is(typeof(takeExactly(typeof(R._input),0)) == R )) //
Does applying takeExactly on R gives R back?
alias typeof(R._input) Hello; // Extract the original range type
else
alias void Hello;
}
void main()
{
auto str = hello;
auto t = takeExactly(str, 3);
writeln(t);
writeln(Hello!(typeof(t)).stringof); // string
}
Transforming it into a predicate template is easy, I just wanted to
show that R._input is accessible.
Caution: takeExactly returns a slice when the range is slice-able. You
should test for hasSlicing on R first.
As for Voldemort (Nameless One, Dark Lord, whatever) types, I find
them more annoying than useful, personally.
Philippe
Re: Testing for template argument being result of takeExactly
On 09/23/2012 01:54 AM, Jonathan M Davis wrote:
I'm trying to test whether a template argument is the type returned by
takeExactly, and I haven't been able to sort out the template voodoo required
yet. It would be a lot easier if I had a variable to work with, but I just
have the type, and the fancy is expression required to pull it off is fancy
enough that I haven't been able to sort it out yet. At present, I have this:
import std.range;
import std.stdio;
template Hello(R)
if(is(R r == U, V, V w, U = typeof(takeExactly(w, 1
{
alias R Hello;
}
void main()
{
auto str = hello;
auto t = takeExactly(str, 3);
writeln(t);
Hello!(typeof(t)) h = t;
writeln(h);
}
I need Hello to instatiate if R is the type returned by takeExactly and fail
to instantiate otherwise. At present, the code gives these compilation errors:
q.d(15): Error: template instance Hello!(Result) Hello!(Result) does not match
template declaration Hello(R) if (is(R r == U,V,V w,U =
typeof(takeExactly(w,1
q.d(15): Error: Hello!(Result) is used as a type
q.d(16): Error: template std.stdio.writeln does not match any function
template declaration
q.d(16): Error: template std.stdio.writeln(T...) cannot deduce template
function from argument types !()(_error_)
So, clearly I don't have the is expression right, and this is seriously
pushing the edge of my knowledge of is expressions. So, any help would be
appreciated. Thanks.
- Jonathan M Davis
import std.range, std.traits;
import std.stdio;
template Hello(R) if(is(typeof(R._input.takeExactly(2)) == R)){
alias R Hello;
}
void main(){
auto str = hello;
auto t = takeExactly(str, 3);
writeln(t);
Hello!(typeof(t)) h = t;
writeln(h);
}
Re: Testing for template argument being result of takeExactly
On 9/23/12 8:47 AM, Timon Gehr wrote:
import std.range, std.traits;
import std.stdio;
template Hello(R) if(is(typeof(R._input.takeExactly(2)) == R)){
alias R Hello;
}
That's the nicest. Regarding availability of _input, I meant to make
it available systematically as input for ranges where the notion makes
sense.
Andrei
Re: Passing associative array to another thread
On 2012-09-22 13:50, Johannes Pfau wrote: 1. Declare it as shared There's also __gshared. Yeah, forgot about that one. -- /Jacob Carlborg
Re: Testing for template argument being result of takeExactly
On 09/23/2012 03:48 PM, Andrei Alexandrescu wrote:
On 9/23/12 8:47 AM, Timon Gehr wrote:
import std.range, std.traits;
import std.stdio;
template Hello(R) if(is(typeof(R._input.takeExactly(2)) == R)){
alias R Hello;
}
That's the nicest.
Well, I noticed it is not entirely correct as takeExactly special cases
sliceable inputs. Therefore, the guard also passes for ranges that have
a sliceable member called _input of the same range type. The correct
guard therefore would be:
if(hasSlicing!R || is(typeof(R._input.takeExactly(2)) == R))
or
if(!hasSlicing!R is(typeof(R._input.takeExactly(2)) == R))
depending on what the goal is.
Regarding availability of _input, I meant to make
it available systematically as input for ranges where the notion makes
sense.
Andrei
This seems to be reasonable.
educational graphics library for D
Hi, I'm evaluating D as a language for my computer science classses. Can you recommend a graphics library which can be used for simple graphic programming like logo, turtle or processing.org? Regards, Thomas Koch
alias to a property as an argument to a mixin template
For this program I'm getting an Error: need 'this' to access
member x at line (*). Does that mean that we cannot alias a
property as an argument of a template mixin?
import std.stdio;
mixin template T(alias a) {
void f() {
writeln(a); // (*)
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
mixin T!(s.x);
f();
}
If I change main() as follows, I still get the same error:
void main1() {
auto s = S(4);
with (s) {
mixin T!(x);
f();
}
}
But now, I can get it working by this trick:
import std.stdio;
mixin template T(alias a) {
void f() {
mixin(writeln( ~ a.stringof ~ ););
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
with (s) {
mixin T!(x);
f();
}
} // prints 4
So, using string mixins works, but explicit alias to the property
name seems not to. Why is that and is there any other way of
achieving the result witout using template mixins?
Re: alias to a property as an argument to a mixin template
On Sunday, 23 September 2012 at 18:48:14 UTC, comco wrote:
For this program I'm getting an Error: need 'this' to access
member x at line (*). Does that mean that we cannot alias a
property as an argument of a template mixin?
import std.stdio;
mixin template T(alias a) {
void f() {
writeln(a); // (*)
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
mixin T!(s.x);
f();
}
If I change main() as follows, I still get the same error:
void main1() {
auto s = S(4);
with (s) {
mixin T!(x);
f();
}
}
But now, I can get it working by this trick:
import std.stdio;
mixin template T(alias a) {
void f() {
mixin(writeln( ~ a.stringof ~ ););
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
with (s) {
mixin T!(x);
f();
}
} // prints 4
So, using string mixins works, but explicit alias to the
property name seems not to. Why is that and is there any other
way of achieving the result witout using template mixins?
I think it is normal behavior. Keep in mind what you are
instantiating your template with (something know at compile
time), and how you are using it.
When you write T!(s.x), the compiler understands it as S.x
(in D, you may use an instance when you could use a type).
Of course, when trying to use the mixed-in in T, you get:
void f() {
writeln(S.x);
}
To which the compiler replies: Who's x? (eg: I need this).
EG: as the title implies, you parametrized your template on a
property, but there is no associated instance.
What you are really trying to do, is parametrize your template on
a variable *name*, so you were right taking your mixin approach.
However, I think this is more like what you want:
import std.stdio;
//ss is the variable name
mixin template T(alias ss) {
void f() {
mixin(writeln( ~ ss ~ ););
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
mixin T!s.x; //mix with the variable s.x
f();
}
On a side note, if the alias was named s, the compiler would
have gotten confused, because of the conflict with the mixed'd in
s. THAT however, I think is a bug.
Re: alias to a property as an argument to a mixin template
monarch_dodra already answered, but since, I typed this, I may as well
post it :)
On Sun, Sep 23, 2012 at 8:49 PM, comco void.unsig...@gmail.com wrote:
For this program I'm getting an Error: need 'this' to access member x at
line (*). Does that mean that we cannot alias a property as an argument of a
template mixin?
By using s.x, you're not referencing the property, but directly the
value s.x, which is known only at runtime: it cannot be a template
argument.
If x where a static member, you could probably use it, hence the error
message (need 'this', ...).
So, using string mixins works, but explicit alias to the property name seems
not to. Why is that?
a.stringof can be obtained for any symbol a, so s.x (or with(s) ... x)
just gives s.x, which can be mixed in. It's transformed into a
string, transformation for which there is no need for 'this'.
and is there any other way of achieving the result
witout using template mixins
Sorry but... what result? Referencing a member inside a template?
Remember templates can be in another module, written years ago. If you
really want a template to act on a local value, either use a mixin
template, as you did, or reference the member by its name as a string:
import std.stdio;
mixin template T(string member)
{
void f()
{
mixin(writeln( ~ member ~ ););
}
}
struct S
{
int x;
}
void main() {
auto s = S(4);
mixin T!(s.x);
f();
} // prints 4
I see monarch proposed exactly the same way to do it...
Re: alias to a property as an argument to a mixin template
On 09/23/2012 11:49 AM, comco wrote:
For this program I'm getting an Error: need 'this' to access member x
at line (*). Does that mean that we cannot alias a property as an
argument of a template mixin?
import std.stdio;
mixin template T(alias a) {
void f() {
writeln(a); // (*)
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
mixin T!(s.x);
f();
}
If I change main() as follows, I still get the same error:
void main1() {
auto s = S(4);
with (s) {
mixin T!(x);
f();
}
}
But now, I can get it working by this trick:
import std.stdio;
mixin template T(alias a) {
void f() {
mixin(writeln( ~ a.stringof ~ ););
}
}
struct S {
int x;
}
void main() {
auto s = S(4);
with (s) {
mixin T!(x);
f();
}
} // prints 4
So, using string mixins works, but explicit alias to the property name
seems not to. Why is that and is there any other way of achieving the
result witout using template mixins?
There is also delegates:
import std.stdio;
struct S {
int x;
}
void main() {
auto s = S(4);
auto f = { return s.x; };
f();
}
Ali
Re: Testing for template argument being result of takeExactly
On 09/23/2012 12:02 PM, monarch_dodra wrote:
On Saturday, 22 September 2012 at 23:53:28 UTC, Jonathan M Davis wrote:
I'm trying to test...
[SNIP]
- Jonathan M Davis
I *kind of* see what you are doing with U, V, W, but what's wrong with
just doing:
import std.range;
template Hello(R)
if(is(typeof(R == typeof(takeExactly(R, 1)
{
alias R Hello;
}
struct S;
void main( ) {
Hello!(int[]) a; //OK
Hello!S b; //FAIL
}
?
It seems to work for me..., but I'm not 100% sure there isn't something
illegal/unsafe in there.
The goal is to test whether a template argument is the type returned by
takeExactly.
Your solution (I think) is looking at a container and determining
whether the type of that container can be compared to the return type of
takeExactly(). (Note that typeof(X == Y) is used for checking whether
that expression itself is valid.)
Also, I think your code should have passed a range like R.init to
takeExactly, not R, which is a type:
takeExactly(R.init, 1)
I don't know why your code compiles.
Ali
Re: Testing for template argument being result of takeExactly
On Sunday, 23 September 2012 at 20:56:42 UTC, Ali Çehreli wrote:
On 09/23/2012 12:02 PM, monarch_dodra wrote:
On Saturday, 22 September 2012 at 23:53:28 UTC, Jonathan M
Davis wrote:
I'm trying to test...
[SNIP]
- Jonathan M Davis
I *kind of* see what you are doing with U, V, W, but what's
wrong with
just doing:
import std.range;
template Hello(R)
if(is(typeof(R == typeof(takeExactly(R, 1)
{
alias R Hello;
}
struct S;
void main( ) {
Hello!(int[]) a; //OK
Hello!S b; //FAIL
}
?
It seems to work for me..., but I'm not 100% sure there isn't
something
illegal/unsafe in there.
The goal is to test whether a template argument is the type
returned by takeExactly.
Your solution (I think) is looking at a container and
determining whether the type of that container can be compared
to the return type of takeExactly(). (Note that typeof(X == Y)
is used for checking whether that expression itself is valid.)
Good point. My bad then.
Also, I think your code should have passed a range like R.init
to takeExactly, not R, which is a type:
takeExactly(R.init, 1)
I don't know why your code compiles.
That did seem fishy to me too actually, but it does compile.
Ali
In that case, what about:
import std.range;
template Hello(R)
if(is(typeof(takeExactly(R.init, 1))) is(R ==
typeof(takeExactly(R.init, 1
{
alias R Hello;
}
struct S{};
void main( ) {
Hello!(int[]) a; //OK
Hello!S b; //FAIL (again)
}
---
Re: alias to a property as an argument to a mixin template
On Sunday, 23 September 2012 at 19:53:26 UTC, Philippe Sigaud
wrote:
monarch_dodra already answered, but since, I typed this, I may
as well
post it :)
On Sun, Sep 23, 2012 at 8:49 PM, comco
void.unsig...@gmail.com wrote:
For this program I'm getting an Error: need 'this' to access
member x at
line (*). Does that mean that we cannot alias a property as an
argument of a
template mixin?
By using s.x, you're not referencing the property, but directly
the
value s.x, which is known only at runtime: it cannot be a
template
argument.
If x where a static member, you could probably use it, hence
the error
message (need 'this', ...).
So, using string mixins works, but explicit alias to the
property name seems
not to. Why is that?
a.stringof can be obtained for any symbol a, so s.x (or with(s)
... x)
just gives s.x, which can be mixed in. It's transformed into a
string, transformation for which there is no need for 'this'.
and is there any other way of achieving the result
witout using template mixins
Sorry but... what result? Referencing a member inside a
template?
Remember templates can be in another module, written years ago.
If you
really want a template to act on a local value, either use a
mixin
template, as you did, or reference the member by its name as a
string:
import std.stdio;
mixin template T(string member)
{
void f()
{
mixin(writeln( ~ member ~ ););
}
}
struct S
{
int x;
}
void main() {
auto s = S(4);
mixin T!(s.x);
f();
} // prints 4
I see monarch proposed exactly the same way to do it...
Thank you for the answers. Passing a string does the job, but the
result I wanted to achieve is: the client of the mixin template
to use it without strings. Here's the motivating example: when
implementing algorithms for linked data structures, a common
pattern is such a chain of assignments:
a1 = a2; a2 = a3; a3 = a4 ...
For example, take a rotation of a binary tree:
struct node {
node* left, right;
}
void rotate(node* u) {
auto v = u.right;
u.right = v.left;
v.left = u;
}
For this pattern, we may design a template function like this:
void reassign(A...)(ref A a) {
static if (A.length 1) {
a[0] = a[1];
reassign(a[1 .. $]);
}
}
Now we can implement our rotate in terms of reassign:
void rotate(node* u) {
auto v = u.right;
reassign(u.right, v.left, u);
}
This works and is general enough, but notice the duplication of
u.right. I don't like it - this may become an arbitrary large
expression.
But the naive attempt fails:
void rotate(node* u) {
node* v;
reassign(v, u.right, v.left, u); // runtime error at
v.left
}
That's because v is not initialized when we call the function. So
what we really want is to pass a list of symbols (and I thought
`v.left` qualifies as a symbol) to the function, not references
to value. But this means we'll need template mixins, because you
can pass symbols by alias to them. Since alias arguments for
templates are classified as symbolic arguments, I was expecting
that you can pass u.right as an atomic symbol, without using
strings. So, then my strange rotate would look like this:
void rotate(node* u) {
node* v;
mixin ReassignMixin!(v, u.right, v.left, u);
reassign();
}
See how the client code looks nicer when the template arguments
are not wrapped as strings.
So, I thought of template mixins as a too-much-as-macros as they
are.
Still, why is `u` more symbolic than, say `u.left
Re: alias to a property as an argument to a mixin template
On Sunday, 23 September 2012 at 21:42:54 UTC, comco wrote:
On Sunday, 23 September 2012 at 19:53:26 UTC, Philippe Sigaud
wrote:
monarch_dodra already answered, but since, I typed this, I may
as well
post it :)
On Sun, Sep 23, 2012 at 8:49 PM, comco
void.unsig...@gmail.com wrote:
For this program I'm getting an Error: need 'this' to access
member x at
line (*). Does that mean that we cannot alias a property as
an argument of a
template mixin?
By using s.x, you're not referencing the property, but
directly the
value s.x, which is known only at runtime: it cannot be a
template
argument.
If x where a static member, you could probably use it, hence
the error
message (need 'this', ...).
So, using string mixins works, but explicit alias to the
property name seems
not to. Why is that?
a.stringof can be obtained for any symbol a, so s.x (or
with(s) ... x)
just gives s.x, which can be mixed in. It's transformed into
a
string, transformation for which there is no need for 'this'.
and is there any other way of achieving the result
witout using template mixins
Sorry but... what result? Referencing a member inside a
template?
Remember templates can be in another module, written years
ago. If you
really want a template to act on a local value, either use a
mixin
template, as you did, or reference the member by its name as a
string:
import std.stdio;
mixin template T(string member)
{
void f()
{
mixin(writeln( ~ member ~ ););
}
}
struct S
{
int x;
}
void main() {
auto s = S(4);
mixin T!(s.x);
f();
} // prints 4
I see monarch proposed exactly the same way to do it...
Thank you for the answers. Passing a string does the job, but
the result I wanted to achieve is: the client of the mixin
template to use it without strings. Here's the motivating
example: when implementing algorithms for linked data
structures, a common pattern is such a chain of assignments:
a1 = a2; a2 = a3; a3 = a4 ...
For example, take a rotation of a binary tree:
struct node {
node* left, right;
}
void rotate(node* u) {
auto v = u.right;
u.right = v.left;
v.left = u;
}
For this pattern, we may design a template function like this:
void reassign(A...)(ref A a) {
static if (A.length 1) {
a[0] = a[1];
reassign(a[1 .. $]);
}
}
Now we can implement our rotate in terms of reassign:
void rotate(node* u) {
auto v = u.right;
reassign(u.right, v.left, u);
}
This works and is general enough, but notice the duplication of
u.right. I don't like it - this may become an arbitrary large
expression.
But the naive attempt fails:
void rotate(node* u) {
node* v;
reassign(v, u.right, v.left, u); // runtime error at
v.left
}
That's because v is not initialized when we call the function.
So what we really want is to pass a list of symbols (and I
thought `v.left` qualifies as a symbol) to the function, not
references to value. But this means we'll need template mixins,
because you can pass symbols by alias to them. Since alias
arguments for templates are classified as symbolic arguments, I
was expecting that you can pass u.right as an atomic symbol,
without using strings. So, then my strange rotate would look
like this:
void rotate(node* u) {
node* v;
mixin ReassignMixin!(v, u.right, v.left, u);
reassign();
}
See how the client code looks nicer when the template arguments
are not wrapped as strings.
So, I thought of template mixins as a too-much-as-macros as
they are.
Still, why is `u` more symbolic than, say `u.left
Sorry for the last line.
Re: Testing for template argument being result of takeExactly
On Sunday, September 23, 2012 14:47:27 Timon Gehr wrote:
template Hello(R) if(is(typeof(R._input.takeExactly(2)) == R)){
alias R Hello;
}
Thanks. That does the trick quite cleanly, though you'd think that it would be
possible to test whether a template argument is the result of takeExactly
without caring or knowing about the guts of takeExactly. So, this isn't a
general purpose solution at all, when I think that there should be one. Still,
I don't need a general purpose one for what I'm doing, so this should work
just fine.
- Jonathan M Davis
Re: Testing for template argument being result of takeExactly
On 09/23/2012 10:57 PM, Ali Çehreli wrote: ... Also, I think your code should have passed a range like R.init to takeExactly, not R, which is a type: takeExactly(R.init, 1) I don't know why your code compiles. See discussion here: http://d.puremagic.com/issues/show_bug.cgi?id=8220
Re: Testing for template argument being result of takeExactly
On Sunday, September 23, 2012 13:55:04 Philippe Sigaud wrote: Transforming it into a predicate template is easy, I just wanted to show that R._input is accessible. I was trying to test it without checking its internals (which should be possible IMHO), but if I have to check its internals, I have to check its internals. Actually, it hadn't occured to me to check its internals, but I would have wanted to avoid it (and still do), but this will work for now. Thanks. Caution: takeExactly returns a slice when the range is slice-able. You should test for hasSlicing on R first. Actually, I'm messing with hasSlicing, so I have to be _very_ careful here. Per a discussion on github, I'm changing it to require that the return type of opSlice for finite ranges returns a type which can be assigned to the original type and that for infinite ranges it be the result of takeExactly. The changes to opSlice themselves seem straightforward enough but the side effects on take and takeExactly have gotten a bit hairy, since they reference hasSlicing. I don't think that it'll take many changes, but getting it right has been hard. As for Voldemort (Nameless One, Dark Lord, whatever) types, I find them more annoying than useful, personally. Due to how they affect the init property and some other stuff, they may have to be axed (there's a bug report discussing some of those issues somewhere, but I don't remember it's number), but we still have them for the moment. The idea is cool, but the ultimate result is definitely problematic. - Jonathan M Davis
memory de-allocation?
Given:
void main () {
system(rdmd prog_one.d);
//... output from prog_one
system(rdmd prog_two.d);
//... output again from prog_one and new output from prog_two.
}
Any suggestions for getting rid of the ghost of prog_one?
[Issue 8081] pure nothrow unittest problem in generated 'header' file
http://d.puremagic.com/issues/show_bug.cgi?id=8081 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Platform|x86 |All --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-09-22 23:28:11 PDT --- https://github.com/D-Programming-Language/dmd/pull/1139 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8475] postblits fails attributes qualifying when in a template.
http://d.puremagic.com/issues/show_bug.cgi?id=8475 --- Comment #2 from github-bugzi...@puremagic.com 2012-09-22 23:39:46 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3e171f435d2761489818c83b0bda305a158a353a fix Issue 8475 - postblits fails attributes qualifying when in a template. In PostBlitDeclaration::syntaxCopy, storage_class should also be copied to new AST object. It's a design failure of the signature in PostBlitDeclaration constructor, so merge two constructors into one. https://github.com/D-Programming-Language/dmd/commit/3f8a3b6bf85fda3e93e032fe07a33967cf76768f Merge pull request #1137 from 9rnsr/fix8475 Issue 8475 - postblits fails attributes qualifying when in a template. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
