Jump to page: 1 2
Thread overview
#! probably should be legal
Nov 19, 2001
Russ Lewis
Nov 19, 2001
Sean L. Palmer
Nov 19, 2001
Axel Kittenberger
Nov 19, 2001
Sean L. Palmer
Nov 19, 2001
Axel Kittenberger
Nov 20, 2001
Walter
Nov 19, 2001
Russell Borogove
Nov 20, 2001
Sean L. Palmer
Nov 19, 2001
Russ Lewis
Nov 22, 2001
a
Nov 19, 2001
Pavel Minayev
Nov 20, 2001
Walter
November 19, 2001
I'm thinking that maybe we should allow #! (at the beginning of a line,
followed by any number of characters) as a legal line of D syntax.  It
would be treated by the parser as a null-line (no effect).

It would allow us to run d programs almost as scripts (when we move to UNIX), since #! at the beginning of the line is used to determine the correct interpreter for a shell.  I might add

#! /usr/bin/d-interpreter

at the beginning of some of my files.  It might not be exactly the smartest thing to do, but it seems like it would add a lot of flexibility w/o adding hardly any complexity to the language or its parser.

Thoughts?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]


November 19, 2001
Please, no favors for Unix (or any other specific platform).  Especially
when it adds so little.

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BF8C7F1.63A80CC4@deming-os.org...
> I'm thinking that maybe we should allow #! (at the beginning of a line,
> followed by any number of characters) as a legal line of D syntax.  It
> would be treated by the parser as a null-line (no effect).
>
> It would allow us to run d programs almost as scripts (when we move to UNIX), since #! at the beginning of the line is used to determine the correct interpreter for a shell.  I might add
>
> #! /usr/bin/d-interpreter
>
> at the beginning of some of my files.  It might not be exactly the smartest thing to do, but it seems like it would add a lot of flexibility w/o adding hardly any complexity to the language or its parser.
>
> Thoughts?



November 19, 2001
Sean L. Palmer wrote:

> Please, no favors for Unix (or any other specific platform).  Especially
> when it adds so little.

Well funny defintion of "specific platform", today almost all major computers systems except ms-windows run on a unix-like or compatible OS. Now even the MAC has gone unix....

The special question in this regard should better be: do you allow the language to be also interpreted beside beeing compiled? I guess no.

However I agree with the orignal author that '#' is a better comment token. It's shorter than '//', it does not bring system problems like '/*' and is stackable, also from an artistic view it seperates the text better, beside that it is write-spread as comment token in all non computing language definition files, like almost in all /etc files, or as comment in makefiles. Beside it's exactly as the he said it, on unix systems it allows you to specify an executable a text file should be computed with if executed.

- Axel
-- 
|D) http://www.dtone.org
November 19, 2001
So what's so wrong with using:

   dinterp mydscript.d

instead of merely

   mydscript.d

?

Maybe you could rename the file  'mydscript.di' to signify it's interpreted.

If you tie the D language to Unix today, and 5 years from now Unix is out of vogue because some new OS comes in and takes over the world, then what?

If you think about sheer number of computers running the OS, Windows wins. Why not make ';' the end-of-line comment, since ';' is used as end-of-line comment in Windows .ini files?  I'd be happier if make used ';' or '//' as eol comment tokens.

Think about what is being requested.  This is clearly a platform/OS specific issue and should not be addressed by the core D spec.

Sean

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9tajbh$1gm1$1@digitaldaemon.com...
> Sean L. Palmer wrote:
>
> > Please, no favors for Unix (or any other specific platform).  Especially
> > when it adds so little.
>
> Well funny defintion of "specific platform", today almost all major computers systems except ms-windows run on a unix-like or compatible OS. Now even the MAC has gone unix....
>
> The special question in this regard should better be: do you allow the language to be also interpreted beside beeing compiled? I guess no.
>
> However I agree with the orignal author that '#' is a better comment token. It's shorter than '//', it does not bring system problems like '/*' and is stackable, also from an artistic view it seperates the text better, beside that it is write-spread as comment token in all non computing language definition files, like almost in all /etc files, or as comment in makefiles. Beside it's exactly as the he said it, on unix systems it
allows
> you to specify an executable a text file should be computed with if executed.
>
> - Axel



November 19, 2001
> Maybe you could rename the file  'mydscript.di' to signify it's interpreted.

