Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #68955 > unrolled thread

just curious:Equel

Back to article view | Back to comp.lang.c

Contents

  just curious:Equel G G <gdotone@gmail.com> - 2015-09-01 22:37 -0700
    Re: just curious:Equel James Kuyper <jameskuyper@verizon.net> - 2015-09-02 09:56 -0400
      Re: just curious:Equel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-02 16:03 +0100
        Re: just curious:Equel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 08:12 -0700
          Re: just curious:Equel gordonb.d8f7l@burditt.org (Gordon Burditt) - 2015-09-02 11:09 -0500
          Re: just curious:Equel Richard Heathfield <rjh@cpax.org.uk> - 2015-09-02 17:27 +0100
            Re: just curious:Equel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 09:36 -0700
              Re: just curious:Equel Richard Heathfield <rjh@cpax.org.uk> - 2015-09-02 17:57 +0100
                Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-02 22:34 +0200
                  Re: just curious:Equel Richard Heathfield <rjh@cpax.org.uk> - 2015-09-02 21:48 +0100
                    Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-03 09:31 +0200
                      Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:29 -0700
                  Re: just curious:Equel James Kuyper <jameskuyper@verizon.net> - 2015-09-02 17:09 -0400
                    Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:33 -0700
                  Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 12:56 -0700
                    Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-07 10:57 +0200
                      Re: just curious:Equel Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-07 19:29 +0000
                        Re: just curious:Equel James Kuyper <jameskuyper@verizon.net> - 2015-09-07 15:49 -0400
                          Re: just curious:Equel Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-10 16:44 +0000
                      Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:12 -0700
                        Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-08 10:35 +0200
                          Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-09 10:22 -0700
                            Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-10 10:21 +0200
                              Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 12:06 -0700
                                Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-12 17:53 +0200
                                  Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:04 -0700
                                    Re: just curious:Equel Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 16:17 -0700
                                      Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 12:53 -0700
                                    Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-28 18:00 +0200
                                      Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 12:51 -0700
                              Re: just curious:Equel Philip Lantz <prl@canterey.us> - 2015-09-23 22:18 -0700
                                Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-24 10:08 +0200
                                  Re: just curious:Equel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-24 10:23 +0100
                                    Re: just curious:Equel Philip Lantz <prl@canterey.us> - 2015-09-24 10:28 -0700
                                      Re: just curious:Equel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-24 19:56 +0100
                                  Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:16 -0700
                                    Re: just curious:Equel August Karlstrom <fusionfile@gmail.com> - 2015-09-28 08:18 +0200
                                Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:10 -0700
                                  Re: just curious:Equel supercat@casperkitty.com - 2015-09-27 11:40 -0700
                                    Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-29 10:03 -0700
                  Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:25 -0700
                  Re: just curious:Equel Ike Naar <ike@iceland.freeshell.org> - 2015-09-07 09:14 +0000
            Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 15:44 -0700
              Re: just curious:Equel Keith Thompson <kst-u@mib.org> - 2015-09-06 17:27 -0700
                Re: just curious:Equel Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-08 10:49 -0700
        Re: just curious:Equel James Kuyper <jameskuyper@verizon.net> - 2015-09-02 11:49 -0400
          Re: just curious:Equel Jay Braun <lyngwyst@gmail.com> - 2015-09-02 13:02 -0700
            Re: just curious:Equel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 13:08 -0700
              Re: just curious:Equel G G <gdotone@gmail.com> - 2015-09-02 16:10 -0700
    Re: just curious:Equel Bartc <bc@freeuk.com> - 2015-09-02 21:30 +0100
      Re: just curious:Equel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 13:37 -0700
        Re: just curious:Equel Jay Braun <lyngwyst@gmail.com> - 2015-09-02 13:44 -0700
          Re: just curious:Equel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 13:52 -0700
      Re: just curious:Equel G G <gdotone@gmail.com> - 2015-09-02 16:07 -0700
      Re: just curious:Equel Andreas Perstinger <andipersti@gmail.com> - 2015-09-03 08:49 +0000
        Re: just curious:Equel Bartc <bc@freeuk.com> - 2015-09-03 10:47 +0100
    Re: just curious:Equel G G <gdotone@gmail.com> - 2015-09-02 16:17 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#69658

