Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #57152 > unrolled thread
| Started by | Philip Herron <herron.philip@googlemail.com> |
|---|---|
| First post | 2013-10-20 10:56 -0700 |
| Last post | 2013-10-25 14:49 -0700 |
| Articles | 20 on this page of 123 — 27 participants |
Back to article view | Back to comp.lang.python
Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-20 10:56 -0700
Re: Python Front-end to GCC victorgarcianet@gmail.com - 2013-10-20 15:10 -0700
Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-22 23:48 -0700
Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-23 00:25 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 09:42 +0100
Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-23 13:51 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-20 20:35 -0700
Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-21 07:46 +0000
Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-21 10:55 +0100
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-21 23:41 +0000
Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 10:14 +0100
Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:32 -0700
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 12:00 +0000
Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-22 23:20 +1100
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:27 +0000
Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 08:43 +1100
Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 14:04 +0000
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 15:22 +0000
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:39 +0000
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 16:40 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 17:50 +0100
Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 09:52 -0700
Re: Python Front-end to GCC Frank Miles <fpm@u.washington.edu> - 2013-10-22 16:53 +0000
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:23 +0000
Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 10:35 -0700
Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:37 +0000
Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 18:37 +0100
Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 18:42 +0100
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:49 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 04:40 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 04:55 -0700
Re: Python Front-end to GCC Dan Sommers <dan@tombstonezero.net> - 2013-10-25 12:55 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 15:18 +0100
Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-25 10:35 -0400
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:26 -0700
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-25 19:06 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 19:40 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:45 -0700
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 11:59 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:09 -0700
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 12:15 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:02 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:18 -0700
Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-26 14:31 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 15:10 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-27 15:14 -0700
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-27 19:15 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-28 08:44 +0000
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-28 02:31 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:36 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:49 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:14 +0100
Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:11 +1100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 13:29 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:36 +0100
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 02:42 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:44 +0100
Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:48 +1100
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:56 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:02 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:11 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:37 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:56 +0100
Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-26 13:36 +1100
Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:15 +0000
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:58 +0000
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 20:26 +0000
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:36 +0000
Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 15:15 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:14 -0700
Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-21 16:29 -0400
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-21 20:40 -0700
Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 04:08 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:26 -0700
Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 14:03 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 16:04 -0700
Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-21 23:45 -0400
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 21:24 -0700
Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-22 05:25 +0000
Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 04:39 +0000
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 08:04 -0700
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:09 +0000
Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 13:20 -0400
Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 11:46 -0400
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 16:52 +0100
Re: Python Front-end to GCC Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-10-22 09:03 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 10:50 -0700
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:11 -0700
Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 18:18 +0000
Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 15:20 -0400
Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 19:27 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:38 +0100
Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 20:00 +0000
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:32 +0100
Re: Python Front-end to GCC Skip Montanaro <skip@pobox.com> - 2013-10-22 13:08 -0500
Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:16 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:16 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:22 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:28 -0700
Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 18:11 -0400
Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 17:28 +1100
Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 22:47 +0000
Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:23 -0400
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:40 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 19:58 +0100
Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:40 -0400
Re: Python Front-end to GCC alex23 <wuwei23@gmail.com> - 2013-10-23 11:36 +1000
Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 21:04 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:06 +0100
Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:47 +0100
Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 13:56 -0400
Re: Python Front-end to GCC Michael Torrie <torriem@gmail.com> - 2013-10-22 22:05 -0600
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:13 +0100
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:25 -0700
Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:33 -0700
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:38 +0100
Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:35 +0100
Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 08:55 +0000
Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:08 -0700
Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 10:10 +0000
Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 15:51 +0000
Re: Python Front-end to GCC Stefan Behnel <stefan_ml@behnel.de> - 2013-10-24 08:47 +0200
Re: Python Front-end to GCC xDog Walker <thudfoo@gmail.com> - 2013-10-25 14:49 -0700
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-10-22 08:04 -0700 |
| Message-ID | <mailman.1356.1382454270.18130.python-list@python.org> |
| In reply to | #57230 |
I love it. Watch this... [context] >>> A language specification in BNF is just syntax. It doesn't say anything >>> about semantics. So how could this be used to produce executable C code >>> for a program? BNF is used to produce parsers. But a parser isn't >>> sufficient. >> >> A C program is just syntax also. How does the compiler generate >> executable machine code? Extrapolate into a Python front-end to C. [Dave Angel responds:] > Did you even read the paragraph you quoted above? The BNF specification > does NOT completely describe a language, it only defines its syntax. [Steven D'Aprano responds:] > Like every other language, C programs are certainly not *just* syntax. > Here is some syntax: > > &foo bar^ := Now, I don't know where y'all were taught Computer Science, but BNF specifies not only syntax (which would be the *tokens* of a language), but also its *grammar*; how syntax relates to linguistic categories like keywords, and tokens relate to each other. Dave is claiming that BNF only defines the syntax of a language, but then Stephen goes on to supply some syntax that a BNF specification of the language would not allow (even though Steven calls it "syntax" which is what BNF in Dave's claim parses). So which of you is confused? I ask that in the inclusive (not exclusive OR) sense.... ;^) <-- face says "both". Mark Janssen Tacoma, Washington.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-10-22 17:09 +0000 |
| Message-ID | <5266b12c$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #57263 |
On Tue, 22 Oct 2013 08:04:21 -0700, Mark Janssen wrote: >>>> A language specification in BNF is just syntax. It doesn't say >>>> anything about semantics. So how could this be used to produce >>>> executable C code for a program? BNF is used to produce parsers. But >>>> a parser isn't sufficient. >>> >>> A C program is just syntax also. How does the compiler generate >>> executable machine code? Extrapolate into a Python front-end to C. > > [Dave Angel responds:] >> Did you even read the paragraph you quoted above? The BNF >> specification does NOT completely describe a language, it only defines >> its syntax. > > [Steven D'Aprano responds:] >> Like every other language, C programs are certainly not *just* syntax. >> Here is some syntax: >> >> &foo bar^ := > > Now, I don't know where y'all were taught Computer Science, Melbourne University Computer Science Department. How about you? > but BNF > specifies not only syntax (which would be the *tokens* of a language), > but also its *grammar*; how syntax relates to linguistic categories > like keywords, and tokens relate to each other. I'm not about to get into a debate about the difference between syntax and grammar as they apply to computer languages, because it doesn't matter. Neither syntax nor grammar tell you what something *means*, the semantics of the code. The parser knows that (say) "x ^% y" is legal and (say) "x y ^%" is not, but it doesn't know what machine code to generate when it sees "x ^% y". That's not the job of the parser. I expect that some compilers -- ancient ones, or lousy ones, or simple ones -- have a single routine that do all the parsing, lexing, code generation, linking, optimizing, etc., rather than separate routines that do the parsing, the code generation, and so on. But even those compilers cannot just take a description of the syntax and intuit what it means. Syntax isn't enough. At some point, the compiler needs to know that "^" means to generate code to dereference pointers (like in Pascal), or perhaps it's bitwise or (like in C), or maybe even exponentiation (like in VisualBasic), or perhaps it's something completely different. > Dave is claiming that BNF only defines the syntax of a language, but > then Stephen goes on to supply some syntax that a BNF specification of > the language would not allow (even though Steven calls it "syntax" which > is what BNF in Dave's claim parses). I think you have misunderstood me. I gave an example of some invented syntax that your hypothetical language might choose to use. Here it is again: &foo bar^ := Since I didn't provide the BNF specification for that syntax, you aren't in a position to say it is illegal. You should assume that it is legal syntax. If you really insist, I'll waste my time and yours and generate a BNF specification that allows that as valid syntax, or you could just accept that it's legal for this imaginary language. Your task is to describe what the code does, and hence what machine code your hypothetical compiler will generate, when it sees that line of code. You should be asking "How the hell can I tell what that does?" Exactly. That's the point. Neither can the compiler, not from syntax alone. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Piet van Oostrum <piet@vanoostrum.org> |
|---|---|
| Date | 2013-10-22 13:20 -0400 |
| Message-ID | <m2d2mx2pe4.fsf@cochabamba.vanoostrum.org> |
| In reply to | #57263 |
Mark Janssen <dreamingforward@gmail.com> writes: > I love it. Watch this... > > [context] >>>> A language specification in BNF is just syntax. It doesn't say anything >>>> about semantics. So how could this be used to produce executable C code >>>> for a program? BNF is used to produce parsers. But a parser isn't >>>> sufficient. >>> >>> A C program is just syntax also. How does the compiler generate >>> executable machine code? Extrapolate into a Python front-end to C. > > [Dave Angel responds:] >> Did you even read the paragraph you quoted above? The BNF specification >> does NOT completely describe a language, it only defines its syntax. > > [Steven D'Aprano responds:] >> Like every other language, C programs are certainly not *just* syntax. >> Here is some syntax: >> >> &foo bar^ := > > Now, I don't know where y'all were taught Computer Science, but BNF > specifies not only syntax (which would be the *tokens* of a language), > but also its *grammar*; how syntax relates to linguistic categories > like keywords, and tokens relate to each other. Syntax is grammar. Tokens are part of the grammar (but often specified separately with a different grammar, usually regular expressions, which is a subset of BNF). So are you just confused or are you trollong? -- Piet van Oostrum <piet@vanoostrum.org> WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2013-10-22 11:46 -0400 |
| Message-ID | <mailman.1357.1382456781.18130.python-list@python.org> |
| In reply to | #57230 |
On 10/22/13 11:04 AM, Mark Janssen wrote:
> I love it. Watch this...
>
> [context]
>>>> A language specification in BNF is just syntax. It doesn't say anything
>>>> about semantics. So how could this be used to produce executable C code
>>>> for a program? BNF is used to produce parsers. But a parser isn't
>>>> sufficient.
>>> A C program is just syntax also. How does the compiler generate
>>> executable machine code? Extrapolate into a Python front-end to C.
> [Dave Angel responds:]
>> Did you even read the paragraph you quoted above? The BNF specification
>> does NOT completely describe a language, it only defines its syntax.
> [Steven D'Aprano responds:]
>> Like every other language, C programs are certainly not *just* syntax.
>> Here is some syntax:
>>
>> &foo bar^ :=
> Now, I don't know where y'all were taught Computer Science, but BNF
> specifies not only syntax (which would be the *tokens* of a language),
> but also its *grammar*; how syntax relates to linguistic categories
> like keywords, and tokens relate to each other.
Mark, you had expressed interest in "an app that will take a language
specification in BNF (complete with keywords and all) and output C code
which is then compiled to an executable". I'm interested in how that
app might work.
Here's a BNF for a (very!) simple language:
<program> ::= <number> <op> <number>
<op> ::= "*!?" | "--+" | "..:"
That means these are three valid programs:
123 *!? 456
2 --+ 2
1001 ..: 4
What will the app output as C code for each of these?
>
> Dave is claiming that BNF only defines the syntax of a language, but
> then Stephen goes on to supply some syntax that a BNF specification of
> the language would not allow (even though Steven calls it "syntax"
> which is what BNF in Dave's claim parses).
>
> So which of you is confused? I ask that in the inclusive (not
> exclusive OR) sense.... ;^) <-- face says "both".
Could you please be less snarky? We're trying to communicate here, and
it is not at all clear yet who is confused and who is not. If you are
interested in discussing technical topics, then discuss them.
--Ned.
>
> Mark Janssen
> Tacoma, Washington.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-10-22 16:52 +0100 |
| Message-ID | <mailman.1359.1382457184.18130.python-list@python.org> |
| In reply to | #57230 |
On 22/10/2013 16:46, Ned Batchelder wrote: > > Could you please be less snarky? We're trying to communicate here, and > it is not at all clear yet who is confused and who is not. If you are > interested in discussing technical topics, then discuss them. > > --Ned. > Well put, particularly when considering that both Dave Angel and Steven D'Aprano, the targets of the snarkiness, have been regular, helpful contributors over many years. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Kaplan <benjamin.kaplan@case.edu> |
|---|---|
| Date | 2013-10-22 09:03 -0700 |
| Message-ID | <mailman.1360.1382458235.18130.python-list@python.org> |
| In reply to | #57230 |
On Tue, Oct 22, 2013 at 8:04 AM, Mark Janssen <dreamingforward@gmail.com> wrote: > I love it. Watch this... > > [context] >>>> A language specification in BNF is just syntax. It doesn't say anything >>>> about semantics. So how could this be used to produce executable C code >>>> for a program? BNF is used to produce parsers. But a parser isn't >>>> sufficient. >>> >>> A C program is just syntax also. How does the compiler generate >>> executable machine code? Extrapolate into a Python front-end to C. > > [Dave Angel responds:] >> Did you even read the paragraph you quoted above? The BNF specification >> does NOT completely describe a language, it only defines its syntax. > > [Steven D'Aprano responds:] >> Like every other language, C programs are certainly not *just* syntax. >> Here is some syntax: >> >> &foo bar^ := > > Now, I don't know where y'all were taught Computer Science, but BNF > specifies not only syntax (which would be the *tokens* of a language), > but also its *grammar*; how syntax relates to linguistic categories > like keywords, and tokens relate to each other. > > Dave is claiming that BNF only defines the syntax of a language, but > then Stephen goes on to supply some syntax that a BNF specification of > the language would not allow (even though Steven calls it "syntax" > which is what BNF in Dave's claim parses). > > So which of you is confused? I ask that in the inclusive (not > exclusive OR) sense.... ;^) <-- face says "both". > I don't know where you were taught English, but syntax is " the way in which linguistic elements (as words) are put together to form constituents (as phrases or clauses) ", not the set of valid words (tokens) in a language. A grammar, such as those grammars written in BNF, describe the rules for the syntax of a language. And, as Steven said, it still doesn't describe the semantics of a language, which is the set of instructions described by the syntax.
[toc] | [prev] | [next] | [standalone]
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-10-22 10:50 -0700 |
| Message-ID | <mailman.1366.1382464240.18130.python-list@python.org> |
| In reply to | #57230 |
>> So which of you is confused? I ask that in the inclusive (not >> exclusive OR) sense.... ;^) <-- face says "both". > > Could you please be less snarky? We're trying to communicate here, and it > is not at all clear yet who is confused and who is not. If you are > interested in discussing technical topics, then discuss them. Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. -- MarkJ Tacoma, Washington
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-10-22 11:11 -0700 |
| Message-ID | <51960ae2-f43c-4bc5-97d6-b8e099878cd2@googlegroups.com> |
| In reply to | #57285 |
Mark Janssen said: > Unattributed > > No its not like those 'compilers' i dont really agree with a compiler > > generating C/C++ and saying its producing native code. I dont really believe > > its truely within the statement. Compilers that do that tend to put in alot > > of type saftey code and debugging internals at a high level to get things > > working in other projects i am not saying python compilers here i havent > > analysed enough to say this. > > Hmm, well what I'd personally find interesting from a computer science > point of view is a app that will take a language specification in BNF > (complete with keywords and all) and output C code which is then > compiled to an executable as normal. This is how a front-end should > be designed. A middle-layer for translating common language elements > like lists, sets, etc, could make it easy. Taking this starting sortie I was going to try to justify what Mark is saying. Somewhat along the following lines. Things like lex and yacc (and equivalents in ecosystems other than C) give a kind of holy-grail in the following sense. When a writer of a lex/yacc spec does his thing, he does not need to think at the C level at all. Given that executable C is produced (and ignoring mishaps/bugs like shift-reduce conflicts etc) its a very ideal situation. The yacc-grammar (and its lex-helper) are completely declarative and yet they result in perfectly good ( O(n)) good C code. Taking this cue from the syntax domain one can treat it as a holy grail for semantics. ie can one specify the semantics of a language completely declaratively and have a lex/yacc *analogous* magic wand and get out a compiler/interpreter etc. Many people have pursued this holy grail but it remains elusive. Some examples: 1. Atribute grammars 2. Utrecht univs UUAG 3. Action semantics etc Note a key word above is "analogous" However when I see this: > Okay. The purpose of BNF (at least as I envision it) is to > produce/specify a *context-free* "grammar". A lexer parses the tokens > specified in the BNF into an Abstract Syntax Tree. If one can produce > such a tree for any given source, the language, in theory, can be > compiled by GCC into an executable. all I will say is "eyes-roll"
[toc] | [prev] | [next] | [standalone]
| From | Neil Cerutti <neilc@norwich.edu> |
|---|---|
| Date | 2013-10-22 18:18 +0000 |
| Message-ID | <bcntraFko8pU1@mid.individual.net> |
| In reply to | #57285 |
On 2013-10-22, Mark Janssen <dreamingforward@gmail.com> wrote:
>>> So which of you is confused? I ask that in the inclusive (not
>>> exclusive OR) sense.... ;^) <-- face says "both".
>>
>> Could you please be less snarky? We're trying to communicate here, and it
>> is not at all clear yet who is confused and who is not. If you are
>> interested in discussing technical topics, then discuss them.
>
> Okay. The purpose of BNF (at least as I envision it) is to
> produce/specify a *context-free* "grammar".
Context-sensitive grammars can be parse, too.
> A lexer parses the tokens specified in the BNF into an Abstract
> Syntax Tree.
A lexer traditionaly reads the text and generates a stream of
tokens to the parser.
> If one can produce such a tree for any given source, the
> language, in theory, can be compiled by GCC into an executable.
What executable would GCC compile from a program that matched
this grammar?
spamgram = spam1, { ', ', more_spam }, '.'
spam1 = 'Spam'
more_spam = spam, { ', ', spam }
spam = 'spam'
--
Neil Cerutti
[toc] | [prev] | [next] | [standalone]
| From | Piet van Oostrum <piet@vanoostrum.org> |
|---|---|
| Date | 2013-10-22 15:20 -0400 |
| Message-ID | <m28uxl2jvh.fsf@cochabamba.vanoostrum.org> |
| In reply to | #57291 |
Neil Cerutti <neilc@norwich.edu> writes: > > Context-sensitive grammars can be parse, too. > That's not English. Do you mean "parsed"? But context-sentitive grammars cannot be specified by BNF. -- Piet van Oostrum <piet@vanoostrum.org> WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]
[toc] | [prev] | [next] | [standalone]
| From | Neil Cerutti <neilc@norwich.edu> |
|---|---|
| Date | 2013-10-22 19:27 +0000 |
| Message-ID | <bco1s7FlujuU1@mid.individual.net> |
| In reply to | #57303 |
On 2013-10-22, Piet van Oostrum <piet@vanoostrum.org> wrote: > Neil Cerutti <neilc@norwich.edu> writes: >> Context-sensitive grammars can be parse, too. > > That's not English. Do you mean "parsed"? Thanks, yes, I meant parsed. > But context-sentitive grammars cannot be specified by BNF. Yes. I thought Mark might have had a misconception that all programming languages have to be defined in BNF. -- Neil Cerutti
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-10-22 20:38 +0100 |
| Message-ID | <mailman.1379.1382470730.18130.python-list@python.org> |
| In reply to | #57304 |
On 22/10/2013 20:27, Neil Cerutti wrote: > On 2013-10-22, Piet van Oostrum <piet@vanoostrum.org> wrote: >> Neil Cerutti <neilc@norwich.edu> writes: >>> Context-sensitive grammars can be parse, too. >> >> That's not English. Do you mean "parsed"? > > Thanks, yes, I meant parsed. > >> But context-sentitive grammars cannot be specified by BNF. > > Yes. I thought Mark might have had a misconception that all > programming languages have to be defined in BNF. > Please be kind enough to disambiguate Mark, as I would not wish to be tarred with the same brush. TIA. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Neil Cerutti <neilc@norwich.edu> |
|---|---|
| Date | 2013-10-22 20:00 +0000 |
| Message-ID | <bco3qrFmcbcU1@mid.individual.net> |
| In reply to | #57306 |
On 2013-10-22, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: > On 22/10/2013 20:27, Neil Cerutti wrote: >> On 2013-10-22, Piet van Oostrum <piet@vanoostrum.org> wrote: >>> Neil Cerutti <neilc@norwich.edu> writes: >>>> Context-sensitive grammars can be parse, too. >>> >>> That's not English. Do you mean "parsed"? >> >> Thanks, yes, I meant parsed. >> >>> But context-sentitive grammars cannot be specified by BNF. >> >> Yes. I thought Mark might have had a misconception that all >> programming languages have to be defined in BNF. > > Please be kind enough to disambiguate Mark, as I would not wish > to be tarred with the same brush. Oops! I didn't notice he'd dropped out of the attributions. I was speculating about Mark Janssen, not you. -- Neil Cerutti
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-10-22 20:32 +0100 |
| Message-ID | <mailman.1378.1382470342.18130.python-list@python.org> |
| In reply to | #57303 |
On 22/10/2013 20:20, Piet van Oostrum wrote: > Neil Cerutti <neilc@norwich.edu> writes: > >> >> Context-sensitive grammars can be parse, too. >> > That's not English. Do you mean "parsed"? > > But context-sentitive grammars cannot be specified by BNF. > That's not English. Do you mean "context-sensitive"? :) -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Skip Montanaro <skip@pobox.com> |
|---|---|
| Date | 2013-10-22 13:08 -0500 |
| Message-ID | <mailman.1367.1382465327.18130.python-list@python.org> |
| In reply to | #57230 |
On Tue, Oct 22, 2013 at 12:50 PM, Mark Janssen <dreamingforward@gmail.com> wrote: > Okay. The purpose of BNF (at least as I envision it) is to > produce/specify a *context-free* "grammar". A lexer parses the tokens > specified in the BNF into an Abstract Syntax Tree. If one can produce > such a tree for any given source, the language, in theory, can be > compiled by GCC into an executable. Well, not quite. The lexer breaks the stream of characters up into tokens, which are fed to the parser, which produces an abstract syntax tree. From the WIkipedia entry: "In computer science, an abstract syntax tree (AST), or just syntax tree, is a tree representation of the abstract syntactic structure of source code written in a programming language. Each node of the tree denotes a construct occurring in the source code." Skip
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2013-10-22 19:16 +0100 |
| Message-ID | <mailman.1368.1382465764.18130.python-list@python.org> |
| In reply to | #57230 |
On 22/10/2013 18:50, Mark Janssen wrote: >>> So which of you is confused? I ask that in the inclusive (not >>> exclusive OR) sense.... ;^) <-- face says "both". >> >> Could you please be less snarky? We're trying to communicate here, and it >> is not at all clear yet who is confused and who is not. If you are >> interested in discussing technical topics, then discuss them. > > Okay. The purpose of BNF (at least as I envision it) is to > produce/specify a *context-free* "grammar". A lexer parses the tokens > specified in the BNF into an Abstract Syntax Tree. If one can produce > such a tree for any given source, the language, in theory, can be > compiled by GCC into an executable. > > Boom. > But you still need to specify the semantics.
[toc] | [prev] | [next] | [standalone]
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-10-22 11:16 -0700 |
| Message-ID | <mailman.1369.1382465816.18130.python-list@python.org> |
| In reply to | #57230 |
>>>> So which of you is confused? I ask that in the inclusive (not >>>> exclusive OR) sense.... ;^) <-- face says "both". >>> >>> Could you please be less snarky? >> >> Okay. The purpose of BNF (at least as I envision it) is to >> produce/specify a *context-free* "grammar". A lexer parses the tokens >> specified in the BNF into an Abstract Syntax Tree. If one can produce >> such a tree for any given source, the language, in theory, can be >> compiled by GCC into an executable. >> >> Boom. > > Hmm, I don't hear the boom yet. An Abstract Syntax Tree is a tree > representation of a program. To use my previous example: the program "123 > *!? 456" would become a tree: > > op: "*!?" > num: 123 > num: 456 > > There's still not enough information to compile this. ....Is your language Turing complete? -- MarkJ Tacoma, Washington
[toc] | [prev] | [next] | [standalone]
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-10-22 11:22 -0700 |
| Message-ID | <mailman.1370.1382466169.18130.python-list@python.org> |
| In reply to | #57230 |
>> Okay. The purpose of BNF (at least as I envision it) is to >> produce/specify a *context-free* "grammar". A lexer parses the tokens >> specified in the BNF into an Abstract Syntax Tree. If one can produce >> such a tree for any given source, the language, in theory, can be >> compiled by GCC into an executable. >> >> Boom. >> > But you still need to specify the semantics. In my world, like writing pseudo-code or flow-charts, the AST *is* the semantics. What world are you guys from? -- MarkJ Tacoma, Washington
[toc] | [prev] | [next] | [standalone]
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-10-22 11:28 -0700 |
| Message-ID | <mailman.1371.1382466509.18130.python-list@python.org> |
| In reply to | #57230 |
>> ....Is your language Turing complete? >> > > 1) No, it's not. > 2) So what? That should make it easier to compile to C, if anything. > 3) Don't change the subject. Well, if your language is not Turing complete, it is not clear that you will be able to compile it at all. That's the difference between a calculator and a computer. Thank you. You may be seated. Mark J Tacoma, Washington
[toc] | [prev] | [next] | [standalone]
| From | Piet van Oostrum <piet@vanoostrum.org> |
|---|---|
| Date | 2013-10-22 18:11 -0400 |
| Message-ID | <m21u3d2bxe.fsf@cochabamba.vanoostrum.org> |
| In reply to | #57293 |
Mark Janssen <dreamingforward@gmail.com> writes: >>> ....Is your language Turing complete? >>> >> >> 1) No, it's not. >> 2) So what? That should make it easier to compile to C, if anything. >> 3) Don't change the subject. > > Well, if your language is not Turing complete, it is not clear that > you will be able to compile it at all. That's the difference between > a calculator and a computer. You think a language that is not Turing-complete cannot be compiled? What nonsense is that. Please Mark, spare us your nonsense. -- Piet van Oostrum <piet@vanoostrum.org> WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web