Dave wrote:
> In article <drv4st$2bif$1@digitaldaemon.com>, kris says...
>> Dave wrote:
>>> If D had a few more script-language like conveniences, then I think many C
>>> developers using shell or Perl for utilities would be impressed if they could
>>> replace both script and C with D..
>> On the face of it, trying to mix languages from the opposite ends of the spectrum sounds like dangerous ground :)
>>
> 
> What's funny is that at my current and previous gigs (everything outside my
> workspace has to be ksh, Perl or C and the UNIX platform doesn't support D),
> I've found myself typing 'notepad foo.d' when I want a quick prototype of an
> algorithm or whatever that doesn't involve regex work.
> 
> That's because D arrays, AA's, D strings and things like writefln and
> std.file.open() make it quicker to do some things than even Perl - at least in
> my case. I'd have a lot easier time convincing current and future co-workers of
> the same if some rudimentary search/replace regex stuff was built into the
> language, I think.
> 
> Imagine demo'ing D (with built-in regex) to a bunch of Perl/C users on an
> overhead, and then running a few array and AA benchmarks...

This is an interesting idea.  Since D is generally more productive and less error-prone than C/C++, it would be a good language for product demos (where rapid stable development is the crucial factor).  And once D had proven itself in that arena...

D would really need a solid GUI library for this to succeed, but it sounds like we're on the road to having one.


Sean

Dave wrote:
> In article <drve1c$2it4$1@digitaldaemon.com>, Roberto Mariottini says...
>> In article <druv9v$27p3$1@digitaldaemon.com>, Dave says...
>> [...]
>>> I just built a small 'interpreter' that will take a D file prefaced with
>>> '#!/usr/bin/rdmd', compile it and run it.
>> Nice!
>>
>>> To really make this work nicely, the compiler would have to ignore any first
>>> line starting with '#!' and would also (ideally) be able to take input from
>>> stdin.
>>>
>>> example:
>>>
>>> hello_script.d:
>>> ---------------
>>> #!/usr/bin/rdmd
>>> import std.stdio;
>>> int main()
>>> {
>>> writefln("Hello (pseudo) scripting world");
>>> }
>>>
>>> # chmod u+x hello_script.d
>>> # hello_script.d
>>>
>>> (At any time it could be simply compiled and run, of course).
>>>
>>> Since the compiler is so fast, it's feasible for even larger 'script' files (one
>>> problem is that linking with gcc is a bottleneck for single files).
>> You can cache compilations using timestamps. The first time you compile the
>> script and put the binary in some known directory. The second time you pick the
>> cached executable file, if it's newer than the source, otherwise recompile.
> 
> That was the next step, after I bring in the env for things like /usr/tmp,
> etc... <g>
> 
> Once I figured out how the shell interprets '#!' it took about 1/2 hour to
> actually get something running. I'll persue it more since others seem to think
> it's a decent idea (that is, if my wife lets me 'play with my computer' over the
> weekend <g>).

Please do.  I would love to be able to use D for shell scripting at work.  *sigh* that settles it then... sounds like I'm going to look into a Solaris port of GDC.


Sean

In article <drv7gb$2d4c$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Dave" <Dave_member@pathlink.com> wrote in message news:druv9v$27p3$1@digitaldaemon.com...
>> To really make this work nicely, the compiler would have to ignore any
>> first
>> line starting with '#!' and would also (ideally) be able to take input
>> from
>> stdin.
>>
>> example:
>>
>> hello_script.d:
>> ---------------
>> #!/usr/bin/rdmd
>> import std.stdio;
>> int main()
>> {
>> writefln("Hello (pseudo) scripting world");
>> }
>>
>> # chmod u+x hello_script.d
>> # hello_script.d
>
>Is that really all that's necessary to make this work, just ignore the first line with #! ? This is surely a wild idea. I like it.
>

Yep - the 'input from stdin' thing is not really all that important either, especially if '#!' is ignored.

>
>> (At any time it could be simply compiled and run, of course).
>>
>> Since the compiler is so fast, it's feasible for even larger 'script'
>> files (one
>> problem is that linking with gcc is a bottleneck for single files).
>
>True, the gcc linker is painfully slow.
>

