www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion -- implicit imports

reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Okay, so this could get hairy.  Still, I think it deserves to be considered, so
I'm posting it here.  Walter, if you're reading this... thanks for encouraging
me to try the newsgroup.  I hope you see this, because I think it could be very
important in the long run.

What I'm proposing is that functions and such which have been well established
should not require explicit importing of the module that contains them.

I'm not saying that "all" established functions, objects, members, and so on
should be automatically imported, but rather that the ones which are used as if
they are a needed part of the D language should be treated as a part of the
language, but without having to be built into the language.

For example, if I use the writef function but fail to specifically import a
module that contains a function by that name, the D compiler could choose a
default module for me from a list and import it without being asked to.  If I
do import a module that contains a writef function, then the default module
would not have to be imported.  If I neither specify to import a module that
contains a writef function nor use a writef function, then again... the default
module for the writef function would not be imported... unless another function
that I did use also specified the same default module and I didn't specify a
different module to import containing a variation of that other function.

I bring this up, because I have frequently seen C and C++ programmers talk
about certain functions as if they are a built in part of the C language...
most likely because they usually start with an old source file that's evolved
from something they wrote longer ago than they can remember, and the include
statements that they need most often are already in it.

This concept could theoretically be further expanded to allow parts of a module
to be imported, based on possible dependancies... but I digress.

The idea is to simply make it so that features which are considered for all
practical purposes to be a needed part of the language could simply be used as
if they are a built in part of the language, saving the newbie programmer a
whole lot of trouble in learning to write a simple program.

As an example, I should be able to write a "Hello world" program as follows...

int main()
{
 writef("Hello world!);
 return 0;
}

and have it compile and run "as is" rather than having to specifically import a
module containing the writef function.

If I want the program to open a dialog in Windows or just print in DOS, then I
should be able to write it as...

int main()
{
version(Windows)
 MessageBoxA(null,"hello!","message_box",MB_OK);
else
 writef("Hello world!);
 return 0;
}

That is, if the MessageBoxA function were included in implicit import list.  I
know I'm not nearly qualified to say which functions should be considered that
well known or that important to the programming community as a whole, but I'm
sure there are people programming in D who are... and I would like their input.

I've never liked C, and I like C++ even less.  As programming languages go,
they are among my least liked, but anyone who programs is forced to put up with
them because they are just that pervasive.   One of the things that I dislike
most about them is that they tend to discourage people from learning to
program.  In the D programming language, I see the potential to capture what is
good in C and C++ while doing away with this "no newbies allowed" attitude.

Here's what I think a minimal "Hello world" program "should" look like in D...

write("Hello world");

Yep.. that's it.  A keyword that could be guessed in a few tries by someone who
has never used the language, and the established D syntax, with an implied main
function and an implied return value.

Think about it.  How many programs have you seen that have...
return 0;
}
...at the end?

If a module with no return value at the end is compiled and linked to run as a
standalone program, the compiler-linker should be able to make the assumprion
that 0 is to be returned when the "end" of the program is reached.

Also, if no main function is found in a module, but there is a list of
statements not enclosed in anything... that list should be assumed to be the
main function.

I might even go as far as to say that if someone tries to see what's in
args[][1] in the main function without first specifying what "args" stands for,
the compiler could probably make an assumption about that too... and if it's
not obvious to someone reading this what that assumption should be, it would
probably surprise most of the other people reading this... because there is a
well known standard usage that probably every D programmer is familliar with.

Okay, so instead of "write" I could have used "writef" which is more
established... but my point is, while it's nice to make the D language feel
familliar to established programmers, I would think it equally important to
make it easy for a new programmer to get started in.

Donald A. Kronos, PhD. - TechnoZeus
Apr 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
TechnoZeus wrote:


 I bring this up, because I have frequently seen C and C++ programmers
 talk about certain functions as if they are a built in part of the C
 language... most likely because they usually start with an old source
 file that's evolved from something they wrote longer ago than they
 can remember, and the include statements that they need most often
 are already in it.


It's sad when precompiled headers and compiler prefixes files
rots the brain like that :-) Seriously, the C and C++ standard
headers are pretty well defined ? #include <stdlib.h>, and friends.

In Java, that loads "code" very differently from what C/C++ does,
you can call upon a routine by just referencing to the full name :
i.e. "std.stdio.writefln", but that does not work as easy in D
(since the "import" is more than just a syntax convenience here)


 As an example, I should be able to write a "Hello world" program as
 follows...
 
 int main() { writef("Hello world!); return 0; }
 
 and have it compile and run "as is" rather than having to
 specifically import a module containing the writef function.


There are several other things in that program that could be simpler.

For instance, the EXIT_SUCCESS return value (a.k.a "0") could be implied 
by declaring the function as "void main()" (this does not work yet in D)

And you could have a "write" function that avoids learning that all %
characters must be written as %%, to avoid the exceptions at runtime ?

Perhaps even use the "ln" versions, to avoid learning that you escape
a newline character like "\n", when escaped in a string like that.

Thus:

import std.stdio;
void main()
{
   writeln("Hello, World!");
}


 I've never liked C, and I like C++ even less.  As programming
 languages go, they are among my least liked, but anyone who programs
 is forced to put up with them because they are just that pervasive.
 One of the things that I dislike most about them is that they tend to
 discourage people from learning to program.  In the D programming
 language, I see the potential to capture what is good in C and C++
 while doing away with this "no newbies allowed" attitude.


Oh, I'm not sure that D would be your new best friend either, then ?
I find that they do encourage people to learn, by *not* holding hands.

Although with a little better documentation, it shouldn't be *that*
scary for newcomers - just a bit complex as a first language to learn.


 Here's what I think a minimal "Hello world" program "should" look
 like in D...
 
 write("Hello world");
 
 Yep.. that's it.  A keyword that could be guessed in a few tries by
 someone who has never used the language, and the established D
 syntax, with an implied main function and an implied return value.


With all due respect, you might want to try another language...
There are several languages, where things like that are allowed.

Something with a little connection to DMD is DMDscript, for instance ?
It all depends on what you are trying to do... (probably not "say hi")

--anders
Apr 13 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Thanks for the response.

Yes, that's the kind of stuff I'm talking about. The most commonly "needed"
stuff that's not "built in" so that they can be used without having to import
them explicitly.  Especially those that are already part of the Phobos runtime
library.

There would be one disadvantage that I can think of.  Imigine this example:
Someone writes a program that uses a function from std.c.stdio and later a D
specific version of that function is added to std.stdio and set as the default
for that function.  If the program was re-compiled, it would implicitly import
the function from it's new default module and if that version was not backward
compatible, it could break the program.

Of course, such a scenario would only happen if the programmer had "not"
specified to import a specific module, in which case it would have been a
broken program already the way things are right now... and fixing it would
require nothing more than to add the import line.  Also, that scenario would
only happen in cases where it was decided that replacing the old function with
a new one that may break older programs was worth the trade-off... which I
suspect would be likely to happen if the function was indeed well known and
well established.

Yes, the import is more than just a syntax convenience, but in some cases it is
actually an inconvenience.  There's no real reason a person should have to
explicitly import a module to do simple common tasks like getting keyboard
input, printing something to the screen, reading a file or directory,
multithreading an application, extracting the extension from a filename,
extracting a numeric value from a string, or generating a random number... and
there's also no need to have all those functions "built into the compiler" when
importing them works just fine.  Implicit importing should deliver the best of
both worlds.

----

Actually, "void main()" does work in D, but I hadn't thought of that until
after I had already posted my comments.  How-ever, it could still be simplified
by allowing compilation without even declaring a main function.  Is it worth
while?  I'm not sure... but I tend to think it would be.  Not because
programmers would like to be able to save typing a couple of lines of text, but
because it would help to facilitate new programmers learning the D language
more independantly.

I like that... a write function that acts differently than the writef
function... one that works perhaps more like the Print statement in most
versions of BASIC, or like the write statement in Pascal.  Walter?  Care to
comment on the possibility of something like a write and writeln statement
being added as built-in functions?

Just a side thought: I wonder if a "write" function could be made platform and
operating system independant somehow... and where it would write to in Windows
if no output device or object was specified.

Yes, I know what you mean.  Since D is derived from C and in some ways from
C++, it's to be expected that most of the people using it will be long standing
C and C++ programmers... at first.  Keep in mind though, that most of the
people who have been programming C or C++ for many years are not going to be
all that anxious to learn yet another programming language.  Those who are
already learning D are of course most likely the exception, but if D is to
thrive in the long run it will be mostly due to it's popularity with people who
are not too set in their ways with any one specific programming language when
they encounter D for the first time.  That includes those of us who have never
had a single favorite programming language as well as those who have never
programmed at all.

As for me trying another language... I was writing my own assemblers and
compilers well over 20 years ago, and I've written plenty of programs in
straight hexadecimal machine language on various processors.  Yes, I would like
it simpler for me... because it would make the experience of learning it that
much more enjoyable, but that's not the "reason" that I would like to see it
simplified.  I would like to see it simplified first because it would be better
that way and I'm all for making it better, and second because it would mean
that more people could learn the language who might not otherwise.

And yes, there are other languages where things like that are allowed... which
proves that it can be done.  There's no reason that I can see why D should have
to follow in the footsteps of C when it comes to the learning curve.  As I
stated before, I see in the D language the potential to capture what is good in
C and C++ while doing away with this "no newbies allowed" attitude that has
plagues those two languages for far too long.  Everyone who programs ANY
language was once a newbie at it, so we should give the newbies some respect
because some of them will be programming circles around us some day.

TZ


"Anders F Björklund" <afb algonet.se> wrote in message
news:d3in7m$18f9$1 digitaldaemon.com...

 It's sad when precompiled headers and compiler prefixes files
 rots the brain like that :-) Seriously, the C and C++ standard
 headers are pretty well defined ? #include <stdlib.h>, and friends.

 In Java, that loads "code" very differently from what C/C++ does,
 you can call upon a routine by just referencing to the full name :
 i.e. "std.stdio.writefln", but that does not work as easy in D
 (since the "import" is more than just a syntax convenience here)


 There are several other things in that program that could be simpler.

 For instance, the EXIT_SUCCESS return value (a.k.a "0") could be implied
 by declaring the function as "void main()" (this does not work yet in D)

 And you could have a "write" function that avoids learning that all %
 characters must be written as %%, to avoid the exceptions at runtime ?

 Perhaps even use the "ln" versions, to avoid learning that you escape
 a newline character like "\n", when escaped in a string like that.

 Thus:

 import std.stdio;
 void main()
 {
    writeln("Hello, World!");
 }


 Oh, I'm not sure that D would be your new best friend either, then ?
 I find that they do encourage people to learn, by *not* holding hands.

 Although with a little better documentation, it shouldn't be *that*
 scary for newcomers - just a bit complex as a first language to learn.


 With all due respect, you might want to try another language...
 There are several languages, where things like that are allowed.

 Something with a little connection to DMD is DMDscript, for instance ?
 It all depends on what you are trying to do... (probably not "say hi")

 --anders
Apr 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
TechnoZeus wrote:


 I like that... a write function that acts differently than the writef
 function... one that works perhaps more like the Print statement in
 most versions of BASIC, or like the write statement in Pascal.
 Walter?  Care to comment on the possibility of something like a write
 and writeln statement being added as built-in functions?


I've already written the write and writeln functions, and
they're working just fine. :-) (just waiting to get added)

It's actually writef without the formats. Nothing more,
and nothing less (not sure what BASIC and Pascal does ?)


 As for me trying another language... I was writing my own assemblers
 and compilers well over 20 years ago, and I've written plenty of
 programs in straight hexadecimal machine language on various
 processors.  Yes, I would like it simpler for me... because it would
 make the experience of learning it that much more enjoyable, but
 that's not the "reason" that I would like to see it simplified.  I
 would like to see it simplified first because it would be better that
 way and I'm all for making it better, and second because it would
 mean that more people could learn the language who might not
 otherwise.


Sounds good, as I didn't mean to scare anyone off from using D...
Nothing wrong with being new, as long as you're willing to learn.

Just that if you want a simple program, to do stuff like say "hi";
then there are more productive languages than using C, C++ or D.

I use Perl, others prefer Python... Ruby is a great language too.
Even a simple shell script would do. But I wouldn't touch .BAT :-)

--anders
Apr 13 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Yes, I agree.  For one, any interpreted language is likely to be rather
efficient for the development of very simple programs since there is no need
for the compilation step, although I have also seen language implementations
compile transparantly from the editor in the integrated development environment
so that the programmer never had to even know it was compiled unless they
wanted to distribute their program to someone who didn't have the IDE to run
the source code from.

There's always a better way.  The trick is in finding it.  :)

TZ

"Anders F Björklund" <afb algonet.se> wrote in message
news:d3j5km$1lnu$1 digitaldaemon.com...

 TechnoZeus wrote:


 I like that... a write function that acts differently than the writef
 function... one that works perhaps more like the Print statement in
 most versions of BASIC, or like the write statement in Pascal.
 Walter?  Care to comment on the possibility of something like a write
 and writeln statement being added as built-in functions?


 I've already written the write and writeln functions, and
 they're working just fine. :-) (just waiting to get added)

 It's actually writef without the formats. Nothing more,
 and nothing less (not sure what BASIC and Pascal does ?)


 As for me trying another language... I was writing my own assemblers
 and compilers well over 20 years ago, and I've written plenty of
 programs in straight hexadecimal machine language on various
 processors.  Yes, I would like it simpler for me... because it would
 make the experience of learning it that much more enjoyable, but
 that's not the "reason" that I would like to see it simplified.  I
 would like to see it simplified first because it would be better that
 way and I'm all for making it better, and second because it would
 mean that more people could learn the language who might not
 otherwise.


 Sounds good, as I didn't mean to scare anyone off from using D...
 Nothing wrong with being new, as long as you're willing to learn.

 Just that if you want a simple program, to do stuff like say "hi";
 then there are more productive languages than using C, C++ or D.

 I use Perl, others prefer Python... Ruby is a great language too.
 Even a simple shell script would do. But I wouldn't touch .BAT :-)

 --anders
Apr 13 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:

 Yes, I agree.  For one, any interpreted language is likely to be
 rather efficient for the development of very simple programs since
 there is no need for the compilation step, although I have also seen
 language implementations compile transparantly from the editor in the
 integrated development environment so that the programmer never had
 to even know it was compiled unless they wanted to distribute their
 program to someone who didn't have the IDE to run the source code
 from.
 
 There's always a better way.  The trick is in finding it.  :)


There's always dscript. (Not the same as DMDscript.)

It compiles transparently, so all you do is write the code and then run 
it. But it does not work on windows (yet).
Apr 14 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Well, I still think D has real potential.  It's new... so give it some time. 
Of course, the people standing behind it can make all the difference in the
world.

Adding the ability for the compiler to look things up in an implied import
table if they are not declared or imported explicitly wouldn't change any
existing programs, and would make it a little easier for experienced
programmers to write programs more quickly and a lot easier for newbies to
learn the D programming language.

Adding the ability to have the compiler treat a missing main function
declaration as an implication that the first line of the unenclosed code is the
program's entry point and that reaching the end of the program returns 0, might
require a little more integration between the ideas of compiling and linking,
but again wouldn't change any existing programs, and would make it easy for
someone learning the language to write very short practice programs to test
their understanding of how the parts of it work.

Adding the ability to let the compiler recognize a program as being written for
a specific environment and save the programmer the trouble of specifying such
details as how to link it would still allow overriding of that default
functionality, but would again make it easier for a beginner to learn.

Adding long filename support to the compiler and the ability to have it look in
default relative paths for files that are commonly needed to compile and link a
program wouldn't break any existing functionality, if done right, but would
make the compiler that much easier to use... especially for beginners.

Adding a graphical user interface that allows the source code to be edited, and
run with transparent compiling and linking for the operating system it's
installed on, would make D as easy to use as an interpreted language, but
without removing any of it's current advantages.  That same graphical interface
could have menu options for compiling and linking to other platforms.

I see no down side to any of this, except the following:  None of it will
happen without a lot of work going into it.

So, what it comes down to is a simple question of what's worth the effort it
would take, and what isn't.  I think the key to it is colaboration, but can
this be accomplished to a sufficient degree?

TZ

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:425E327E.9050403 nospam.org...

 TechnoZeus wrote:

 Yes, I agree.  For one, any interpreted language is likely to be
 rather efficient for the development of very simple programs since
 there is no need for the compilation step, although I have also seen
 language implementations compile transparantly from the editor in the
 integrated development environment so that the programmer never had
 to even know it was compiled unless they wanted to distribute their
 program to someone who didn't have the IDE to run the source code
 from.

 There's always a better way.  The trick is in finding it.  :)


 There's always dscript. (Not the same as DMDscript.)

 It compiles transparently, so all you do is write the code and then run
 it. But it does not work on windows (yet).
Apr 14 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TechnoZeus schrieb am Thu, 14 Apr 2005 04:31:09 -0500:

 Adding the ability to have the compiler treat a missing main function 
 declaration as an implication that the first line of the unenclosed code
 is the program's entry point and that reaching the end of the program
 returns 0, might require a little more integration between the ideas of
 compiling and linking, but again wouldn't change any existing programs,
 and would make it easy for someone learning the language to write very short
 practice programs to test their understanding of how the parts of it work.


Consequence: Compiling would dependend on the order of the source files
given - that's troublesome.


 Adding the ability to let the compiler recognize a program as being written
 for a specific environment and save the programmer the trouble of specifying
 such details as how to link it would still allow overriding of that default
 functionality, but would again make it easier for a beginner to learn.


An example please.


 Adding long filename support to the compiler


Just tested it and had no problems with a long(267 character) file name.


  and the ability to have it look in default relative paths for files
 that are commonly needed to compile and link a program wouldn't break
 any existing functionality, if done right, but would make the compiler
 that much easier to use... especially for beginners.


Have a look at dmd/sc.ini dmd/dmd.conf. 


 Adding a graphical user interface that allows the source code to be edited,
 and run with transparent compiling and linking for the operating system it's
 installed on, would make D as easy to use as an interpreted language, but
 without removing any of it's current advantages.


That the job of an IDE(editing) or of an VM(interpreted) not the compiler.
Ofcoure the VM(in the broad sence) could be integrated into the IDE and
closely interact with the compiler.


 That same graphical interface could have menu options for compiling and
 linking to other platforms.


Crosslinking is non-trivial. Adding crosscompiling to DMD should be
fairly easy.


 I see no down side to any of this, except the following:  None of it will
 happen without a lot of work going into it.


I'm sure you know what I'm going to say:

1) analyse the situation, shortcommings, desires etc.
2) have a vision
2) analyse available capabilities/resource
3) set a target
4) aquire required capabilities/resource
...


 So, what it comes down to is a simple question of what's worth the effort
 it would take, and what isn't.  I think the key to it is colaboration,
 but can this be accomplished to a sufficient degree?