August Karlstrom <fusionfile@gmail.com> writes:

> On 2015-09-02 18:57, Richard Heathfield wrote:
>> They would indeed be objects, as would p[i] after p = malloc(n * sizeof
>> *p), for p != NULL and i in [0, n)
>
> In C terminology, is there a name for the sequence of allocated
> elements of which p points to the first?

Sure.  It's an array.  See 7.20.3 "Memory management functions",
p1.

[toc] | [prev] | [next] | [standalone]

#69752

On 2015-09-02, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> August Karlstrom <fusionfile@gmail.com> writes:
>>> They would indeed be objects, as would p[i] after p = malloc(n * sizeof
>>> *p), for p != NULL and i in [0, n)
>>In C terminology, is there a name for the sequence of allocated elements 
>>of which p points to the first?
>
>   An array type describes a contiguously allocated nonempty
>   set of objects with a particular member object type. The
>   sequence is an object of array type, given then p has an
>   appropriate type. An object of array type is sometimes
>   colloquially referred to as an ?array?.
>
>   When p points to the first element, this is an array with
>   only one element, even for n > 1.
>
>   However, one could do something like this:
>
> #include <stdio.h>

Did you mean <stdlib.h> instead of <stdio.h>?

> #define N 8
>
> int main( void ) 
> { int( *p )[ N ];
>   if( p = malloc( N * sizeof 0[ ( *p )] )

  if (p = malloc(sizeof *p))

would have been simpler.

[toc] | [prev] | [next] | [standalone]

#69691

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 02/09/2015 16:12, Rick C.  Hodgin wrote:
>
>> What are "C objects?"
>
> 3.14 says:  "region of data storage in the execution environment, the
> contents of which can represent
> values".
>
> For example, in this program:
>
> #include <stdio.h>
>
> int main(void)
> {
>   int i;
>   for(i = 0; i < 10; i++)
>   {
>     printf("%d\n", i);
>   }
>   return 0;
> }
>
> i is an object.  [snip]

i is an identifier.  In this function definition the identifier i
refers to an object (and may refer to more than one, for a
function that might have multiple instantiations), but its
an abuse of teminology to say i is an object.

[toc] | [prev] | [next] | [standalone]

#69706

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 02/09/2015 16:12, Rick C.  Hodgin wrote:
>>
>>> What are "C objects?"
>>
>> 3.14 says:  "region of data storage in the execution environment, the
>> contents of which can represent
>> values".
>>
>> For example, in this program:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>>   int i;
>>   for(i = 0; i < 10; i++)
>>   {
>>     printf("%d\n", i);
>>   }
>>   return 0;
>> }
>>
>> i is an object.  [snip]
>
> i is an identifier.  In this function definition the identifier i
> refers to an object (and may refer to more than one, for a
> function that might have multiple instantiations), but its
> an abuse of teminology to say i is an object.

Tim is a sequence of three ASCII characters.  Tim is a name.
Is it an "abuse of terminology" to say that Tim is a person?

The C standard routinely refers to objects by their names.  The first
example I happened to run across is in N1570 6.7.2.1p20 (an example)
which refers to "the object pointed to by p".  Clearly an identifier
does not point to an object; equally clearly, when the standard says
"p", it means "the pointer object whose name is the identifier p".

Things have names precisely so we can refer to them by those names.
We can add clarifying wording when it's necessary to avoid confusion
(for example to distinguish between you and someone else named Tim);
there is no such need in this case.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#69948

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 02/09/2015 16:12, Rick C.  Hodgin wrote:
>>>
>>>> What are "C objects?"
>>>
>>> 3.14 says:  "region of data storage in the execution environment, the
>>> contents of which can represent
>>> values".
>>>
>>> For example, in this program:
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>>   int i;
>>>   for(i = 0; i < 10; i++)
>>>   {
>>>     printf("%d\n", i);
>>>   }
>>>   return 0;
>>> }
>>>
>>> i is an object.  [snip]
>>
>> i is an identifier.  In this function definition the identifier i
>> refers to an object (and may refer to more than one, for a
>> function that might have multiple instantiations), but its
>> an abuse of teminology to say i is an object.
>
> Tim is a sequence of three ASCII characters.  Tim is a name.
> Is it an "abuse of terminology" to say that Tim is a person?

