Subscribe to this thread
Home - General / All posts - EXECUTE query : error --> cannot parse query
340 post(s)
#07-Apr-22 08:18


I am trying to execute a bunch of queries from within another query,

Here is my code from within this other query


EXECUTE 1_Check_for_overlaps_modified_Yves


Manifold responds with "cannot parse query" though running the initial query directly executes flawlessly.

I am probably overseeing something obvious.


340 post(s)
#07-Apr-22 08:28

OK. Solved.

EXECUTE does not like query names starting with figures.


1,935 post(s)
#07-Apr-22 09:54

I have had this same problem in the past and each query runs fine individually. I will have to check whether my query stack is sequentially named. Thanks for the tip.

Landsystems Ltd ... Know your land |


9,976 post(s)
#07-Apr-22 11:24

Figures (chiffres)?

If you're sure, then that would be a bug.

148 post(s)
#07-Apr-22 11:55

It is not the number that is the problem but the underline. In fact, the query must be identified by a word without spaces or symbols like _ - / +.

340 post(s)
#07-Apr-22 13:47

Thought underscore '_' was allowed, and is working fine for me !


583 post(s)
#07-Apr-22 15:38

It is the number at the start that is the problem. For safety I always use []


10,011 post(s)
#18-May-22 08:46

That's a bug. I will file a report to fix it. Identifiers starting with decimal digits should still be recognized as identifiers.


10,011 post(s)
#01-Jun-22 06:38

Post mortem.

I was too hasty to call that a bug. It is not a bug. Identifiers starting with decimal digits should NOT be recognized as identifiers because that creates ambiguities. (Quick illustration: if 1_check_for_overlaps should be an identifier, why 123 shouldn't? Or 1e20? Both are valid component names. That's why we need a simple rule like: if something starts with a decimal digit, that's a number. If you have an identifier that happens to start with a decimal digit, enclose it in [].)


9,976 post(s)
#01-Jun-22 08:07

I think this death was called prematurely.

Why not 123 or 1e20? Because they CAN be parsed as float.

1_check_for_overlaps cannot. So it is clearly meant as a name.

That is a simple enough rule, isn't it?

I.e. if a token can be parsed as float, then it can't be an identifier; and if it stands where an identifier should stand, that is a syntax error. (The fact that 9 requires AS for aliases helps here.)

Otherwise an identifier starting with a digit should be fine.

(No bug here though, agreed. Just a decision.)


10,011 post(s)
#01-Jun-22 12:20

Then you have to remember all ways one can write a number. And we either stop being able to add more ways to write numbers (eg, many languages allow hexadecimal literals like 12ABh or binary literals like 1001011b or just long decimal literals with digit groups separated for readability like 1_250_000 or 1'250'000, we'd like to eventually add some of these things and / or others), or break some queries every time we add them.

The logic is simple: there is an ambiguity in that an identifier can be spelled like a number. To resolve this ambiguity we need to have some rule. The rule can be "anything that can be parsed as a number, is a number", like you propose, but this forces everyone to remember what exactly can be parsed as a number and harms the ability to add more ways to write numbers. The rule of "anything that starts with a decimal digit is a number" is simpler to remember and is guaranteed to not break over time.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.