Russell McMahon wrote:
> Most of these errors are due to insufficient programming environments.
> How many people still program without syntax highlighting? Without
> autocompletion? Without an editor that scans your sources while you're
> writing and knows all the symbols and their scope? Without something
> like lint that would catch 99% of these silly mistakes (independently
> of the fact that most of them were already avoided by using a more
> appropriate editor)? Just because it doesn't come out of the box with
> whatever compiler you installed doesn't mean it's not there. This is
> not related to C, this is related to lack of doing what a programmer
> needs
> to do.
>
> OK.
> So take the best in class of the support material, build it all into
> an integrated development environment so it's always there unless
> somebody explicitly turns some or all of it off, and you have what
> could be consdiered to be a new flavour of the language (especially
> if you squint your eyes when you look). If a better language is one
> which doesn't ley you do bad things and enforces the doing of 'good'
> things and C doesn't do that then this MUST be a new language. Right
> ? ;-).

Russell, please do something to fix how quoted sections look in your post.
The first paragraph above came from the message you are replying to, the
second is your response.

> You could even add Olin's? cotton-wool
> can't-user-redefine-instructions as an optional switch. Sounds a
> surprisingly 'nanny-state'  approach for Olin to be advocating, but
> would have it's advantages)(As long as you can turn it off :-) ).

Huh?  I have no idea what you're referring to about redefining instructions
and in what context someone could redefine a instruction if they wanted to.
The funny thing is that with my preprocessor, it is actually possible to
redefine or hook a instruction, although I wouldn't recommend it except for
very special cases when you really really know what you're doing and write a
big warning comment so other people know too.

For example, I can define a preprocessor macro to make MOVWF mean something
else:

/macro movwf
  /var local name = [ucase [arg 1]] ;upper case destination name
  /if [= name "SPECIALVAR"]
    /then                    ;special case
         incf    [arg 1]     ;catch this bug if you can!
    /else                    ;normal case, no modification
      /write " movwf " [arg 1]
    /endif
  /endmac

In this devious example, MOVWF will work normally unless you do a MOVWF to
SPECIALVAR.  In that case it will increment SPECIALVAR instead of writing W
to it.  Note that I'm not recommending this, nor have I ever used this
technique, but it is possible.

As a aside but more in keeping on the topic of languages, in a future
version of Prepic you wouldn't have to use /WRITE to write out the movwf
instruction to avoid recursion.  All Prepic symbols are already "stacked".
This is a different way of looking at symbol definitions and scope than most
languages.  Each symbol is actually a stack of definitions for that name.
When a symbol is defined, the new definition is pushed onto the top of the
stack, which then becomes the current one.  When a symbol is deleted, the
current definition is popped from the stack and the previous becomes the
current.  When the last is popped, the symbol becomes undefined.

In the example above, the /VAR LOCAL command defined a new (possibly the
only) version of the symbol NAME, which is then automatically deleted at the
end of the macro excution block.  If /VAR NEW had been used instead, then
the new definition would have peristed after the macro until it was
explicitly deleted.

Currently the top of the stack is the active version of that symbol.  I plan
on changing that for subroutines and macros.  The default version within a
subroutine or macro of that name will be one previous to the version the
subroutine or macro was called with.  Using the example above, MOVFW in top
level code refers to the macro shown.  Within the macro MOVWF would refer to
the previous version of that symbol.  If there is no previous version, it
would not be treated special and it would be just the native MPASM MOVFW
instruction.

This scheme allows a succession of hooks to any routine, with each hook
routine automatically calling the previous.  There will be a special syntax
to identify a absolute or relative version of a symbol so that you can do
recursion when you want.

For now though this hasn't been implemented, which is why the native MPASM
MOVWF instruction had to be written to the output file using the /WRITE
command.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist