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

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

Information on compiler/parser techniques for a new C-derived programming language

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

Contents

  Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-16 13:26 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-16 23:02 +0100
      Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 12:40 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language James Kuyper <jameskuyper@verizon.net> - 2015-04-17 16:36 -0400
          Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 11:04 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language James Kuyper <jameskuyper@verizon.net> - 2015-04-18 22:53 -0400
              Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-22 13:07 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language Robert Wessel <robertwessel2@yahoo.com> - 2015-04-18 23:14 -0500
        Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-18 14:34 +0100
    Re: Information on compiler/parser techniques for a new C-derived programming language Richard Damon <Richard@Damon-Family.org> - 2015-04-16 20:59 -0400
      Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 13:33 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language James Kuyper <jameskuyper@verizon.net> - 2015-04-17 16:59 -0400
    Re: Information on compiler/parser techniques for a new C-derived programming language Robert Wessel <robertwessel2@yahoo.com> - 2015-04-16 23:02 -0500
      Re: Information on compiler/parser techniques for a new C-derived programming language David Brown <david.brown@hesbynett.no> - 2015-04-17 10:55 +0200
        Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 11:48 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language David Brown <david.brown@hesbynett.no> - 2015-04-18 21:55 +0200
            Re: Information on compiler/parser techniques for a new C-derived programming language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-19 11:39 +0000
              Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-19 12:48 +0100
                Re: Information on compiler/parser techniques for a new C-derived programming language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-19 14:07 +0000
              Re: Information on compiler/parser techniques for a new C-derived programming language David Brown <david.brown@hesbynett.no> - 2015-04-19 23:26 +0200
          Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-19 12:28 +0100
      Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 14:41 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language Robert Wessel <robertwessel2@yahoo.com> - 2015-04-17 18:41 -0500
          Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 11:30 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 03:37 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 03:44 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 03:59 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 02:38 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 02:54 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 12:43 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 13:56 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-19 00:43 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-19 01:18 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-22 13:39 -0700
              Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-22 22:28 +0100
                Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-28 13:28 -0700
                  Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-28 21:55 +0100
              Re: Information on compiler/parser techniques for a new C-derived programming language Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-22 23:21 +0100
              Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-24 00:27 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 01:09 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 11:29 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 03:16 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 03:38 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-17 06:32 -0500
          Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 05:11 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-17 07:33 -0500
              Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 06:02 -0700
                Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-17 11:56 -0500
                  Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 16:15 -0700
                  Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 10:40 -0700
                    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 10:47 -0700
                    Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-26 13:49 -0500
    Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 11:17 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language Melzzzzz <mel@zzzzz.com> - 2015-04-18 05:34 +0200
    Re: Information on compiler/parser techniques for a new C-derived programming language luser droog <luser.droog@gmail.com> - 2015-04-17 23:18 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-20 09:39 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language luser droog <luser.droog@gmail.com> - 2015-04-20 23:11 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language luser droog <luser.droog@gmail.com> - 2015-04-25 21:41 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 04:59 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 05:16 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 05:43 -0700

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

#61153

W dniu niedziela, 26 kwietnia 2015 10:09:24 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 19 kwietnia 2015 09:43:42 UTC+2 użytkownik fir napisał:
> > (besides var and any are most probably bad names, the better imo should be probably something like packed type, or described 
> > type) implementation is easy thing, but what with usability cases?
> 
> i mean something like "signed" types (form signing/autograph, writing name with hand)
> as those are just normal types or records that are signed
> 'dynamic' refers probably to some usability cases builded on top of that
> 
> such automatical signing of arguments in calls
> might be considered alternative to the format string way in c, both probably have some advantages (old way is quite clever, seem to be like a bit primitive but in reality imo those old c ideas are ingenious) -- though those signet types are for sure imo worth considering/rethinking, maybe i say yet more something on it

ps (post scriptum)

what meand dynamic here? signed tipization managed in runtime

imo teh trouble here is 

1) it probably will always be slower than old
static approach