Thats classic way of windows thinking, note that on core unix
systems the filename or extention is not necessarly the connected to an
application (well the KDE IDE does interpred extendions today). If you
execute a 'file' some conditions are checked, first if #! is presented the
rest of the line is interpreted as path, and the matching file will be
executed with this filename as paramter, than it's checked to be an ELF
file, and various other formats, I don't know of :o)

> If you tie the D language to Unix today, and 5 years from now Unix is out of vogue because some new OS comes in and takes over the world, then what?

Well Unix has just celebrated it's 30 birthday. So it please draw out the odds of this to change in the next 5 years.

> If you think about sheer number of computers running the OS, Windows wins.

No, If you take out the sheer number of CPU's windows looses high, it's far beneth 1 percent, well all unixes counted together also loose high. The most CPU's on this world run some RTOS, or are total monolithic. Think of it were everywhere a CPU is used, starting from your handy (actually having 2 CPU's in them), your digital watch, your TV, your washmashine, yes even some credit cards contain full CPU'S.

If you count all computer running servers and non-desktop operations windows looses again, through how many unix servers do you think your telephone call will be routed through if you call your friend on the phone? How many unix based routers does this post pass until it reaches your desktop? (Note that IOS from CISCO routers is BSD (al'a UNIX) based. What do you other crucial systems like the stock market runs upon? Hospital databases?

Now turn over the scope, let's get all computing languages that exist, where were they developed on? C? Java? Perl? Phython? Eiffel..

Honestly I cannot think of a single language that was "born" on windows systems, sure there are some but they do not come in my mind currently, all I can think of are "imported". Hmmm okay Ms Bob, C#, Visual Basic (However Basic come originally from monolithic systems)

I do not know where Pascal was developed on, since it was orignially written 1970 it's umm 1 year older than K&R's C and their UNIX.

> Why not make ';' the end-of-line comment, since ';' is used as end-of-line comment in Windows .ini files?  I'd be happier if make used ';' or '//' as eol comment tokens.
> 
> Think about what is being requested.  This is clearly a platform/OS specific issue and should not be addressed by the core D spec.

Note, I argueed that # is good comment sign on itself, beside that I just drew examples where it is otherwhere used.  ';' is a very bad commentor, first it is used already as seperator, second it's contra intuative, third it's not a "thick" character seperating syntactic total different parts well.

- Axel
November 19, 2001
Sheesh.  I had no desire to start a flame war.

Sorry.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]


November 19, 2001
"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BF8C7F1.63A80CC4@deming-os.org...
> I'm thinking that maybe we should allow #! (at the beginning of a line,
> followed by any number of characters) as a legal line of D syntax.  It
> would be treated by the parser as a null-line (no effect).

I agree. This is a feature seen in so many languages so
I think it must find its place in D.

And it might be allowed not even at the beginning of the
line, but _only_ at the very start of the file. Should
be easy for the compiler to check this.



November 19, 2001
"Sean L. Palmer" wrote:
> 
> Please, no favors for Unix (or any other specific platform).  Especially
> when it adds so little.

It costs so little, particularly if the parser only has to accept #! at the beginning of the file.

-RB
November 20, 2001
"Axel Kittenberger" <axel@dtone.org> wrote in message news:9tatp8$1mo6$1@digitaldaemon.com...
> Honestly I cannot think of a single language that was "born" on windows systems,

Uh, D. <g>

Though I am trying to not make it inherently dependent on Windows in any way.


November 20, 2001
"Pavel Minayev" <evilone@omen.ru> wrote in message news:9tbbv1$1vl7$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BF8C7F1.63A80CC4@deming-os.org...
> > I'm thinking that maybe we should allow #! (at the beginning of a line,
> > followed by any number of characters) as a legal line of D syntax.  It
> > would be treated by the parser as a null-line (no effect).
>
> I agree. This is a feature seen in so many languages so
> I think it must find its place in D.
>
> And it might be allowed not even at the beginning of the
> line, but _only_ at the very start of the file. Should
> be easy for the compiler to check this.


I have thought of requiring that all D source files start out with some unique string, the point being that will make it easier for the compiler to distinguish between D source and some random text. I can't tell you the number of irritating problems I and others have had by it not being obvious if a source file is meant to be compiled with a C or a C++ compiler.


« First   ‹ Prev
1 2