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

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

Experimental languages/features for C or similar

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

Contents

  Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 03:07 -0800
    Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-08 13:25 +0100
      Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 05:47 -0800
        Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-08 21:03 +0100
          Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 12:10 -0800
            Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-08 21:17 +0100
              Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 13:27 -0800
                Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-09 11:19 +0100
                  Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:00 -0800
                  Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-09 09:04 -0800
                    Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 09:57 -0800
    Re: Experimental languages/features for C or similar fir <profesor.fir@gmail.com> - 2016-11-08 05:16 -0800
      Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-08 06:22 -0800
        Re: Experimental languages/features for C or similar fir <profesor.fir@gmail.com> - 2016-11-08 06:52 -0800
          Re: Experimental languages/features for C or similar fir <profesor.fir@gmail.com> - 2016-11-08 07:08 -0800
            Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-08 07:47 -0800
        Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:13 -0800
          Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:48 -0800
          Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-17 03:21 -0800
    Re: Experimental languages/features for C or similar "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:16 +0800
      Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:00 -0800
        Re: Experimental languages/features for C or similar "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 00:13 +0800
          Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-08 08:41 -0800
            Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:50 -0800
              Re: Experimental languages/features for C or similar Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 17:10 +0000
    Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 19:06 +0100
    Re: Experimental languages/features for C or similar Andreas <nospam@invalid.invalid> - 2016-11-08 21:43 +0100
    Re: Experimental languages/features for C or similar luser droog <luser.droog@gmail.com> - 2016-11-10 12:29 -0800
      Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-11 02:35 -0800
      Re: Experimental languages/features for C or similar BartC <bc@freeuk.com> - 2016-11-11 10:43 +0000
        Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-17 20:15 +0100
          Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-17 11:59 -0800
            Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-17 22:27 +0100
              Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-17 22:45 +0100
              Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-17 14:28 -0800
                Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 00:13 +0100
                  Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-17 15:37 -0800
                    Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 09:29 +0000
                      Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 21:59 +0100
                        Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 21:14 +0000
                          Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 22:38 +0100
                    Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 11:26 +0100
                      Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-18 08:56 -0800
                  Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 08:16 +0100
                    Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 11:42 +0100
                      Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 13:16 +0100
                        Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 12:23 +0000
                          Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 14:28 +0100
                            Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 14:24 +0000
                              Re: Experimental languages/features for C or similar raltbos@xs4all.nl (Richard Bos) - 2016-11-18 14:34 +0000
                              Re: Experimental languages/features for C or similar BartC <bc@freeuk.com> - 2016-11-18 14:37 +0000
                              Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 14:38 +0000
                              Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 15:47 +0100
                                [OT] Linux and Firefox "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:50 +0800
                                Re: Window$ and Firefox "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:51 +0800
                                  Re: taskkill "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:52 +0800
                                    Re: taskkill David Brown <david.brown@hesbynett.no> - 2016-11-18 16:44 +0100
                                Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 15:11 +0000
                                  Re: Who cares (about Window$)? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 23:24 +0800
                                    Re: Who cares (about Window$)? David Brown <david.brown@hesbynett.no> - 2016-11-18 16:41 +0100
                                      Re: Who cares (about Window$)? Melzzzzz <mel@zzzzz.com> - 2016-11-18 16:45 +0100
                                        Re: Who cares (about Window$)? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:35 +0100
                                          Re: Who cares (about Window$)? Real Troll <real.troll@trolls.com> - 2016-11-18 13:10 -0400
                                          Re: Who cares (about Window$)? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-18 18:29 +0000
                                    Re: Who cares (about Window$)? jameskuyper@verizon.net - 2016-11-18 11:49 -0800
                              Re: Experimental languages/features for C or similar jameskuyper@verizon.net - 2016-11-18 11:42 -0800
                                Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-19 20:37 +0000
                        Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 12:34 +0000
                          Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 13:46 +0100
                        Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 13:44 +0100
                          Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 14:44 +0100
                            Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-19 01:16 +0100
                              Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-19 15:43 +0100
                                Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-19 18:13 +0100
              Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 00:16 +0000
                Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 09:25 +0100
            Re: Experimental languages/features for C or similar BartC <bc@freeuk.com> - 2016-11-18 18:15 +0000
              Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 19:18 +0000
          Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 08:20 +0100
    Re: Experimental languages/features for C or similar "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 20:36 +0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#96090

On Tuesday, November 8, 2016 at 12:16:30 PM UTC-2, Mr. Man-wai Chang wrote:
> On 8/11/2016 7:07 PM, Thiago Adams wrote:
> > My question is: Do you have debug, autocomplete?
> > I know there are some IDEs ready for language plugins but this also requires a lot of work (time).
> 
> You don't need those crap. A good programmers don't need clues nor cues 
> to write codes. They only need TRUSTED, MANAGED, TRUE compilers and 
> relevant tools (e.g. HONEST manuals).
> 
> BUT, it could be a good teaching tools for the "virgins". :)

So, what you are saying, is that if you need to send rocket to the moon using C code (what language would you choose?) you don't need debug and more compiler checks? 
If you are a professional programmer with C, with a large code base, I am sure you (we) will need debug.
 
> > One possible solution I thought is to generate one big file with C code using #line and then use inside a C IDE. (I don't have experience with assembler as well, but I am happy with the "C generated code")
> > Does anyone has experience with this?
> 
> Pre-processor?

Sometimes it's not enough.

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

#96095

On 9/11/2016 12:00 AM, Thiago Adams wrote:
> So, what you are saying, is that if you need to send rocket to the moon using C code (what language would you choose?) you don't need debug and more compiler checks?

I don't play with dangerous fuel. :)

> If you are a professional programmer with C, with a large code base, I am sure you (we) will need debug.

printf("");

>>> One possible solution I thought is to generate one big file with C code using #line and then use inside a C IDE. (I don't have experience with assembler as well, but I am happy with the "C generated code")
>>> Does anyone has experience with this?
>>
>> Pre-processor?
>
> Sometimes it's not enough.

C++ is a pre-processor, at least, initially.

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

#96101

On Tuesday, November 8, 2016 at 10:13:26 AM UTC-6, Mr. Man-wai Chang wrote:
> On 9/11/2016 12:00 AM, Thiago Adams wrote:
> > If you are a professional programmer with C, with a large code base, I am sure you (we) will need debug.
> 
> printf("");

Of course, in modern compilers, printf can introduce some surprises of its
own.  For example, something like:

    if (p != NULL) { printf("Pointer p was not null"); getch(); }
    someFunction(p);

might unconditionally print out the message and wait for a character if
the compiler determines that the code in someFunction() would invoke UB
if given a null pointer.

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

#96105

On Tuesday, November 8, 2016 at 2:41:29 PM UTC-2, supe...@casperkitty.com wrote:
> On Tuesday, November 8, 2016 at 10:13:26 AM UTC-6, Mr. Man-wai Chang wrote:
> > On 9/11/2016 12:00 AM, Thiago Adams wrote:
> > > If you are a professional programmer with C, with a large code base, I am sure you (we) will need debug.
> > 
> > printf("");
> 
> Of course, in modern compilers, printf can introduce some surprises of its
> own.  For example, something like:
> 
>     if (p != NULL) { printf("Pointer p was not null"); getch(); }
>     someFunction(p);
> 
> might unconditionally print out the message and wait for a character if
> the compiler determines that the code in someFunction() would invoke UB
> if given a null pointer.

I thought printf was a joke. I never know , because of many :)

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

#96107

Thiago Adams <thiago.adams@gmail.com> writes:

> On Tuesday, November 8, 2016 at 2:41:29 PM UTC-2, supe...@casperkitty.com wrote:
>> On Tuesday, November 8, 2016 at 10:13:26 AM UTC-6, Mr. Man-wai Chang wrote:
>> > On 9/11/2016 12:00 AM, Thiago Adams wrote:
>> > > If you are a professional programmer with C, with a large code
>> > > base, I am sure you (we) will need debug.
>> > 
>> > printf("");
>> 
>> Of course, in modern compilers, printf can introduce some surprises of its
>> own.  For example, something like:
>> 
>>     if (p != NULL) { printf("Pointer p was not null"); getch(); }
>>     someFunction(p);
>> 
>> might unconditionally print out the message and wait for a character if
>> the compiler determines that the code in someFunction() would invoke UB
>> if given a null pointer.