2) i dont quite see some very serious usability cases (probably they are some, but it would be good to know it

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

#60216

W dniu czwartek, 16 kwietnia 2015 22:26:41 UTC+2 użytkownik Emiliano Gomes Padilha napisał:
> - the formats and linking process of C/C++ object files/symbol tables (are they the same on different platforms?? Say, is the object/symbol table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the same apart from the differing machine codes?)
> 
> Phew, it's a lot,
> anyway, thanx on ANY info or comments...
> Emiliano.

[as to link]

as to this there is for example a well known (?) book called 'linkers and loaders' (it is at least long so probably enough info here, though im not sure a only scanned this book),

as to executable formats there are many tutorials in the net, 

[as to asm ]

as to machine code there  are about 4000 pages long intel manuals, and also some neraly insanely complex opcode tables, also some other tutorials

[as to compilers]

not sure here as i was not interested and not 
scaned thryu avaliable books tutorials much 
but i belive there is a lot of info too (i only know for example that open source compilers are awaliable, soem even annotated etc)

the overal problem here IMHO is that when wrote such projects the based components (executable format specyfication, processors,
language complexity) is todeay nearly deadly
complex so this is deadly amount of reading
into all the details

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

#60217

W dniu piątek, 17 kwietnia 2015 12:17:03 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 16 kwietnia 2015 22:26:41 UTC+2 użytkownik Emiliano Gomes Padilha napisał:
> > - the formats and linking process of C/C++ object files/symbol tables (are they the same on different platforms?? Say, is the object/symbol table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the same apart from the differing machine codes?)
> > 
> > Phew, it's a lot,
> > anyway, thanx on ANY info or comments...
> > Emiliano.
> 
> [as to link]
> 
> as to this there is for example a well known (?) book called 'linkers and loaders' (it is at least long so probably enough info here, though im not sure a only scanned this book),
> 
> as to executable formats there are many tutorials in the net, 
> 
> [as to asm ]
> 
> as to machine code there  are about 4000 pages long intel manuals, and also some neraly insanely complex opcode tables, also some other tutorials
> 
> [as to compilers]
> 
> not sure here as i was not interested and not 
> scaned thryu avaliable books tutorials much 
> but i belive there is a lot of info too (i only know for example that open source compilers are awaliable, soem even annotated etc)
> 
> the overal problem here IMHO is that when wrote such projects the based components (executable format specyfication, processors,
> language complexity) is todeay nearly deadly
> complex so this is deadly amount of reading
> into all the details

ps if someone would like to add some litereture references yet with commentary
(of usability etc) it could be good to look at it (most usable would be online materials), amazon stuff is harder to obtain

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

#60221

On 4/17/15 5:38 AM, fir wrote:

> if someone would like to add some litereture references yet with
> commentary (of usability etc) it could be good to look at it (most
> usable would be online materials), amazon stuff is harder to obtain

At http://www.iedu.com/tmp/plc3.plc you can see the source code for a 
compiler that compiles extended BNF written in its own target language. 
The version shown produced code for the MACRO-80 assembler.

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#60223

W dniu piątek, 17 kwietnia 2015 13:32:51 UTC+2 użytkownik Morris Dovey napisał:
> On 4/17/15 5:38 AM, fir wrote:
> 
> > if someone would like to add some litereture references yet with
> > commentary (of usability etc) it could be good to look at it (most
> > usable would be online materials), amazon stuff is harder to obtain
> 
> At http://www.iedu.com/tmp/plc3.plc you can see the source code for a 
> compiler that compiles extended BNF written in its own target language. 
> The version shown produced code for the MACRO-80 assembler.
> 
I would say it is good looking (looks good)
but what it is exactly doing? what it is able to compile and where is the main compiler? (it looks like interpreter program stub for some compiler not working compiler itself)










> -- 
> Morris Dovey
> http://www.iedu.com/Solar

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

#60225

On 4/17/15 7:11 AM, fir wrote:
> W dniu piątek, 17 kwietnia 2015 13:32:51 UTC+2 użytkownik Morris
> Dovey napisał:
>> On 4/17/15 5:38 AM, fir wrote:
>>
>>> if someone would like to add some litereture references yet with
>>> commentary (of usability etc) it could be good to look at it
>>> (most usable would be online materials), amazon stuff is harder
>>> to obtain
>>
>> At http://www.iedu.com/tmp/plc3.plc you can see the source code for
>> a compiler that compiles extended BNF written in its own target
>> language. The version shown produced code for the MACRO-80
>> assembler.
>>
> I would say it is good looking (looks good) but what it is exactly
> doing? what it is able to compile and where is the main compiler? (it
> looks like interpreter program stub for some compiler not working
> compiler itself)

It /is/ the main compiler program. If the source file you saw is fed to 
the compiled and linked version, the output will be assembler source 
that when assembled and linked, will be the executable program.

The library of subroutines contains about a dozen modules, each of which 
is about 50 or 60 assembly instructions.

A write-up was published in the March 1984 issue of Doctor Dobbs Journal 
titled "Introduction to PL/C".

And no, it's not a stub. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#60226

W dniu piątek, 17 kwietnia 2015 14:34:03 UTC+2 użytkownik Morris Dovey napisał:
> On 4/17/15 7:11 AM, fir wrote:
> > W dniu piątek, 17 kwietnia 2015 13:32:51 UTC+2 użytkownik Morris
> > Dovey napisał:
> >> On 4/17/15 5:38 AM, fir wrote:
> >>
> >>> if someone would like to add some litereture references yet with
> >>> commentary (of usability etc) it could be good to look at it
> >>> (most usable would be online materials), amazon stuff is harder
> >>> to obtain
> >>
> >> At http://www.iedu.com/tmp/plc3.plc you can see the source code for
> >> a compiler that compiles extended BNF written in its own target
> >> language. The version shown produced code for the MACRO-80
> >> assembler.
> >>
> > I would say it is good looking (looks good) but what it is exactly
> > doing? what it is able to compile and where is the main compiler? (it
> > looks like interpreter program stub for some compiler not working
> > compiler itself)
> 
> It /is/ the main compiler program. If the source file you saw is fed to 
> the compiled and linked version, the output will be assembler source 
> that when assembled and linked, will be the executable program.
> 
> The library of subroutines contains about a dozen modules, each of which 
> is about 50 or 60 assembly instructions.
> 
> A write-up was published in the March 1984 issue of Doctor Dobbs Journal 
> titled "Introduction to PL/C".
> 
> And no, it's not a stub. :-)
> 
but something must compile this.. this looks like only description of the translation flow, not the algorithms to translate the source file according to those rules..

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

#60248

On 4/17/15 8:02 AM, fir wrote:

> but something must compile this.. this looks like only description of
> the translation flow, not the algorithms to translate the source file
> according to those rules..

Yes, of course. There are three steps...

[1] I have an executable named PLC3.COM that reads PLC3.PLC and outputs 
an assembly language file named PLC3.MAC

[2] PLC3.MAC is read by the assembler to produce PLC3.OBJ and PLC3.PRN 
(a listing file)

[3] PLC3.OBJ and PLCLIB.OBJ are read by the linker to produce 
(amazingly!) an executable program named PLC3.COM - an exact duplicate 
of the program used in the first step.

To make a different compiler, you need only perform this same sequence 
with the source file for your new compiler, it's not very complicated.

I uploaded a copy of PLC3.PRN so you can see PLC3.MAC and what the 
assembler makes of it. See http://www.iedu.com/tmp/PLC3.PRN

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#60277

W dniu piątek, 17 kwietnia 2015 18:56:28 UTC+2 użytkownik Morris Dovey napisał:
> On 4/17/15 8:02 AM, fir wrote:
> 
> > but something must compile this.. this looks like only description of
> > the translation flow, not the algorithms to translate the source file
> > according to those rules..
> 
> Yes, of course. There are three steps...
> 
> [1] I have an executable named PLC3.COM that reads PLC3.PLC and outputs 
> an assembly language file named PLC3.MAC
> 
> [2] PLC3.MAC is read by the assembler to produce PLC3.OBJ and PLC3.PRN 
> (a listing file)
> 
> [3] PLC3.OBJ and PLCLIB.OBJ are read by the linker to produce 
> (amazingly!) an executable program named PLC3.COM - an exact duplicate 
> of the program used in the first step.
> 
> To make a different compiler, you need only perform this same sequence 
> with the source file for your new compiler, it's not very complicated.
> 
> I uploaded a copy of PLC3.PRN so you can see PLC3.MAC and what the 
> assembler makes of it. See http://www.iedu.com/tmp/PLC3.PRN
> 

alrright tnx for this info, i will say saomething on this a bit later

> -- 
> Morris Dovey
> http://www.iedu.com/Solar

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

#61150

W dniu piątek, 17 kwietnia 2015 18:56:28 UTC+2 użytkownik Morris Dovey napisał:
> On 4/17/15 8:02 AM, fir wrote:
> 
> > but something must compile this.. this looks like only description of
> > the translation flow, not the algorithms to translate the source file
> > according to those rules..
> 
> Yes, of course. There are three steps...
> 
> [1] I have an executable named PLC3.COM that reads PLC3.PLC and outputs 
> an assembly language file named PLC3.MAC
> 
> [2] PLC3.MAC is read by the assembler to produce PLC3.OBJ and PLC3.PRN 
> (a listing file)
> 
> [3] PLC3.OBJ and PLCLIB.OBJ are read by the linker to produce 
> (amazingly!) an executable program named PLC3.COM - an exact duplicate 
> of the program used in the first step.
> 
> To make a different compiler, you need only perform this same sequence 
> with the source file for your new compiler, it's not very complicated.
> 
> I uploaded a copy of PLC3.PRN so you can see PLC3.MAC and what the 
> assembler makes of it. See http://www.iedu.com/tmp/PLC3.PRN
> 
It is hardly unbelivable, i am not understanding something or yopu are skipping something

this plc code has 9probably) no algorithm, routines, it seem only like rules to interpret