If you dont start a project or join an existing to fulfill your vision
you wont reach your target.

In case you lack the capabilities I'm sure there peoples you could
encourage and/or bribe into helping you.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCXkKK3w+/yD4P9tIRAvNjAJ9xlakIFwarrYVwPqEzVelMlPfAEQCgjfxE
VLHYBcpd3ujKkzWeg73bXDI=
=i/0B
-----END PGP SIGNATURE-----
Apr 14 2005
next sibling parent reply James Dunne <jdunne4 bradley.edu> writes:
 I would like to see it simplified first because it would be better that
 way and I'm all for making it better, and second because it would
 mean that more people could learn the language who might not
 otherwise.


Not to sound arrogant or anything... but people that could learn the language
better with an implied main function are just the people we don't want
programming in the first place.

There, someone finally said it :-P.  I, for one, am tired of looking at code
written by bad programmers.  Dumbening (thanks Lisa Simpson) languages up is not
going to help make better coders - just more bad/mediocre ones.

It's almost akin to saying "lets remove all prepositions from English to make it
easier for dumber kids to speak it."  What does this do to the overall quality
of the English language (as if it was ever that great to begin with)?  The
result:  we're all talking like morons.

I'm not harping on you personally, TZ, and I of course mean you no offense.  I
apologize if I did offend you.

Regards,
James Dunne
Apr 14 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I hate to tell you this, but "everyone" learns better that way.

There are many differences in people's learning styles, but one thing that all
biological brains I have ever encountered have in common with all forms of
artificial intellegence I have ever looked into is that they all learn to
recognize and understand something with more accuracy in a shorter time if that
"something" is less obscured.

If you don't believe me, try teaching yourself machine language on a processor
that you've never worked with by reading hexadecimal dumps of programs.  I've
done it, and I can tell you from experience it's not easy... but more
importantly, it's impossible to be sure you've actually understood any of it
correctly until you start testing your understanding in actual programs of your
own.

Furthermore, the accuracy of any theories that you can't isolate and test
separately will permanently remain dependant on your understanding of the parts
that you couldn't isolate them from.  Therefore, if it's impossible to isolate
one part from another part, if you are wrong about one you will likely be wrong
about the other also and never even know it.  Sure, you can write "working"
code that way... but there's a big difference between successful morphology of
a working program into another working program and actual understanding of how
the programming language works.

As for your reference to English, if happens to be a disaster of a language...
but that's a whole other topic.  More to the point, there are many fluent
speakers of English who still use the word "unthaw" to mean "thaw" and "borrow"
to mean "loan" because they have never isolated those words and learned to
understand them outside of the context in which they are used to encountering
them.

The word "inflammable" used to be printed on cans for petroleum feuls such as
gasoline, but they don't do that anymore because too many people thought it
meant "won't burn" when the intended definition was "flammable" which is
confusing enough in itself since it makes one wonder what happened to the "-in"
prefix, but the confusion doesn't stop there.  "inflammable" also means "easily
inflamed" and "inflamed" can mean either set on fire or having "inflammation"
which in turn more often means "swelling" than "burning" but again, depends on
the context.

I once suggested to Microsoft that they add a choice between tiling windows
horizontally or vertically, which they promptly added... but with the ambiguous
wording of "horizontal tile" and "vertical tile" where the word "tile" could be
interpreted as either a verb or a noun, and the direction of the tiling would
be different for one interpretation than the other.  I pointed this out, and
they decided to fix it.

I suggested that they use "portrait tile" and "landscape tile" which were well
known already in many industries and non-ambiguous, but also mentioned the
option of "horizontal tiles" and "vertical tiles" which matched what was the
current functionality at that time, would be the easiest change to make, and
was unambiguous and more accurate (since nobody really tiles a single item
anyway), and of course the option of changing them to "tile horizontally" and
"tile vertically" which would specify that "tile" was being used as a verb,
since adverbs aren't used to modify nouns... but also pointed out that this
change would be the least desireable, since it would require swapping the then
current functionality and hence the existing keyboard shortcuts.

Well, they chose to go with the my "last choice" and not to swap the two, so
now we have a "Tile Windows Horizontally" option that tiles windows vertically,
and a "Tile Windows Vertically" function that tiles windows horizontally.  I
did attempt to address this issue, but I was told that they had a big meeting
in which a top executive which the employee I was speaking with felt it would
be in his interest not to actually mention by name, had decided that
"horizontally" meant top to bottom, and "vertically" meant left to right.

So, you may wonder how someone can come to such nonsensical conclusions... or
perhaps you're one of the many people who agrees with that notion.  I wouldn't
know... but I can tell you where it came from...

Back when televisions still had tubes in them that controlled various functions
and occasionally needed to be replaced, if the horizontal oscillation tube went
bad, the television would display a vertical line, because the cathode ray no
longer scanned horizontally.  Technicians called this a "horizontal collapse"
or in more common terms, simpy a horizontal problem.  They would tell customers
who reported a single white line from the top of the TV screen to the bottom,
"that's your horizontal" and for likewise would tell those who reported a
single white line from left to right "that's your vertical" usually with no
further explanation.  As a result, many people who were previously unfamilliar
with these terms, including a lot of children growing up when televisions were
new and broke down a lot, learned the meanings of "horizontal" and "vertical"
wrong because they learned them in context without the opportunity to isolate
them.

Maybe "you" don't want people who like to learn things thoroughly and
accurately to join the D programming community, but I highly doubt that you
speak for everyone in that regard.  I know you don't speak for me.

"James Dunne" <jdunne4 bradley.edu> wrote in message
news:d3lm5v$q76$1 digitaldaemon.com...

 I would like to see it simplified first because it would be better that
 way and I'm all for making it better, and second because it would
 mean that more people could learn the language who might not
 otherwise.


 Not to sound arrogant or anything... but people that could learn the language
 better with an implied main function are just the people we don't want
 programming in the first place.

 There, someone finally said it :-P.  I, for one, am tired of looking at code
 written by bad programmers.  Dumbening (thanks Lisa Simpson) languages up is
not
 going to help make better coders - just more bad/mediocre ones.

 It's almost akin to saying "lets remove all prepositions from English to make
it
 easier for dumber kids to speak it."  What does this do to the overall quality
 of the English language (as if it was ever that great to begin with)?  The
 result:  we're all talking like morons.

 I'm not harping on you personally, TZ, and I of course mean you no offense.  I
 apologize if I did offend you.

 Regards,
 James Dunne
Apr 14 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
James Dunne wrote:

 I would like to see it simplified first because it would be better
 that way and I'm all for making it better, and second because it
 would mean that more people could learn the language who might not 
 otherwise.


 
 Not to sound arrogant or anything... but people that could learn the
 language better with an implied main function are just the people we
 don't want programming in the first place.


I actually don't like this being said out aloud.

BUT, I REALLY DO AGREE HERE!


 There, someone finally said it :-P.  I, for one, am tired of looking
 at code written by bad programmers.  Dumbening (thanks Lisa Simpson)
 languages up is not going to help make better coders - just more
 bad/mediocre ones.
 
 It's almost akin to saying "lets remove all prepositions from English
 to make it easier for dumber kids to speak it."  What does this do to
 the overall quality of the English language (as if it was ever that
 great to begin with)?  The result:  we're all talking like morons.


That is gravely Politically non-Correct.  :-)

But the fact remains. A serious language is for serious work. And that 
gets disturbed if the, er, wrong kind of people populate our cubicles 
/en masse/.

And hey, there is always VB for them. :-(

I've talked with quite a few programming language teachers, at 
university level. Most of them confess, that the first few weeks they go 
on like madmen, in order to get the weaker students to quit early. That 
leaves more energy and time to spend on those who really do have a 
chance of learning the stuff. Sad to say. But I feel everybody gains 
here. Even those who got "ousted", because then they can concentrate on 
other classes that better suit their talent.

-----

That said, of course D (or any good language) should be easy to use, and 
be designed to not cause unnecessary work or problems (as opposed to C++).
Apr 14 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Actually, in the C community, it's pretty much politically correct, and
generally well accepted... but it's also what killed the momentum that the
computer industry once had.  We could get that momentum back... but not if the
attitude of "only serious programming is important" is so pervasive that poeple
are discouraged from learning to "enjoy" programming.

TZ

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:425EDA0C.1090604 nospam.org...

 James Dunne wrote:

 I would like to see it simplified first because it would be better
 that way and I'm all for making it better, and second because it
 would mean that more people could learn the language who might not
 otherwise.


 Not to sound arrogant or anything... but people that could learn the
 language better with an implied main function are just the people we
 don't want programming in the first place.


 I actually don't like this being said out aloud.

 BUT, I REALLY DO AGREE HERE!


 There, someone finally said it :-P.  I, for one, am tired of looking
 at code written by bad programmers.  Dumbening (thanks Lisa Simpson)
 languages up is not going to help make better coders - just more
 bad/mediocre ones.

 It's almost akin to saying "lets remove all prepositions from English
 to make it easier for dumber kids to speak it."  What does this do to
 the overall quality of the English language (as if it was ever that
 great to begin with)?  The result:  we're all talking like morons.


 That is gravely Politically non-Correct.  :-)

 But the fact remains. A serious language is for serious work. And that
 gets disturbed if the, er, wrong kind of people populate our cubicles
 /en masse/.

 And hey, there is always VB for them. :-(

 I've talked with quite a few programming language teachers, at
 university level. Most of them confess, that the first few weeks they go
 on like madmen, in order to get the weaker students to quit early. That
 leaves more energy and time to spend on those who really do have a
 chance of learning the stuff. Sad to say. But I feel everybody gains
 here. Even those who got "ousted", because then they can concentrate on
 other classes that better suit their talent.

 -----

 That said, of course D (or any good language) should be easy to use, and
 be designed to not cause unnecessary work or problems (as opposed to C++).
Apr 14 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
What order of source files?  D uses modules. Unless someone specifically wants
a textual include, the order of the source files shouldn't make any
difference.... and when someone does want to use textual includes, they should
write their code accordingly.  Nothing problematic about that.  Just added
flexability when D programmers think like D programmers rather than like
they're still stuck in the C language.

Okay, you wanted an example?

version (Windows)
{
 MessageBoxA(null,"click OK to continue","message_box",MB_OK);
}

save as pausok.d and compile with
DMD pausok

In the current version, that wouldn't even compile... but it wouldn't take a
lot of changes to make it so that it would.  In fact, adding implied imports
and including "MessageBoxA" in the implied imports list would keep the
compilation from failing due to the lack of "import windows;" in the source
code, and version sensative automatic linking would cause the compiler to built
a properly linked executable by default, while still also producing an unlinked
object file.

You tested what? I'm not talking about long filenaes support in the language
here.  I'm talking about the Digital Mars D compiler itself.  Sorry it I was
ambiguous.  Try compiling a file named longfilename.d and you will get an error
to the effect of "C:\DM\TEST\LONGFI~1.D: module LONGFI~1 has non-identifier
characters in filename, use module declaration instead".

At least, that's what happens in Windows 98.  Maybe on another operating system
this is not the case.  The inability to compile at all is probably the "~"
character being used in the MS_DOS short filename that Windows is automatically
generated by the operating system for the benefit of programs that only support
<= 8 character long filenames with <= 3 character extensions.  The DMD compiler
apears to be one of those programs.  That's what I was suggesting should be
corrected.

Okay, now that's cool.  I'm guessing the dmd.conf is for something other than
Windows, since I don't seem to have one.  (Sounds like Linus to me.) but I
would have never thought to look for "sc.ini" though.  Any idea what the "sc"
stands for?  Anyway... thank you very much for that!  Do you know if there are
other settings that can be placed in that file, besides just modifying those
that are there by default?

No need for a virtual machine, unless you want to compile for a platform that
you don't have, and then run the resulting executable on a virtual machine...
but IDE stands to "integrated development environment" and is more than just an
editor.  The whole idea behind the IDE concept is that the editor and the
compiler are really two parts of one thing.  Integrating those two parts can
save developers a lot of trouble, especially if done well.  Microsoft Visual
Studio 6.0 is a great example of one that was done quite poorly.  Lots of nice
features, but the integration is loose and incomplete at best.

The D language was designed with integration in mind. That much is obvious. To
what extent integration between editor, linker, and compiler was intended to be
supportd, I could only guess. Ideally, the D programmer shouldn't have to
switch between an editor and a compiler and/or linker to build and run programs
as they are written.

In fact, it should even be "possible" to run hidden "simulated tests"
automatically at crucial times such as when the cursor moves out of a
particular enclosed scope, using the unittest function if one has been written
within the module. Such an option could be turned on or off from a menu, and
the preference saved automatically, rather than having to be specified as a
compiler switch at the command prompt.

Hmmm.  Crosscompiling.  Now, there's a thought I hadn't had.  Cool idea.  Not
what I was talking about though.  What I meant was that the user could pull
down a "compile" or "make" or "build" menu and choose what platform they want
to generate an executable for.  Yes, crosscompiling support would also be nice.
 Separate issue altogether, but still... cool thought.

A for your list of steps.. I've already done steps one and 3, and both step 2s.
Step 4 is why I decided to post the results of the other steps here.  :)

I agree with you.  Better to take action than to simply wish.  Much better. 
Currently, I'm not in a position to take a more active role than I am already
taking, for several reasons, but hopefully my input here will have some
motivating force or at least be unique enough to give other people who have
been actively involved in the development of D something "different" to think
about.

As for myself, I have picked a target project to write as I learn the D
language, and I'm satisfied with my choice... at this time.

TZ

"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:ads1j2-5t6.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 TechnoZeus schrieb am Thu, 14 Apr 2005 04:31:09 -0500:

 Adding the ability to have the compiler treat a missing main function
 declaration as an implication that the first line of the unenclosed code
 is the program's entry point and that reaching the end of the program
 returns 0, might require a little more integration between the ideas of
 compiling and linking, but again wouldn't change any existing programs,
 and would make it easy for someone learning the language to write very short
 practice programs to test their understanding of how the parts of it work.


 Consequence: Compiling would dependend on the order of the source files
 given - that's troublesome.


 Adding the ability to let the compiler recognize a program as being written
 for a specific environment and save the programmer the trouble of specifying
 such details as how to link it would still allow overriding of that default
 functionality, but would again make it easier for a beginner to learn.


 An example please.


 Adding long filename support to the compiler


 Just tested it and had no problems with a long(267 character) file name.


  and the ability to have it look in default relative paths for files
 that are commonly needed to compile and link a program wouldn't break
 any existing functionality, if done right, but would make the compiler
 that much easier to use... especially for beginners.


 Have a look at dmd/sc.ini dmd/dmd.conf.


 Adding a graphical user interface that allows the source code to be edited,
 and run with transparent compiling and linking for the operating system it's
 installed on, would make D as easy to use as an interpreted language, but
 without removing any of it's current advantages.


 That the job of an IDE(editing) or of an VM(interpreted) not the compiler.
 Ofcoure the VM(in the broad sence) could be integrated into the IDE and
 closely interact with the compiler.


 That same graphical interface could have menu options for compiling and
 linking to other platforms.


 Crosslinking is non-trivial. Adding crosscompiling to DMD should be
 fairly easy.


 I see no down side to any of this, except the following:  None of it will
 happen without a lot of work going into it.


 I'm sure you know what I'm going to say:

 1) analyse the situation, shortcommings, desires etc.
 2) have a vision
 2) analyse available capabilities/resource
 3) set a target
 4) aquire required capabilities/resource
 ...


 So, what it comes down to is a simple question of what's worth the effort
 it would take, and what isn't.  I think the key to it is colaboration,
 but can this be accomplished to a sufficient degree?


 If you dont start a project or join an existing to fulfill your vision
 you wont reach your target.

 In case you lack the capabilities I'm sure there peoples you could
 encourage and/or bribe into helping you.

 Thomas


 -----BEGIN PGP SIGNATURE-----

 iD8DBQFCXkKK3w+/yD4P9tIRAvNjAJ9xlakIFwarrYVwPqEzVelMlPfAEQCgjfxE
 VLHYBcpd3ujKkzWeg73bXDI=
 =i/0B
 -----END PGP SIGNATURE-----
Apr 14 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:

 Okay, you wanted an example?

 version (Windows)
 {
  MessageBoxA(null,"click OK to continue","message_box",MB_OK);
 }

 save as pausok.d and compile with
 DMD pausok

 In the current version, that wouldn't even compile... but it wouldn't take a
 lot of changes to make it so that it would.


<snip>

Anyone care to demonstrate that by patching GDC?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCX4WW3w+/yD4P9tIRAg8XAJ4qvlpnYv8txgMM4WVIo5COKVKskwCgjgeK
PbFbOo77O+7r/KmoxI5x8Rw=
=bh/f
-----END PGP SIGNATURE-----
Apr 15 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:m5d4j2-g75.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:

 Okay, you wanted an example?

 version (Windows)
 {
  MessageBoxA(null,"click OK to continue","message_box",MB_OK);
 }

 save as pausok.d and compile with
 DMD pausok

 In the current version, that wouldn't even compile... but it wouldn't take a
 lot of changes to make it so that it would.


 <snip>

 Anyone care to demonstrate that by patching GDC?

 Thomas


That would be great.  I would, if I had the time, but I'm doing all I can as it
is just to be involved in here at all.

By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html

<quote>

int main()
{
  printf("hello world\n");
  return 0;
}

</quote>

Notice that there is no "..." anywhere indicating snipped or missing lines.  It
is presented as a complete, working "Hello World" program... but it won't
compile, because even though most D programmers probably already know from C
what needs to be imported or included to make it work, the DMD compiler doesn't.

TZ
Apr 15 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:m5d4j2-g75.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:

 Okay, you wanted an example?

 version (Windows)
 {
  MessageBoxA(null,"click OK to continue","message_box",MB_OK);
 }

 save as pausok.d and compile with
 DMD pausok

 In the current version, that wouldn't even compile... but it wouldn't take a
 lot of changes to make it so that it would.


 <snip>

 Anyone care to demonstrate that by patching GDC?

 Thomas


That would be great.  I would, if I had the time, but I'm doing all I can as it
is just to be involved in here at all.

By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html

<quote>

int main()
{
  printf("hello world\n");
  return 0;
}

</quote>

Notice that there is no "..." anywhere indicating snipped or missing lines.  It
is presented as a complete, working "Hello World" program... but it won't
compile, because even though most D programmers probably already know from C
what needs to be imported or included to make it work, the DMD compiler doesn't.

TZ
Apr 15 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TechnoZeus schrieb am Fri, 15 Apr 2005 06:12:40 -0500:

 By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html


Please hand over your harddisk!


<quote>

 int main()
 {
   printf("hello world\n");
   return 0;
 }

</quote>

 Notice that there is no "..." anywhere indicating snipped or missing lines.
  It is presented as a complete, working "Hello World" program... but it won't
 compile, because even though most D programmers probably already know from 
 C what needs to be imported or included to make it work, the DMD compiler
doesn't.


Have you actually tired to compile the source above?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCX6Td3w+/yD4P9tIRArsGAKDQT9c70wELVm0xlfPS1LZcRSnvUwCgu1KM
yAMLm25GRxhcH20xOPe1kSs=
=Rq9f
-----END PGP SIGNATURE-----
Apr 15 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Hahaha.  Oops.... that's the address of the local copy that I made so I could
read it off line.  Phone modem connection here.

Okay, here's the "correct" address...

http://digitalmars.com/d/sdwest/page1.html

Sorry about that.

TZ

"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:uvk4j2-gtl.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 TechnoZeus schrieb am Fri, 15 Apr 2005 06:12:40 -0500:

 By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html


 Please hand over your harddisk!


<quote>

 int main()
 {
   printf("hello world\n");
   return 0;
 }

</quote>

 Notice that there is no "..." anywhere indicating snipped or missing lines.
  It is presented as a complete, working "Hello World" program... but it won't
 compile, because even though most D programmers probably already know from
 C what needs to be imported or included to make it work, the DMD compiler
doesn't.


 Have you actually tired to compile the source above?

 Thomas


 -----BEGIN PGP SIGNATURE-----

 iD8DBQFCX6Td3w+/yD4P9tIRArsGAKDQT9c70wELVm0xlfPS1LZcRSnvUwCgu1KM
 yAMLm25GRxhcH20xOPe1kSs=
 =Rq9f
 -----END PGP SIGNATURE-----
Apr 15 2005
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
TechnoZeus wrote:


 By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html


You mean the page at http://www.digitalmars.com/d/sdwest/index.html


 <quote>
 
 int main()
 {
   printf("hello world\n");
   return 0;
 }
 
 </quote>
 
 Notice that there is no "..." anywhere indicating snipped or missing lines.
 It is presented as a complete, working "Hello World" program...


It does compile alright? Unfortunately. I don't think it's very good...

A better introduction would be:

import std.c.stdio;
import std.c.stdlib;

int main()
{
   printf("Hello, World!\n");
   return EXIT_SUCCESS;
}

Or, perhaps more modern:

import std.stdio;

void main()
{
   writeln("Hello, World!");
}

Second program assuming that "void main" and "writeln" gets fixed/added.

--anders
Apr 15 2005
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
TechnoZeus wrote:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:m5d4j2-g75.ln1 lnews.kuehne.cn...
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:


Okay, you wanted an example?

version (Windows)
{
 MessageBoxA(null,"click OK to continue","message_box",MB_OK);
}

save as pausok.d and compile with
DMD pausok

In the current version, that wouldn't even compile... but it wouldn't take a
lot of changes to make it so that it would.


<snip>

Anyone care to demonstrate that by patching GDC?

Thomas


 
 
 That would be great.  I would, if I had the time, but I'm doing all I can as
it is just to be involved in here at all.
 
 By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html
 
 <quote>
 
 int main()
 {
   printf("hello world\n");
   return 0;
 }
 
 </quote>
 
 Notice that there is no "..." anywhere indicating snipped or missing lines. 
It is presented as a complete, working "Hello World" program... but it won't
compile, because even though most D programmers probably already know from C
what needs to be imported or included to make it work, the DMD compiler doesn't.
 
 TZ


