Subject RE: [IB-Architect] Extending SP lang. to ISQL
Author Ann Harrison
At 04:21 AM 5/17/00 -0400, Claudio Valderrama C. wrote:

> >
> > CASE, no question. BREAK ... well there are alternatives (label & leave)
> > that are more elegant.
>
> It seems we clashed only in the name (I hope). If LEAVE means
> "going to the
>next instruction past the immediate surrounding loop", then I'm happy. As a
>disgression, an IBM language known as REXX has a variable name as an option
>to the LEAVE instruction, so you can "leave" not only the most internal loop
>in the case of nested loops. About LABEL, are you writing about the typical
>BASIC programming? If this is more elegant, God save us! Perhaps I
>misunderstood your point, but you didn't provide enough information to
>guess.

Right. You probably don't know BLR intimately. The label statement puts
an identifier on various loop levels. The leave statement includes an
identifier and leaves at that loop level. In BLR, the name space is
integers < 256, I believe, but in a larger language, it could be anything
unique.

> To state in other words: if the client can
>know the result of an operation regardless of the total accuracy (or lack of
>in the case of views) without the need for committing, why I cannot have the
>same number available in the procedure/trigger doing such change? I'm not
>asking for reentrancy or esoterical things (although I suspect reentrancy is
>always a spider waiting for a naive fly) but the modifying last command's
>results are replaced by a new number when my procedure executes a new
>modifying command. As I said, the same number reported by TQuery/TIB_Query
>as RowsAffected.

Understood.


> > >- Some long needed functions, like substr, length and trim.
>
>I assume you didn't comment because these functions would be embedded in the
>server, so no need to fight for the preferred language.

Yes. One of these days we should use the priorities list to prioritize
functions to build in.

> > >- Does anybody knows exactly what's all the power of Interbase?
> > Probably not, but we're working to gather all the bits together.
>
> Maybe you'll discover that substr is already buried in the engine
> under the
>name __substr or something alike, keep us informed!

From ibase.h:
#define blr_substring 40
Don't get too excited. It's not implemented, to the best of my
knowledge.

> > Care? Sure. And maybe when the code is open, it will happen.
>
> As long as it's not 40% assembler, high level languages adherents
> will have
>a chance to see and smell, too.

The only assembler is a tiny module necessary to generate the entry
point list for the VMS shared image.


> > And there are lots of things that are partially implemented and never
> > tested.
>
> Maybe the CURSOR trick inside stored procedures being the most known?

That one was documented at some point, because stored procedures
happened after I left - I didn't figure them out by reading the
code.


>SET FLAME ON
> This fact only confirms that IB is not only the best kept secret
> of Borland
>to the rest of the world but it's the best hidden secret even inside
>Borland.
>SET FLAME OFF

You underestimate Borland.

Ann