RE: Block Commenting
Block comments would be a godsend, as well as a number of other bits of
shorthand I'd like to see.
I was actually thinking about this recently -- what if any of us could
add any kind of short-hand to Euphoria that we liked? Now of course I
can make a pre-processor that converts my special code to
Euphoria-compliant code if I want, but then you've got to manage
different sets of source files, ex.err will refer to the final version
only, etc.
What if there was a standard pre-processing protocol built-in the
interpreter? Users could optionally link a pre-processor syntax file to
the interpreter, which would automatically convert the user source files
to regular Euphoria before it gets on with the actual interpreting. In
other words, allow custom exentions to the parser. And when errors
occur, the line numbers could be synchronized with the original source
(or with the converted source as well as an option).
Now this is a project that would probably need to tackled by one of us,
but it would be a lot more feasible if some of the facility was built-in
to the interpreter. I suppose you could make a front-end that did the
preprocessing, called the interpreter, and caught the error file, but
there would be more overhead.
-- Andy
Derek Parnell wrote:
>
>
> ----- Original Message -----
> From: "Robert Craig" <rds at RapidEuphoria.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, August 03, 2003 11:49 AM
> Subject: Re: Block Commenting
>
>
> > Dave Probert wrote:
> > > Any chance we'll see block commenting abilities in the next Euphoria?
> >
> > I don't think so.
> > I'm not interested in having two different ways
> > to write comments.
>
> And yet your *customers* are. Interesting, no?
>
> >In ed, I hit F12 a bunch of times
> > to comment out a block. (uncommenting isn't quite as easy)
>
> And why were block comments invented? To make life easier for the CODER
> not the language author.
>
> > > Also is there any chance of gathering together some of the more useful
> > > (small!) code funcs/procs, that are often rewritten by coders, into a
> > > base include file (ie one that is supplied with the standard Euphoria
> > > download)?
> >
> > Do you want me to maintain a bunch of code written
> > by other people? When they change/improve their code
> > will I have to keep my version up to date as well?
>
> Of course not! However, some of the submissions (and stuff not
> submitted) are so common that you ought to consider making them standard
> (read: RDS Supported) routines. For example: abs().
>
> Another 'compromise' could be to make RDS's Euphoria have the ability to
> read directly from ZIP files. A ZIP file could contain a set of normal
> 'include files'. This would be a real library (a collection of books in
> one place) facility. The commonly available tools could be used to
> maintain the library contents as updated versions come in. JAVA uses
> this type of facility to good effect.
>
> Would it really hurt RDS to take on a bit more responsibility for this?
> I'd pay for such an 'add-on' service.
>
> > > Possibly worth asking for submissions for the above.
> > >
> > > The main reason for this would be to reduce the number of "This
> > > application requires the xxx library to work" when people supply their
> > > tools (or else people often include them as well, so there can be
> > > various versions of the same file located in many folders).
> >
> > Maybe we just need a big index that you can search
> > that will tell you where to find the latest version
> > of an include file. I could periodically run
> > a program that would go through all 1100+ .zip files,
> > and prepare a sorted list of all the contained files,
> > along with their time stamp and size. Maybe I could
> > list all the global symbols and index them somehow too.
>
> Wouldn't hurt to have that service available either, Robert. Thanks for
> the offer; its appreciated.
>
> --
> Derek
>
|
Not Categorized, Please Help
|
|