None that I know do so if you have optimisation turned off which it
pretty much a universal recommendation for debugging.  If the problem
(and the print call) only shows up when you crank up the optimisation,
then you know, pretty much, where the problem is.

> I thought printf was a joke. I never know , because of many :)

Man-wai Chang was suggesting using printf calls to debug (sometime you
have to a sometimes it's even the best way).

And supercat was posting about his one topic: evil compilers that
optimise in way he does not like.  Neither is joking.

-- 
Ben.

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

#96109

Le 08/11/2016 à 12:07, Thiago Adams a écrit :
>
> Many people in this group have experience implementing new languages or compilers.
>
Yes, I am the author of lcc-win. I have a modified version of the lcc 
compiler, and an IDE with all the code under windows (debugger is 
present too)

> I have thought about this many times, but the main problem I see is to have something as productive as the IDEs

like Visual Studio etc instead of just some experimental language that 
needs command line and no debug.

I  have a debugger
>
> My question is:

Do you have debug, autocomplete?

YES

> I know there are some IDEs ready for language plugins but this also requires a lot of work (time).

It took me around 2 years  and still has a lot of bugs
>
> What do you think? How do you do?

If you want I can send you the IDE code and we work together

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

#96135

Thiago Adams <thiago.adams@gmail.com> writes:

> I have thought about this many times, but the main problem I see is to
> have something as productive as the IDEs like Visual Studio etc
> instead of just some experimental language that needs command line and
> no debug.

Maybe mbeddr (http://mbeddr.com/) might be of interest for you; a
C-based domain-specific language, which is both interesting in itself
and a nice showcase for JetBrain's MPS (https://www.jetbrains.com/mps/).
The general idea is to make it easier to create domain-specific
languages with IDE-suport built-in.

-- 
What do you mean? An African or a European swallow?

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

#96332

On Tuesday, November 8, 2016 at 5:07:11 AM UTC-6, Thiago Adams wrote:
> Many people in this group have experience implementing new languages or compilers.
> 
> I have thought about this many times, but the main problem I see is to have something as productive as the IDEs like Visual Studio etc instead of just some experimental language that needs command line and no debug.
> 
> My question is: Do you have debug[?] 

For my languages there are 2 kinds of debugging available. The program may 
be compiled in a "gratuitously verbose output mode" where it printf's 
hopefully enough information that you can follow exactly what it's trying
to do when (if?) it crashes. 

The other kind is debugging tools available to the input language. Only for
postscript have I done this, viz. 

  https://github.com/luser-dr00g/debug.ps

but it also runs on any other standard-compliant postscript interpreter like
ghostscript. I think it provides a valuable tool even if you're not ps-ssessed
as me. It can generate traces of ps code executing with running stack comments,
in a form that can even be cut-and-pasted back into the interpreter. That is a
big benefit that window environments add to the text-terminal interface. 
The Roguelike that can be named is not the true Roguelike.

>autocomplete? 

No. Learn to type. It is hard. It's good for you.

> I know there are some IDEs ready for language plugins but this also requires a lot of work (time). 
> 
> What do you think? How do you do?

I love my languages! But I don't "use them" for much, besides inspiration to 
write new ones and new features.

> One possible solution I thought is to generate one big file with C code using #line and then use inside a C IDE. (I don't have experience with assembler as well, but I am happy with the "C generated code")
> Does anyone has experience with this?

Dude, Fraser and Hanson. lmgtfy
https://smile.amazon.com/Retargetable-Compiler-Design-Implementation-1995-02-10/dp/B01JXMG072/ref=sr_1_1?s=books&ie=UTF8&qid=1478809500&sr=1-1&keywords=fraser+and+hanson

If you're quick, there's one for $13 +change.

Read. That. Book. Dude. All  the answers your looking for. Seriously.
The whole compiler. In C. Explained. $14.

> The reason I start doing one static analyzer for C it's because I think it's useful. It can analyze itself for instance.
> But, I would like to try new features for C, like the {default} initialization I posted here, and try to improve the type-system  and some feature for polimorphism.

google up axel schreiner's oopc.pdf OOP in ANSI C.

--  
that's what I'm saying. some of this good stuff is old.

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

#96372

On Thursday, November 10, 2016 at 6:29:22 PM UTC-2, luser droog wrote:
> On Tuesday, November 8, 2016 at 5:07:11 AM UTC-6, Thiago Adams wrote:
> > Many people in this group have experience implementing new languages or compilers.
> > 
> > I have thought about this many times, but the main problem I see is to have something as productive as the IDEs like Visual Studio etc instead of just some experimental language that needs command line and no debug.
> > 
> > My question is: Do you have debug[?] 
> 
> For my languages there are 2 kinds of debugging available. The program may 
> be compiled in a "gratuitously verbose output mode" where it printf's 
> hopefully enough information that you can follow exactly what it's trying
> to do when (if?) it crashes. 
> 
> The other kind is debugging tools available to the input language. Only for
> postscript have I done this, viz. 
> 
>   https://github.com/luser-dr00g/debug.ps
> 
> but it also runs on any other standard-compliant postscript interpreter like
> ghostscript. I think it provides a valuable tool even if you're not ps-ssessed
> as me. It can generate traces of ps code executing with running stack comments,
> in a form that can even be cut-and-pasted back into the interpreter. That is a
> big benefit that window environments add to the text-terminal interface. 
> The Roguelike that can be named is not the true Roguelike.
> 
> >autocomplete? 
> 
> No. Learn to type. It is hard. It's good for you.
> 
> > I know there are some IDEs ready for language plugins but this also requires a lot of work (time). 
> > 
> > What do you think? How do you do?
> 
> I love my languages! But I don't "use them" for much, besides inspiration to 
> write new ones and new features.
> 
> > One possible solution I thought is to generate one big file with C code using #line and then use inside a C IDE. (I don't have experience with assembler as well, but I am happy with the "C generated code")
> > Does anyone has experience with this?
> 
> Dude, Fraser and Hanson. lmgtfy
> https://smile.amazon.com/Retargetable-Compiler-Design-Implementation-1995-02-10/dp/B01JXMG072/ref=sr_1_1?s=books&ie=UTF8&qid=1478809500&sr=1-1&keywords=fraser+and+hanson

Yes I know this book, thanks.
Will  buy in case I want to generate machine code.

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

#96374

On 10/11/2016 20:29, luser droog wrote:

> Dude, Fraser and Hanson. lmgtfy
> https://smile.amazon.com/Retargetable-Compiler-Design-Implementation-1995-02-10/dp/B01JXMG072/ref=sr_1_1?s=books&ie=UTF8&qid=1478809500&sr=1-1&keywords=fraser+and+hanson

I liked this comment in one of the reviews:

"This text seemed more suited to University level Computer Science 
students than to the average Joe Schmoe who just wants to write a C 
compiler."

Like the average guy even knows what a compiler is!

-- 
Bartc

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

#96763

Le 11/11/2016 à 11:43, BartC a écrit :
> On 10/11/2016 20:29, luser droog wrote:
>
>> Dude, Fraser and Hanson. lmgtfy
>> https://smile.amazon.com/Retargetable-Compiler-Design-Implementation-1995-02-10/dp/B01JXMG072/ref=sr_1_1?s=books&ie=UTF8&qid=1478809500&sr=1-1&keywords=fraser+and+hanson
>>
>

There are other stupid comments there. For instance this one:


By A Customer on April 5, 1999
Format: Paperback
Here "A customer" is the Amazon comments guy. The other text is by me.

A customer:
I did not like this book.

I did like this book. It changed many things in my life.

A customer:
First of all the authors are egotistical saying things along the lines 
of "this compiler *must* be great, hundreds of people are using it."


Well, they point out that the compiler they publish for everyone to read 
and study is used by many people.

"Egotistical"?

When they make available the whole compiler with commented source code?
This is not just GNU that overwhelms us with megabytes of code where the 
only comment is the copyright notice and no technical documentation.
This is a fully commented code in a top down manner, easy to get into.

A customer:
Secondly, they wrote their compiler in pre-ANSI C, making it difficult 
to read.

No, this is wrong. The code is written in Ansi C 89, at the time the 
current standard. If you had read the book they fully support prototypes
and follow very well the then current standard!

A customer:
Similarly, they use a hokey "hypertext" style format for presenting the 
source code,also making it difficult to read.

This is called "literate programming" and was developed by Don Knuth 
with his program that intermixes Tex with source code by giving 
connected snippets of it each at a time decreasing the effort to 
understand what is going on. Source code is thus very well cross referenced.

A customer:
Thirdly, their techniques are questionable - they don't use automatic 
tools for scanning or parser generation.

Yes. This is true, and I am happy that they didn't use lex/yacc/whatever 
tools but they just gave us a very simple code that fulfills its job 
without a hitch.

A customer:
In fact their scanner is one big 'case' statment. Their parser is 
recursive descent, hand-written.

Yes, and it is incredibly FAST. No automated tools, just raw C and its 
great speed. Automated tools have limits. There is nothing like a brain 
when you want quality.


A customer:
This is one of the least maintainable and most hard to read parsing 
techniques.

I have added a lots of stuff to the parser, all C99, that wasn't even 
present when I started. No problems here, their parser was very easy to 
understand and modify!

A customer:
I do give them credit, though, for writing a compiler with easily 
changeable back ends.

A great thing. I could port it to the power PC and I am now porting to 
ARM. Compare that to porting  gcc to do a new CPU.

A customer:
This part is way cool, especially with such diverse platforms as Sparc 
and x86. Finally, their writing is not easily read - especially with the 
hokey code interspersed.

Writing a compiler, modifying one, retargeting one are no easy tasks.
Their writing is technical writing that is difficult not because of the 
writing style, but because the stuff tehy are talking about is complex 
and really hard to understand.

A customer:
I bought it wanting to learn about their code generation but have 
decided to return it, and will probably buy Advanced Compiler Design And 
Implementation; Muchnick, Steve instead.

Those books do not provide a running compiler, their center of attention 
is different.

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

#96766

jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> When they make available the whole compiler with commented source code?
> This is not just GNU that overwhelms us with megabytes of code where the 
> only comment is the copyright notice and no technical documentation.
> This is a fully commented code in a top down manner, easy to get into.

Are you saying gcc has no technical documentation?

https://gcc.gnu.org/onlinedocs/gccint/

(I make no comment on the quality of the documentation, since I haven't
read it.)

-- 
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]

#96776

Le 17/11/2016 à 20:59, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> [...]
>> When they make available the whole compiler with commented source code?
>> This is not just GNU that overwhelms us with megabytes of code where the
>> only comment is the copyright notice and no technical documentation.
>> This is a fully commented code in a top down manner, easy to get into.
>
> Are you saying gcc has no technical documentation?
>
> https://gcc.gnu.org/onlinedocs/gccint/
>
> (I make no comment on the quality of the documentation, since I haven't
> read it.)
>

If you haven't read it why do you say that that is documentation?

Well obviously you say that because you haven't read it.

For instance, just one thing that I took from that link

<quote>
9.1 Parsing pass

The language front end is invoked only once, via lang_hooks.parse_file, 
to parse the entire input. The language front end may use any 
intermediate language representation deemed appropriate. The C front end 
uses GENERIC trees (see GENERIC), plus a double handful of language 
specific tree codes defined in c-common.def. The Fortran front end uses 
a completely different private representation.
<end quote>

What do you learn from that? It doesn't even name the affected files, 
nor the interface between the language front end and the rest of the 
software, nor it explains (for the C front end) how this is done.

You learn nothing from that sentence. And then it goes on:

<quote>
At some point the front end must translate the representation used in 
the front end to a representation understood by the language-independent 
portions of the compiler. Current practice takes one of two forms. The C 
front end manually invokes the gimplifier (see GIMPLE) on each function, 
and uses the gimplifier callbacks to convert the language-specific tree 
nodes directly to GIMPLE before passing the function off to be compiled. 
The Fortran front end converts from a private representation to GENERIC, 
which is later lowered to GIMPLE when the function is compiled. Which 
route to choose probably depends on how well GENERIC (plus extensions) 
can be made to match up with the source language and necessary parsing 
data structures.
<end quote>

And that is all. Those two sentences tell you everything you need to 
know about parsing and the intrincacies of writing a new language front 
end. Because that is the sense of having a language independent compiler 
front end isn't it?

1156 bytes of text, that is all. And you call this a technical 
documentation?

Wait a minute. This is there to give people the impression that there is 
a detailed documentation so that in discussion forums some gcc fan can 
always point to that URL to silence critics.

:-)

Compare that to the book of Chris and Dave: Everything is explained, why 
the code is like that, the algorithms used, etc.  Wait a minute,
before saying that that URL contains technical docs you should READ IT 
FIRST!

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

#96777

Le 17/11/2016 à 22:27, jacobnavia a écrit :

That sentence in the gcc "docs" for instance:

> The C front end uses GENERIC trees (see GENERIC), plus a double handful
> of language specific tree codes defined in c-common.def.


Mmmm c-common.def where is that used in the code of gcc?

/Volumes/Disque1-B/gcc-4.9/gcc $ grep c-common.def *.h  *.c
/Volumes/Disque1-B/gcc-4.9/gcc $

It doesn't appear in the source? How it is compiled then?

No clue, and the "documentation" will not say that to you. You should be 
able to get into their psychology:

OK, they are comoiler writers, there is probably a GENERATED file in the 
Makefile isn't it?

BINGO!

1583 s-alltree: Makefile
1584     rm -f tmp-all-tree.def
1585     echo '#include "tree.def"' > tmp-all-tree.def
1586     echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def
1587     echo '#include "c-family/c-common.def"' >> tmp-all-tree.def
1588     ltf="$(lang_tree_files)"; for f in $$ltf; do \
1589       echo "#include \"$$f\""; \
1590     done | sed 's|$(srcdir)/||' >> tmp-all-tree.def
1591     $(SHELL) $(srcdir)/../move-if-change tmp-all-tree.def all-tree.def
1592     $(STAMP) s-alltree

Look I am used to their psychology, that is why I know that they will 
never do a technical documentation. They are mostly not getting paid, so 
they must have some fun at least isn't it?

Writing the documentation is not fun. And please do not tell me that I 
should "contribute  instead of complaining" ok?

Thanks

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

#96779

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 17/11/2016 á 20:59, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> [...]
>>> When they make available the whole compiler with commented source code?
>>> This is not just GNU that overwhelms us with megabytes of code where the
>>> only comment is the copyright notice and no technical documentation.
>>> This is a fully commented code in a top down manner, easy to get into.
>>
>> Are you saying gcc has no technical documentation?
>>
>> https://gcc.gnu.org/onlinedocs/gccint/
>>
>> (I make no comment on the quality of the documentation, since I haven't
>> read it.)
>
> If you haven't read it why do you say that that is documentation?
>
> Well obviously you say that because you haven't read it.

[snip]

Apparently saying "I make no comment on the quality of the
documentation, since I haven't read it" wasn't clear enough.
Let me restate it  more clearly for you.

I MAKE NO COMMENT ON THE QUALITY OF THE DOCUMENTATION, SINCE I
HAVEN'T READ IT.

-- 
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]

#96781

Le 17/11/2016 à 23:28, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 17/11/2016 á 20:59, Keith Thompson a écrit :
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> [...]
>>>> When they make available the whole compiler with commented source code?
>>>> This is not just GNU that overwhelms us with megabytes of code where the
>>>> only comment is the copyright notice and no technical documentation.
>>>> This is a fully commented code in a top down manner, easy to get into.
>>>
>>> Are you saying gcc has no technical documentation?
>>>
>>> https://gcc.gnu.org/onlinedocs/gccint/
>>>
>>> (I make no comment on the quality of the documentation, since I haven't
>>> read it.)
>>
>> If you haven't read it why do you say that that is documentation?
>>
>> Well obviously you say that because you haven't read it.
>
> [snip]
>
> Apparently saying "I make no comment on the quality of the
> documentation, since I haven't read it" wasn't clear enough.
> Let me restate it  more clearly for you.
>
> I MAKE NO COMMENT ON THE QUALITY OF THE DOCUMENTATION, SINCE I
> HAVEN'T READ IT.
>