to make a compiler you must to code algorithm/procedure 

com is taking plc outputing mac thats okay stap it may be doing this

asembletr and linker is makimg  com from mac it is also okay, 

but it is hard to belive that this plc describes whole mechanic of "reading this plc 
and transforming it to mac" that describes this
whole progrem of reading that and transforming it to mac (there musyt be come component that is hidden and is not in plc source )

if so (and this is a whole compiler of itself) how it is doing that? i damn doesnt understand this

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

#61151

ps

for example is such compiler of such source of itself

"compile this compiler"

possible? im bit confuzed maybe but i think NO
compiler needs a code to read its source then output what it needs etc 9and here if it works the source is somewhere behind this line)

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

#61154

On 4/26/15 12:40 PM, fir wrote:
> W dniu piątek, 17 kwietnia 2015 18:56:28 UTC+2 użytkownik Morris
> Dovey napisał:
>> On 4/17/15 8:02 AM, fir wrote:
>>
>>> but something must compile this.. this looks like only
>>> description of the translation flow, not the algorithms to
>>> translate the source file according to those rules..
>>
>> Yes, of course. There are three steps...
>>
>> [1] I have an executable named PLC3.COM that reads PLC3.PLC and
>> outputs an assembly language file named PLC3.MAC
>>
>> [2] PLC3.MAC is read by the assembler to produce PLC3.OBJ and
>> PLC3.PRN (a listing file)
>>
>> [3] PLC3.OBJ and PLCLIB.OBJ are read by the linker to produce
>> (amazingly!) an executable program named PLC3.COM - an exact
>> duplicate of the program used in the first step.
>>
>> To make a different compiler, you need only perform this same
>> sequence with the source file for your new compiler, it's not very
>> complicated.
>>
>> I uploaded a copy of PLC3.PRN so you can see PLC3.MAC and what the
>>  assembler makes of it. See http://www.iedu.com/tmp/PLC3.PRN
>>
> It is hardly unbelivable, i am not understanding something or yopu
> are skipping something

