"Sean L. Palmer" wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> > On a somewhat related note, I've often thought that it would be nice to
> embed
> > various types of documents into my source code.  For instance, what if
> your
> > comment could be in the form of a document from a word processor, inlined
> into
> > the source document?  Or what if, instead of having a big block of
> constants to
> > initialize an array of structures, you could inline a spreadsheet and have
> the
> > rows from the spreadsheet be the various array elements?  Stuff like that.
>
> Coolness.
>
> You could initialize a string from a hyperlink to a text file or a word processor document.
>
> Have a function take a bitmap as an argument, but a hyperlink to a bitmap file on disk would work too (the compiler generates the call to the "load bitmap file from disk" function to convert it).
>
> But you're talking about embedding via OLE.  Hmm...

My original vision was OLE-esque.  But the hyperlink idea works, too.  Your IDE could expand the hyperlink (if you so desired) to display the included document inline without putting an OLE-reading requirement on the compiler.

Heck, if you used hyperlinks, you could be referencing stuff accessible through HTTP, FTP, or whatever.  Leads to some interesting possibilities for cooperative development - especially if you can import http files as well!

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

On Wed, 12 Jun 2002 09:03:36 -0400, "Andrew" <crxace13@comcast.net> wrote:
> Epsilon comes with the source code, so it could be extended to support D. Though I'm not capable of doing such a thing! I'm sure someone in this newsgroup is!
> 
Is the only difference between C and D (rom the editor's point of view!) a different list of keywords to be colored?  The hard part is automatic indenting, and comments. Aren't C and D just abot the same there?

The first step would be to see where the C module comes up short when doing D files.

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023942917@bose...

> Is the only difference between C and D (rom the editor's point of view!) a different list of keywords to be colored?  The hard part is automatic
indenting,
> and comments. Aren't C and D just abot the same there?

Yes, only D also have /+ +/ comments in addition to /* */

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1023868581@bose...
> The editor I use,  Epsilon, does automatic indenting, and I find it
invaluable.
> Many errors are caught when the editor indents strangely due to a missing semicolon,  dangling else etc. It seems to me that I have seen an editor
that
> marks the extent of blocks in the left margin. You're right though -- much more could be done.

The kinds of errors I worry about aren't syntax errors that quickly get caught by the compiler, but subtle semantic ones. D is designed to make it easier to catch those.

Walter wrote:
> "Karl Bochert" <kbochert@ix.netcom.com> wrote in message
> news:1103_1023868581@bose...
> 
>>The editor I use,  Epsilon, does automatic indenting, and I find it
> 
> invaluable.
> 
>>Many errors are caught when the editor indents strangely due to a missing
>>semicolon,  dangling else etc. It seems to me that I have seen an editor
> 
> that
> 
>>marks the extent of blocks in the left margin. You're right though -- much
>>more could be done.
> 
> 
> The kinds of errors I worry about aren't syntax errors that quickly get
> caught by the compiler, but subtle semantic ones. D is designed to make it
> easier to catch those.
> 
> 

I like the semicolons..  they're pretty.

Racking my brain to think of a simple case:

How about this case,

for(int n; n<Max && !isFound(n); n++);

if (n != Max) //found at n-1
{
...
}

but without semicolon

for(int n; n<Max && !isFound(n); n++)

if (n != Max) //found at n-1
{
...
}

Beep - ERROR

This would mean manditory bracks are needed for the complier to make sense of it.


"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:advgr5$2seb$1@digitaldaemon.com...
> I would like to humbly ask that semicolons not be mandatory statement separators in D, but that they be equivalent to newline, and that newline
is
> a potential statement separator, semicolon is a definite one, and
semicolon
> + newline is treated as only one separation.
>
> if (ihadacoollanguage)
> {
>   int a = b + c
>   int k = b + c +
>              d + e   // these don't count because they don't parse in the
> same places comma and semicolon do.
>   int j = b + c
>             + d + e  // it actually has to be looking for a comma or
> semicolon for a newline to work instead
>   // or it at least needs the remaining fragment to not to compile without
> treating the eoline as a terminator
>   char[]
>      thisstillworkshowever(char[]a,  // comma is ok, it's just not
necessary
>                                       char[]b // comma optional because
> there's a newline instead
>                                       char[]c;  // semi optional where
comma
> is accepted?
>                                       char[]d);
> }
>
> I mean, I would like my compiler to not pick nits about semicolons.  If I forget one, so friggin what it usually doesn't matter... the compiler has figured it out that it indeed was a missing semicolon big friggin deal,
just
> deal with it and move on.  It should be a warning at best.  In order for
the
> compiler to figure out that a semicolon is missing, it is known that a semicolon must be inserted to fix the problem, but since that's a legal
fix
> it should just do it.
>
> It's like real english, sometimes you Dot all you're P"s and q's and someTimes you don't, and yes the code would be nicer if you did all your grammar homework or weren't lazy it's not crucial to get the point across. Allowing slop in syntax allows one to do quick "phrasing" while blocking
out
> the code and clean up the subtle issues later. (if this ever becomes an issue because maybe the program works perfectly as written)  Sometimes you just wanna test something quickly and do some cut'n'paste and the last
thing
> you want to see is some stupid "you forgot a semicolon" problems.
>
> Yes I realize it would maybe create a few bugs;  about as many as for(;;); has.  Number of bugs created by a construct is proportional to the number
of
> times that construct is used by someone.  Useful constructs will
inherently
> generate more bugs up to a point.
>
> Sean
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:aee9k9$1baf$1@digitaldaemon.com...

> How about this case,
>
> for(int n; n<Max && !isFound(n); n++);

The compiler won't allow you to do this, anyhow. You need to use { } for both cases. So, the funny thing is, the first case would give an error, while the second won't =)

There I go again, putting my foot in my mouth.


"Pavel Minayev" <evilone@omen.ru> wrote in message news:aeeleo$1m8q$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:aee9k9$1baf$1@digitaldaemon.com...
>
> > How about this case,
> >
> > for(int n; n<Max && !isFound(n); n++);
>
> The compiler won't allow you to do this, anyhow. You need to use { } for both cases. So, the funny thing is, the first case would give an error, while the second won't =)
>
>

