Hi MArio
First af all: I'm not an expert on IEC lang
I think the standard is wrong
I wonder where is the advantage to create so huge
complexity
reserved keyword are there for all the programming language
and it's just a simple miss for the user that give a huge
advantage for the implementation of compiler tool
I think the best way to face this is to be not-compliant
with standard and if it is possible to issue a specific
not-compliancy warning if a keyword is used as a variable
or
function name
I ask: How many people really need to use this NEW feature?
Just my idea
Ciao
Marco
----- Segue Messaggio Originale -----
Da : Mario de Sousa <msousa fe.up.pt>
A : mat-devellists.sourceforge.net
oggetto : [MAT-devel] IEC 61131-3 standard and
namespaces...
Data : Thu, 18 Oct 2007 11:50:17 +0100
> Hi all,
>
> You all probably know by now that the IEC compiler
> development has shifted (at least for the time being)
to
> the auspices of another project (www.beremiz.org),
but
> still it continues. Later on, it will probably all be
> incorporated back into the MatPLC project too. The
future
> will tell...
>
> Anyway, the time has now come to start looking at
> incorporating error messages into the IL and ST
syntax
> parser. However, I would like to get your input on an
> important issue, that will heavily affect on how I
should
> go forward.
>
>
> But first, a little background:
> -------------------------------------
> IEC 61131-3 version 1 defined all the IL operators
(LD,
> ST, CAL, RET, JMP, etc...) as reserved words. However,
in
> version 2 of the standard (the version we have been
> following) these operators are no longer reserved
words.
>
> This means that it should be possible to define a
> variable or functiion or function block named LD (for
> example!), and use it inside an IL program. Now, it
may
> seem that it should be possible to distinguish between
an
> IL operator and the reference to a variable/function
by
> the context in which it is used. However, this is not
> always the case. Consider for example:
>
> FUNCTION LD
> VAR_INPUT
>
> ..
> END_FUNCTION
>
>
> FUNCTION FOO
> VAR b: BYTE; END_VAR
> (* IL code *)
> LD b
> END_FUNCTION
>
>
> The line 'LD b' may be interpreted and parsed as
either
> a) the IL operator LD
> b) call of LD funtion
>
> It is not possible to distinguish between the two.
>
>
> Despite all this, when I wrote the syntax parser I
> decided to be pedantic and follow the standard as
> strictly as possible. This means that the syntax
parser
> as it currently stands accepts the declaration of
> functions named 'LD', 'JMP', etc...
>
>
> And now, my question:
> ------------------------------
> All of the above introduced a lot of complexity to
the
> parser, which I am now considering on removing.
>
> Why? Because this is really a flaw in the standard,
and I
> believe that normal users would consider it perfectly
> natural if all the IL operators were to be considered
as
> keywords.
>
> It does have the drawback that we will not be IEC
61131-3
> version 2 compliant, but from what I have seen from
other
> IEC 61131-3 implementations, those are even worse.
>
> Also consider that we are the first and currently only
> implementation of version 2 of the standard. All
previous
> implementations followed version 1, where I believe
IL
> operators were considered keywords, so the above mess
(LB
> b) did not come up.
>
> I would like to hear your opinion. Should we simplify
the
> parser and consider IL operators as keywords, or
should
> we keep it as it is?
>
>
> As you may guess, my vote is on simplifying the
parser.
>
>
> This decision cannot be put off. If we are going to
> simplify the parser, it has to be now, before we
start
> introducing the error guessing algorithms. What do I
mean
> by error guessing algorithms?
>
> The syntax parser can detect syntax errors, but
currently
> does not give out user friendly error messages. In
order
> to do this, we have to guess at the most likely
intention
> of the user, and give an error message to that effect.
> This error handling will all be hard coded and
intricately
> intertwined with the syntax parsing itself.
> If we start doing the error handling now, before we
> simplify the parser, it would:
> a) make introducing error messages now much more
difficult
> ; b) make simplification more difficult later on;
> c) later simplifictaion would also mean throwing out
many
> error messages, and re-doing it all.
>
>
> So, My question again:
>
> Should we:
> a) stop being pedantic (i.e. stop following the
standard
> when we believe the standard is wrong), and simplify
the
> syntax parser now before starting the error message
> guessing,
>
> OR
>
> b) start the error guessing with the syntax parser as
it
> curently stands.
>
>
>
>
>
>
>
> All comments and opinions are forthcoming.....
>
>
>
> Cheers,
>
> Mario.
>
>
----------------------------------------------------------
> --------------- This SF.net email is sponsored by:
Splunk
> Inc. Still grepping through log files to find problems?
> Stop. Now Search log events and configuration files
using
> AJAX and a browser. Download your FREE copy of Splunk
now
> >> http://get.splunk.com/
> _______________________________________________
MAT-devel
> mailing list MAT-devellists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mat-devel
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel
|