The only part you haven't seen are the functions called by the compiler.
There are between one and two dozen of them, and none are very large.
They are, however somewhat visible in the form of CALLs in both compiler
output specifications and in the generated assembly code.

> this plc code has 9probably) no algorithm, routines, it seem only
> like rules to interpret

Correct. This is not a general purpose programming language but, rather,
a language intended to deal only with translation of an input stream
with a specified syntax to an output stream according to the rules the
programmer specifies.

> to make a compiler you must to code algorithm/procedure

Yes/no/maybe. :-) If you choose, you may find it easier to think of this
language in a way that defines each statement as a procedure, with each
element of each statement producing a call to a sub-procedure.

> com is taking plc outputing mac thats okay stap it may be doing this

Thank you, that's exactly how it works. It did take some time and effort
on my part to make that happen. :-)

> asembletr and linker is makimg  com from mac it is also okay,

Yes - but I can't take credit for that part.

> but it is hard to belive that this plc describes whole mechanic of
> "reading this plc and transforming it to mac" that describes this
> whole progrem of reading that and transforming it to mac (there
> musyt be come component that is hidden and is not in plc source )

Believe it. You've seen everything except the library (written in
assembly code).

> if so (and this is a whole compiler of itself) how it is doing that?
> i damn doesnt understand this