I usually put braces there in any case because they're more visible than a semicolon.

Sean

"anderson" <anderson@firestar.com.au> wrote in message news:aee9k9$1baf$1@digitaldaemon.com...
> Racking my brain to think of a simple case:
>
> How about this case,
>
> for(int n; n<Max && !isFound(n); n++);
>
> if (n != Max) //found at n-1
> {
> ...
> }
>
> but without semicolon
>
> for(int n; n<Max && !isFound(n); n++)
>
> if (n != Max) //found at n-1
> {
> ...
> }
>
> Beep - ERROR
>
> This would mean manditory bracks are needed for the complier to make sense of it.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae6ql5$1c6h$1@digitaldaemon.com...
> I'm not taking anything as flame (that's just how I react occasionally.
;)
> I didn't mean my post as reactionary or flame either;  sorry if you took
it
> that way.
>
> Oh well I can live with semicolons.  Not a big deal.  It's better than having to surround every statement with parenthesis or braces.
>
> I just wish the IDE/Editor performed more of these functions.  The text-based nature of programming languages is getting me down lately.  A smart IDE can detect errors as you type, and could auto-indent, as well
as,
> say, draw barely-visible boxes around each statement or whatever.
>
> You could program in a sort of boxes, plugs, and sockets view; a kind of data flow graph.  Maybe toggle back and forth between that and text view. Or to a class hierarchy view.  The raw text view is so restrictive and antiquated in comparison.  One could make a programming language that
didn't
> use text at all if you tried.
>
> What's really important in a language (to me) is the conceptual relationships between its elements. What gets what to do what with what.
>
> Sean
>


Sean, check out this article called
SCID - Source Code In Database:
http://mindprod.com/scid.html
I found it to be a very iluminating
article, with some great ideas!
It talks about a lot of the things
you mention in your post.

Incidentally, we have already been
talking on this group on something that
comes close to this, DML, a format
to store D source code in XML. The idea
is that you store only the pure code
and leave petty details like indentation
to be handled by the editor and an
XSLT stylesheet with some preferences.
DML never came further than pipe-dream
status though... :(


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