> Vlad Khorsun escreveu:
> > I.e. this is assignment operator. Is it consistent to have one assignment operator (:=)
> > for one purpose, and another (=) from another purposes ? I don't think so
> >
> It's inconsistent to use (=) here, as the purposes is different.
>
> When you use (:=), you are assigning to something in another "layer" (a
> calling procedure/function parameter or a named parameter).
>
> (=) is used to compare and assign in the same PSQL module.

The both purposes is assignment. This is the key of the inconsistency. There is no such
syntax construction as "layer", sorry.

> >>> Yes. But how it related to the our question ? Also i suggest not allow to mix named and unnamed
> >>> parameters at one query.
> >>>
> >>>
> >> And it's not good to have different syntax regarding named/unnamed
> >> parameter is used inside the exec. stmt. string.
> >>
> >
> > EXEC STMT will use named parameters only. At least at first implementation.
> It seems you're not planning this feature good enough. You first said it
> named and unnamed parameters is (already?) available... And...

Adriano, this is just our inability to understand each other. I planned named input parameters
for EXEC STMT from the day one.

> > And this named parameters wouldn't been implemented at DSQL level. As we allow to call EXEC STMT from
> > PSQL only i see no problem with compatibility in future.
> >
> ... are creating a different parameter mechanism that work only for EXEC
> STMT, and the current existing one will not work for EXEC STMT.

I not creating any new parameter mechanism. I just need to set correspondence between
named parameter and its value. Not at DSQL level. Not at PSQL level. Just in EXEC STMT
code. That is all. DSQL still worked with plain "?" as parameters.

> > Please, don't make generic statements, show examples when possible. Else we never
> > understand each other.
> >
> Examples of ambiguous expressions has already posted.

Again you not understand what i want to say. Or don't want to understand

> >> How many features has more votes than it? It was one of the more voted
> >> things when I looked.
> >>
> >
> > Again, 10 votes is equal to no votes at all. My opinion of course. Currently i didn't consider
> > voting system as working\representative.
> >
> If the voting system is not representative is another problem.
> Among the voted things, it's the more voted feature.

This list is a wrong place to discuss usability of our voting system. Currently
i don't take it into account as not representative, like you it or not. This is offtopic
here so i see no reason to continue disscussion of this theme in this list.

Ask this 10 people who vote for boolean support - "what exactly do you want".
And you get the answer - "delphi must understand boolean data type of table's fields".
Look at how boolean data type is "implemented" in IB and ask IB users if they need
something more. This is about "quality" of this votes...

...

> statement:
> x = a -- always assignment
>
> expression:
> where x = a -- always expression
> x = a = b -- a = b should always be expression with boolean
> datatype

Tell me please, why "x = a = b" is not ambiguous in PSQL block of code
but is ambiguous in EXEC STMT input parameter syntax ???

> > Anyway, i need to move forward. I'll implement following syntax for input parameters of EXEC STMT :
> >
> > param_name = expression [, param_name = expression]
> >
> > If we'll decide to change syntax it wouldn't been too hard as only parser would need to be changed
> >
> As long you not introduce it in the main branches, I see no problem.
>
> One main purpose of this list is to not create features that causes
> future ones to not be possible.

And to make good explanation with clean arguments

> I see no problem in staged implementations (first named params. for
> EXEC. and latter for DSQL).
> But please do not think at current existing features only.
>
> Look at other implementations too. VBA uses different operator (:= and
> =). Oracle too (=> and :=).

I never said VBA is a good example of how language syntax may looks. As for Oracle - i don't
know reasons why they introduced this ugly construction.

But i always appreciate explanations and i can be convinced by the good ones.

And, you must know, change "=" by ":=" or "=>" in one place in parce.y is a not a hardest job :)

Regards,
Vlad

PS first time i send this message to Adriano instead of list, sorry