Well, it's not magic. I started with Bakus-Naur notation for syntax and
observed that it /could/ be a programming language for producing
parsers, and from there I hypothesized that with the addition of an
output capability, it could also produce full-bore interpreters and
translators.

> ps
>
> for example is such compiler of such source of itself
>
> "compile this compiler"

Yes, plc3.plc is the source for the compiler hand-written in its own
source language. Version 3 was the first to have all the language
features I felt were needed to produce future variants.

> possible? im bit confuzed maybe but i think NO compiler needs a code
> to read its source then output what it needs etc 9and here if it
> works the source is somewhere behind this line)

It's not altogether easy to grasp, but neither is it impossible. If
you're interested, I just uploaded a stripped-down (to show only a
simplified syntax) version of the source. With the housekeeping and
output code out of the way, you'll see a much stronger resemblance to
the Bakus-Naur format I started with. See
http://www.iedu.com/tmp/PLC-Syntax.PLC

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#60254

Em quinta-feira, 16 de abril de 2015 18:24:50 UTC-3, Stefan Ram  escreveu:
> 
>   Finally, someone I can ask! What does »object-oriented« mean?

Are you serious?
Well, regardless, I can only give you a small description here, look for object-oriented in Wikipedia or tutorials on computer programming concepts.

Object-oriented means support in a programming language for the concept of "object" which is an improvement and an elaboration on data types, particularly the old "record": a heterogeneous collection of data of (possibly) different types, say, in C a struct:

struct somename { int field_a; char field_b[]; float field_c; }

This only specifies data, not the operations that manipulate it, so they will necessarily be intermixed diffusely with other code and operations, which, except for trivial programs, is generally bad. The concept of objects therefore allow you to specify not only the data, but also the operations that work on it, giving that "record", thus, a sort of INTERFACE of operations:

object some_one { data_specification_like_above; plus functions that operate
                 on that data, typically called METHODS; }
  
So the objects are data like those "records"/structs, but also containing METHODS (functions that operate on INSTANCES of that object), and also would have CLASSES and/or PROTOTYPES (ie. you define classes of instances of that object, or then a constructor, a function/procedure to create instances of that structure and attach to it a PROTOTYPE object for default behaviour).

Moreover, objects could/should provide ENCAPSULATION, INHERITANCE (single, or the much-maligned MULTIPLE INHERITANCE), construction and cleanup (automatic destruction), POLIMORPHISM and DYNAMIC DISPATCH (or even better, MULTIPLE DISPATCH), ABSTRACT CLASSES, and possibly the ability for an object to decide what to do with every MESSAGE it receives (ie. at every attempt to access one of its methods, as in the SmallTalk/Object-C model of OO, not the  Simula/C++/Java static model, where each MESSAGE to an object is just a method call with the object instance as a hidden parameter...)

It's a lot of concepts, each one of these you'd have to look-up at Wikipedia or tutorials, or learn the languages. I recommend C++ for the static/class-based OO, Javascript for prototype-based OO, and Object-C for the Smalltalk model (which is the langauge used to program iPhone/iPad/OSX applications). They are all similar to C.

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

#60288

On Thu, 16 Apr 2015 13:26:25 -0700 (PDT)
Emiliano Gomes Padilha <egpadilha@gmail.com> wrote:

> 
> My language is going to be object-oriented, threaded, functional,
> statically & dynamically imperative as well 

Ahahhhahahahhahahhah

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

#60294

On Thursday, April 16, 2015 at 3:26:41 PM UTC-5, Emiliano Gomes Padilha wrote:
> Hi,
> I'm designing a new programming language on the vein of C/C++ (I know, I know, "why are you doing that?, It's worthless, don't do that, Yet another goof, etc..").
> Nevertheless, please let me pursue my "vain" effort, and anyway because I don't have experience in designing & programming parsers/interpreters/compilers (other than the long-ago class I had on Compilers in my Computer Science graduation -- I have a Msc and Phd but it's in Artificial Intelligence & Natural Language/Cognitive Science, so... very different fields of study!),
> 
> therefore I'm looking for any pointers anyone around might have on where do I start. I know I'll program a parser/interpreter and later possibly compilers (hopefully for different platforms) in C (NOT C++, I know both but I prefer to go with the basics in this "low-level" project).
> 
> My language is going to be object-oriented, threaded, functional, statically & dynamically imperative as well (yes, I KNOW what all these mean, I'm versed in programming language concepts/design, I just don't know much on the INTERNALS), so if anyone can point me to information on:
> 
> - modern parsing/optimization techniques (info and/or codes)
> - look-up tables, hashing info and techniques to get the best/efficient hashing on tables of identifiers of various types (functions, basic types, objects, global/local, etc.)
> - threading (I know the basic Unix's fork() call for creating new processes) but that doesn't count, does it?)
> 
> - the formats and linking process of C/C++ object files/symbol tables (are they the same on different platforms?? Say, is the object/symbol table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the same apart from the differing machine codes?)
> 
> Phew, it's a lot,
> anyway, thanx on ANY info or comments...
> Emiliano.