If the statement is made in a context where it is important
to be technically precise, then Yes, it is.

> The C standard routinely refers to objects by their names.

I expect it does, but the context for those statements is
different, so the distinction is not so important in those
cases.

> The first
> example I happened to run across is in N1570 6.7.2.1p20 (an example)
> which refers to "the object pointed to by p".  Clearly an identifier
> does not point to an object;  equally clearly, when the standard says
> "p", it means "the pointer object whose name is the identifier p".

I would say "the object pointed to by p" means "the object
pointed to by the value held in the variable p", or perhaps "the
object pointed to by the value held in the object referred to
by the identifier p".  I don't think of objects as "having"
names;  in some cases we use an identifier to refer to an
object, but that doesn't give the object "ownership" of the
name, it's the other way around.  In any case all that is
pretty much beside the point, which is that this text assumes
a different context where the distinction between object and
identifier is presumed to be already understood.  When someone
is asking for an explanation of what an object is, we should
assume the distinction between an identifier and an object
is /not/ already understood, which makes it important to
highlight the distinction.

> Things have names precisely so we can refer to them by those names.

That is true in some cases but not all cases.  That observation
is especially important in C, where the relationship between
identifiers and objects is nowhere near one-to-one.

> We can add clarifying wording when it's necessary to avoid confusion
> (for example to distinguish between you and someone else named Tim);
> there is no such need in this case.

I emphatically disagree.  When someone is asking for an
explanation of what an object (in C) is, it is very important
to highlight subtle distinctions, like that of object and an
identifier that is used to refer to an object.  To gloss over
that distinction is doing a severe disservice to both the
questioner and the explnation.

[toc] | [prev] | [next] | [standalone]

#69006

On 09/02/2015 11:03 AM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> On 09/02/2015 01:37 AM, G G wrote:
>>> i am currently reading Compilers, Principles, Techniques, and Tools. 
>>> in chapter one, the author(s) tells the reader that a database query 
>>> language exist in C, Equel.
>>>
>>> is Equel still there as a language extension in the current C compilers.
>>>
>>
>> A google search turned up a company name Equel which provides database
>> services, and a couple of dictionaries that provide the following
>> definition for Equel:
>>
>> "Embedded Quel. INGRES, Inc. Combines QUEL theories with C code."
>>
>> I suspect that you may have misinterpreted what the book was saying -
>> Equel is more likely to have a C-compatible library, rather than being
>> an extension to C itself.
> 
> It's more than a library.  There's a pre-processor that lets you embed
> Ingress queries into C code such they can reference C objects.  It's all
> a bit 1980s.  I don't think anyone thinks that's a good way to do things
> anymore.

That's pretty clumsy. It goes a long way toward explaining why I found
so little about it when I searched.

If that's the way it works, then I was wrong - the book was not being
unreasonable if it talked about the combination of the Equel
pre-processor and the C compiler as working together to effectively
implement an extended version of C.

[toc] | [prev] | [next] | [standalone]

#69023

Equel was one of the fist relational query languages, and was used by INGRES, a very popular database in the early 1980s. At about the same time, IBM developed an alternative, called Structure Query Language, or SQL.  Many at the time believed that Equel was more elegant.  But the IBM product became the standard, much as IBM PCs (actually, as IBM soon discovered, the operating system that Microsoft wrote for them) became a standard.  In both cases, IBM's product was adopted because, in those days, no one ever got fired for choosing IBM.

[toc] | [prev] | [next] | [standalone]

#69024