In article <ds03v0$dcl$1@digitaldaemon.com>, Dave says...
>
>In article <drv7gb$2d4c$1@digitaldaemon.com>, Walter Bright says...
>>
>>
>>"Dave" <Dave_member@pathlink.com> wrote in message news:druv9v$27p3$1@digitaldaemon.com...
>>> To really make this work nicely, the compiler would have to ignore any
>>> first
>>> line starting with '#!' and would also (ideally) be able to take input
>>> from
>>> stdin.
>>>
>>> example:
>>>
>>> hello_script.d:
>>> ---------------
>>> #!/usr/bin/rdmd
>>> import std.stdio;
>>> int main()
>>> {
>>> writefln("Hello (pseudo) scripting world");
>>> }
>>>
>>> # chmod u+x hello_script.d
>>> # hello_script.d
>>
>>Is that really all that's necessary to make this work, just ignore the first line with #! ? This is surely a wild idea. I like it.
>>
>
>Yep - the 'input from stdin' thing is not really all that important either, especially if '#!' is ignored.
>

BTW - Things like this will work too:

#!/usr/bin/rdmd -O -inline -release -version=Howdy
import std.stdio;
void main()
{
version(Howdy)
writefln("Howdy (pseudo) scripting world");
else
writefln("Hello (pseudo) scripting world");
}

>>
>>> (At any time it could be simply compiled and run, of course).
>>>
>>> Since the compiler is so fast, it's feasible for even larger 'script'
>>> files (one
>>> problem is that linking with gcc is a bottleneck for single files).
>>
>>True, the gcc linker is painfully slow.
>>
>
>

"Dave" <Dave_member@pathlink.com> wrote...
> No changes to D except ignoring the first line of a program if the first
> two
> characters are '#!'.

And there's no way to hide that in a comment? I mean, that would be better; yes ?


> I personally can type 'int var', 'char[] var' or 'int[char[]] var' faster
> than
> that damn $var, @var or %var all over the place, when you factor in the
> extra
> time I spend having to go back and prepend [$@%] 1/2 the time <g>
>
> Alot of the Perl I've seen (in shops and even OSS) could often be almost
> as
> easily written in C (not the regex stuff of course), because it doesn't
> need
> Perl's 'dynamism'.

Sounds good.

>>Native regular-expressions in D have been visited a number of times, but I don't think anyone has come up with a really solid approach for it yet. There's the distinct possiblity of doing so via templates, but that perhaps wouldn't have the charm or simplicity of a scripting language?
>>
>
> Yes, I know and it's a tough nut to crack. I'm not sure if the DM regexp
> lib.
> strictly supports PCRE or PERE either, which may be a road-block.
>
> But if the requirements start out with basic search, replace and some form
> of
> paranthesized substring support, then I think that *could* be big (the old
> 80-20
> rule).

Yes; a lot of the scripting simplicity comes from output formatting. You haven't mentioned 'automatic' conversion of numerics to strings, such as "int: "~23~", float: "~3.14159; is there a reason for that?


> I haven't checked out Eric's compile-time regex stuff yet either, and I'm
> no
> regex expert by a long shot, I just get the feeling that there is a market
> in D
> 'bridging' the script / compiled gap as best a static compiled language
> can,
> because others don't.

Yes. To achieve that, I suspect regex would then have to be supported directly by the lexer as a first class citizen.


> The whole idea is to encourage others to reach for D instead of either
> Perl or C
> for much of what they're doing. Bring the 'cost' (of using D for simple
> tasks)
> down and 'value' (adding native regex + all of D's other features) up
> until it
> meets a break-even. As soon as people start using D for 'throw-away'
> utilities,
> the market is ours (moohuhuhahahaha).

Sometimes anything is better than nothing :~)

>
>>Then there's long unanswered questions about how to handle things like regex text-folding in unicode ~ toupper() et. al. just don't cut it anymore, and the rules can become really quite complex. Perhaps building all that into the language itself (rather than via a configurable library) ought to raise an eyebrow or two? I mention this because of a familiarity with ICU.
>>
>>After that, wouldn't one want to start building, say, the IO system directly into the language? Or is that stretching the concept?
>
> That would be too far <g> But I've been thinking about how to make it
> easier to
> just open up an editor and start knocking out D code for utility type
> programs.
>
> import std.script;
>
> This would publically include, say, std.stdio, std.file, std.string, std.regexp.