The "magic" here is that D automatically imports object.d. If it were 
desirable (and I don't think it is), we could import the kitchen sink 
through object.d and we wouldn't need to use import for any of the 
standard library.

Several of us have been trying to convince Walter for months that the 
printf should be removed from object.d. I think it's reasonable to 
expect that the programmer will request printf explicitly with an import.


-- 
jcc7
http://jcc_7.tripod.com/d/
Apr 15 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
This misses my point though.  Rather than having just one big import that's
automatic whether you use it or not, I am suggesting that there be many
commonly used items be listed as "automatic if needed" so that no action needs
to be done to import the file containing that item other than to try to use the
item without first creating the item or explicitly importing the item.  In
other words, if it's unknown... check the list.  If it's unknown and in the
list... import it.

TZ


"J C Calvarese" <jcc7 cox.net> wrote in message
news:d3q46v$1qrh$1 digitaldaemon.com...

 TechnoZeus wrote:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:m5d4j2-g75.ln1 lnews.kuehne.cn...


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:


Okay, you wanted an example?

version (Windows)
{
 MessageBoxA(null,"click OK to continue","message_box",MB_OK);
}

save as pausok.d and compile with
DMD pausok

In the current version, that wouldn't even compile... but it wouldn't take a
lot of changes to make it so that it would.


<snip>

Anyone care to demonstrate that by patching GDC?

Thomas



 That would be great.  I would, if I had the time, but I'm doing all I can as
it is just to be involved in here at all.

 By the way, I found a good example at file:///F:/dmd/html/d/sdwest/page1.html

 <quote>

 int main()
 {
   printf("hello world\n");
   return 0;
 }

 </quote>

 Notice that there is no "..." anywhere indicating snipped or missing lines. 
It is presented as a complete, working "Hello World" program... but it won't
compile, because even though most D programmers probably already know from C
what needs to be imported or included to make it work, the DMD compiler doesn't.

 TZ


 The "magic" here is that D automatically imports object.d. If it were
 desirable (and I don't think it is), we could import the kitchen sink
 through object.d and we wouldn't need to use import for any of the
 standard library.

 Several of us have been trying to convince Walter for months that the
 printf should be removed from object.d. I think it's reasonable to
 expect that the programmer will request printf explicitly with an import.


 -- 
 jcc7
 http://jcc_7.tripod.com/d/
Apr 19 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:

 This misses my point though.  Rather than having just one big import
 that's automatic whether you use it or not, I am suggesting that
 there be many commonly used items be listed as "automatic if needed"
 so that no action needs to be done to import the file containing that
 item other than to try to use the item without first creating the
 item or explicitly importing the item.  In other words, if it's
 unknown... check the list.  If it's unknown and in the list... import
 it.


This guy is starting to make sense. If we have "Standard Libraries" in 
D, then it is not entirely too far-fetced to automate the inclusion of 
them -- in "regular programs".


 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d3q46v$1qrh$1 digitaldaemon.com...
 

 TechnoZeus wrote:
 

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in
 message news:m5d4j2-g75.ln1 lnews.kuehne.cn...
 
 

 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
 
 TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:
 
 

 Okay, you wanted an example?
 
 version (Windows) { MessageBoxA(null,"click OK to
 continue","message_box",MB_OK); }
 
 save as pausok.d and compile with DMD pausok
 
 In the current version, that wouldn't even compile... but it
 wouldn't take a lot of changes to make it so that it would.


 
 <snip>
 
 Anyone care to demonstrate that by patching GDC?
 
 Thomas
 
 


 
 
 That would be great.  I would, if I had the time, but I'm doing
 all I can as it is just to be involved in here at all.
 
 By the way, I found a good example at
 file:///F:/dmd/html/d/sdwest/page1.html
 
 <quote>
 
 int main() { printf("hello world\n"); return 0; }
 
 </quote>
 
 Notice that there is no "..." anywhere indicating snipped or
 missing lines.  It is presented as a complete, working "Hello
 World" program... but it won't compile, because even though most
 D programmers probably already know from C what needs to be
 imported or included to make it work, the DMD compiler doesn't.
 
 TZ


 
 The "magic" here is that D automatically imports object.d. If it
 were desirable (and I don't think it is), we could import the
 kitchen sink through object.d and we wouldn't need to use import
 for any of the standard library.
 
 Several of us have been trying to convince Walter for months that
 the printf should be removed from object.d. I think it's reasonable
 to expect that the programmer will request printf explicitly with
 an import.




Printf _should_ be removed from the language _entirely_. If someone 
wants to use it, then let him import (ehh, something like) std.c.stdio, 
or whatever.

What's the point of bragging with a smoother and more consistent 
language, if at the same time something as arcane as printf is imported 
by default??
Apr 19 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 20 Apr 2005 01:36:31 +0300, Georg Wrede wrote:


 TechnoZeus wrote:

 This misses my point though.  Rather than having just one big import
 that's automatic whether you use it or not, I am suggesting that
 there be many commonly used items be listed as "automatic if needed"
 so that no action needs to be done to import the file containing that
 item other than to try to use the item without first creating the
 item or explicitly importing the item.  In other words, if it's
 unknown... check the list.  If it's unknown and in the list... import
 it.


 
 This guy is starting to make sense. If we have "Standard Libraries" in 
 D, then it is not entirely too far-fetced to automate the inclusion of 
 them -- in "regular programs".


Funny you should say this...I'm currently putting this sort of thing into
my Build utility.
 

[snip]
 

 Printf _should_ be removed from the language _entirely_. If someone 
 wants to use it, then let him import (ehh, something like) std.c.stdio, 
 or whatever.
 
 What's the point of bragging with a smoother and more consistent 
 language, if at the same time something as arcane as printf is imported 
 by default??


Gets my vote!

-- 
Derek
Melbourne, Australia
20/04/2005 9:14:44 AM
Apr 19 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Ah, finally... someone understood me.  Thank you!  :)

TZ

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:426587EF.3000808 nospam.org...

 TechnoZeus wrote:

 This misses my point though.  Rather than having just one big import
 that's automatic whether you use it or not, I am suggesting that
 there be many commonly used items be listed as "automatic if needed"
 so that no action needs to be done to import the file containing that
 item other than to try to use the item without first creating the
 item or explicitly importing the item.  In other words, if it's
 unknown... check the list.  If it's unknown and in the list... import
 it.


 This guy is starting to make sense. If we have "Standard Libraries" in
 D, then it is not entirely too far-fetced to automate the inclusion of
 them -- in "regular programs".


 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d3q46v$1qrh$1 digitaldaemon.com...


 TechnoZeus wrote:


 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in
 message news:m5d4j2-g75.ln1 lnews.kuehne.cn...



 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

 TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:



 Okay, you wanted an example?

 version (Windows) { MessageBoxA(null,"click OK to
 continue","message_box",MB_OK); }

 save as pausok.d and compile with DMD pausok

 In the current version, that wouldn't even compile... but it
 wouldn't take a lot of changes to make it so that it would.


 <snip>

 Anyone care to demonstrate that by patching GDC?

 Thomas



 That would be great.  I would, if I had the time, but I'm doing
 all I can as it is just to be involved in here at all.

 By the way, I found a good example at
 file:///F:/dmd/html/d/sdwest/page1.html

 <quote>

 int main() { printf("hello world\n"); return 0; }

 </quote>

 Notice that there is no "..." anywhere indicating snipped or
 missing lines.  It is presented as a complete, working "Hello
 World" program... but it won't compile, because even though most
 D programmers probably already know from C what needs to be
 imported or included to make it work, the DMD compiler doesn't.

 TZ


 The "magic" here is that D automatically imports object.d. If it
 were desirable (and I don't think it is), we could import the
 kitchen sink through object.d and we wouldn't need to use import
 for any of the standard library.

 Several of us have been trying to convince Walter for months that
 the printf should be removed from object.d. I think it's reasonable
 to expect that the programmer will request printf explicitly with
 an import.




 Printf _should_ be removed from the language _entirely_. If someone
 wants to use it, then let him import (ehh, something like) std.c.stdio,
 or whatever.

 What's the point of bragging with a smoother and more consistent
 language, if at the same time something as arcane as printf is imported
 by default??
Apr 20 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:

 This misses my point though.  Rather than having just one big import
 that's automatic whether you use it or not, I am suggesting that
 there be many commonly used items be listed as "automatic if needed"


The more I think about this, the more I find it difficult to oppose it.

I do, however, also see a lot of specters and demons rising up the wall.

How would this combine with the "(compiler or linker) skip what's not 
actually used"?

OTOH, if this falls in the same category as "why should you write a Main 
Procedure, if all you do is a bunch of commands in series", then I'd 
oppose to this, vehemently. (I.e. there needs to be a more valid reason 
for "automatic imports", whether they mean only Phobos, or imports in 
general.)
Apr 19 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:42658940.9080500 nospam.org...

 TechnoZeus wrote:

 This misses my point though.  Rather than having just one big import
 that's automatic whether you use it or not, I am suggesting that
 there be many commonly used items be listed as "automatic if needed"


 The more I think about this, the more I find it difficult to oppose it.

 I do, however, also see a lot of specters and demons rising up the wall.

 How would this combine with the "(compiler or linker) skip what's not
 actually used"?

 OTOH, if this falls in the same category as "why should you write a Main
 Procedure, if all you do is a bunch of commands in series", then I'd
 oppose to this, vehemently. (I.e. there needs to be a more valid reason
 for "automatic imports", whether they mean only Phobos, or imports in
 general.)


Simple... If it's not called, don't implicitly import it.  If it's not
imported... there's nothing to skip.

Unfortunately, I think you still don't understand my reasoning behind the idea
of not "requiring" superflous code such as a "main" function declaration, but
that's probably just because it's not something you have ever seen any use
for... and I don't think it would be easy for me to get around your inability
to see past what you have no experience with... but anyway, that I idea and the
concept of implicit imports are entirely independant of each other.

TZ
Apr 20 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:


 Unfortunately, I think you still don't understand my reasoning behind
 the idea of not "requiring" superflous code such as a "main" function
 declaration, but that's probably just because it's not something you
 have ever seen any use for... and I don't think it would be easy for
 me to get around your inability to see past what you have no
 experience with... but anyway, that I idea and the concept of
 implicit imports are entirely independant of each other.


I guess I don't.

All I can say is, I started with Fortran, then went to Basic (on 
Commodore VIC-20, Kaypro-II CP/M, then GW-Basic on MS-DOS.

Then I switched to Turbo Pascal, around 1983. (At that time I also got 
my first computer job, as the operator of a unix machine (Data General 
16-user Super Micro, running DG-AOS).)

When I started with Pascal, I did feel that it's a chore to write

   program myprog;

   uses crt;

   const
     myconst = 37;

   var
     myvar1, myvar2 : Integer;

   begin
     {start writing here}

   end.

just to get even started to program anything. But I got used to it. Then 
I wrote C, C++ and Java progs, and all of them required "superfluous 
crap" to be written before you come to your own stuff.

But then I realized that this is just an illusion. It looks like a chore 
when you do 5-line programs. There the "obligatory crap" outnumbers 
"your own" code. But as soon as you get to 50 lines (a paper page), this 
superfluos stuff just diminishes out of sight. And when you write 10000 
line programs, you don't even notice.

Today, I also use languages where you don't "need to do the crap". Shell 
scripts, Perl, Euphoria. It's "your own code" all the way, and no "crap".

But you're right: I don't see your point.

Maybe you should explain it "like to a child", slow and precisely. I may 
not even be the only one who has a hard time understanding your point.

(And yes, this and the implicit imports are separate issues.)
Apr 20 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
But that is exactly my point...
If you don't even notice it, then it is obviously of no importance to you.
What is important, you notice.

For example, if you want your main function to take in a single integer
argument rather than the usual array or arrays of characters,
then you will "want" to write your main function accordingly.
If you don't even care whether or not you "have" a "main" function,
or what it's called,
then why should you have to type it at all?

Yes, I agree that in larger programs those few extra lines don't ammount to
much...
but I also realize that as long as they are "required" nobody can start
programming without them.
This means that rather than being able to look at any existing program and pick
out one line to learn the meaning of,
it becomes necessary for the beginning programmer to find useless programs to
learn from,
that exist only for the purpose of showing newbies the minimum amount of
un-needed junk necessary to begin programming.
This means that their first lessons in programming are first to plagiarize
someone else's junk (litterally) and second, to ignore it rather than
understand it.
Not good lessons to start a newbie off with.

TZ


"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:426624DC.6030309 nospam.org...

 TechnoZeus wrote:


 Unfortunately, I think you still don't understand my reasoning behind
 the idea of not "requiring" superflous code such as a "main" function
 declaration, but that's probably just because it's not something you
 have ever seen any use for... and I don't think it would be easy for
 me to get around your inability to see past what you have no
 experience with... but anyway, that I idea and the concept of
 implicit imports are entirely independant of each other.


 I guess I don't.

 All I can say is, I started with Fortran, then went to Basic (on
 Commodore VIC-20, Kaypro-II CP/M, then GW-Basic on MS-DOS.

 Then I switched to Turbo Pascal, around 1983. (At that time I also got
 my first computer job, as the operator of a unix machine (Data General
 16-user Super Micro, running DG-AOS).)

 When I started with Pascal, I did feel that it's a chore to write

    program myprog;

    uses crt;

    const
      myconst = 37;

    var
      myvar1, myvar2 : Integer;

    begin
      {start writing here}

    end.

 just to get even started to program anything. But I got used to it. Then
 I wrote C, C++ and Java progs, and all of them required "superfluous
 crap" to be written before you come to your own stuff.

 But then I realized that this is just an illusion. It looks like a chore
 when you do 5-line programs. There the "obligatory crap" outnumbers
 "your own" code. But as soon as you get to 50 lines (a paper page), this
 superfluos stuff just diminishes out of sight. And when you write 10000
 line programs, you don't even notice.

 Today, I also use languages where you don't "need to do the crap". Shell
 scripts, Perl, Euphoria. It's "your own code" all the way, and no "crap".

 But you're right: I don't see your point.

 Maybe you should explain it "like to a child", slow and precisely. I may
 not even be the only one who has a hard time understanding your point.

 (And yes, this and the implicit imports are separate issues.)
Apr 20 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:

 But that is exactly my point... If you don't even notice it, then it
 is obviously of no importance to you. What is important, you notice.
 
 For example, if you want your main function to take in a single
 integer argument rather than the usual array or arrays of characters,
  then you will "want" to write your main function accordingly. If you
 don't even care whether or not you "have" a "main" function, or what
 it's called, then why should you have to type it at all?
 
 Yes, I agree that in larger programs those few extra lines don't
 ammount to much... but I also realize that as long as they are
 "required" nobody can start programming without them. This means that
 rather than being able to look at any existing program and pick out
 one line to learn the meaning of, it becomes necessary for the
 beginning programmer to find useless programs to learn from, that
 exist only for the purpose of showing newbies the minimum amount of
 un-needed junk necessary to begin programming. This means that their
 first lessons in programming are first to plagiarize someone else's
 junk (litterally) and second, to ignore it rather than understand it.
  Not good lessons to start a newbie off with.


Ok, I now see your point.

However, I don't agree with it.

Furthermore, I expect that to convince Matthew, and some of the other
"opinion makers" around here, you'll have a heck of a job in doing so.

And, to get Walter to see it your way -- boy would I be surprised.

----

You might consider writing a template. That is, a file called unnamed.d, 
that contains "all the obligatory crap" needed before you come to your 
own code. Then save it, and click it with the "other" mouse button, 
choose Properties, and there Attributes. Check the Read-only box.

This way, each time you start programming, just open this file, and 
you'll have the "obligatories" taken care of. (That's why we have 
computers: to do the drudgery for us!)

And when you save, your editor will refuse, whereby you'll remember to 
save it under another name.

Problem solved.

You might even create an icon for that file on your desktop, so by 
double-clicking it you're ready to fly -- instantly!



 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:426624DC.6030309 nospam.org...
 

 TechnoZeus wrote:
 
 

 Unfortunately, I think you still don't understand my reasoning
 behind the idea of not "requiring" superflous code such as a
 "main" function declaration, but that's probably just because
 it's not something you have ever seen any use for... and I don't
 think it would be easy for me to get around your inability to see
 past what you have no experience with... but anyway, that I idea
 and the concept of implicit imports are entirely independant of
 each other.


 
 I guess I don't.
 
 All I can say is, I started with Fortran, then went to Basic (on 
 Commodore VIC-20, Kaypro-II CP/M, then GW-Basic on MS-DOS.
 
 Then I switched to Turbo Pascal, around 1983. (At that time I also
 got my first computer job, as the operator of a unix machine (Data
 General 16-user Super Micro, running DG-AOS).)
 
 When I started with Pascal, I did feel that it's a chore to write
 
 program myprog;
 
 uses crt;
 
 const myconst = 37;
 
 var myvar1, myvar2 : Integer;
 
 begin {start writing here}
 
 end.
 
 just to get even started to program anything. But I got used to it.
 Then I wrote C, C++ and Java progs, and all of them required
 "superfluous crap" to be written before you come to your own stuff.
 
 
 But then I realized that this is just an illusion. It looks like a
 chore when you do 5-line programs. There the "obligatory crap"
 outnumbers "your own" code. But as soon as you get to 50 lines (a
 paper page), this superfluos stuff just diminishes out of sight.
 And when you write 10000 line programs, you don't even notice.
 
 Today, I also use languages where you don't "need to do the crap".
 Shell scripts, Perl, Euphoria. It's "your own code" all the way,
 and no "crap".
 
 But you're right: I don't see your point.
 
 Maybe you should explain it "like to a child", slow and precisely.
 I may not even be the only one who has a hard time understanding
 your point.
 
 (And yes, this and the implicit imports are separate issues.)
Apr 20 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
That wouldn't solve the issue though.
The issue isn't whether or not "my programs" have a few extra lines of code in..
them that really didn't need to be there other than to get the compiler to
"work"...
but rather that anyone learning the language has to jump that hurdle before
they can start running,
and it's liable to trip a lot of them.

Making a template that contains
all the things that the compiler could safely "assume" would
require the person using the template to know that all that stuff is needed,
where to find the template that contains it,
and how to put that template to use.
This is no easier for an absolute beginner than what we have now.

TZ

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:42665C79.90108 nospam.org...

 TechnoZeus wrote:

 But that is exactly my point... If you don't even notice it, then it
 is obviously of no importance to you. What is important, you notice.

 For example, if you want your main function to take in a single
 integer argument rather than the usual array or arrays of characters,
  then you will "want" to write your main function accordingly. If you
 don't even care whether or not you "have" a "main" function, or what
 it's called, then why should you have to type it at all?

 Yes, I agree that in larger programs those few extra lines don't
 ammount to much... but I also realize that as long as they are
 "required" nobody can start programming without them. This means that
 rather than being able to look at any existing program and pick out
 one line to learn the meaning of, it becomes necessary for the
 beginning programmer to find useless programs to learn from, that
 exist only for the purpose of showing newbies the minimum amount of
 un-needed junk necessary to begin programming. This means that their
 first lessons in programming are first to plagiarize someone else's
 junk (litterally) and second, to ignore it rather than understand it.
  Not good lessons to start a newbie off with.


 Ok, I now see your point.

 However, I don't agree with it.

 Furthermore, I expect that to convince Matthew, and some of the other
 "opinion makers" around here, you'll have a heck of a job in doing so.

 And, to get Walter to see it your way -- boy would I be surprised.

 ----

 You might consider writing a template. That is, a file called unnamed.d,
 that contains "all the obligatory crap" needed before you come to your
 own code. Then save it, and click it with the "other" mouse button,
 choose Properties, and there Attributes. Check the Read-only box.

 This way, each time you start programming, just open this file, and
 you'll have the "obligatories" taken care of. (That's why we have
 computers: to do the drudgery for us!)

 And when you save, your editor will refuse, whereby you'll remember to
 save it under another name.

 Problem solved.

 You might even create an icon for that file on your desktop, so by
 double-clicking it you're ready to fly -- instantly!



 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:426624DC.6030309 nospam.org...


 TechnoZeus wrote:



 Unfortunately, I think you still don't understand my reasoning
 behind the idea of not "requiring" superflous code such as a
 "main" function declaration, but that's probably just because
 it's not something you have ever seen any use for... and I don't
 think it would be easy for me to get around your inability to see
 past what you have no experience with... but anyway, that I idea
 and the concept of implicit imports are entirely independant of
 each other.


 I guess I don't.

 All I can say is, I started with Fortran, then went to Basic (on
 Commodore VIC-20, Kaypro-II CP/M, then GW-Basic on MS-DOS.

 Then I switched to Turbo Pascal, around 1983. (At that time I also
 got my first computer job, as the operator of a unix machine (Data
 General 16-user Super Micro, running DG-AOS).)

 When I started with Pascal, I did feel that it's a chore to write

 program myprog;

 uses crt;

 const myconst = 37;

 var myvar1, myvar2 : Integer;

 begin {start writing here}

 end.

 just to get even started to program anything. But I got used to it.
 Then I wrote C, C++ and Java progs, and all of them required
 "superfluous crap" to be written before you come to your own stuff.


 But then I realized that this is just an illusion. It looks like a
 chore when you do 5-line programs. There the "obligatory crap"
 outnumbers "your own" code. But as soon as you get to 50 lines (a
 paper page), this superfluos stuff just diminishes out of sight.
 And when you write 10000 line programs, you don't even notice.

 Today, I also use languages where you don't "need to do the crap".
 Shell scripts, Perl, Euphoria. It's "your own code" all the way,
 and no "crap".

 But you're right: I don't see your point.

 Maybe you should explain it "like to a child", slow and precisely.
 I may not even be the only one who has a hard time understanding
 your point.

 (And yes, this and the implicit imports are separate issues.)
Apr 20 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:

 That wouldn't solve the issue though. The issue isn't whether or not
 "my programs" have a few extra lines of code in.. them that really
 didn't need to be there other than to get the compiler to "work"... 
 but rather that anyone learning the language has to jump that hurdle
 before they can start running, and it's liable to trip a lot of them.
 
 
 Making a template that contains all the things that the compiler
 could safely "assume" would require the person using the template to
 know that all that stuff is needed, where to find the template that
 contains it, and how to put that template to use. This is no easier
 for an absolute beginner than what we have now.


Ok. I give up.


 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:42665C79.90108 nospam.org...
 

 TechnoZeus wrote:
 

 But that is exactly my point... If you don't even notice it, then
 it is obviously of no importance to you. What is important, you
 notice.
 
 For example, if you want your main function to take in a single 
 integer argument rather than the usual array or arrays of
 characters, then you will "want" to write your main function
 accordingly. If you don't even care whether or not you "have" a
 "main" function, or what it's called, then why should you have to
 type it at all?
 
 Yes, I agree that in larger programs those few extra lines don't 
 ammount to much... but I also realize that as long as they are 
 "required" nobody can start programming without them. This means
 that rather than being able to look at any existing program and
 pick out one line to learn the meaning of, it becomes necessary
 for the beginning programmer to find useless programs to learn
 from, that exist only for the purpose of showing newbies the
 minimum amount of un-needed junk necessary to begin programming.
 This means that their first lessons in programming are first to
 plagiarize someone else's junk (litterally) and second, to ignore
 it rather than understand it. Not good lessons to start a newbie
 off with.


 
 Ok, I now see your point.
 
 However, I don't agree with it.
 
 Furthermore, I expect that to convince Matthew, and some of the
 other "opinion makers" around here, you'll have a heck of a job in
 doing so.
 
 And, to get Walter to see it your way -- boy would I be surprised.
 
 ----
 
 You might consider writing a template. That is, a file called
 unnamed.d, that contains "all the obligatory crap" needed before
 you come to your own code. Then save it, and click it with the
 "other" mouse button, choose Properties, and there Attributes.
 Check the Read-only box.
 
 This way, each time you start programming, just open this file, and
  you'll have the "obligatories" taken care of. (That's why we have 
 computers: to do the drudgery for us!)
 
 And when you save, your editor will refuse, whereby you'll remember
 to save it under another name.
 
 Problem solved.
 
 You might even create an icon for that file on your desktop, so by 
 double-clicking it you're ready to fly -- instantly!
 
 
 

 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:426624DC.6030309 nospam.org...
 
 

 TechnoZeus wrote:
 
 
 

 Unfortunately, I think you still don't understand my
 reasoning behind the idea of not "requiring" superflous code
 such as a "main" function declaration, but that's probably
 just because it's not something you have ever seen any use
 for... and I don't think it would be easy for me to get
 around your inability to see past what you have no experience
 with... but anyway, that I idea and the concept of implicit
 imports are entirely independant of each other.


 
 I guess I don't.
 
 All I can say is, I started with Fortran, then went to Basic
 (on Commodore VIC-20, Kaypro-II CP/M, then GW-Basic on MS-DOS.
 
 Then I switched to Turbo Pascal, around 1983. (At that time I
 also got my first computer job, as the operator of a unix
 machine (Data General 16-user Super Micro, running DG-AOS).)
 
 When I started with Pascal, I did feel that it's a chore to
 write
 
 program myprog;
 
 uses crt;
 
 const myconst = 37;
 
 var myvar1, myvar2 : Integer;
 
 begin {start writing here}
 
 end.
 
 just to get even started to program anything. But I got used to
 it. Then I wrote C, C++ and Java progs, and all of them
 required "superfluous crap" to be written before you come to
 your own stuff.
 
 
 But then I realized that this is just an illusion. It looks
 like a chore when you do 5-line programs. There the "obligatory
 crap" outnumbers "your own" code. But as soon as you get to 50
 lines (a paper page), this superfluos stuff just diminishes out
 of sight. And when you write 10000 line programs, you don't
 even notice.
 
 Today, I also use languages where you don't "need to do the
 crap". Shell scripts, Perl, Euphoria. It's "your own code" all
 the way, and no "crap".
 
 But you're right: I don't see your point.
 
 Maybe you should explain it "like to a child", slow and
 precisely. I may not even be the only one who has a hard time
 understanding your point.
 
 (And yes, this and the implicit imports are separate issues.)
Apr 20 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Well, I would rather have you support the idea than oppose it,
but I think I would also rather have you oppose the idea than give up.

After all, either it's a good idea or it's not...
and your opinion counts at least as much as mine does...
probably more, because I'm rather new here.

Up to you though.  If you choose to just let it drop, I will understand.
Sometimes a neutral position is the only comfortable one.  It happens.

TZ

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4266E3AC.6040307 nospam.org...

 TechnoZeus wrote:

 That wouldn't solve the issue though. The issue isn't whether or not
 "my programs" have a few extra lines of code in.. them that really
 didn't need to be there other than to get the compiler to "work"...
 but rather that anyone learning the language has to jump that hurdle
 before they can start running, and it's liable to trip a lot of them.


 Making a template that contains all the things that the compiler
 could safely "assume" would require the person using the template to
 know that all that stuff is needed, where to find the template that
 contains it, and how to put that template to use. This is no easier
 for an absolute beginner than what we have now.


 Ok. I give up.


 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:42665C79.90108 nospam.org...


 TechnoZeus wrote:


 But that is exactly my point... If you don't even notice it, then
 it is obviously of no importance to you. What is important, you
 notice.

 For example, if you want your main function to take in a single
 integer argument rather than the usual array or arrays of
 characters, then you will "want" to write your main function
 accordingly. If you don't even care whether or not you "have" a
 "main" function, or what it's called, then why should you have to
 type it at all?

 Yes, I agree that in larger programs those few extra lines don't
 ammount to much... but I also realize that as long as they are
 "required" nobody can start programming without them. This means
 that rather than being able to look at any existing program and
 pick out one line to learn the meaning of, it becomes necessary
 for the beginning programmer to find useless programs to learn
 from, that exist only for the purpose of showing newbies the
 minimum amount of un-needed junk necessary to begin programming.
 This means that their first lessons in programming are first to
 plagiarize someone else's junk (litterally) and second, to ignore
 it rather than understand it. Not good lessons to start a newbie
 off with.


 Ok, I now see your point.

 However, I don't agree with it.

 Furthermore, I expect that to convince Matthew, and some of the
 other "opinion makers" around here, you'll have a heck of a job in
 doing so.

 And, to get Walter to see it your way -- boy would I be surprised.

 ----

 You might consider writing a template. That is, a file called
 unnamed.d, that contains "all the obligatory crap" needed before
 you come to your own code. Then save it, and click it with the
 "other" mouse button, choose Properties, and there Attributes.
 Check the Read-only box.

 This way, each time you start programming, just open this file, and
  you'll have the "obligatories" taken care of. (That's why we have
 computers: to do the drudgery for us!)

 And when you save, your editor will refuse, whereby you'll remember
 to save it under another name.

 Problem solved.

 You might even create an icon for that file on your desktop, so by
 double-clicking it you're ready to fly -- instantly!




 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:426624DC.6030309 nospam.org...



 TechnoZeus wrote:




 Unfortunately, I think you still don't understand my
 reasoning behind the idea of not "requiring" superflous code
 such as a "main" function declaration, but that's probably
 just because it's not something you have ever seen any use
 for... and I don't think it would be easy for me to get
 around your inability to see past what you have no experience
 with... but anyway, that I idea and the concept of implicit
 imports are entirely independant of each other.


 I guess I don't.

 All I can say is, I started with Fortran, then went to Basic
 (on Commodore VIC-20, Kaypro-II CP/M, then GW-Basic on MS-DOS.

 Then I switched to Turbo Pascal, around 1983. (At that time I
 also got my first computer job, as the operator of a unix
 machine (Data General 16-user Super Micro, running DG-AOS).)

 When I started with Pascal, I did feel that it's a chore to
 write

 program myprog;

 uses crt;

 const myconst = 37;

 var myvar1, myvar2 : Integer;

 begin {start writing here}

 end.

 just to get even started to program anything. But I got used to
 it. Then I wrote C, C++ and Java progs, and all of them
 required "superfluous crap" to be written before you come to
 your own stuff.


 But then I realized that this is just an illusion. It looks
 like a chore when you do 5-line programs. There the "obligatory
 crap" outnumbers "your own" code. But as soon as you get to 50
 lines (a paper page), this superfluos stuff just diminishes out
 of sight. And when you write 10000 line programs, you don't
 even notice.

 Today, I also use languages where you don't "need to do the
 crap". Shell scripts, Perl, Euphoria. It's "your own code" all
 the way, and no "crap".

 But you're right: I don't see your point.

 Maybe you should explain it "like to a child", slow and
 precisely. I may not even be the only one who has a hard time
 understanding your point.

 (And yes, this and the implicit imports are separate issues.)
Apr 20 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 20 Apr 2005 18:38:13 -0500, TechnoZeus wrote:

...a whole lot of top posted stuff...

Can I please suggest that you place your reply to a post an the bottom of
the original post, and also snip out the stuff in the original post that
are not relevant to your reply.

That way, we can see what (specifically) you are replying to, and we don't
have to re-read the rest of the original post that isn't germane to your
reply.

I see that you are using Outlook Express and I know that the MS tool does
not encourage good posting etiquette, so you will have to make a bit of
conscious effort to help us. Alternatively, you might like to try one of
the many better news reader tools. I use 40Tude Dialog, but there a many
good ones out there.

-- 
Derek
Melbourne, Australia
21/04/2005 10:38:07 AM
Apr 20 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1lxl070gexoie$.1f0dgjutmv2mk$.dlg 40tude.net...

 On Wed, 20 Apr 2005 18:38:13 -0500, TechnoZeus wrote:

 ...a whole lot of top posted stuff...

 Can I please suggest that you place your reply to a post an the bottom of
 the original post, and also snip out the stuff in the original post that
 are not relevant to your reply.

 That way, we can see what (specifically) you are replying to, and we don't
 have to re-read the rest of the original post that isn't germane to your
 reply.

 I see that you are using Outlook Express and I know that the MS tool does
 not encourage good posting etiquette, so you will have to make a bit of
 conscious effort to help us. Alternatively, you might like to try one of
 the many better news reader tools. I use 40Tude Dialog, but there a many
 good ones out there.

 -- 
 Derek
 Melbourne, Australia
 21/04/2005 10:38:07 AM


Actually, I prefer adding to the top rather than the bottom, for several
reasons.
To name a couple, it usually makes it clearer who said what,
and it saves people having to scroll before they can start reading.
Yes, I know some readers open already scrolled to the bottom,
but that is a fault in my opinion, since they do it even if nothing is quoted.

I do, however, try to remember to type at the bottom when I have
learned that the person I am responding to apears to prefer it that way,
or when the quoted text has that format established as a pattern.

This "difference in style" isn't a matter of one way is better than the other.
If it was, there would be some consistancy.
I've been around enough to realize, there's not.

Regardless, your comments are appreciated.
One more opinion to take into consideration.
Thanks.


TZ
Apr 20 2005
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d46jrs$1e27$1 digitaldaemon.com>, TechnoZeus says...

Making a template that contains
all the things that the compiler could safely "assume" would
require the person using the template to know that all that stuff is needed,
where to find the template that contains it,
and how to put that template to use.
This is no easier for an absolute beginner than what we have now.

TZ


The imports declarations allow you to write replacements for standard library
components.  You can write your own stream stuff or (more commonly) replace the
garbage collector with a custom version.

It also insulates you from changes in the parts of those libraries you don't
use.  If I have a function called "insert" or "read" it will conflict with the
std.string and std.file libraries respectively.  This can be nuisance, but you
can use private imports to control the level of "inclusion".

They also provide more efficient linkage.  Every module can include "static
init" code.  If your program does not use regex, it should not run the static
init for that module.  If it is linked in, it will get run.  It will probably
pull in the rest of the module.  This is a source of bloat.

Languages like Java would not technically need the "import", because you can say
"java.strings.foo" and specify the path to the code as the namespace.  These
languages suffer from a lack of flexibility as a result.  You cannot have two
defnitions of a class and "include<>" or "import" the one you want.  Instead,
you need to go through all the code and specify the new classname everywhere.

Often when refactoring a program, you can rename the main() function and modify
it slightly.  Then you write a new main() function that calls the old one.  It
is a big help to have all the code in one place, instead of having to search
through the "primary" file, looking for non-definitions that must therefore be
"part of main".

Basically, the "junk" serves a purpose.  It was added for a reason.  If you take
time to understand the reasons, the reasons can lead you down the path to
leverage more utility from the language.  Like a good mathematical proof, that
can serve as a guide to doing the calculation the proof is related to.

Kevin
Apr 21 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Right, but you are overlooking an important fact.

Having something that you didn't define or explicitly import get implicitly
imported wouldn't effect "any" of what you just said.
All it would do is allow people to let the compiler pick standard versions of
things that they chose to use without explicitly importing or writing
definitions for.

TZ

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d4a055$1j52$1 digitaldaemon.com...

 In article <d46jrs$1e27$1 digitaldaemon.com>, TechnoZeus says...

Making a template that contains
all the things that the compiler could safely "assume" would
require the person using the template to know that all that stuff is needed,
where to find the template that contains it,
and how to put that template to use.
This is no easier for an absolute beginner than what we have now.

TZ


 The imports declarations allow you to write replacements for standard library
 components.  You can write your own stream stuff or (more commonly) replace the
 garbage collector with a custom version.

 It also insulates you from changes in the parts of those libraries you don't
 use.  If I have a function called "insert" or "read" it will conflict with the
 std.string and std.file libraries respectively.  This can be nuisance, but you
 can use private imports to control the level of "inclusion".

 They also provide more efficient linkage.  Every module can include "static
 init" code.  If your program does not use regex, it should not run the static
 init for that module.  If it is linked in, it will get run.  It will probably
 pull in the rest of the module.  This is a source of bloat.

 Languages like Java would not technically need the "import", because you can
say
 "java.strings.foo" and specify the path to the code as the namespace.  These
 languages suffer from a lack of flexibility as a result.  You cannot have two
 defnitions of a class and "include<>" or "import" the one you want.  Instead,
 you need to go through all the code and specify the new classname everywhere.

 Often when refactoring a program, you can rename the main() function and modify
 it slightly.  Then you write a new main() function that calls the old one.  It
 is a big help to have all the code in one place, instead of having to search
 through the "primary" file, looking for non-definitions that must therefore be
 "part of main".

 Basically, the "junk" serves a purpose.  It was added for a reason.  If you
take
 time to understand the reasons, the reasons can lead you down the path to
 leverage more utility from the language.  Like a good mathematical proof, that
 can serve as a guide to doing the calculation the proof is related to.

 Kevin
Apr 22 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4a7q6$1rnf$1 digitaldaemon.com>, TechnoZeus says...

Right, but you are overlooking an important fact.

Having something that you didn't define or explicitly import get implicitly 
imported wouldn't effect "any" of what you just said.

All it would do is allow people to let the compiler pick standard versions of 
things that they chose to use without explicitly importing or writing 
definitions for.

TZ


This is mostly true, if your program is complete and correct.  But most compiles
are of broken or incomplete programs.  Compilation/repair cycles are a big part
of code development.

If you make an error anywhere in your program, several things happen:

1. For every mistake (mistyped identifier), the standard library is searched.
This clobbers compile time.  The compile time for a broken file (to get error
messages) is quite important during the coding phase.

2. In some cases, the ident will be found somewhere.  If it's the wrong module
or function, you get a "bogus" error message about parameters or conversion.
Worse, it matches and is a silent bug.  (To prevent this, you need to have a
familiarity with everything in the standard libraries...)

3. Even for correct programs, using a standard library symbol requires searching
every file in the library.

Implicit inclusion essentially throws everything into one namespace.  It gets
worse when libraries and programs get bigger (M*N).

The technique does work well for a "small" language, however.  The languages
that are used inside spreadsheets, databases, and other "extensible" systems
usually don't require "importing" anything.

Kevin
Apr 22 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Ah, okay.  I see the delema there.

Yes, if you assume "implicit imports" to happen where ever the compiler can
possibly find a way to make them happen,
that would be a very bad thing in indead.

What I am proposing is not implicit imports of every undefined identifier that
the compiler can find a match to in the available libraries.

What I am proposing also would not require (or even allow) the compiler to
"search" for a match to an undefined identifier.

What I am proposing is that the compiler be supplied with a list of known
identifiers that are used so commonly that people talk about them as if they
are a part of the language,
but that are not actually "built into" the language.

The only thing that the compiler would be required to search when an undefined
identifier is found would be the list of default locations for commonly used
identifiers.

Specifically, I'm talking about those identifiers that you find mentioned in
books, tutorials, and general conversation,
as if "everybody knows where they are defined" or worse yet, as if they are
defined as a part of the language specifications, when in fact they are not.

Face it. If all of the standard libraries were taken away, there are
very few people who could write a program in D or C or C++ that would
serve any useful purpose.

As such, some of the "standard library" features are treated by experienced
programmers as if they are built in.

This causes a potential problem for newbies who attempt to use the features
that they hear or read about only to find that their "properly written" code
will not compile.

Yes, I know D is not meant to be a language for newbies...
but this feature would make it more accessible to them,
and wouldn't hurt anything.

Why make people who are totally new to porgramming have to learn another
language before they start learning D?
The only two things that I can see keeping D from being
easy to learn as a "first" programming language are,
the fact that the programmer can't possibly write a single command and test
it...
and the fact that even in once a proper "shell of a program" is written to test
a single command in,
many of the commands that they are lead to expect to work without importing
anything...
won't.

TZ



"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d4cbva$l11$1 digitaldaemon.com...

 In article <d4a7q6$1rnf$1 digitaldaemon.com>, TechnoZeus says...

Right, but you are overlooking an important fact.

Having something that you didn't define or explicitly import get implicitly
imported wouldn't effect "any" of what you just said.

All it would do is allow people to let the compiler pick standard versions of
things that they chose to use without explicitly importing or writing
definitions for.

TZ


 This is mostly true, if your program is complete and correct.  But most
compiles
 are of broken or incomplete programs.  Compilation/repair cycles are a big part
 of code development.

 If you make an error anywhere in your program, several things happen:

 1. For every mistake (mistyped identifier), the standard library is searched.
 This clobbers compile time.  The compile time for a broken file (to get error
 messages) is quite important during the coding phase.

 2. In some cases, the ident will be found somewhere.  If it's the wrong module
 or function, you get a "bogus" error message about parameters or conversion.
 Worse, it matches and is a silent bug.  (To prevent this, you need to have a
 familiarity with everything in the standard libraries...)

 3. Even for correct programs, using a standard library symbol requires
searching
 every file in the library.

 Implicit inclusion essentially throws everything into one namespace.  It gets
 worse when libraries and programs get bigger (M*N).

 The technique does work well for a "small" language, however.  The languages
 that are used inside spreadsheets, databases, and other "extensible" systems
 usually don't require "importing" anything.

 Kevin
Apr 23 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4e8nn$29gq$1 digitaldaemon.com>, TechnoZeus says...

Ah, okay.  I see the delema there.

Yes, if you assume "implicit imports" to happen where ever the compiler can
possibly find a way to make them happen,
that would be a very bad thing in indead.

What I am proposing is not implicit imports of every undefined identifier that
the compiler can find a match to in the available libraries.

What I am proposing also would not require (or even allow) the compiler to
"search" for a match to an undefined identifier.

What I am proposing is that the compiler be supplied with a list of known
identifiers that are used so commonly that people talk about them as if they
are a part of the language,
but that are not actually "built into" the language.

The only thing that the compiler would be required to search when an undefined 


identifier is found would be the list of default locations for commonly used 
identifiers.

Specifically, I'm talking about those identifiers that you find mentioned in
books, tutorials, and general conversation,
as if "everybody knows where they are defined" or worse yet, as if they are
defined as a part of the language specifications, when in fact they are not.

Face it. If all of the standard libraries were taken away, there are
very few people who could write a program in D or C or C++ that would
serve any useful purpose.

As such, some of the "standard library" features are treated by experienced 


programmers as if they are built in.

This causes a potential problem for newbies who attempt to use the features 


that they hear or read about only to find that their "properly written" code 
will not compile.

Yes, I know D is not meant to be a language for newbies...
but this feature would make it more accessible to them,
and wouldn't hurt anything.

Why make people who are totally new to porgramming have to learn another
language before they start learning D?
The only two things that I can see keeping D from being
easy to learn as a "first" programming language are,
the fact that the programmer can't possibly write a single command and test
it...
and the fact that even in once a proper "shell of a program" is written to test
a single command in,
many of the commands that they are lead to expect to work without importing
anything...
won't.

TZ


Okay - I see now.  You mean a sort of default translation:

use splitlines() --> automatic import std.strings;
use writef() --> automatic import of std.stdio;

True -- that would not hurt compile time.

What you are suggesting elevates these identifiers to special status.  Is that a
good or bad thing?  Hard to say.  The learning curve is a little softer at the
beginning this way.

On the other hand, if you are reading someone else's program (as a newbie), and
you don't recognize someFunction(), you can't dig through the imports for it.
So it would need to be only the very very common identifiers, as you say.

I think that most newer languages steer away from "special" behavior of the
standard libraries, but I'm not sure if there is a good reason to, per se.  

There was probably an expectation that some C++ (for example) programmers would
create their own, complete, alternative to the standard library, but this never
really happens.

Kevin Bealer
Apr 25 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d4irfu$1rtm$1 digitaldaemon.com...

 In article <d4e8nn$29gq$1 digitaldaemon.com>, TechnoZeus says...

Ah, okay.  I see the delema there.

Yes, if you assume "implicit imports" to happen where ever the compiler can
possibly find a way to make them happen,
that would be a very bad thing in indead.

What I am proposing is not implicit imports of every undefined identifier that
the compiler can find a match to in the available libraries.

What I am proposing also would not require (or even allow) the compiler to
"search" for a match to an undefined identifier.

What I am proposing is that the compiler be supplied with a list of known
identifiers that are used so commonly that people talk about them as if they
are a part of the language,
but that are not actually "built into" the language.

The only thing that the compiler would be required to search when an undefined


 identifier is found would be the list of default locations for commonly used
 identifiers.

Specifically, I'm talking about those identifiers that you find mentioned in
books, tutorials, and general conversation,
as if "everybody knows where they are defined" or worse yet, as if they are
defined as a part of the language specifications, when in fact they are not.

Face it. If all of the standard libraries were taken away, there are
very few people who could write a program in D or C or C++ that would
serve any useful purpose.

As such, some of the "standard library" features are treated by experienced


 programmers as if they are built in.

This causes a potential problem for newbies who attempt to use the features


 that they hear or read about only to find that their "properly written" code
 will not compile.

Yes, I know D is not meant to be a language for newbies...
but this feature would make it more accessible to them,
and wouldn't hurt anything.

Why make people who are totally new to porgramming have to learn another
language before they start learning D?
The only two things that I can see keeping D from being
easy to learn as a "first" programming language are,
the fact that the programmer can't possibly write a single command and test
it...
and the fact that even in once a proper "shell of a program" is written to test
a single command in,
many of the commands that they are lead to expect to work without importing
anything...
won't.

TZ


 Okay - I see now.  You mean a sort of default translation:

 use splitlines() --> automatic import std.strings;
 use writef() --> automatic import of std.stdio;

 True -- that would not hurt compile time.

 What you are suggesting elevates these identifiers to special status.  Is that
a
 good or bad thing?  Hard to say.  The learning curve is a little softer at the
 beginning this way.

 On the other hand, if you are reading someone else's program (as a newbie), and
 you don't recognize someFunction(), you can't dig through the imports for it.
 So it would need to be only the very very common identifiers, as you say.

 I think that most newer languages steer away from "special" behavior of the
 standard libraries, but I'm not sure if there is a good reason to, per se.

 There was probably an expectation that some C++ (for example) programmers would
 create their own, complete, alternative to the standard library, but this never
 really happens.

 Kevin Bealer


Thankyou!  That is "EXACTLY" what I mean!

Please, do us all a favor, and post a new thread with a translation in your
words.
I could swear I've been speaking an unknown foreign language here.

See, here's the thing.
Those that are important enough to be in the implicit import list would be
as you said, raised to a "special status"
and as such, would be included in the official documentation,
which would include a mention of what import they come in,
and perhaps a link to or mention of the documentation for the
version of that import that ships with the D language.
The description in the documentation would match the one that
comes with the language, and as such, the D language could be considered
a little more "complete" because it would do all the most fundamental stuff
without having to have that stuff explicitly imported into the language
as if it were something "foreign" to it.

Again... thank you for being able to see things in a different light.  Please
help others to do the same. The world may end up benefiting from this concept
by way of the D community yet.  :)

TechnoZeus
Apr 27 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4oa35$1aui$1 digitaldaemon.com>, TechnoZeus says...

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d4irfu$1rtm$1 digitaldaemon.com...

 In article <d4e8nn$29gq$1 digitaldaemon.com>, TechnoZeus says...

Ah, okay.  I see the delema there.

Yes, if you assume "implicit imports" to happen where ever the compiler can
possibly find a way to make them happen,
that would be a very bad thing in indead.

What I am proposing is not implicit imports of every undefined identifier that
the compiler can find a match to in the available libraries.

What I am proposing also would not require (or even allow) the compiler to
"search" for a match to an undefined identifier.

What I am proposing is that the compiler be supplied with a list of known
identifiers that are used so commonly that people talk about them as if they
are a part of the language,
but that are not actually "built into" the language.

The only thing that the compiler would be required to search when an undefined


 identifier is found would be the list of default locations for commonly used
 identifiers.

Specifically, I'm talking about those identifiers that you find mentioned in
books, tutorials, and general conversation,
as if "everybody knows where they are defined" or worse yet, as if they are
defined as a part of the language specifications, when in fact they are not.

Face it. If all of the standard libraries were taken away, there are
very few people who could write a program in D or C or C++ that would
serve any useful purpose.

As such, some of the "standard library" features are treated by experienced


 programmers as if they are built in.

This causes a potential problem for newbies who attempt to use the features


 that they hear or read about only to find that their "properly written" code
 will not compile.

Yes, I know D is not meant to be a language for newbies...
but this feature would make it more accessible to them,
and wouldn't hurt anything.

Why make people who are totally new to porgramming have to learn another
language before they start learning D?
The only two things that I can see keeping D from being
easy to learn as a "first" programming language are,
the fact that the programmer can't possibly write a single command and test
it...
and the fact that even in once a proper "shell of a program" is written to test
a single command in,
many of the commands that they are lead to expect to work without importing
anything...
won't.

TZ


 Okay - I see now.  You mean a sort of default translation:

 use splitlines() --> automatic import std.strings;
 use writef() --> automatic import of std.stdio;

 True -- that would not hurt compile time.

 What you are suggesting elevates these identifiers to special status.  Is that
a
 good or bad thing?  Hard to say.  The learning curve is a little softer at the
 beginning this way.

 On the other hand, if you are reading someone else's program (as a newbie), and
 you don't recognize someFunction(), you can't dig through the imports for it.
 So it would need to be only the very very common identifiers, as you say.

 I think that most newer languages steer away from "special" behavior of the
 standard libraries, but I'm not sure if there is a good reason to, per se.

 There was probably an expectation that some C++ (for example) programmers would
 create their own, complete, alternative to the standard library, but this never
 really happens.

 Kevin Bealer


Thankyou!  That is "EXACTLY" what I mean!

Please, do us all a favor, and post a new thread with a translation in your
words.
I could swear I've been speaking an unknown foreign language here.

See, here's the thing.
Those that are important enough to be in the implicit import list would be
as you said, raised to a "special status"
and as such, would be included in the official documentation,
which would include a mention of what import they come in,
and perhaps a link to or mention of the documentation for the
version of that import that ships with the D language.
The description in the documentation would match the one that
comes with the language, and as such, the D language could be considered
a little more "complete" because it would do all the most fundamental stuff
without having to have that stuff explicitly imported into the language
as if it were something "foreign" to it.

Again... thank you for being able to see things in a different light.  Please
help others to do the same. The world may end up benefiting from this concept
by way of the D community yet.  :)

TechnoZeus


Tell you what, feel free to grab and repost my words anywhere you like.

Kevin
Apr 27 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Fair enough... I'll do that.  :)  Thanks for the permission.

TZ

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d4q1a9$30i8$1 digitaldaemon.com...

 In article <d4oa35$1aui$1 digitaldaemon.com>, TechnoZeus says...

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d4irfu$1rtm$1 digitaldaemon.com...

 In article <d4e8nn$29gq$1 digitaldaemon.com>, TechnoZeus says...

Ah, okay.  I see the delema there.

Yes, if you assume "implicit imports" to happen where ever the compiler can
possibly find a way to make them happen,
that would be a very bad thing in indead.

What I am proposing is not implicit imports of every undefined identifier that
the compiler can find a match to in the available libraries.

What I am proposing also would not require (or even allow) the compiler to
"search" for a match to an undefined identifier.

What I am proposing is that the compiler be supplied with a list of known
identifiers that are used so commonly that people talk about them as if they
are a part of the language,
but that are not actually "built into" the language.

The only thing that the compiler would be required to search when an undefined


 identifier is found would be the list of default locations for commonly used
 identifiers.

Specifically, I'm talking about those identifiers that you find mentioned in
books, tutorials, and general conversation,
as if "everybody knows where they are defined" or worse yet, as if they are
defined as a part of the language specifications, when in fact they are not.

Face it. If all of the standard libraries were taken away, there are
very few people who could write a program in D or C or C++ that would
serve any useful purpose.

As such, some of the "standard library" features are treated by experienced


 programmers as if they are built in.

This causes a potential problem for newbies who attempt to use the features


 that they hear or read about only to find that their "properly written" code
 will not compile.

Yes, I know D is not meant to be a language for newbies...
but this feature would make it more accessible to them,
and wouldn't hurt anything.

Why make people who are totally new to porgramming have to learn another
language before they start learning D?
The only two things that I can see keeping D from being
easy to learn as a "first" programming language are,
the fact that the programmer can't possibly write a single command and test
it...
and the fact that even in once a proper "shell of a program" is written to test
a single command in,
many of the commands that they are lead to expect to work without importing
anything...
won't.

TZ


 Okay - I see now.  You mean a sort of default translation:

 use splitlines() --> automatic import std.strings;
 use writef() --> automatic import of std.stdio;

 True -- that would not hurt compile time.

 What you are suggesting elevates these identifiers to special status.  Is that
a
 good or bad thing?  Hard to say.  The learning curve is a little softer at the
 beginning this way.

 On the other hand, if you are reading someone else's program (as a newbie), and
 you don't recognize someFunction(), you can't dig through the imports for it.
 So it would need to be only the very very common identifiers, as you say.

 I think that most newer languages steer away from "special" behavior of the
 standard libraries, but I'm not sure if there is a good reason to, per se.

 There was probably an expectation that some C++ (for example) programmers would
 create their own, complete, alternative to the standard library, but this never
 really happens.

 Kevin Bealer


Thankyou!  That is "EXACTLY" what I mean!

Please, do us all a favor, and post a new thread with a translation in your
words.
I could swear I've been speaking an unknown foreign language here.

See, here's the thing.
Those that are important enough to be in the implicit import list would be
as you said, raised to a "special status"
and as such, would be included in the official documentation,
which would include a mention of what import they come in,
and perhaps a link to or mention of the documentation for the
version of that import that ships with the D language.
The description in the documentation would match the one that
comes with the language, and as such, the D language could be considered
a little more "complete" because it would do all the most fundamental stuff
without having to have that stuff explicitly imported into the language
as if it were something "foreign" to it.

Again... thank you for being able to see things in a different light.  Please
help others to do the same. The world may end up benefiting from this concept
by way of the D community yet.  :)

TechnoZeus


 Tell you what, feel free to grab and repost my words anywhere you like.

 Kevin
Apr 27 2005
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[cross post & followup to digitalmars.D.bugs]

TechnoZeus schrieb am Thu, 14 Apr 2005 16:12:44 -0500:

 You tested what? I'm not talking about long filenaes support in the language
here.
 I'm talking about the Digital Mars D compiler itself.  Sorry it I was
ambiguous.
 Try compiling a file named longfilename.d and you will get an error to the
 effect of "C:\DM\TEST\LONGFI~1.D: module LONGFI~1 has non-identifier
 characters in filename, use module declaration instead".

 At least, that's what happens in Windows 98.  Maybe on another operating
 system this is not the case.  The inability to compile at all is probably
 the "~" character being used in the MS_DOS short filename that Windows is
 automatically generated by the operating system for the benefit of programs
 that only support <= 8 character long filenames with <= 3 character
 extensions.  The DMD compiler apears to be one of those programs.  


Seems to be Windows specific.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCX4aC3w+/yD4P9tIRAjytAKCxAwTmWD44LNjRRLj2nqrUMe3FogCgw32n
CWtvJNnASveJLKpHVdA+H+I=
=zN22
-----END PGP SIGNATURE-----
Apr 15 2005