That's a big pile of interesting.
A very good read if you haven't seen it already
is Jack Crenshaw's "So You Want To Write a Compiler".
It covers implementing a recursive-descent parser,
which is a perfectly acceptable choice for a C-like
language, and frees you from also learning a parser-
generator.

Or for the parser-generator route, 2 excellent books
are Kernighan & Pike's "The Unix Programming Environment".
The second half of the book is an extended tutorial on 
yacc (it briefly mentions lex, but mostly uses a custom
scanner). The other book is Axel Tobias Schreiner's 
"Curses, Lex and Yacc" which is a much longer tutorial
for a much larger window-shell/calculator/editor program
for a terminal-interface environment.

My own course through these waters has been to eschew 
generators and external tools and to concentrate on 
implementing powerful algorithms directly in the C language.
My two big projects have been language interpreters,
so it avoids all the machine issues of a compiler,
but still has to handle all of the language-implementation
issues.

But with more lisp perspective, I'm beginning to see less 
distinction between the two. I'd still recommend implementing
an interpreter first. Directly testing expressions gives
very fast turn-around for experimentation and discovery.
Producing a compiled output can be added as an option, if
(when) needed.

-- 
just some opinions and reading suggestions.

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

#60535

Em sábado, 18 de abril de 2015 03:18:33 UTC-3, luser droog  escreveu:
> 
> That's a big pile of interesting.
> A very good read if you haven't seen it already
> is Jack Crenshaw's "So You Want To Write a Compiler".
> It covers implementing a recursive-descent parser,
> which is a perfectly acceptable choice for a C-like
> language, and frees you from also learning a parser-
> generator.
> 
> Or for the parser-generator route, 2 excellent books
> are Kernighan & Pike's "The Unix Programming Environment".
> The second half of the book is an extended tutorial on 
> yacc (it briefly mentions lex, but mostly uses a custom
> scanner). The other book is Axel Tobias Schreiner's 
> "Curses, Lex and Yacc" which is a much longer tutorial
> for a much larger window-shell/calculator/editor program
> for a terminal-interface environment.
> 
> My own course through these waters has been to eschew 
> generators and external tools and to concentrate on 
> implementing powerful algorithms directly in the C language.
> My two big projects have been language interpreters,
> so it avoids all the machine issues of a compiler,
> but still has to handle all of the language-implementation
> issues.
> 
> But with more lisp perspective, I'm beginning to see less 
> distinction between the two. I'd still recommend implementing
> an interpreter first. Directly testing expressions gives
> very fast turn-around for experimentation and discovery.
> Producing a compiled output can be added as an option, if
> (when) needed.
> 
> -- 
> just some opinions and reading suggestions.


Thanks for the pointer. That's the sort of thing I need to
look at. I've been reading up to now things like "Structure
and interpretation of Computer Programs" by Abelson, Sussman
etal., that is, only upper-level things about programming
concepts. The low-level under-the-hood machinery is what I
need to get into (provided I have infinite amounts of time,
of course :)

Emiliano.

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

#60606