But it's a trap that's easy to fall into :)

For example, the 'automatic' conversions above would probably link directly to Phobos? That would tends to exclude alternate libraries? The imports you describe bind directly to Phobos also. That tends to heavily bias the "scripts" toward a library that many of us feel is 'closed'. Perhaps this needs to be considered? Some of this could be addressed by Walter leaving some indirection within the bindings (rather than binding directly to some 'internal-only' label, like the way comparison/equality is performed).

- Kris

In article <ds09nc$hpo$1@digitaldaemon.com>, Kris says...
>
>"Dave" <Dave_member@pathlink.com> wrote...
>> No changes to D except ignoring the first line of a program if the first
>> two
>> characters are '#!'.
>
>And there's no way to hide that in a comment? I mean, that would be better; yes ?

You probably already know this, but the '#!' is a token used by the shell directly:

http://www.tldp.org/LDP/abs/html/sha-bang.html

"The  sha-bang  ( #!) at the head of a script tells your system that this file is a set of commands to be fed to the command interpreter indicated. The #! is actually a two-byte [1]  magic number, a special marker that designates a file type, or in this case an executable shell script (type man magic for more details on this fascinating topic). Immediately following the sha-bang is a path name. This is the path to the program that interprets the commands in the script, whether it be a shell, a programming language, or a utility. This command interpreter then executes the commands in the script, starting at the top (line following the sha-bang line), ignoring comments."

So the convention is geared toward sh/bash scripts, is used directly by the system, so any other grammar has to (unfortunately) follow suit.  AFAIK, there's no getting rid of it.

Of course if the D specification allowed such a directive, convienently named '!' (*coughwalter?cough*), then there wouldn't be any problem with D shell scripts being compilable via conventional means. ;)

- Eric Anderton at yahoo

"pragma" <pragma_member@pathlink.com> ...

> You probably already know this, but the '#!' is a token used by the shell directly:
>
> http://www.tldp.org/LDP/abs/html/sha-bang.html


I guessed so, but was hoping there'd be an alternative?


> "The  sha-bang  ( #!) at the head of a script tells your system that this
> file
> is a set of commands to be fed to the command interpreter indicated. The
> #! is
> actually a two-byte [1]  magic number, a special marker that designates a
> file
> type, or in this case an executable shell script (type man magic for more
> details on this fascinating topic). Immediately following the sha-bang is
> a path
> name. This is the path to the program that interprets the commands in the
> script, whether it be a shell, a programming language, or a utility. This
> command interpreter then executes the commands in the script, starting at
> the
> top (line following the sha-bang line), ignoring comments."
>
> So the convention is geared toward sh/bash scripts, is used directly by
> the
> system, so any other grammar has to (unfortunately) follow suit.  AFAIK,
> there's
> no getting rid of it.


Thanks, Eric ~ much appreciated. So, what happens when there's a unicode BOM at the start of the file?


> Of course if the D specification allowed such a directive, convienently
> named
> '!' (*coughwalter?cough*), then there wouldn't be any problem with D shell
> scripts being compilable via conventional means. ;)


Can you expound on that a bit further, please?

"Dave" <Dave_member@pathlink.com> wrote in message news:ds02v2$cnb$1@digitaldaemon.com...
> Once I figured out how the shell interprets '#!' it took about 1/2 hour to
> actually get something running. I'll persue it more since others seem to
> think
> it's a decent idea (that is, if my wife lets me 'play with my computer'
> over the
> weekend <g>).

Is there a url where I can learn more about this?

"Sean Kelly" <sean@f4.ca> wrote in message news:ds03jc$ctu$1@digitaldaemon.com...
> Please do.  I would love to be able to use D for shell scripting at work. *sigh* that settles it then... sounds like I'm going to look into a Solaris port of GDC.

I have the easy part, just ignore the first line <g>.

Dave wrote:
[snip]
> 
> 
> No changes to D except ignoring the first line of a program if the first two
> characters are '#!'.
> 

A thought occurrs... does UNIX check the BOM first?  If not, then Unicode source code could not be coerced into this...

[snip]


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne