syntax errors: a seriously newby question

Fletch

Member
Up until now I've been playing with code fragments that I've picked up from other sources. As such I've known were errors are because I've known what I changed. This weekend I wrote a couple of programs "from scratch" and had syntax errors. Unfortunately the entire program was highlighted in the editor and the message "error in line" was displayed which was less than usefull. Is there a way to see specific faults?
 

BeanieBots

Moderator
One error often causes another, so you should only concentrate on the first line that causes an error and don't worry about anything that comes after it.

Post the first line that causes the error. Bound to be something simple!
 

Fletch

Member
I fixed the issue, I was just expecting some meaningfull messages that can help in localising future faults.
 

BeanieBots

Moderator
I've found the errors nearly always tell you what is wrong.
"syntax error" being a classic where you have written something it does not understand. Usually (with the PICAXE) a command that wants several values to be specified and you've only given it one.
"Insufficient parameters" for example might be a little more meaningful but with the limited command set of PICAXE and the fact that it does point at the offending line, probably a lot of hard work in the compiler with very little real extra value returned.
 

hippy

Technical Support
Staff member
As a writer of compilers and assemblers I've complained in the past about lack of meaningful error messages; "Error in this line" is rather vague given that the compiler knows exactly where on the line it is, what it's just read as a word, what it was expecting, what it got and why that's not right. I disagree that it's a lot of work and with little value. If calling a routine to indicate an error anyway one may as well give the most appropriate error message one can.

My philosopy is that a compiler should give as detailed an error report as it can rather than leave it to a programmer to guess what they've done wrong. Every second saved for the user by a compiler soon adds up given that we all make coding mistakes. Let the programmer get on with thinking about getting code right not having to think about what they just got wrong.

For cases where the compiler highlights the entire file; I've only found a few of them. My approach is to start commenting out lines until the error goes away and then adding code back in, or open a new editor window and move small sections of code until something shows up as an error.
 

Fletch

Member
For cases where the compiler highlights the entire file; I've only found a few of them. My approach is to start commenting out lines until the error goes away and then adding code back in, or open a new editor window and move small sections of code until something shows up as an error.
That was how I resolved it in the end. I was wondering something though. The PICAXE uses a very similar dialect to Stamp PBasic which in turn seems to have been used by other compiler makers. Do any of the other manufactuers tools offer better syntax checking? Could I run the code though the Paralax tools first and only move the code to the PICAXE IDE when most of the errors have been fixed?
 

hippy

Technical Support
Staff member
@ Fletch : I don't know if other compilers offer better error reporting but the programming language will be subtley different between each making it complicated to do what you suggest.

As most errors are minor, their line location identified and usually easy to find, it would be a lot of extra work for little gain.
 

inglewoodpete

Senior Member
One of the better but really simple syntax error handlers that I've seen is used by Cisco in their router command line interpretter. In generic terms, the error is reported as follows:

Code:
Prompt>command parameter1 parameter2 parameter3
                          ^ Unrecognised parameter
The interpretter simply indicates where it got into trouble.

The Programming Editor, being a windows tool could highlight the error in a similar way:

command parameter1 parameter2 parameter3

The impression I have of the PE is that it hasn't been developed in an ideal language and the 'clunkyness' shows at times.
 

hippy

Technical Support
Staff member
The impression I have of the PE is that it hasn't been developed in an ideal language and the 'clunkyness' shows at times.
Again I have to disagree. I acknowledge the 'clunkyness' where it does exist but do not think that's the fault of the language. The IDE front-end is written in Microsoft Visual Basic and entirely suitable for writing an IDE in. The original back-end compilers appear to be written in some version of 16-Bit C, the enhanced compilers in Microsoft Visual C++.

A problem with any code is that as it grows it becomes harder to maintain or alter, and the consequences of past decisions are not easily undone. I can well understand the argument of 'if it's not broken, don't change it' because that brings a lot of unexpected debugging, testing and use of resources which may be needed elsewhere.

So while any shortcomings have to be, inescapably, laid at the door of Rev-Ed, I can understand a reluctance to alter things when what exists is functional and does its job as expected, even if there are places where it could be even better.
 
Top