But you say that those 1256 bytes are "documentation".

Without reading it. Just because you are you of course. And
can't be contradicted by anyone and starts shouting when you ran out of 
arguments since you do not know what you are talking about:

You haven't even READ the document you cite!

I am saying that those bytes are just not by any means part of any 
documentation, i.e. explaining in a human readable form the workings of 
the code its trying to document.

You pointed to that link in the context where I just said that gcc 
overwhelms the reader with tons of code with absolutely no technical 
documentatiobn, so you IMPLIED that that link was a documentation!

And no amount of shouting will hide that from anyone.

The book of Chris Fraser and Dave Hanson *IS* a full technical 
documentation. Just see the difference and when you do not know what you 
are talking about keep your mouth shut.

Thanks

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

#96783

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 17/11/2016 à 23:28, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 17/11/2016 á 20:59, Keith Thompson a écrit :
>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>> [...]
>>>>> When they make available the whole compiler with commented source code?
>>>>> This is not just GNU that overwhelms us with megabytes of code where the
>>>>> only comment is the copyright notice and no technical documentation.
>>>>> This is a fully commented code in a top down manner, easy to get into.
>>>>
>>>> Are you saying gcc has no technical documentation?
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gccint/
>>>>
>>>> (I make no comment on the quality of the documentation, since I haven't
>>>> read it.)
>>>
>>> If you haven't read it why do you say that that is documentation?
>>>
>>> Well obviously you say that because you haven't read it.
>>
>> [snip]
>>
>> Apparently saying "I make no comment on the quality of the
>> documentation, since I haven't read it" wasn't clear enough.
>> Let me restate it  more clearly for you.
>>
>> I MAKE NO COMMENT ON THE QUALITY OF THE DOCUMENTATION, SINCE I
>> HAVEN'T READ IT.
>
> But you say that those 1256 bytes are "documentation".