On Wednesday, September 2, 2015 at 4:02:52 PM UTC-4, Jay Braun wrote:
> Equel was one of the fist relational query languages, and was used by
> INGRES, a very popular database in the early 1980s. At about the same
> time, IBM developed an alternative, called Structure Query Language, or
> SQL.  Many at the time believed that Equel was more elegant.  But the
> IBM product became the standard, much as IBM PCs (actually, as IBM soon
> discovered, the operating system that Microsoft wrote for them) became
> a standard.  In both cases, IBM's product was adopted because, in those
> days, no one ever got fired for choosing IBM.

I would like to read about Equel.  If anyone has a direct link, please
post it.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#69044

On Wednesday, September 2, 2015 at 4:08:29 PM UTC-4, Rick C. Hodgin wrote:

> I would like to read about Equel.  If anyone has a direct link, please
> post it.

There is an annotation in the book ( StoneBraker et al. [1976] ).

[toc] | [prev] | [next] | [standalone]

#69026

On 02/09/2015 06:37, G G wrote:
> i am currently reading Compilers, Principles, Techniques, and Tools.
> in chapter one, the author(s) tells the reader that a database query
> language exist in C, Equel.
>
> is Equel still there as a language extension in the current C compilers.
>
Is that the one by Aho, et al? I'm looking at a preview of it on Amazon, 
and there's no mention of Equel in the index (nor in the bits of Chapter 
1 that are shown). Or maybe that was an updated edition.

But it seems an odd thing to mention in a book about compilers, which 
already has enough on its plate without dragging in proprietary database 
extensions.

I'd forget it.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#69028

On Wednesday, September 2, 2015 at 4:30:57 PM UTC-4, Bart wrote:
> On 02/09/2015 06:37, G G wrote:
> > i am currently reading Compilers, Principles, Techniques, and Tools.
> > in chapter one, the author(s) tells the reader that a database query
> > language exist in C, Equel.
> >
> > is Equel still there as a language extension in the current C compilers.
> >
> Is that the one by Aho, et al? I'm looking at a preview of it on Amazon, 
> and there's no mention of Equel in the index (nor in the bits of Chapter 
> 1 that are shown). Or maybe that was an updated edition.
> 
> But it seems an odd thing to mention in a book about compilers, which 
> already has enough on its plate without dragging in proprietary database 
> extensions.
> 
> I'd forget it.

I'm a database guy.  It would be interesting to see how it was merged
in.  Plus, it's a very clever follow-on if EQUEL preceded SQL, because
some people pronounce SQL as ESS-QUEUE-EL, while others pronounce it
as SEQUEL.  If it were designed to be that way, a follow-on actually
named "sequel" which then happened to work into Standard Query Language,
well ... it's a rather ingenious naming convention.  It makes me wonder
though why EQUEL was called EQUEL. :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#69029

> I'm a database guy.  It would be interesting to see how it was merged
> in.  Plus, it's a very clever follow-on if EQUEL preceded SQL, because
> some people pronounce SQL as ESS-QUEUE-EL, while others pronounce it
> as SEQUEL.  If it were designed to be that way, a follow-on actually
> named "sequel" which then happened to work into Standard Query Language,
> well ... it's a rather ingenious naming convention.  It makes me wonder
> though why EQUEL was called EQUEL. :-)


I found the link below.  EQUEL stood for Embedded QUEL, and QUEL was the query language supplanted by SQL.  Oracle was one of the early adopters of SQL.

The "Embedded" part worked exactly as described above.  You embedded QUEL statements in your C code, and a pre-processor would generate C with all the necessary library calls.

http://downloads.actian.com/download/equel.pdf

[toc] | [prev] | [next] | [standalone]

#69031

On Wednesday, September 2, 2015 at 4:44:55 PM UTC-4, Jay Braun wrote:
> > I'm a database guy.  It would be interesting to see how it was merged
> > in.  Plus, it's a very clever follow-on if EQUEL preceded SQL, because
> > some people pronounce SQL as ESS-QUEUE-EL, while others pronounce it
> > as SEQUEL.  If it were designed to be that way, a follow-on actually
> > named "sequel" which then happened to work into Standard Query Language,
> > well ... it's a rather ingenious naming convention.  It makes me wonder
> > though why EQUEL was called EQUEL. :-)
> 
> 
> I found the link below.  EQUEL stood for Embedded QUEL, and QUEL was the query language supplanted by SQL.  Oracle was one of the early adopters of SQL.
> 
> The "Embedded" part worked exactly as described above.  You embedded QUEL statements in your C code, and a pre-processor would generate C with all the necessary library calls.
> 
> http://downloads.actian.com/download/equel.pdf