On Monday, April 20, 2015 at 11:39:17 AM UTC-5, Emiliano Gomes Padilha wrote:
> Em sábado, 18 de abril de 2015 03:18:33 UTC-3, luser droog  escreveu:
> > 
> > A very good read if you haven't seen it already
> > is Jack Crenshaw's "So You Want To Write a Compiler".
> > Or for the parser-generator route, 2 excellent books
> > are Kernighan & Pike's "The Unix Programming Environment".
> > The second half of the book is an extended tutorial on 
> > yacc (it briefly mentions lex, but mostly uses a custom
> > scanner). The other book is Axel Tobias Schreiner's 
> > "Curses, Lex and Yacc" which is a much longer tutorial
> > for a much larger window-shell/calculator/editor program
> > for a terminal-interface environment.
> > 
> > My own course through these waters has been to eschew 
> > generators and external tools and to concentrate on 
> > implementing powerful algorithms directly in the C language.
> > My two big projects have been language interpreters,
> > so it avoids all the machine issues of a compiler,
> > but still has to handle all of the language-implementation
> > issues.
> > 
> > But with more lisp perspective, I'm beginning to see less 
> > distinction between the two. I'd still recommend implementing
> > an interpreter first. Directly testing expressions gives
> > very fast turn-around for experimentation and discovery.
> > Producing a compiled output can be added as an option, if
> > (when) needed.
> > 
> > -- 
> > just some opinions and reading suggestions.
> 
> 
> Thanks for the pointer. That's the sort of thing I need to
> look at. I've been reading up to now things like "Structure
> and interpretation of Computer Programs" by Abelson, Sussman
> etal., that is, only upper-level things about programming
> concepts. The low-level under-the-hood machinery is what I
> need to get into (provided I have infinite amounts of time,
> of course :)
> 
> Emiliano.

I've tried many times to read that book. But I always seem to
put it back down again. But I recently read the 1979 book
Anatomy of Lisp and found many illuminating points. The second
half has extensive discussion of compiling the various construct.
The target is a fictitious symbolic "assembly" code which is then
simulated, but it gives a very thorough presentation (IMHO, which
of course is not sufficiently informed to evaluate the merits of
SICP).

For more C implementation ideas, there are two posts in the 
discussion group for my postscript interpreter which collects
all the usenet threads where I've asked questions or posted
prototype code for various ideas. 
https://groups.google.com/forum/#!forum/xpost-discuss
One of the posts is more specific to implementing Postscript
language constructs, but the other one is less focused as
to the target language.

And several other little interpreters I've written are browsable
on my github: https://github.com/luser-dr00g

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

#61111

On Tuesday, April 21, 2015 at 1:11:51 AM UTC-5, luser droog wrote:
> On Monday, April 20, 2015 at 11:39:17 AM UTC-5, Emiliano Gomes Padilha wrote:
> > Em sábado, 18 de abril de 2015 03:18:33 UTC-3, luser droog  escreveu:
> > > 
> > > A very good read if you haven't seen it already
> > > is Jack Crenshaw's "So You Want To Write a Compiler".
> > > Or for the parser-generator route, 2 excellent books
> > > are Kernighan & Pike's "The Unix Programming Environment".
> > > The second half of the book is an extended tutorial on 
> > > yacc (it briefly mentions lex, but mostly uses a custom
> > > scanner). The other book is Axel Tobias Schreiner's 
> > > "Curses, Lex and Yacc" which is a much longer tutorial
> > > for a much larger window-shell/calculator/editor program
> > > for a terminal-interface environment.
> > > 
> > > My own course through these waters has been to eschew 
> > > generators and external tools and to concentrate on 
> > > implementing powerful algorithms directly in the C language.
> > > My two big projects have been language interpreters,
> > > so it avoids all the machine issues of a compiler,
> > > but still has to handle all of the language-implementation
> > > issues.
> > > 
> > > But with more lisp perspective, I'm beginning to see less 
> > > distinction between the two. I'd still recommend implementing
> > > an interpreter first. Directly testing expressions gives
> > > very fast turn-around for experimentation and discovery.
> > > Producing a compiled output can be added as an option, if
> > > (when) needed.
> > > 
> > > -- 
> > > just some opinions and reading suggestions.
> > 
> > 
> > Thanks for the pointer. That's the sort of thing I need to
> > look at. I've been reading up to now things like "Structure
> > and interpretation of Computer Programs" by Abelson, Sussman
> > etal., that is, only upper-level things about programming
> > concepts. The low-level under-the-hood machinery is what I
> > need to get into (provided I have infinite amounts of time,
> > of course :)
> > 
> > Emiliano.
> 
> I've tried many times to read that book. But I always seem to
> put it back down again. But I recently read the 1979 book
> Anatomy of Lisp and found many illuminating points. The second
> half has extensive discussion of compiling the various construct.
> The target is a fictitious symbolic "assembly" code which is then
> simulated, but it gives a very thorough presentation (IMHO, which
> of course is not sufficiently informed to evaluate the merits of
> SICP).
> 
> For more C implementation ideas, there are two posts in the 
> discussion group for my postscript interpreter which collects
> all the usenet threads where I've asked questions or posted
> prototype code for various ideas. 
> https://groups.google.com/forum/#!forum/xpost-discuss
> One of the posts is more specific to implementing Postscript
> language constructs, but the other one is less focused as
> to the target language.
> 
> And several other little interpreters I've written are browsable
> on my github: https://github.com/luser-dr00g

