LO 80731 - Incorrect syntax does compile, MID without end bracket

Jean-Pierre Ledure jp at ledure.be
Thu Jun 29 10:12:01 UTC 2017


The default bahaviour of any Basic interpreter should be IMHO to check 
the syntax as strictly as possible.

On the other side tons of legacy Basic sources will not compile anymore, 
- including the Basic libraries (Access2Base, ...) delivered with LO 
unless they're patched  on time !

I do support Pierre's proposal to have an option to (temporarily) 
*uncheck* the strict syntax checking,
However
- the option should be easily visible and accessible from the Basic IDE 
(f.i. not after having checked "enable experimental features" first ...)
- the text of the option should be less cryptic then "StarBasic Pragma 
Strict", but preferably something like "Do not check Basic syntax strictly"
- Release Notes and help pages should inform the users in detail
- the option should remain during a long enough period of time

JP


Le 28/06/17 à 13:08, Kaganski Mike a écrit :
> On 6/28/2017 2:03 PM, Stephan Bergmann wrote:
>> On 06/28/2017 12:12 PM, Pierre Lepage wrote:
>>> The solution brings a lot of hassle for customers of the LibreOffice
>>> suite whose work relies on the performance of StarBasic macros written
>>> by third parties. Macros containing code in error by the absence of a
>>> closing parenthesis suddenly cease to function. For this reason, the
>>> patch has not been released. Here I want to explore a transitional
>>> solution by getting your feedback first. This is to include in
>>> StarBasic options dialog accessible to the client a "StarBasic Pragma
>>> Strict" option (checkbox) by which the client consciously activates
>>> the solution (the patch that has not been published!). This check box
>>> would be available for a few years with a warning to prompt
>>> programmers and customers to require their programmer to correct their
>>> default code on the closing parenthesis.
>> Another option might be to have some form of such a pragma in individual
>> BASIC source files, instead of as an IDE option.  (And have the pragma
>> enabled in the "REM ***** BASIC ****** Sub Main ... End Sub" boilerplate
>> that is automatically present in a fresh source file.)  That way, users
>> could enable it for their own, new code, while (implicitly) keeping it
>> off for non-conforming old, 3rd-party code.
> I'd suggest also a special handling of "Compile" IDE command. It should
> always use strict parsing method. As it is a developer's tool, used when
> something is created anew, it would help all developers catch the
> problem early even when they don't know the strict option (wherever it be).
>



More information about the LibreOffice mailing list