Re: The D Scripting Language
Tomek Sowiński wrote: This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. Thanks for doing this. I think D fares rather well in it.
Re: The D Scripting Language
Tomek Sowiñski Wrote: > This wraps up a thread from a few days ago. Pascal featured my D examples > on his Scriptometer site. > > http://rigaux.org/language-study/scripting-language/ > > D comes 17th out of 28, so it's so-so for scripting. > > -- > Tomek When I looked over his scoring from the original post, it seemed > 100 was a great choice for a scripting language and everything below wasn't. D hit where I expected, just good enough to use for scripting.
Re: The D Scripting Language
On 11/7/10 5:34 PM, Jesse Phillips wrote: Tomek Sowiñski Wrote: This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. -- Tomek When I looked over his scoring from the original post, it seemed> 100 was a great choice for a scripting language and everything below wasn't. D hit where I expected, just good enough to use for scripting. Perhaps a module std.scripting could help quite a lot, too. Andrei
Re: The D Scripting Language
On 11/7/2010 8:49 PM, Andrei Alexandrescu wrote: On 11/7/10 5:34 PM, Jesse Phillips wrote: Tomek Sowiñski Wrote: This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. -- Tomek When I looked over his scoring from the original post, it seemed> 100 was a great choice for a scripting language and everything below wasn't. D hit where I expected, just good enough to use for scripting. Perhaps a module std.scripting could help quite a lot, too. Andrei I'm having trouble thinking of something that would go in this module that wouldn't be a better fit somewhere else. What do you envision?
Re: The D Scripting Language
Hello Tomek, This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. The link from D seems dead to me (missing ':' after http).
Re: The D Scripting Language
On 11/7/10 9:12 PM, Eric Poggel wrote:
On 11/7/2010 8:49 PM, Andrei Alexandrescu wrote:
On 11/7/10 5:34 PM, Jesse Phillips wrote:
Tomek Sowiñski Wrote:
This wraps up a thread from a few days ago. Pascal featured my D
examples
on his Scriptometer site.
http://rigaux.org/language-study/scripting-language/
D comes 17th out of 28, so it's so-so for scripting.
--
Tomek
When I looked over his scoring from the original post, it seemed> 100
was a great choice for a scripting language and everything below
wasn't. D hit where I expected, just good enough to use for scripting.
Perhaps a module std.scripting could help quite a lot, too.
Andrei
I'm having trouble thinking of something that would go in this module
that wouldn't be a better fit somewhere else. What do you envision?
I thought of it for a bit, but couldn't come up with anything :o). I
think you're right!
Someone proposed to add something like
http://docs.python.org/library/fileinput.html to Phobos. I think it's a
good idea. We have all mechanics in place (byLine/byChunk, chain). So it
should be easy to define byLine to accept an array of filenames:
import std.stdio;
void main(string args[]) {
getopt(args, ...);
foreach (line; File.byLine(args[1 .. $]) {
...
}
}
I hypothetically made byLine a static method inside File to avoid
confusing beginners (one might think on first read that byLine goes line
by line through an array of strings).
Andrei
Re: The D Scripting Language
Andrei: > Someone proposed to add something like > http://docs.python.org/library/fileinput.html to Phobos. I think it's a > good idea. Good. That someone was me (But I don't use Python fileinput often, so I have never written an enhancement request on this). Bye, bearophile
Re: The D Scripting Language
On 11/09/2010 06:12 PM, Andrei Alexandrescu wrote:
On 11/7/10 9:12 PM, Eric Poggel wrote:
On 11/7/2010 8:49 PM, Andrei Alexandrescu wrote:
On 11/7/10 5:34 PM, Jesse Phillips wrote:
Tomek Sowiñski Wrote:
This wraps up a thread from a few days ago. Pascal featured my D
examples
on his Scriptometer site.
http://rigaux.org/language-study/scripting-language/
D comes 17th out of 28, so it's so-so for scripting.
--
Tomek
When I looked over his scoring from the original post, it seemed> 100
was a great choice for a scripting language and everything below
wasn't. D hit where I expected, just good enough to use for scripting.
Perhaps a module std.scripting could help quite a lot, too.
Andrei
I'm having trouble thinking of something that would go in this module
that wouldn't be a better fit somewhere else. What do you envision?
I thought of it for a bit, but couldn't come up with anything :o). I
think you're right!
Someone proposed to add something like
http://docs.python.org/library/fileinput.html to Phobos. I think it's a
good idea. We have all mechanics in place (byLine/byChunk, chain). So it
should be easy to define byLine to accept an array of filenames:
import std.stdio;
void main(string args[]) {
getopt(args, ...);
foreach (line; File.byLine(args[1 .. $]) {
...
}
}
I hypothetically made byLine a static method inside File to avoid
confusing beginners (one might think on first read that byLine goes line
by line through an array of strings).
Andrei
module std.script;
public import std.stdio, std.file, std.process, std.algorithm, ... etc
I use at least some of these for most of my programs/scripts. And
std.all is probably a bit too heavy.
std.script could basically fetch us enough stuff to be on par with
importless python.
Re: The D Scripting Language
On 8/11/10 1:49 AM, Andrei Alexandrescu wrote: On 11/7/10 5:34 PM, Jesse Phillips wrote: Tomek Sowiñski Wrote: This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. -- Tomek When I looked over his scoring from the original post, it seemed> 100 was a great choice for a scripting language and everything below wasn't. D hit where I expected, just good enough to use for scripting. Perhaps a module std.scripting could help quite a lot, too. Andrei Make it std.s and we save 8 characters for each program :-)
Re: The D Scripting Language
Pelle Månsson Wrote:
> On 11/09/2010 06:12 PM, Andrei Alexandrescu wrote:
> > On 11/7/10 9:12 PM, Eric Poggel wrote:
> >> On 11/7/2010 8:49 PM, Andrei Alexandrescu wrote:
> >>> On 11/7/10 5:34 PM, Jesse Phillips wrote:
> Tomek Sowiñski Wrote:
>
> > This wraps up a thread from a few days ago. Pascal featured my D
> > examples
> > on his Scriptometer site.
> >
> > http://rigaux.org/language-study/scripting-language/
> >
> > D comes 17th out of 28, so it's so-so for scripting.
> >
> > --
> > Tomek
>
> When I looked over his scoring from the original post, it seemed> 100
> was a great choice for a scripting language and everything below
> wasn't. D hit where I expected, just good enough to use for scripting.
> >>>
> >>> Perhaps a module std.scripting could help quite a lot, too.
> >>>
> >>> Andrei
> >>
> >> I'm having trouble thinking of something that would go in this module
> >> that wouldn't be a better fit somewhere else. What do you envision?
> >
> > I thought of it for a bit, but couldn't come up with anything :o). I
> > think you're right!
> >
> > Someone proposed to add something like
> > http://docs.python.org/library/fileinput.html to Phobos. I think it's a
> > good idea. We have all mechanics in place (byLine/byChunk, chain). So it
> > should be easy to define byLine to accept an array of filenames:
> >
> > import std.stdio;
> > void main(string args[]) {
> > getopt(args, ...);
> > foreach (line; File.byLine(args[1 .. $]) {
> > ...
> > }
> > }
> >
> > I hypothetically made byLine a static method inside File to avoid
> > confusing beginners (one might think on first read that byLine goes line
> > by line through an array of strings).
> >
> >
> > Andrei
>
> module std.script;
>
> public import std.stdio, std.file, std.process, std.algorithm, ... etc
>
> I use at least some of these for most of my programs/scripts. And
> std.all is probably a bit too heavy.
>
> std.script could basically fetch us enough stuff to be on par with
> importless python.
I think optimizing this particular test is important for the publicity of D.
Once the scripting community acknowledges D, we could redesign it. We should
make all current test cases one liners, if possible. I'm dreaming of a Linux
system (Ubuntu) which uses dmd instead of bash to compile all init scripts. The
system would boot in just a few seconds.
Re: The D Scripting Language
Jesse Phillips Wrote: > Tomek Sowiñski Wrote: > > > This wraps up a thread from a few days ago. Pascal featured my D examples > > on his Scriptometer site. > > > > http://rigaux.org/language-study/scripting-language/ > > > > D comes 17th out of 28, so it's so-so for scripting. > > > > -- > > Tomek > > When I looked over his scoring from the original post, it seemed > 100 was a > great choice for a scripting language and everything below wasn't. D hit > where I expected, just good enough to use for scripting. If > 100 is good for scripting and < 100 bad, D belongs to the latter category. It only scored 93.
Re: The D Scripting Language
On Wed, Nov 10, 2010 at 2:04 AM, Gary Whatmore wrote: > > I think optimizing this particular test is important for the publicity of D. > Once the scripting community acknowledges D, we could redesign it. We should > make all current test cases one liners, if possible. I'm dreaming of a Linux > system (Ubuntu) which uses dmd instead of bash to compile all init scripts. > The system would boot in just a few seconds. > No it wouldn't. Booting doesn't take so long because you wait for bash/dash to interpret the init scripts but because you wait for what the init-scripts do (mount/fsck filesystems, start daemons, ...). Sure, there's an overhead from bash (or dash, that at least debian uses now and has fewer overhead), but it's not that significant.
Re: The D Scripting Language
Andrei Alexandrescu napisał:
>> I'm having trouble thinking of something that would go in this module
>> that wouldn't be a better fit somewhere else. What do you envision?
>
> I thought of it for a bit, but couldn't come up with anything :o). I
> think you're right!
Yeah, I think std.all would be just fine, or as Pelle proposed, a module
publicly importing a first-aid kit for scripting.
> Someone proposed to add something like
> http://docs.python.org/library/fileinput.html to Phobos. I think it's a
> good idea. We have all mechanics in place (byLine/byChunk, chain). So it
> should be easy to define byLine to accept an array of filenames:
>
> import std.stdio;
> void main(string args[]) {
> getopt(args, ...);
Speaking of getopt, when writing the 'grep' snippet I missed anonymous options
a lot:
bool h, i; string expr; string[] files;
getopt(args, "h",&h, "i",&i, &expr, &files);
They can be implemented with relatively little effort.
> foreach (line; File.byLine(args[1 .. $]) {
> ...
> }
> }
>
> I hypothetically made byLine a static method inside File to avoid
> confusing beginners (one might think on first read that byLine goes line
> by line through an array of strings).
The hipothetical version gave me exactly this impression. Moreover, the element
type should be tuple(line, current file
name or a pointer to File). So maybe File.byFileLine(...)?
--
Tomek
Re: The D Scripting Language
Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
foreach (line; File.byLine(args[1 .. $]) {
...
}
}
I hypothetically made byLine a static method inside File to avoid
confusing beginners (one might think on first read that byLine goes line
by line through an array of strings).
The hipothetical version gave me exactly this impression. Moreover, the element type should be tuple(line, current file
name or a pointer to File). So maybe File.byFileLine(...)?
I too got confused. But personally, I don't like byFileLine either.
Maybe something like Files range:
File.byLine(files(args[1..$])))
or
files(args[1..$]).byLine
?
Re: The D Scripting Language
On 11/10/10 1:45 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
I'm having trouble thinking of something that would go in this module
that wouldn't be a better fit somewhere else. What do you envision?
I thought of it for a bit, but couldn't come up with anything :o). I
think you're right!
Yeah, I think std.all would be just fine, or as Pelle proposed, a module
publicly importing a first-aid kit for scripting.
Someone proposed to add something like
http://docs.python.org/library/fileinput.html to Phobos. I think it's a
good idea. We have all mechanics in place (byLine/byChunk, chain). So it
should be easy to define byLine to accept an array of filenames:
import std.stdio;
void main(string args[]) {
getopt(args, ...);
Speaking of getopt, when writing the 'grep' snippet I missed anonymous options
a lot:
bool h, i; string expr; string[] files;
getopt(args, "h",&h, "i",&i,&expr,&files);
They can be implemented with relatively little effort.
Not getting the example. How would anonymous options work?
Andrei
Re: The D Scripting Language
Andrei Alexandrescu napisał: >> Speaking of getopt, when writing the 'grep' snippet I missed anonymous >> options a lot: >> >> bool h, i; string expr; string[] files; >> getopt(args, "h",&h, "i",&i,&expr,&files); >> >> They can be implemented with relatively little effort. > > Not getting the example. How would anonymous options work? // Let's match assignments. auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"]; bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i, &expr, &files); assert(!h); assert(!i); assert(expr == ".*=.*;"); assert(files == ["file1.d", "file2.d", "file3.d"]); assert(args == ["program.exe"]); Staying conservative, anonymous options would only be allowed at the end of the option list, because their order matters (unlike named options). Perhaps this can be relaxed with time. -- Tomek
Re: The D Scripting Language
On 11/10/10 3:58 PM, Tomek Sowiński wrote: Andrei Alexandrescu napisał: Speaking of getopt, when writing the 'grep' snippet I missed anonymous options a lot: bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i,&expr,&files); They can be implemented with relatively little effort. Not getting the example. How would anonymous options work? // Let's match assignments. auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"]; bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i,&expr,&files); assert(!h); assert(!i); assert(expr == ".*=.*;"); assert(files == ["file1.d", "file2.d", "file3.d"]); assert(args == ["program.exe"]); Staying conservative, anonymous options would only be allowed at the end of the option list, because their order matters (unlike named options). Perhaps this can be relaxed with time. I still don't see added value over the existing situation. Currently getopt leaves whatever wasn't an option in args[1 .. $] (without shuffling order), so the code above would simply use args[1] for expr and args[2 .. $] for files. Andrei
Re: The D Scripting Language
On Wed, 10 Nov 2010 19:12:26 -0500, Andrei Alexandrescu wrote: On 11/10/10 3:58 PM, Tomek Sowiński wrote: Andrei Alexandrescu napisał: Speaking of getopt, when writing the 'grep' snippet I missed anonymous options a lot: bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i,&expr,&files); They can be implemented with relatively little effort. Not getting the example. How would anonymous options work? // Let's match assignments. auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"]; bool h, i; string expr; string[] files; getopt(args, "h",&h, "i",&i,&expr,&files); assert(!h); assert(!i); assert(expr == ".*=.*;"); assert(files == ["file1.d", "file2.d", "file3.d"]); assert(args == ["program.exe"]); Staying conservative, anonymous options would only be allowed at the end of the option list, because their order matters (unlike named options). Perhaps this can be relaxed with time. I still don't see added value over the existing situation. Currently getopt leaves whatever wasn't an option in args[1 .. $] (without shuffling order), so the code above would simply use args[1] for expr and args[2 .. $] for files. 1. uses same type check/conversion that is used for options 2. Less boilerplate code. For 2, without anonymous options, you either use args[1] everywhere, or you assign args[1] to a variable at the top. To just do it in one line is convenient, I kind of like the idea. -Steve
Re: The D Scripting Language
Perhaps a module std.scripting could help quite a lot, too.
module std.script;
public import std.stdio, std.file, std.process, std.algorithm, ... etc
I use at least some of these for most of my programs/scripts. And
std.all is probably a bit too heavy.
std.script could basically fetch us enough stuff to be on par with
importless python.
Maybe it would be better to just make rdmd to surround source code with:
//- rdmd generated text BEGIN
public import std.stdio, ...
void main( string[] args ){
//- rdmd generated text END
// programmer's code
}
in cases when rdmd detects there is no main()
--
Alexander
Re: The D Scripting Language
Alexander Malakhov Wrote:
>
>
> Perhaps a module std.scripting could help quite a lot, too.
>
>
> >
> > module std.script;
> >
> > public import std.stdio, std.file, std.process, std.algorithm, ... etc
> >
> > I use at least some of these for most of my programs/scripts. And
> > std.all is probably a bit too heavy.
> >
> > std.script could basically fetch us enough stuff to be on par with
> > importless python.
>
> Maybe it would be better to just make rdmd to surround source code with:
>
> //- rdmd generated text BEGIN
> public import std.stdio, ...
>
> void main( string[] args ){
> //- rdmd generated text END
>
> // programmer's code
> }
>
> in cases when rdmd detects there is no main()
No, it could do that in all cases. D supports nested declarations. This is how
the other languages do this. It would improve the score a lot. Did TDPL talk
script programming? We can still change this radically without breaking D2 -
thank god the specification is informal and incomplete.
Re: The D Scripting Language
On 11/11/10 5:50 AM, Alexander Malakhov wrote:
Perhaps a module std.scripting could help quite a lot, too.
module std.script;
public import std.stdio, std.file, std.process, std.algorithm, ... etc
I use at least some of these for most of my programs/scripts. And
std.all is probably a bit too heavy.
std.script could basically fetch us enough stuff to be on par with
importless python.
Maybe it would be better to just make rdmd to surround source code with:
//- rdmd generated text BEGIN
public import std.stdio, ...
void main( string[] args ){
//- rdmd generated text END
// programmer's code
}
in cases when rdmd detects there is no main()
rdmd already does that with --eval and --loop.
http://www.digitalmars.com/d/2.0/rdmd.html
Andrei
Re: The D Scripting Language
Perhaps a module std.scripting could help quite a lot, too. Andrei Also, something I just thought of this morning is to create something similar to std.variant for variables where every variable is the same type. Perl, for example, may store the same value multiple times in the same "structure" (I don't know the right term) depending on if it was used as a number, a string, or both. This can make language easier to use for scripting so that the user doesn't have to worry about data types. For example (Using Foo as the name of the type for lack of a better name): Foo x = 27; x += 15; // X is now 42 Foo y = "X is " ~ x; // Here, x is now treated like a string. The way I figure it, and I could be wrong, this could be stored as a struct with the various op* operations defined to perform the correct operation when called. Also, errors should be reported if, for example, someone tries to add the value "bar" to 13. I think this would be a good first step to making D more scripting friendly, though less efficient in terms of memory and speed. And hopefully this would also work with all of the existing methods that we have, though there are probably a ton of issues related to that. Casey
Re: The D Scripting Language
Steven Schveighoffer napisał: >> I still don't see added value over the existing situation. Currently >> getopt leaves whatever wasn't an option in args[1 .. $] (without >> shuffling order), so the code above would simply use args[1] for expr >> and args[2 .. $] for files. > > 1. uses same type check/conversion that is used for options Yeah, auto args =["numcruncher.exe", "-avg", "-med", "5", "3", "4.5", ".8"]; bool avg, med; double[] numbers; getopt(args, "avg",&avg, "med",&med, &numbers); > 2. Less boilerplate code. > > For 2, without anonymous options, you either use args[1] everywhere, or > you assign args[1] to a variable at the top. To just do it in one line is > convenient, I kind of like the idea. Yes. Why should getopt do just half of the job when it can do most, and for cheap? Again, small implementation effort in the denominator boosts the ROI of this development to lucrative levels. -- Tomek
Re: The D Scripting Language
sybrandy napisał: > Foo x = 27; > > x += 15; // X is now 42 > > Foo y = "X is " ~ x; // Here, x is now treated like a string. std.variant? -- Tomek
Re: The D Scripting Language
Gary Whatmore писал(а) в своём письме Thu, 11 Nov 2010
20:07:35 +0600:
Alexander Malakhov Wrote:
...
Maybe it would be better to just make rdmd to surround source code with:
//- rdmd generated text BEGIN
public import std.stdio, ...
void main( string[] args ){
//- rdmd generated text END
// programmer's code
}
in cases when rdmd detects there is no main()
No, it could do that in all cases. D supports nested declarations. This
is how the other languages do this. It would improve the score a lot.
Did TDPL talk script programming? We can still change this radically
without breaking D2 - thank god the specification is informal and
incomplete.
Then you have 2 issues:
void main(string[] args){
import std.stdio; // 1. will not compile
void main(string[] args){
writeln("hello");
}
main(args); // 2. this should be appended, hence anyway rdmd should
analyze
//if there is main()
}
--
btw, why name is not simply "std.io" ?
--
Alexander
Re: The D Scripting Language
Alexander Malakhov wrote: > import std.stdio; // 1. will not compile I wrote a little rund helper program, and a PHP style D interpreter in another thread a couple days ago, that solves this by a simple string scan. http://arsdnet.net/dcode/rund.d http://arsdnet.net/dcode/dhp.d It scans the code byLine. If the line starts with "import", cut it out and move it to the top of the final file outputted, above main. This would break if you indented the import, or if it was in a string literal or something, but there's a simple solution to that: don't do it! Example of use: $ rund import std.math; writeln(pow(4, 3)); 64 == $ dhp Four to the third power is ! Four to the third power is 64! === You can see the rule at work in the second example. wouldn't have been moved, so I just put a newline on it.
Re: The D Scripting Language
Andrei Alexandrescu писал(а) в своём
письме Thu, 11 Nov 2010 21:12:33 +0600:
On 11/11/10 5:50 AM, Alexander Malakhov wrote:
Maybe it would be better to just make rdmd to surround source code with:
//- rdmd generated text BEGIN
public import std.stdio, ...
void main( string[] args ){
//- rdmd generated text END
// programmer's code
}
in cases when rdmd detects there is no main()
rdmd already does that with --eval and --loop.
http://www.digitalmars.com/d/2.0/rdmd.html
Andrei
I was unable to pass file to --eval, is this possible ?
rdmd --eval=script.d
(16): Error: undefined identifier script
also while I'm here. This works: > rdmd
--eval=writeln("");writeln("");writeln("");
and this don't:
rdmd --eval=writeln("hello")
(16): Error: undefined identifier hello
btw, does --eval make "import std.all" or some set of modules ?
--
Alexander
Re: The D Scripting Language
On 11/12/10 9:21 AM, Alexander Malakhov wrote:
Andrei Alexandrescu писал(а) в своём
письме Thu, 11 Nov 2010 21:12:33 +0600:
On 11/11/10 5:50 AM, Alexander Malakhov wrote:
Maybe it would be better to just make rdmd to surround source code with:
//- rdmd generated text BEGIN
public import std.stdio, ...
void main( string[] args ){
//- rdmd generated text END
// programmer's code
}
in cases when rdmd detects there is no main()
rdmd already does that with --eval and --loop.
http://www.digitalmars.com/d/2.0/rdmd.html
Andrei
I was unable to pass file to --eval, is this possible ?
It is:
rdmd --eval $(cat filename)
I know... it's cheating :o). But if you want to pass a file, why not
just make the file a small program and compile it the classic way?
rdmd --eval=script.d
(16): Error: undefined identifier script
also while I'm here. This works: > rdmd
--eval=writeln("");writeln("");writeln("");
and this don't:
rdmd --eval=writeln("hello")
(16): Error: undefined identifier hello
btw, does --eval make "import std.all" or some set of modules ?
It imports all modules.
Andrei
Re: The D Scripting Language
Adam D. Ruppe писал(а) в своём письме Fri, 12
Nov 2010 23:13:13 +0600:
Alexander Malakhov wrote:
import std.stdio; // 1. will not compile
I wrote a little rund helper program, and a PHP style D interpreter
in another thread a couple days ago, that solves this by a simple
string scan.
http://arsdnet.net/dcode/rund.d
http://arsdnet.net/dcode/dhp.d
It scans the code byLine. If the line starts with "import", cut it out
and move it
to the top of the final file outputted, above main.
This would break if you indented the import, or if it was in a string
literal or
something, but there's a simple solution to that: don't do it!
Example of use:
$ rund
import std.math;
writeln(pow(4, 3));
64
==
$ dhp
Four to the third power is !
Four to the third power is 64!
===
You can see the rule at work in the second example. ?>
wouldn't have been moved, so I just put a newline on it.
Looks nice, especially dhp. But if 2nd problem isn't solved there is no
point in fixing imports
void main(string[] args){
import std.stdio; // 1. will not compile
void main(string[] args){
writeln("hello");
}
main(args); // 2. this should be appended, hence anyway rdmd should
analyze
//if there is main()
}
--
Alexander
Re: The D Scripting Language
Andrei Alexandrescu писал(а) в своём письме Fri, 12 Nov 2010 23:44:18 +0600: On 11/12/10 9:21 AM, Alexander Malakhov wrote: I was unable to pass file to --eval, is this possible ? It is: rdmd --eval $(cat filename) I know... it's cheating :o). But if you want to pass a file, why not just make the file a small program and compile it the classic way? Andrei First of all, I have virtually no exp with scripts, and maybe nobody should listen to my opinion :) I was thinking about 2 things: 1. In many examples from that site "import ... void main" was 50% of the code 2. Make Windows to open .d files with rdmd by default, so I could run them with simple double-click -- Alexander
Re: The D Scripting Language
2. Make Windows to open .d files with rdmd by default, so I could run them with simple double-click You should be able to do this yourself quite easily by right-clicking on the D file and associating it with rdmd. I'd give better instructions except I'm not on a Windows machine right now. Casey
Re: The D Scripting Language
On 12/11/2010 19:42, sybrandy wrote: 2. Make Windows to open .d files with rdmd by default, so I could run them with simple double-click You should be able to do this yourself quite easily by right-clicking on the D file and associating it with rdmd. I'd give better instructions except I'm not on a Windows machine right now. Casey Yes you can do it yourself, but if you want it to work seamlessly, DMD would need an installer to set-up that registration. Can't say I'm in favour of it; windows has enough security holes as it is, without allowing a powerful compiler to kick off with an inadvertent click. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: The D Scripting Language
On 11/12/10 11:42 AM, sybrandy wrote: 2. Make Windows to open .d files with rdmd by default, so I could run them with simple double-click You should be able to do this yourself quite easily by right-clicking on the D file and associating it with rdmd. I'd give better instructions except I'm not on a Windows machine right now. Casey Would be nice if the installer took care of that though. Andrei
Re: The D Scripting Language
2010/11/12 div0 > On 12/11/2010 19:42, sybrandy wrote: > >> 2. Make Windows to open .d files with rdmd by default, so I could run >>> them >>> with simple double-click >>> >>> >> You should be able to do this yourself quite easily by right-clicking on >> the D file and associating it with rdmd. I'd give better instructions >> except I'm not on a Windows machine right now. >> >> Casey >> > > Yes you can do it yourself, but if you want it to work seamlessly, DMD > would need an installer to set-up that registration. > > Can't say I'm in favour of it; windows has enough security holes as it is, > without allowing a powerful compiler to kick off with an inadvertent click. That sounds good until you think of comparable situations. Python does this, Perl does this, heck, if allowing powerful things to start with an inadvertent click, why do we have batch files? Why do we have executables? Being able to run things by clicking on them is a feature, not a security hole. It only becomes a security hole when the user doesn't watch what they click. The tradeoff between convenience and protection there hasn't ever been considered because the protection definitely isn't worth the inconvenience of having to start everything from a command prompt. Andrew Wiley
Re: The D Scripting Language
On 11/12/2010 03:06 PM, div0 wrote: On 12/11/2010 19:42, sybrandy wrote: 2. Make Windows to open .d files with rdmd by default, so I could run them with simple double-click You should be able to do this yourself quite easily by right-clicking on the D file and associating it with rdmd. I'd give better instructions except I'm not on a Windows machine right now. Casey Yes you can do it yourself, but if you want it to work seamlessly, DMD would need an installer to set-up that registration. Can't say I'm in favour of it; windows has enough security holes as it is, without allowing a powerful compiler to kick off with an inadvertent click. True...I'm not a fan of having the OS do things beyond my control. Hell, I complained to my current company's tech support one time because they installed new software and I didn't know about it. I told them that I thought it was a virus! Of course, I just may be a control freak when it comes to computers I use. Casey
Re: The D Scripting Language
That sounds good until you think of comparable situations. Python does this, Perl does this, heck, if allowing powerful things to start with an inadvertent click, why do we have batch files? Why do we have executables? Being able to run things by clicking on them is a feature, not a security hole. It only becomes a security hole when the user doesn't watch what they click. The tradeoff between convenience and protection there hasn't ever been considered because the protection definitely isn't worth the inconvenience of having to start everything from a command prompt. Andrew Wiley I fully understand and agree with your point. It's all about how much power does a user really need so that they don't shoot themselves in the foot and does the user know what is on their system. The scenario that concerns me is the user double-clicking on some unknown file (E.g. one that ends with .d in this case) and it doing something unexpected. In other words, they may expect it to open in a viewer or editor vs. performing some operation to a set of files. However, this isn't the fault of the installer, though the installer can help by making the association optional. For example, if I'm sharing a computer with someone who's not technical, it may be better that I do not have that association in place as I'm comfortable with running files from the command line and I don't trust the other user to not double-click on a file that they shouldn't. Of course, I prefer to use double-click to open the file in Vim vs. executing it. Having the option to not set the association would keep me from executing files when I want to edit them. Casey
Re: The D Scripting Language
Fri, 12 Nov 2010 23:01:24 +0600, Alexander Malakhov wrote:
> Gary Whatmore писал(а) в своём письме Thu, 11 Nov 2010
> 20:07:35 +0600:
>
>> Alexander Malakhov Wrote:
>>> ...
>>> Maybe it would be better to just make rdmd to surround source code
>>> with:
>>>
>>> //- rdmd generated text BEGIN
>>> public import std.stdio, ...
>>>
>>> void main( string[] args ){
>>> //- rdmd generated text END
>>>
>>> // programmer's code
>>> }
>>>
>>> in cases when rdmd detects there is no main()
>>
>> No, it could do that in all cases. D supports nested declarations. This
>> is how the other languages do this. It would improve the score a lot.
>> Did TDPL talk script programming? We can still change this radically
>> without breaking D2 - thank god the specification is informal and
>> incomplete.
>
> Then you have 2 issues:
>
> void main(string[] args){
>
> import std.stdio; // 1. will not compile void main(string[] args){
> writeln("hello");
> }
>
> main(args); // 2. this should be appended, hence anyway rdmd
should
> analyze
> //if there is main()
> }
I don't have any opinion of this, but the 1) point make me ask, why
imports can't be used inside methods just like in Scala. There's no
technical reason other than "this adds bugs!" - at least no scientific
research can prove this since Scala hasn't been in wide use that long.
Re: The D Scripting Language
On Fri, 12 Nov 2010 14:42:38 -0500 sybrandy wrote: > > 2. Make Windows to open .d files with rdmd by default, so I could run them > > with simple double-click > > > > You should be able to do this yourself quite easily by right-clicking on > the D file and associating it with rdmd. I'd give better instructions > except I'm not on a Windows machine right now. > -- > Casey Yes. Maybe Alexander meant this for users rather than for developpers. The association should then be set during install of the compiler, I guess (but I actually have no idea how this is supposed to be done -- just know that some apps installers do this: set their own file associations -- which by the way is pretty annoying when you don't want eg an image viewer to "hijack" all image file formats). Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: The D Scripting Language
On 11/13/2010 05:15 AM, spir wrote: On Fri, 12 Nov 2010 14:42:38 -0500 sybrandy wrote: 2. Make Windows to open .d files with rdmd by default, so I could run them with simple double-click You should be able to do this yourself quite easily by right-clicking on the D file and associating it with rdmd. I'd give better instructions except I'm not on a Windows machine right now. -- Casey Yes. Maybe Alexander meant this for users rather than for developpers. The association should then be set during install of the compiler, I guess (but I actually have no idea how this is supposed to be done -- just know that some apps installers do this: set their own file associations -- which by the way is pretty annoying when you don't want eg an image viewer to "hijack" all image file formats). Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com The nice thing is many installers will ask before they mess things up. In all honesty, I was just trying to help him out. I didn't realize my answer would open up so much discussion! Casey
Re: The D Scripting Language
On Sat, Nov 13, 2010 at 4:15 AM, spir wrote: > On Fri, 12 Nov 2010 14:42:38 -0500 > sybrandy wrote: > > > > 2. Make Windows to open .d files with rdmd by default, so I could run > them > > > with simple double-click > > > > > > > You should be able to do this yourself quite easily by right-clicking on > > the D file and associating it with rdmd. I'd give better instructions > > except I'm not on a Windows machine right now. > > -- > > Casey > > Yes. Maybe Alexander meant this for users rather than for developpers. The > association should then be set during install of the compiler, I guess (but > I actually have no idea how this is supposed to be done -- just know that > some apps installers do this: set their own file associations -- which by > the way is pretty annoying when you don't want eg an image viewer to > "hijack" all image file formats). > > Denis > -- -- -- -- -- -- -- > vit esse estrany ☣ > > spir.wikidot.com > > If I remember correctly, the dinstaller is built using the Nullsoft Scriptable Install System (NSIS), and adding file associations to the installer is simple and documented.
Re: The D Scripting Language
retard, el 13 de noviembre a las 08:24 me escribiste:
> > void main(string[] args){
> >
> > import std.stdio; // 1. will not compile void main(string[] args){
> > writeln("hello");
> > }
> >
> > main(args); // 2. this should be appended, hence anyway rdmd
> should
> > analyze
> > //if there is main()
> > }
>
> I don't have any opinion of this, but the 1) point make me ask, why
> imports can't be used inside methods just like in Scala. There's no
> technical reason other than "this adds bugs!" - at least no scientific
> research can prove this since Scala hasn't been in wide use that long.
Python allows that too, that's why I opened an enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=3506
As the bugzilla issue shows, this is particularly annoying when combined
with unittest.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Hoy estuvimos en el museo de antropología, pero yo voy a volver
para estar por lo menos un día ahí adentro... es una locura, como Disney pero
de indigenas
-- Carla Lucarella (10/2008 contando de su viaje a México)
Re: The D Scripting Language
Leandro Lucarella писал(а) в своём письме Sat, 13 Nov
2010 21:13:42 +0600:
retard, el 13 de noviembre a las 08:24 me escribiste:
> void main(string[] args){
>
> import std.stdio; // 1. will not compile> void main(string[]
args){
>writeln("hello");
>}
<...> the 1) point make me ask, why
imports can't be used inside methods just like in Scala. There's no
technical reason other than "this adds bugs!"
Maybe it will somehow affect compile time or complicate module dependency
analysis ?
Python allows that too, that's why I opened an enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=3506
As the bugzilla issue shows, this is particularly annoying when combined
with unittest.
Even if there are technical issues, special case for unit tests sounds
like a good improvement of usability
--
Alexander
Re: The D Scripting Language
On 2010-11-14 13:40, Alexander Malakhov wrote: Even if there are technical issues, special case for unit tests sounds like a good improvement of usability Another thing that comes to mind about things not allowed in unittest scope that could facilitate unit testing: defining templates. -- Per Å.
Re: The D Scripting Language
spir писал(а) в своём письме Sat, 13 Nov 2010
16:15:39 +0600:
On Fri, 12 Nov 2010 14:42:38 -0500
sybrandy wrote:
> 2. Make Windows to open .d files with rdmd by default, so I could run
them with simple double-click
Yes. Maybe Alexander meant this for users rather than for developpers.
The association should then be set during install of the compiler, I
guess (but I actually have no idea how this is supposed to be done --
just know that some apps installers do this: set their own file
associations -- which by the way is pretty annoying when you don't want
eg an image viewer to "hijack" all image file formats).
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
With my point 2 I meant that I want to __have an option__ to run .d with
rdmd, of course
It would certainly be much simpler for users. I'm in-house programmer, and
actually it's not even an option to make any user from financial
department to run anything from command line (most likely they will forget
how to do this in a couple weeks)
My main idea was a little different, though: to be able to write short
scripts ("import"- and "main()"-less, like with rdmd --eval) AND to run
them easily.
Then, if I need smth like 30-liner for some files manipulation and if I'm
proficient with D, I would go with D instead of .bat.
I have never used scripting for anything except this stuff, so I can't
come up with better example.
You should be able to do this yourself quite easily by right-clicking on
the D file and associating it with rdmd. I'd give better instructions
except I'm not on a Windows machine right now.
Yeah, that's really easy (roughly translated from russian win7):
1. right click on .d file (shift + right-click on XP, IIRC)
2. "Open with..."
3. "Choose Program"
4. find rdmd.exe (default is C:\D\dmd2\windows\bin)
5. check "Use this program with all files of this type" box
--
Alexander
Re: The D Scripting Language
On 2010-11-07 22:29, Tomek Sowiński wrote:
This wraps up a thread from a few days ago. Pascal featured my D
examples on his Scriptometer site.
http://rigaux.org/language-study/scripting-language/
D comes 17th out of 28, so it's so-so for scripting.
I'm wondering whether the issue of D's or-expression, compared to that
of languages such as Perl and Ruby, has been discussed and dismissed.
Personally, I was a bit disappointed to learn that D had such a
traditional or-expression, seeing how much it is willing to improve over
C/C++ in other areas.
I think the following code summarizes the issue. I'm not a language
lawyer, so maybe the rules could be described more succinctly, but I
think you'll get my drift. I'm aware that with D being a typed and
compiled language, there has to a be a restriction that both
sub-expressions must be convertible to a common type, but I'm sure that
can be worked out somehow.
string func(string s)
{
/++
// A handy feature of many scripting languages, but not in D
// (in D, the type of the or-expression is bool):
// The type of the or-expression is the type of the first
// sub-expression that evaluates to true.
return s || "default";
+/
// The D equivalent, arguably more readable but also more verbose:
return s ? s : "default";
}
void main()
{
assert(func("a") == "a");
assert(func(null) == "default");
}
--
Per Å.
Re: The D Scripting Language
On Mon, 15 Nov 2010 13:15:50 +0100
Per Ångström wrote:
> On 2010-11-07 22:29, Tomek Sowiński wrote:
> > This wraps up a thread from a few days ago. Pascal featured my D
> > examples on his Scriptometer site.
> >
> > http://rigaux.org/language-study/scripting-language/
> >
> > D comes 17th out of 28, so it's so-so for scripting.
> >
> I'm wondering whether the issue of D's or-expression, compared to that
> of languages such as Perl and Ruby, has been discussed and dismissed.
>
> Personally, I was a bit disappointed to learn that D had such a
> traditional or-expression, seeing how much it is willing to improve over
> C/C++ in other areas.
>
> I think the following code summarizes the issue. I'm not a language
> lawyer, so maybe the rules could be described more succinctly, but I
> think you'll get my drift. I'm aware that with D being a typed and
> compiled language, there has to a be a restriction that both
> sub-expressions must be convertible to a common type, but I'm sure that
> can be worked out somehow.
>
> string func(string s)
> {
> /++
> // A handy feature of many scripting languages, but not in D
> // (in D, the type of the or-expression is bool):
> // The type of the or-expression is the type of the first
> // sub-expression that evaluates to true.
> return s || "default";
> +/
> // The D equivalent, arguably more readable but also more verbose:
> return s ? s : "default";
> }
More verbose?
Real programmers *want* to type 3 more characters when this makes code
clearer!
;-)
I read once that professional programmers produce about one dozen lines of
effective code per day. Let us say they actually write three times more, by
editing and/or recoding. How much time & effort is typing 36 lines of code?
Maybe it's just me: I find nearly all complains about verbosity simply
ridiculous. Programmers spend 49% of their time thinking about the model, 49%
controlling their code, the rest typing.
I *want* my language of choice to let me write clear code -- this is by far the
most important task of a language designer, and cost in terms of number of
characters is hardly even a side-issue. All major problems around software come
from the extreme difficulty of understanding.
Also: that logical expressions do not return logical values (read: bools) is
arguably semantic mismatch (that necessarily hurts newcomers). I even find Lua's
if x then doSomethingWith(x)
borderline (here "x" is shortcut for "x != nil").
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: The D Scripting Language
spir: > I *want* my language of choice to let me write clear code -- During the design stages of Python3 I've even asked to remove those dirty boolean shortcuts of Python2 :-) Bye, bearophile
Re: The D Scripting Language
On 2010-11-15 14:27, spir wrote:
On Mon, 15 Nov 2010 13:15:50 +0100
Per Ångström wrote:
string func(string s)
{
/++
// A handy feature of many scripting languages, but not in D
// (in D, the type of the or-expression is bool):
// The type of the or-expression is the type of the first
// sub-expression that evaluates to true.
return s || "default";
+/
// The D equivalent, arguably more readable but also more verbose:
return s ? s : "default";
}
More verbose?
Real programmers *want* to type 3 more characters when this makes code
clearer!
;-)
Verbosity is not only about more code to type, it's also about more code
to read. My example was brief so of course that difference is
negligible. Here's a somewhat more complex example which forces a
trade-off between an extra temporary variable, evaluating the same
expression twice or using a template:
/++
Simulates type-returning or-expression
+/
template or(T) {
T _(T a, lazy T b) {T tmp = a; return tmp ? tmp : b;}
}
void m() {
/+ least verbose, invalid D:
string s = func("...") || "default";
+/
/+ valid D, but requires extra temp variable:
string tmp = func("...");
string s = tmp ? tmp : "default";
+/
/+ valid D, no temp variable but two (hopefully idempotent)
function calls:
string s = func("...") ? func(".,.") : "default";
+/
// valid D, but arguably ugly:
string s = or!string._(func("..."), "default");
}
--
Per Å.
Re: The D Scripting Language
Per Ångström wrote:
/++
Simulates type-returning or-expression
+/
template or(T) {
T _(T a, lazy T b) {T tmp = a; return tmp ? tmp : b;}
}
You should probably use a function template[1] or at least an eponymous
template here:
// function template:
auto or( T )( T a, lazy T b ) {
return a ? a : b;
}
// eponymous template:
template or( T ) {
auto or( T a, lazy T b ) {
return a ? a : b;
}
}
[1]: http://digitalmars.com/d/2.0/template.html#function-templates
--
Simen
Re: The D Scripting Language
On 2010-11-15 18:40, Simen kjaeraas wrote:
Per Ångström wrote:
/++
Simulates type-returning or-expression
+/
template or(T) {
T _(T a, lazy T b) {T tmp = a; return tmp ? tmp : b;}
}
You should probably use a function template[1] or at least an eponymous
template here:
// function template:
auto or( T )( T a, lazy T b ) {
return a ? a : b;
}
// eponymous template:
template or( T ) {
auto or( T a, lazy T b ) {
return a ? a : b;
}
}
[1]: http://digitalmars.com/d/2.0/template.html#function-templates
Great, using either of those makes this possible:
string s = or(func2("..."), "default");
Which is a lot less ugly.
Cheers,
--
Per Å.
Re: The D Scripting Language
"Per Ångström" wrote in message news:ibr8bs$22m...@digitalmars.com... > return s || "default"; I think allowing the second expression in the ternary operator to be omitted would be a better fit for D, and provide the same function. ie. auto x = a ? a : b; auto x = a ? : b; I think bearophile might have already proposed this?
Re: The D Scripting Language
On 2010-11-16 01:10, Daniel Murphy wrote: I think allowing the second expression in the ternary operator to be omitted would be a better fit for D, and provide the same function. ie. auto x = a ? a : b; auto x = a ? : b; Personally I had '|||' in mind, but I'm OK with '?:'. I think it should be one single token and not an extension of the tertiary operator, though: auto x = condition ? a : b; // tertiary operator auto x = condition ? : b; // error, did you forget the middle operand? auto x = a ?: b; // OK -- Cheers, Per Å.
Re: The D Scripting Language
On Tue, 16 Nov 2010 09:44:06 +0100 Per Ångström wrote: > On 2010-11-16 01:10, Daniel Murphy wrote: > > I think allowing the second expression in the ternary operator to be omitted > > would be a better fit for D, and provide the same function. > > > > ie. > > auto x = a ? a : b; > > auto x = a ? : b; > > Personally I had '|||' in mind, but I'm OK with '?:'. I think it should > be one single token and not an extension of the tertiary operator, though: > > auto x = condition ? a : b; // tertiary operator > auto x = condition ? : b; // error, did you forget the middle operand? > auto x = a ?: b; // OK Yes, then it becomes a binary operator :-) Read "a if defined, else b". Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: The D Scripting Language
Daniel Murphy, el 16 de noviembre a las 10:10 me escribiste: > "Per �ngstr�m" wrote in message > news:ibr8bs$22m...@digitalmars.com... > > return s || "default"; > > I think allowing the second expression in the ternary operator to be omitted > would be a better fit for D, and provide the same function. > > ie. > auto x = a ? a : b; > auto x = a ? : b; > > I think bearophile might have already proposed this? Yes, the "elvis operator" ?: -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Sometimes I think the sure sign that life exists elsewhere in the universe Is that that none of them tried to contact us
Re: The D Scripting Language
"Script mode" (actually - simple wrapper) would be better:
It could do simple parsing of script, bringing all "import" clauses to
the beginning and add some default imports (like std.stdio). It seems
that all code below imports can be wrapped into main declaration. So
for
writeln("hello, world!");
we get
import std.stdio;
int main(char[] argv) {
writeln("hello, world!");
return 0;
}
Trick will be to intercept error messages and change line numbers in
them to correct.
2010/11/16 gooba :
> spir Wrote:
>
>> On Tue, 16 Nov 2010 09:44:06 +0100
>> Per Ångström wrote:
>>
>> > On 2010-11-16 01:10, Daniel Murphy wrote:
>> > > I think allowing the second expression in the ternary operator to be
>> > > omitted
>> > > would be a better fit for D, and provide the same function.
>> > >
>> > > ie.
>> > > auto x = a ? a : b;
>> > > auto x = a ? : b;
>> >
>> > Personally I had '|||' in mind, but I'm OK with '?:'. I think it should
>> > be one single token and not an extension of the tertiary operator, though:
>> >
>> > auto x = condition ? a : b; // tertiary operator
>> > auto x = condition ? : b; // error, did you forget the middle operand?
>> > auto x = a ?: b; // OK
>>
>> Yes, then it becomes a binary operator :-) Read "a if defined, else b".
>>
>>
>> Denis
>> -- -- -- -- -- -- --
>> vit esse estrany ☣
>>
>> spir.wikidot.com
>>
>
> They now added Scala to scriptometer
> http://rigaux.org/language-study/scripting-language/ it sees abomination i/o
> classes don't stop it being better script language then d. What can do? Scala
> bad competition and straight better. Next release has std.script?
>
--
С уважением,
Алексей Хмара
Re: The D Scripting Language
> "Script mode" (actually - simple wrapper) would be better: > It could do simple parsing of script, bringing all "import" > clauses to the beginning and add some default imports > (like std.stdio). It seems that all code below imports can be > wrapped into main declaration. My rund.d program does this. http://arsdnet.net/dcode/rund.d As you can see, it's a trivial program.
Re: The D Scripting Language
I really think that it would be good to ship something like this with dmd and promote it default "D script" handler. May be, parsing must be more complicated (I'm not sure that all features will work inside main()), but as D is easy for parsing I see no big problems.Of cource, we can add more complicated code wrapper - for example, something that will give null when trying to get non-existant arg, or default key hadling, or something else. Of cource, special module also could be useful for this purpose. Hmm, it's interesting to write this toy... Compiled language being as easy as script at least looks interesting, so this can help to promote D with minimal resources involved. 2010/11/16 Adam Ruppe : >> "Script mode" (actually - simple wrapper) would be better: >> It could do simple parsing of script, bringing all "import" >> clauses to the beginning and add some default imports >> (like std.stdio). It seems that all code below imports can be >> wrapped into main declaration. > > My rund.d program does this. > > http://arsdnet.net/dcode/rund.d > > As you can see, it's a trivial program. > -- С уважением, Алексей Хмара
Re: The D Scripting Language
spir Wrote: > On Tue, 16 Nov 2010 09:44:06 +0100 > Per à ngström wrote: > > > On 2010-11-16 01:10, Daniel Murphy wrote: > > > I think allowing the second expression in the ternary operator to be > > > omitted > > > would be a better fit for D, and provide the same function. > > > > > > ie. > > > auto x = a ? a : b; > > > auto x = a ? : b; > > > > Personally I had '|||' in mind, but I'm OK with '?:'. I think it should > > be one single token and not an extension of the tertiary operator, though: > > > > auto x = condition ? a : b; // tertiary operator > > auto x = condition ? : b; // error, did you forget the middle operand? > > auto x = a ?: b; // OK > > Yes, then it becomes a binary operator :-) Read "a if defined, else b". > > > Denis > -- -- -- -- -- -- -- > vit esse estrany ⣠> > spir.wikidot.com > They now added Scala to scriptometer http://rigaux.org/language-study/scripting-language/ it sees abomination i/o classes don't stop it being better script language then d. What can do? Scala bad competition and straight better. Next release has std.script?
Re: The D Scripting Language
By the way, I found a bug that I think is quite serious if DMD wants to
hit the scripting languages world:
http://d.puremagic.com/issues/show_bug.cgi?id=5243
Copied for convenience:
dmd -run potentially removes user files
See this example:
$ mkdir x
$ echo 'void main() {}' > x/test.d
$ echo "my very important data that shouldn't be ereased" > test
$ ls test
test
$ cat test
my very important data that shouldn't be ereased
$ dmd -run x/test.d
$ ls test
ls: cannot access test: No such file or directory
$ cat test
cat: test: No such file or directory
I think this is a very serious bug. It's really unexpected that DMD
removes the test file (I can understand why it happens, but it
shouldn't). test.d being in another directory is just to point how much
surprising could be that running a "script" in an unrelated directory
removes files in the current directory.
If DMD wants to put D in the scripting world, this should be fixed ASAP,
as no scripting language EVER will remove your files unexpectedly.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
SATANAS EN COMISARIA
-- Crónica TV
Re: The D Scripting Language
On 07/11/2010 21:29, Tomek Sowiński wrote: This wraps up a thread from a few days ago. Pascal featured my D examples on his Scriptometer site. http://rigaux.org/language-study/scripting-language/ D comes 17th out of 28, so it's so-so for scripting. Hum, nice, I think this is a very interesting benchmark/metric. -- Bruno Medeiros - Software Engineer
Re: The D Scripting Language
On 11/11/2010 13:50, Alexander Malakhov wrote:
Perhaps a module std.scripting could help quite a lot, too.
module std.script;
public import std.stdio, std.file, std.process, std.algorithm, ... etc
I use at least some of these for most of my programs/scripts. And
std.all is probably a bit too heavy.
std.script could basically fetch us enough stuff to be on par with
importless python.
Maybe it would be better to just make rdmd to surround source code with:
//- rdmd generated text BEGIN
public import std.stdio, ...
void main( string[] args ){
//- rdmd generated text END
// programmer's code
}
in cases when rdmd detects there is no main()
I think that if one wants to add to D tools additional semantics such as
that one (automatically add main, imports, etc., for scripting), it
would be nice to define a new file extension like ".ds", ".dscript",
whatever, for such files, just to make this clearer and more separate.
--
Bruno Medeiros - Software Engineer
the D scripting language -- command line
[started separate thread]
On Thu, 11 Nov 2010 00:58:31 +0100
Tomek Sowiński wrote:
> Andrei Alexandrescu napisał:
>
> >> Speaking of getopt, when writing the 'grep' snippet I missed anonymous
> >> options a lot:
> >>
> >> bool h, i; string expr; string[] files;
> >> getopt(args, "h",&h, "i",&i,&expr,&files);
> >>
> >> They can be implemented with relatively little effort.
> >
> > Not getting the example. How would anonymous options work?
>
> // Let's match assignments.
> auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"];
> bool h, i; string expr; string[] files;
> getopt(args, "h",&h, "i",&i, &expr, &files);
> assert(!h);
> assert(!i);
> assert(expr == ".*=.*;");
> assert(files == ["file1.d", "file2.d", "file3.d"]);
> assert(args == ["program.exe"]);
>
> Staying conservative, anonymous options would only be allowed at the end of
> the
> option list, because their order matters (unlike named options). Perhaps this
> can
> be relaxed with time.
I thought once at a default interface between the command-line and a program's
startup routine, main(). The idea would be for main to have parameters
automagically fed from whatever the user provides. With a command-line syntax
inspired by named func call. It lets the program itself be called more or less
like a func, via program-level parameter definition:
// program "findword"
int main (string filename, string word, bool verbose=false) {...}
// use it
$ findword filename=foo.txt word=foo verbose=true
Parameters having default value can indeed be omitted by the user. Optionally,
the first arg (often corresponding to the "object" on which a command applies,
like the receiver in OO, and thus usually "obvious") can be automatically
mapped to the first param of main:
$ findword foo.txt word=foo
This is, indeed, a language-specific feature. On the other hand, it brings to
the user consistent program-call format -- rather than each program defining
its own. Maybe after sometime the same syntax trick and syntax would adopted by
other languages.
I find this very coool on the programmer side as well. It must indeed by
implemented in the language('s runtime) itself. To have such a feature without
breaking any code, a possibility may be to use a different name than "main", eg
"script".
(I guess such a feature would make some difference in judging a language's
adequacy to scripting.)
What do you think?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: the D scripting language -- command line
spir Wrote:
> [started separate thread]
>
> On Thu, 11 Nov 2010 00:58:31 +0100
> Tomek SowiÅski wrote:
>
> > Andrei Alexandrescu napisaÅ:
> >
> > >> Speaking of getopt, when writing the 'grep' snippet I missed anonymous
> > >> options a lot:
> > >>
> > >> bool h, i; string expr; string[] files;
> > >> getopt(args, "h",&h, "i",&i,&expr,&files);
> > >>
> > >> They can be implemented with relatively little effort.
> > >
> > > Not getting the example. How would anonymous options work?
> >
> > // Let's match assignments.
> > auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"];
> > bool h, i; string expr; string[] files;
> > getopt(args, "h",&h, "i",&i, &expr, &files);
> > assert(!h);
> > assert(!i);
> > assert(expr == ".*=.*;");
> > assert(files == ["file1.d", "file2.d", "file3.d"]);
> > assert(args == ["program.exe"]);
> >
> > Staying conservative, anonymous options would only be allowed at the end of
> > the
> > option list, because their order matters (unlike named options). Perhaps
> > this can
> > be relaxed with time.
>
> I thought once at a default interface between the command-line and a
> program's startup routine, main(). The idea would be for main to have
> parameters automagically fed from whatever the user provides. With a
> command-line syntax inspired by named func call. It lets the program itself
> be called more or less like a func, via program-level parameter definition:
>
> // program "findword"
> int main (string filename, string word, bool verbose=false) {...}
>
> // use it
> $ findword filename=foo.txt word=foo verbose=true
>
> Parameters having default value can indeed be omitted by the user.
> Optionally, the first arg (often corresponding to the "object" on which a
> command applies, like the receiver in OO, and thus usually "obvious") can be
> automatically mapped to the first param of main:
>
> $ findword foo.txt word=foo
>
> This is, indeed, a language-specific feature. On the other hand, it brings to
> the user consistent program-call format -- rather than each program defining
> its own. Maybe after sometime the same syntax trick and syntax would adopted
> by other languages.
> I find this very coool on the programmer side as well. It must indeed by
> implemented in the language('s runtime) itself. To have such a feature
> without breaking any code, a possibility may be to use a different name than
> "main", eg "script".
> (I guess such a feature would make some difference in judging a language's
> adequacy to scripting.)
>
> What do you think?
That's a nifty feature.
I took a look at the scriptometer page. It looks like if more real scripting
languages are coming there (one or two more), D will be out from the top-20.
The script library and shortcuts are badly needed. D isn't (yet) even the best
static compiled language in the test. At least two Java/JVM languages beat D
and it doesn't yet even have the super tight Groovy. It's also still missing
Clojure, Io, Factor, and those other "tight" languages.
Looking bad without a dedicated library. The library might be good to contain
features 'sed', 'grep', and fill the namespace with name globals. std.s sounds
like a good name.
Re: the D scripting language -- command line
ruben niemann Wrote:
> spir Wrote:
>
> > [started separate thread]
> >
> > On Thu, 11 Nov 2010 00:58:31 +0100
> > Tomek SowiÅski wrote:
> >
> > > Andrei Alexandrescu napisaÅ:
> > >
> > > >> Speaking of getopt, when writing the 'grep' snippet I missed anonymous
> > > >> options a lot:
> > > >>
> > > >> bool h, i; string expr; string[] files;
> > > >> getopt(args, "h",&h, "i",&i,&expr,&files);
> > > >>
> > > >> They can be implemented with relatively little effort.
> > > >
> > > > Not getting the example. How would anonymous options work?
> > >
> > > // Let's match assignments.
> > > auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"];
> > > bool h, i; string expr; string[] files;
> > > getopt(args, "h",&h, "i",&i, &expr, &files);
> > > assert(!h);
> > > assert(!i);
> > > assert(expr == ".*=.*;");
> > > assert(files == ["file1.d", "file2.d", "file3.d"]);
> > > assert(args == ["program.exe"]);
> > >
> > > Staying conservative, anonymous options would only be allowed at the end
> > > of the
> > > option list, because their order matters (unlike named options). Perhaps
> > > this can
> > > be relaxed with time.
> >
> > I thought once at a default interface between the command-line and a
> > program's startup routine, main(). The idea would be for main to have
> > parameters automagically fed from whatever the user provides. With a
> > command-line syntax inspired by named func call. It lets the program itself
> > be called more or less like a func, via program-level parameter definition:
> >
> > // program "findword"
> > int main (string filename, string word, bool verbose=false) {...}
> >
> > // use it
> > $ findword filename=foo.txt word=foo verbose=true
> >
> > Parameters having default value can indeed be omitted by the user.
> > Optionally, the first arg (often corresponding to the "object" on which a
> > command applies, like the receiver in OO, and thus usually "obvious") can
> > be automatically mapped to the first param of main:
> >
> > $ findword foo.txt word=foo
> >
> > This is, indeed, a language-specific feature. On the other hand, it brings
> > to the user consistent program-call format -- rather than each program
> > defining its own. Maybe after sometime the same syntax trick and syntax
> > would adopted by other languages.
> > I find this very coool on the programmer side as well. It must indeed by
> > implemented in the language('s runtime) itself. To have such a feature
> > without breaking any code, a possibility may be to use a different name
> > than "main", eg "script".
> > (I guess such a feature would make some difference in judging a language's
> > adequacy to scripting.)
> >
> > What do you think?
>
> That's a nifty feature.
>
> I took a look at the scriptometer page. It looks like if more real scripting
> languages are coming there (one or two more), D will be out from the top-20.
> The script library and shortcuts are badly needed. D isn't (yet) even the
> best static compiled language in the test. At least two Java/JVM languages
> beat D and it doesn't yet even have the super tight Groovy. It's also still
> missing Clojure, Io, Factor, and those other "tight" languages.
>
> Looking bad without a dedicated library. The library might be good to contain
> features 'sed', 'grep', and fill the namespace with name globals. std.s
> sounds like a good name.
Indeed. The many feces of d doesnt include sop " script oriented prog...
Re: the D scripting language -- command line
spir wrote:
> I thought once at a default interface between the command-line and a
> program's startup routine, main().
We could actually do this with a mixin.
==
int findword (string filename, string word, bool verbose=false) {...}
mixin MakeMain!(findword);
==
And that MakeMain template reads the arguments off findword() and creates a
traditional main() that translates its args into the needed arguments of the
function.
I actually wrote something that does this already, though my goal was to
automate
the creation of web apps, it also (used to - I broke it in my last revision)
works
for command line programs.
http://arsdnet.net/dcode/web.d
See it in action with an example. Given this function:
void addTopicToForum(int topicId, int forumId) {
assert(0, "not implemented");
}
We get this page:
http://arsdnet.net/cgi-bin/forum/add-topic-to-forum?topicId=10
>From just the function signature, it creates a form, populating it with all the
arguments given on the URL, asking the user for the rest. If you give it all the
arguments needed up front, it just skips to executing the function.
The command line interface worked basically the same way.
$ ./forum forumId=30 topidId=10
Assert error: not implemented
But when adding support for array arguments in CGI, I broke the command line
reader so I commented it out and haven't gotten back to fixing it yet.
While my code is based on taking a struct to the make main mixin, so it can do
multiple functions at once, it'd be pretty easy to modify it to just take one
function directly too.
You're free to take it and do whatever you want with it if you're interested.
Re: the D scripting language -- command line
On Thu, 11 Nov 2010 13:45:33 +, Adam Ruppe wrote: > I actually wrote something that does this already, though my goal was to > automate the creation of web apps, it also (used to - I broke it in my > last revision) works for command line programs. > > http://arsdnet.net/dcode/web.d > > [...] I briefly browsed through some of your modules now, and the web stuff (cgi, dom, web) is very interesting. I was actually looking for something like your CGI module just the other day. Have you ever considered cleaning it up and publishing it as a web app library for D, either on dsource or somewhere similar? -Lars
Re: the D scripting language -- command line
Lars T. Kyllingstad wrote: > Have you ever considered cleaning it up and publishing it as > a web app library for D, either on dsource or somewhere similar? Yes, I'd like to do that eventually, but haven't gotten around to it yet. You can see, looking through the code, that I've been lax on documentation and there's a lot of half-baked things in there still. (Even some of the solider things feel incomplete to me, though I'm happy with it. For example, my mysql.d file always returns results as strings, so the client code has to check and convert data types without the help of the column info or anything like that. While it seems like it should be a tagged variant or something like that, using the raw strings has been so easy that I don't care to change it. int a = to!int(line[1]); is remarkably simple.) But, yeah, publishing it is the ultimate goal but I've gotta find the time to at least document it a little better first.
Re: the D scripting language -- command line
spir napisał:
>> // Let's match assignments.
>> auto args = ["program.exe", ".*=.*;", "file1.d", "file2.d", "file3.d"];
>> bool h, i; string expr; string[] files;
>> getopt(args, "h",&h, "i",&i, &expr, &files);
>> assert(!h);
>> assert(!i);
>> assert(expr == ".*=.*;");
>> assert(files == ["file1.d", "file2.d", "file3.d"]);
>> assert(args == ["program.exe"]);
>>
>> Staying conservative, anonymous options would only be allowed at the end
>> of the option list, because their order matters (unlike named options).
>> Perhaps this can be relaxed with time.
>
> I thought once at a default interface between the command-line and a
> program's startup routine, main(). The idea would be for main to have
> parameters automagically fed from whatever the user provides. With a
> command-line syntax inspired by named func call. It lets the program
> itself be called more or less like a func, via program-level parameter
> definition:
>
> // program "findword"
> int main (string filename, string word, bool verbose=false) {...}
>
> // use it
> $ findword filename=foo.txt word=foo verbose=true
>
> Parameters having default value can indeed be omitted by the user.
> Optionally, the first arg (often corresponding to the "object" on which a
> command applies, like the receiver in OO, and thus usually "obvious") can
> be automatically mapped to the first param of main:
>
> $ findword foo.txt word=foo
>
> This is, indeed, a language-specific feature. On the other hand, it brings
> to the user consistent program-call format -- rather than each program
> defining its own. Maybe after sometime the same syntax trick and syntax
> would adopted by other languages. I find this very coool on the programmer
> side as well. It must indeed by implemented in the language('s runtime)
> itself. To have such a feature without breaking any code, a possibility
> may be to use a different name than "main", eg "script". (I guess such a
> feature would make some difference in judging a language's adequacy to
> scripting.)
>
> What do you think?
Nice and terse, but let's not get carried away with the whole scripting thing.
I'd
be more than happy with getopt working at capacity. It can easily phase out
most common boilerplate arg parsing.
--
Tomek
Re: The D Scripting Language -- std imports
On Fri, 12 Nov 2010 23:21:55 +0600 "Alexander Malakhov" wrote: > btw, does --eval make "import std.all" or some set of modules ? Btw, I just had an idea about std imports -- not only for scripting, but for general use of D as well: What if D automagically imported a std set of modules, _provided_ none of them is explicitely imported? Then, I guess, people could go on importing manually (eg to reduce size of executable) without any change. This also applies to all existing apps, doesn't it? A border case would be an app that actually imports nothing -- but is it at all possible to do anything? An interesting debate would be to define this std set ;-) Could it (easily) be made configurable? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: The D Scripting Language -- std imports
"spir" wrote in message news:mailman.322.1289642939.21107.digitalmar...@puremagic.com... >On Fri, 12 Nov 2010 23:21:55 +0600 >"Alexander Malakhov" wrote: > >> btw, does --eval make "import std.all" or some set of modules ? > >Btw, I just had an idea about std imports -- not only for scripting, but >for >general use of D as well: What if D automagically imported a std set of >modules, _provided_ none of them is explicitely imported? > >Then, I guess, people could go on importing manually (eg to reduce size of >executable) without any change. This also applies to all existing apps, >doesn't it? A border case would be an app that actually imports nothing -- >but is it at all possible to do anything? > >An interesting debate would be to define this std set ;-) Could it (easily) >be >made configurable? I like the reasoning, but I think it might be confusing.