What 1256 bytes are you talking about?  I posted a link to the index
page of a manual containing 25 chapters.  Is it not displaying correctly
for you?  I have the equivalent manual on my system as "gccint.info.gz",
which is 2486404 bytes after decompression.

I am not saying that the size of the documentation has anything to do
with its quality.  I am saying only that it exists.  I said so, with an
appropriate disclaimer.  Anyone is free to follow the link and reach
their own conclusions.

If you're saying that it's of such low quality that it shouldn't even be
called "documentation", I won't argue with you.

As usual, I have no idea why you have a problem with me.

[SNIP]

-- 
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]

#96794

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

> As usual, I have no idea why you have a problem with me.

That would be "because you don't agree with everything Jacob says".  He
has a problem with everyone like that (including, now, the C Standards body)

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

#96897

Le 18/11/2016 à 10:29, Gareth Owen a écrit :
> That would be "because you don't agree with everything Jacob says".  He
> has a problem with everyone like that (including, now, the C Standards body)

Yes, you are right. I do not agree at all with the reject of a 
containers library. I still am of the opinion that C can (as I proved 
with a sample implementation) construct containers much more easily than 
in C++.

Heresy.

OK, I am an heretic that knows no religion and I do not take any 
decision of the C standards committee as THE LAW.

:-)

So what?

By the way it is not the fact that you disagree with me that bothers me, 
but your exaggeration of the "hate" I would have against people that 
disagree with me, like you.

I have exposed some arguments in this group, shown some code, I do not 
think I am talking nonsense, if you mind.

Let's discuss in a civilized manner.

jacob

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

#96899

jacobnavia <jacob@jacob.remcomp.fr> writes:

> By the way it is not the fact that you disagree with me that bothers
> me, but your exaggeration of the "hate" I would have against people
> that disagree with me, like you.

Then you need to express your self in a calmer manner when someone does
disagree with you. Instead, you have a tendency to express the sentiment
that you think Keith has some sort of vendetta against you.

> Let's discuss in a civilized manner.

That would've been nice.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web