Stumbled across in interesting post in comp.sources.misc 
from 1990.
https://groups.google.com/forum/#!topic/comp.sources.misc/h2qDIv2_vHA
"Skeleton Parser and Lexer for ANSI C"

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

#60308

W dniu czwartek, 16 kwietnia 2015 23:24:50 UTC+2 użytkownik Stefan Ram napisał:
> Emiliano Gomes Padilha <egpadilha@gmail.com> writes:
> >My language is going to be object-oriented, threaded,
> >functional, statically & dynamically imperative as well
> >(yes, I KNOW what all these mean, I'm versed in programming
> >language concepts/design
> 
>   Finally, someone I can ask! What does »object-oriented« mean?

object-oriented is imo in 99% of its uses shit-paradigm, 

it is like modular but instead of static immediate references you instantiate 'module instances ' (on the heap, stack, statically or what else)
and glue it together with physical pointers
making a lot of mess

i made some work on modular paradigm where
you treat modules as natural c types and could
also instantiate it like ints

void foo()
{
  int x,y,z;
  stack modulex a,b,c;
  heap  modulex d,e,f;
  static modulex g,h,i;

}

this has some elements of resemblance to some properties of OO (though i was not inspired by this sh*t, more of the hate of it if so) but it is like integrated types

there is some elegance here though maybe i should recapitulete the usability of this 
as i was not working long time on this

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

#60310

W dniu sobota, 18 kwietnia 2015 14:00:01 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 16 kwietnia 2015 23:24:50 UTC+2 użytkownik Stefan Ram napisał:
> > Emiliano Gomes Padilha <egpadilha@gmail.com> writes:
> > >My language is going to be object-oriented, threaded,
> > >functional, statically & dynamically imperative as well
> > >(yes, I KNOW what all these mean, I'm versed in programming
> > >language concepts/design
> > 
> >   Finally, someone I can ask! What does »object-oriented« mean?
> 
> object-oriented is imo in 99% of its uses shit-paradigm, 
> 
> it is like modular but instead of static immediate references you instantiate 'module instances ' (on the heap, stack, statically or what else)
> and glue it together with physical pointers
> making a lot of mess
> 
> i made some work on modular paradigm where
> you treat modules as natural c types and could
> also instantiate it like ints
> 
> void foo()
> {
>   int x,y,z;
>   stack modulex a,b,c;
>   heap  modulex d,e,f;
>   static modulex g,h,i;
> 
> }

ps maybe i give a short tutorial to this

you may call modulex function 

 Module_x g,h

 g fu(2,3); // call fu() from module_x

 you could pass it to function

 func(g,h);
 
 return form function etc

 make arrays of modules

 Module_x tab[100];

 use operators on modules 

 you could probably also have an option to call modules

 g();

 in general anything as simple types and 
otherwise you could treat simple types like int and float as modules (where you could provide source for it etc)
 
 you could glue together module instances by
pointers in c++ style if you want like

 Module_x g,h

 g.friend = h;
 h.friend = g;
 
 g();

 could eventally alloc it in realtime (with some kind of new keyword, but i think if this shoul not be spared to very rare cases, at it is more contraollable just to use arrays of modules and not explosion populate it in the void ram)

 I need yet a bit work on this module generalisation though much of this was
as it seen here discovered (it was not easy thing take some years)
 In general i wonder if i should treat this 'feature' as a part of my C2 language or maybe
not (my D2 language?  m not sure still)
 
 
  
 






> 
> this has some elements of resemblance to some properties of OO (though i was not inspired by this sh*t, more of the hate of it if so) but it is like integrated types
> 
> there is some elegance here though maybe i should recapitulete the usability of this 
> as i was not working long time on this

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

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

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

csiph-web