andy wrote:

> > 4) non-2's complement arithmetic
>
> not sure about that one...What will you do when a (moderately mass
> produced) processor based on
> positive, negative, neutral charge (or + & minus) or something of the
> such comes a long and does something like this:
>
> 0000 = 0
> 0001 = 1
> 0002 = 2
> 0010 = 3
>
> This seems like it may end up being an evolutionary rather than revolutionary step in processor technology.

From what I've read, the trinary computing guys model the digits as -1,0,1:

0000 = 0
0001 = 1
001-1 = 2
0010 = 3
0011 = 4
01-1-1 = 5

D should support trinary computing when it comes out...no need to do it now :)

--
The Villagers are Online! villagersonline.com

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

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374389659766782@news.digitalmars.com...

> But then again, I also think that it's better to think in terms of modules and packages rather than files and directories. It's more abstract.

   After all, something like "string.utils.unicode" can be used by the
compiler in different systems to find its files in one of many different
ways: looking in an index file, looking in a directory hierarchy, heck,
"string.utils.unicode" is a valid filename in many systems today, so why not
use it like that, either?

   As long as each module is in its own file, and the compiler has a way to
find it, the rest is implementation details.

Salutaciones,
                         JCAB

"Walter" <walter@digitalmars.com> wrote in message news:afsjbo$2bud$1@digitaldaemon.com...
>
> "C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:afeolg$tnn$1@digitaldaemon.com...
> > Agreed, but please please please do not use back slashes (use forward slashes instead, or colons).  The backslash key on each of my 6 keyboard
> is
> > in a different place - and on one it is completely absent.
>
> When I recently replaced my keyboard, the new one had the [Enter] key with
a
> bulge on the top that replaced the \ key. This caused me no end of grief, because I'd mean to type things like:
>
>     rm foo\abc.def
>
> but would hit enter instead of the \, resulting in:
>
>     rm foo
>
> which would wipe out the directory. Similar disastrous problems happen
with
> the copy command and several others. After a week of this, I finally scrounged around till I found the older style (from IBM) with the small [Enter] key and the \ in the right place!
>
>
>

Ooow that does sound serious indeed.
Sometimes I think these keyboard manufacturers do
not use them to actually type something....doh...
I hate the caps-lock, stuck between the very
usefull left shift and tab keys. I hit it by
accident all the time.
Also what does the scroll-lock key do? Is that
for console mode or something?
I used to hate the Windows key, but nowadays I
actually like it and use it a lot.

If they could just put an LCD screen where the
Num-lock, Caps-Lock and Scroll-lock indicators
are (or just below it) and add a Calc-lock key
which would activate a calculator, now *that*
would be usefull! (I use the Windows Calculator
all the time, but hate the fact that I have to
start the program each time, or keep it running
all the time. It just seems adding a small LCD
screen would be *very* easy...)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

On Tue, 2 Jul 2002 23:28:46 +0200, "OddesE" <OddesE_XYZ@hotmail.com> wrote:
>
>
> I hate the caps-lock, stuck between the very
> usefull left shift and tab keys. I hit it by
> accident all the time.

I finally got to the point where I take my keyboards apart and remove the little rubber doo-hickey under the caps lock key.

Prying off the keycap almost works.

On Tue, 02 Jul 2002 11:51:08 -0700, Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:
> andy wrote:
> 
> 
> From what I've read, the trinary computing guys model the digits as -1,0,1:
> 
> 0000 = 0
> 0001 = 1
> 001-1 = 2
> 0010 = 3
> 0011 = 4
> 01-1-1 = 5
> 
> D should support trinary computing when it comes out...no need to do it now :)
> 

The latest thing is quantum computing with each bit being 0, 1 or both, but I guess thats still just binary (with three states!).

Right the point was that "non-2's complement arithmetic" may have a place in the future.

-Andy

Russ Lewis wrote:
> andy wrote:
> 
> 
>>>4) non-2's complement arithmetic
>>
>>not sure about that one...What will you do when a (moderately mass
>>produced) processor based on
>>positive, negative, neutral charge (or + & minus) or something of the
>>such comes a long and does something like this:
>>
>>0000 = 0
>>0001 = 1
>>0002 = 2
>>0010 = 3
>>
>>This seems like it may end up being an evolutionary rather than
>>revolutionary step in processor technology.
> 
> 
> From what I've read, the trinary computing guys model the digits as -1,0,1:
> 
> 0000 = 0
> 0001 = 1
> 001-1 = 2
> 0010 = 3
> 0011 = 4
> 01-1-1 = 5
> 
> D should support trinary computing when it comes out...no need to do it now :)
> 
> --
> The Villagers are Online! villagersonline.com
> 
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
> 
> 

"andy" <acoliver@apache.org> wrote in message news:3D21E34E.3050907@apache.org...
> On that note.  I'm curious why the "extended" datatype.  I find it a bit queer in reference to the other datatypes.  I understand its purpose, but it seems directly counter to the other datatypes.  I think I'd rather see "extended80" and "extended96" or something of the such with an eye towards processor optimization.  Meaning while extended80 would be a native processor implemnetation on an intel chip, it might not be on another, but would be defined solidly.  The "extended96" would of course would be implemented by the software and not the hardware on an intel chip.  (and its just a guess as to what an extended type might be on some other platform).
>
> I have the same concern with wchar.  It seems to me more logical to provide a defined datatype, and let those who know that its 16 bit on windows and who want to optimize for windows, use the wchar16.  If you don't know, or you don't care, etc, then you'll just choose what's appropriate and perhaps miss the fact that you could have done it more efficiently otherwise.
>
> Does that make sense?

"extended" is supported by the hardware, it just makes sense to have it accessible from the language.

In article <afs4qp$1rsn$1@digitaldaemon.com>, C.R.Chafer says...
>
>Pavel Minayev wrote:
>
>> Since most D implementations are going to implement packages using
>> directories (it just seems to be most logical solution), I guess
>> it won't be possible that easy. Only maybe if Walter allows us to
>> alias modules? Or some alternative way to define packages (like, say,
>> a .dpk file which is just a list of modules).
>
>This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem.  For example (in myProject.dpk).
>
>version Windows {
>        module phobos = "c:\dmd\import\phobos";
>        /* etcetra */
>}
>version Unix {
>        module phobos = "//usr/import/phobos";
>        /* etcetra */
>}
>
>If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary.  All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
> 
>> But then again, I also think that it's better to think in terms
>> of modules and packages rather than files and directories. It's
>> more abstract. While I wouldn't mind using / to separate package
>> names in import directive (even though it _might_ be completely
>> unrelated to directories in some implementations), but dot also okay.
> 
>Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out,  platform independent and consistant with the remainder of the D language.
>
>C 2002/7/2

In article <afs4qp$1rsn$1@digitaldaemon.com>, C.R.Chafer says...
>
>Pavel Minayev wrote:
>
>> Since most D implementations are going to implement packages using
>> directories (it just seems to be most logical solution), I guess
>> it won't be possible that easy. Only maybe if Walter allows us to
>> alias modules? Or some alternative way to define packages (like, say,
>> a .dpk file which is just a list of modules).
>
>This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem.  For example (in myProject.dpk).
>
>version Windows {
>        module phobos = "c:\dmd\import\phobos";
>        /* etcetra */
>}
>version Unix {
>        module phobos = "//usr/import/phobos";
>        /* etcetra */
>}
>
>If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary.  All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
> 
>> But then again, I also think that it's better to think in terms
>> of modules and packages rather than files and directories. It's
>> more abstract. While I wouldn't mind using / to separate package
>> names in import directive (even though it _might_ be completely
>> unrelated to directories in some implementations), but dot also okay.
> 
>Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out,  platform independent and consistant with the remainder of the D language.
>
>C 2002/7/2

Here is another way for including file path imports in D. Perl 5 allows you to specify a library path for modules. The syntax in Perl 5 is: use lib "/pojects/group/path/lib";

You can even use a Windows path in Active Perl for Win32.
Windows may use a Unix style path when Microsoft overhauls the windows shell
in future releases.

With this language facility you can search for classes or libraries in a directory path as well as the local path and program path.

The following is a Unix example:

import stdio;
using library "/home/standard/ext/";
import graphics;

This would be a Windows example:
import stdio;
using library "C:/homes/standard/ext/";
import graphics;

You import stdio, but the class or files can also be located within a directory /home/standard/ext/ that is outside of the classpath.  It will search for the graphics file in this directory if it isn't in the local or standard path. You can maintain import conventions but have the ability to define a external classpath.

In article <b1hs0k$5hn$1@digitaldaemon.com>, Kublai Kahn says...
>
>In article <afs4qp$1rsn$1@digitaldaemon.com>, C.R.Chafer says...
>>
>>Pavel Minayev wrote:
>>
>>> Since most D implementations are going to implement packages using
>>> directories (it just seems to be most logical solution), I guess
>>> it won't be possible that easy. Only maybe if Walter allows us to
>>> alias modules? Or some alternative way to define packages (like, say,
>>> a .dpk file which is just a list of modules).
>>
>>This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem.  For example (in myProject.dpk).
>>
>>version Windows {
>>        module phobos = "c:\dmd\import\phobos";
>>        /* etcetra */
>>}
>>version Unix {
>>        module phobos = "//usr/import/phobos";
>>        /* etcetra */
>>}
>>
>>If a format similar to this was used it would be easy to modify for a new operating system without having to modify the source and as the syntax is similar to the D syntax virtually no extra learning is necessary.  All the compiler would have to do is check for a .dpk file in the directory it was compiling and then parse that file, if the .dpk file was not present it would use the default options, environment variable or simply report a module not found error.
>> 
>>> But then again, I also think that it's better to think in terms
>>> of modules and packages rather than files and directories. It's
>>> more abstract. While I wouldn't mind using / to separate package
>>> names in import directive (even though it _might_ be completely
>>> unrelated to directories in some implementations), but dot also okay.
>> 
>>Since we are already using a full stop (.) in import declarations, I see no reason to change - it is a well though out,  platform independent and consistant with the remainder of the D language.
>>
>>C 2002/7/2
>
>Here is another way for including file path imports in D. Perl 5 allows you to specify a library path for modules. The syntax in Perl 5 is: use lib "/pojects/group/path/lib";
>
>You can even use a Windows path in Active Perl for Win32.
>Windows may use a Unix style path when Microsoft overhauls the windows shell
>in future releases.
>
>With this language facility you can search for classes or libraries in a directory path as well as the local path and program path.
>
>The following is a Unix example:
>
>import stdio;
>using library "/home/standard/ext/";
>import graphics;
>
>This would be a Windows example:
>import stdio;
>using library "C:/homes/standard/ext/";
>import graphics;
>
>You import stdio, but the class or files can also be located within a directory /home/standard/ext/ that is outside of the classpath.  It will search for the graphics file in this directory if it isn't in the local or standard path. You can maintain import conventions but have the ability to define a external classpath.
>
>

In Java it restricts you to one import per line.
Such as:

import Java.awt.Graphics;
import Java.applet.Applet;

It won't let you import multiple includes on one line. import Java.awt.Graphics, Java.applet.Applet;

Could D allow you to import more than one library per line? Is this a good idea? Please comment...