Thank you, Jay.

Very interesting!  This type of translation could be implemented with
a configure {...} block I proposed in this thread...:

     https://groups.google.com/forum/#!topic/comp.lang.c/fIFCBuGH5CQ[126-150]

...translating the unique non-C syntax into equivalent C instructions
which are then compiled.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#69043

On Wednesday, September 2, 2015 at 4:30:57 PM UTC-4, Bart wrote:

> But it seems an odd thing to mention in a book about compilers, which 
> already has enough on its plate without dragging in proprietary database 
> extensions.

Yes the book is by Aho, Sethi and Ullman, the one I have maybe the
first edition, reprint?... March 1988, copyright 1986. My books are old
and used but they seem to have some good information in them.

The authors made mention of it while discussing preprocessors.
Macro processing, File inclusion, "Rational" preprocessors, and Language extensions.

>I'd forget it.

I don't think they, the authors, meant to have the reader spin much time thinking
about it. My interest was such that in all my readings so far  of "C" programming
 I hadn't come across it, Equel.

[toc] | [prev] | [next] | [standalone]

#69070

On 2015-09-02, Bartc <bc@freeuk.com> wrote:
> On 02/09/2015 06:37, G G wrote:
>> i am currently reading Compilers, Principles, Techniques, and Tools.
>> in chapter one, the author(s) tells the reader that a database query
>> language exist in C, Equel.
>>
>> is Equel still there as a language extension in the current C compilers.
>>
> Is that the one by Aho, et al? I'm looking at a preview of it on Amazon, 
> and there's no mention of Equel in the index (nor in the bits of Chapter 
> 1 that are shown). Or maybe that was an updated edition.

It looks like OP is reading the first edition from 1986.

> But it seems an odd thing to mention in a book about compilers, which 
> already has enough on its plate without dragging in proprietary database 
> extensions.

Equel is just mentioned as an example in the introduction and the book
doesn't "drag in proprietary database extensions".

Here is the excerpt from the book ("1.4 COUSINS OF THE COMPILER", page
16):

"Preprocessors

Preprocessors produce input to compilers. They may perform the following
functions:

1. ...
2. ...
3. ...
4. Language extensions. These processors attempt to add capabilities to
the language by what amounts to built-in macros. For example, the
language Equel (Stonebraker et al. [1976]) is a database query language
embedded in C. Statements beginning with ## are taken by the
preprocessor to be database-access statements, unrelated to C, and are
translated into procedure calls on routines that perform the database
access."

> I'd forget it.

That's a pretty stupid conclusion.

Bye, Andreas

[toc] | [prev] | [next] | [standalone]

#69084

On 03/09/2015 09:49, Andreas Perstinger wrote:
> On 2015-09-02, Bartc <bc@freeuk.com> wrote:

>> But it seems an odd thing to mention in a book about compilers, which
>> already has enough on its plate without dragging in proprietary database
>> extensions.
>
> Equel is just mentioned as an example in the introduction and the book
> doesn't "drag in proprietary database extensions".

> 4. Language extensions. These processors attempt to add capabilities to
> the language by what amounts to built-in macros. For example, the
> language Equel (Stonebraker et al. [1976]) is a database query language
> embedded in C.

It sounds like it has dragged them in. Of course it might not be 
proprietary.

> Statements beginning with ## are taken by the
> preprocessor to be database-access statements, unrelated to C, and are
> translated into procedure calls on routines that perform the database
> access."
>
>> I'd forget it.
>
> That's a pretty stupid conclusion.

Well, it depends on what the OP is after: it's not really relevant to 
compilers today (and the new edition seems to have taken my advice), and 
it's not part of C.

But it looks like it's still available if the OP desperately wants to 
use it.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#69046

Thanks everyone.

g.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web