www.digitalmars.com         C & C++   DMDScript  

D - A few ideas

reply madGenius <c.chafer herts.ac.uk> writes:
Hello folks,

I've just stumbled across the 'D' site while looking for ideas for my
pet programming language 'OOMIC'.

OOMIC is a wierd cross between BASIC (read on... :-), C, FORTRAN,
assembler, C++ and ADA -- however it has an overall structure very
similar
to D and as a result has come across some of the problems you have been
discussing here.  So allow me to go through my solutions to them,  maybe
they may be useful to you.

1. Fall through on CASE

	As Walter says having a fall through is very useful sometimes,
though it is full of gotchas,  I solved the problem by implementing a
new control WHEN which does not fall though,  though CASE still does.
This still leaves the DEFAULT,  I implement this using CASE OTHER and
WHEN OTHER though this may not suit D as well.  (DEFAULT / WHEN DEFAULT
maybe?).  The only problem with this is it adds a new reserved word,
though I think creating a label called WHEN is very rare.

2. Octal number constants

	Most assemblers use    [0-7]+[oOqQ]   (flex syntax)
to define octal numbers - though this would not fit in with C style
maybe     0[oOqQ][0-7]+     could be used instead,  of course to make
code easier to read dropping the oO bit may help,  however the
combination
should be easy to guess.  For consistancy when using constant decimals
maybe allow 0[dD][0-9]+ for decimals (though the standard decimal
declare should still be available - as it is intuitive).

3. Returning multiple variable

	I see D uses in, out and inout in the function headers,  this would
achieve the result (an fix the biggest problem in C - even BASIC could
return multiple variables :-).  However it could be easy to forget and
difficult to notice which was which.  OOMIC calls functions using
LABEL '(' inputs ';' outputs ')' though this does not look good when
you have no inputs (brackets are optional).  The idea of enforcing
the order of inputs and outputs is still valid.  You could output a
warning if an 'in' is right of an 'inout' or if an 'inout' is right
of an 'out'.  This should help in developing clearer code.

4. Operator overloading

	I think this is far too useful to leave out, though I admit it is a
pain to implement - especially if adding new operators is possible.  But
reading code which uses overloading well is far easier than code which
uses purely function calls.

5. Arrrgh - you spell synchronise with a 'z' :-)

	You will be missing the 'u' out of colour next :-)

6. Comment nesting

	In OOMIC there is two types of multiline comments :{ ... }:

preprocessor.  This is very useful as it allows me to comment out
multiline comments,  using one version as I normally only use the other
(this is the reason I did not remove preprocessor comments).  I must
assert that these comments DO NOT nest or mix,  they just allow two
forms

parser at
the third ... (and probably produce an error).  I use lex to swallow all
comments so the parser never sees them.
	In D you could use /* ... */ and //* ... *// as comments (maybe
///* ... */// and so on) which would be easy to implement,  easy to
understand and fairly easy to use.  ( if(0) { ... } is nasty and cannot
be used to ie. comment out parts of structures )

7. Variable types

	Using SHORT INT LONG etc for compatibility with C maybe a good idea
though you could support say I32 for a 32 bit integer,  I64 for a 64
bit,
U32 for an unsigned int (I always end up having a header file in C which
does this anyway).  Though this could be implemented using typedefs,  it
is far more expandable than say LONG LONG LONG INT or creating a new
type
which anyone without the latest manual would have to guess at.
	And what happens it say D where to run on a Burroughs which
uses 48 bit vaules?  Does SHORT INT LONG on guarantee a minimum
precision?
(Fixing sizes of SHORT INT LONG etc is a good idea - saves a lot of
#if sizeof(unsigned int)==4 #define U32 int #elseif ...)




(I can not say my solutions are the best - as I just write compilers for
fun)
(Do I get the record for longest post here :-)

Good luck with D, it is shaping up as a really good language spec.

PS: Love the debug { ... } idea - think I will pinch it :-)

C.R.Chafer
2001/8/22

- put it right AT ( ) the correct place to mail me }
Aug 22 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 2. Octal number constants

 Most assemblers use    [0-7]+[oOqQ]   (flex syntax)
 to define octal numbers - though this would not fit in with C style
 maybe     0[oOqQ][0-7]+     could be used instead,  of course to make
 code easier to read dropping the oO bit may help,  however the
 combination
 should be easy to guess.  For consistancy when using constant decimals
 maybe allow 0[dD][0-9]+ for decimals (though the standard decimal
 declare should still be available - as it is intuitive).


Octal is rarely used... I say screw octal.


 6. Comment nesting
 ...
 In D you could use /* ... */ and //* ... *// as comments (maybe
 ///* ... */// and so on) which would be easy to implement,  easy to
 understand and fairly easy to use.  ( if(0) { ... } is nasty and cannot
 be used to ie. comment out parts of structures )


I see no reason why if statements which evaluate only constant expressions
can't be allowed in *any* kind of block or declaration.  I'm certain D
intends the version statement to be usable in the global scope.

version (system.os == OS.WindowsNT)
	{
    import ntsystem;
    typedef ntsystem.systemtype ossystemtype;
}

version (system.os == OS.Linux)
{
    import linuxsystem;
    typedef linuxsystem.systemtype ossystemtype;
}

int main()
{
  return ossystemtype.run();
}


so why can't we do this?

import nativesystem;

if (nativesystem.option_1)
{
  int myfunc(int j)
  {
     return j*2;
  }
}
else
{
  int myfunc(int j)
  {
     return j*3;
  }
}

int main()
{
  return myfunc(1);
}

Hell for that matter why not allow switch/case?

enum compoption { big, small }

const compoption globalcompileroption = big;

struct mystruct
{
   switch (globalcompileroption)
  {
     case small:
       ubyte value;
     case big:
       ulong value;
  }
}

Control statements at global or struct/class declaration scope would not
affect scope of variables within their controlled blocks... i.e. the value
struct members above are placed in mystruct's scope, not the scope of the
switch or case.  The expressions would all be required to be compile time
constants.

Sean
Oct 16 2001
next sibling parent Axel Kittenberger <axel dtone.org> writes:
 Octal is rarely used... I say screw octal.


No, it is not. On unix system octal numbers are very often used for file 
permissions flags.


 I see no reason why if statements which evaluate only constant expressions
 can't be allowed in *any* kind of block or declaration.  I'm certain D
 intends the version statement to be usable in the global scope.


'couse it's very difficult to code to allow it anywhere. goes near to 
impossible except for new parser tech experiments. 


 Hell for that matter why not allow switch/case?


Same reason.

- Axel

-- 
|D) http://www.dtone.org
Oct 16 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9qgril$1mdi$1 digitaldaemon.com...

 2. Octal number constants

 Most assemblers use    [0-7]+[oOqQ]   (flex syntax)
 to define octal numbers - though this would not fit in with C style
 maybe     0[oOqQ][0-7]+     could be used instead,  of course to make
 code easier to read dropping the oO bit may help,  however the
 combination
 should be easy to guess.  For consistancy when using constant decimals
 maybe allow 0[dD][0-9]+ for decimals (though the standard decimal
 declare should still be available - as it is intuitive).


 Octal is rarely used... I say screw octal.


 6. Comment nesting
 ...
 In D you could use /* ... */ and file://* ... *// as comments (maybe
 ///* ... */// and so on) which would be easy to implement,  easy to
 understand and fairly easy to use.  ( if(0) { ... } is nasty and cannot
 be used to ie. comment out parts of structures )


 I see no reason why if statements which evaluate only constant expressions
 can't be allowed in *any* kind of block or declaration.  I'm certain D
 intends the version statement to be usable in the global scope.

 version (system.os == OS.WindowsNT)
 {
     import ntsystem;
     typedef ntsystem.systemtype ossystemtype;
 }

 version (system.os == OS.Linux)
 {
     import linuxsystem;
     typedef linuxsystem.systemtype ossystemtype;
 }

 int main()
 {
   return ossystemtype.run();
 }


 so why can't we do this?

 import nativesystem;

 if (nativesystem.option_1)
 {
   int myfunc(int j)
   {
      return j*2;
   }
 }
 else
 {
   int myfunc(int j)
   {
      return j*3;
   }
 }

 int main()
 {
   return myfunc(1);
 }

 Hell for that matter why not allow switch/case?

 enum compoption { big, small }

 const compoption globalcompileroption = big;

 struct mystruct
 {
    switch (globalcompileroption)
   {
      case small:
        ubyte value;
      case big:
        ulong value;
   }
 }

 Control statements at global or struct/class declaration scope would not
 affect scope of variables within their controlled blocks... i.e. the value
 struct members above are placed in mystruct's scope, not the scope of the
 switch or case.  The expressions would all be required to be compile time
 constants.

 Sean



I think you're on to something there!
Oct 17 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 I think you're on to something there!


You're quite a full-quoter walter :/

Actually on most news-net groups it's something against the "Netiquette", 
you see either way the parent if you want to read it.
Full quotes is something most times to 99% only Outlook users do :o)  (and 
is considered "un-leet" in the "hacker" lists :))

( http://www.smfr.org/mtnw/docs/Usenet.html#Netiquette )

Not mean to be picky, just thought maybe a little pointing can maybe be of 
some help :o)

---
 Avoid unnecessary quoting. For example, it is considered very bad form to 
quote all of a long article and then add a single line of text saying "me 
too". Take the time to edit the quoted text to the bare minimum. Only quote 
text which is directly relevant to your replies. Place your replies so that 
they immediately follow the relevant sections of quoted text. Don't quote 
people's signatures (MT-NewsWatcher will automatically remove properly 
delimited signatures). This convention is such a tradition on Usenet that 
many news servers are configured to reject postings with more quoted text 
than new text. 
---


- Axel
Oct 18 2001
parent "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Axel Kittenberger wrote:


 I think you're on to something there!


 You're quite a full-quoter walter :/


Uh, remember, it *is* Walter's D newsgroup, and it *is* on his own news
server!

I figure nettiquette doesn't apply unless he wants it to...

And having survived being /.ed, I'd imagine he's only now coming out of
information (well, "opinion") overload.


-BobC
Oct 18 2001