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.)
> 
> 
> 

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.)
> >
> >
> >

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.)
>>> 
>>> 
>>> 
> 
> 

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.)
> >>>
> >>>
> >>>
> >
> >

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

"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

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

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
>
>
>

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

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
>
>
>