executables
105 views
Skip to first unread message
Tim Meehan
Nov 24, 2020, 7:34:40 PM11/24/20
to Racket Users
Some Schemes allow you to compile to a (self-hosting?) executable (Chicken {via C}, Chez, Racket, others?). Some do not (Guile, others?), but compile to bytecode.
Why would a group of developers choose one over the other? Or is the end result not that different in either case? Is there a book/paper that I might read on this?
Cheers,
Tim
George Neuner
Nov 25, 2020, 12:26:42 AM11/25/20
to Tim Meehan, Racket Users
On 11/24/2020 7:34 PM, Tim Meehan
wrote:
Some Schemes allow you to compile to a (self-hosting?) executable (Chicken {via C}, Chez, Racket, others?). Some do not (Guile, others?), but compile to bytecode.
Why would a group of developers choose one over the other? Or is the end result not that different in either case?
The reason for creating stand-alone executables is to be able to run
programs in environments where the language tools are not, or cannot
be, installed. For security reasons, many companies do not permit
installing programming tools.
However, creating stand-alone executables is rather unrelated to what the compiler produces. There are a number of language implementations - Racket included - which can embed their bytecode (as static data) into a native "runtime" program which executes it.
However, creating stand-alone executables is rather unrelated to what the compiler produces. There are a number of language implementations - Racket included - which can embed their bytecode (as static data) into a native "runtime" program which executes it.
Is there a book/paper that I might read on this?
Unfortunately, language implementation is a very large subject
area. If you want to understand why things are being done a certain
way, you need to understand the ways that they *could be* done and
what trade-offs are involved in using various methods.
Little understood fact: all languages actually are defined by a *virtual* abstract machine. This is the reason that languages can be implemented on many different real-world CPUs: it is the abstract machine that defines the language's behavior, and it is the abstract machine - not some CPU - that is the *real* compilation target.
[For those about to object: yes, Scheme has a formal denotational definition in contrast to the many languages that are operationally defined by (relatively) informal description of behavior combined with a "reference" implementation. Consider that Scheme's denotational spec is describing the behavior of an abstract machine, and that Scheme implementations are realizations of the machine.]
To get a sense of what is going on under the hood, you need to learn a bit about hardware, and a lot about compilers and interpreters. Particular language features often can be implemented in multiple ways, and the choices made for various features often affect how harmoniously they can coexist.
If you really are serious about learning this stuff, I'm sure we can keep you busy reading for a while.
George
Little understood fact: all languages actually are defined by a *virtual* abstract machine. This is the reason that languages can be implemented on many different real-world CPUs: it is the abstract machine that defines the language's behavior, and it is the abstract machine - not some CPU - that is the *real* compilation target.
[For those about to object: yes, Scheme has a formal denotational definition in contrast to the many languages that are operationally defined by (relatively) informal description of behavior combined with a "reference" implementation. Consider that Scheme's denotational spec is describing the behavior of an abstract machine, and that Scheme implementations are realizations of the machine.]
To get a sense of what is going on under the hood, you need to learn a bit about hardware, and a lot about compilers and interpreters. Particular language features often can be implemented in multiple ways, and the choices made for various features often affect how harmoniously they can coexist.
If you really are serious about learning this stuff, I'm sure we can keep you busy reading for a while.
Cheers,Tim
George
Tim Meehan
Nov 27, 2020, 7:37:31 AM11/27/20
to Racket Users
Hi George, thanks for the reply!
I work a bit with hardware, but I'm not terribly good with assembly. I know enough about hardware to know how hard this must be to get working - but it does interest me a lot. The more I learn, the more respect I have for the tools available.
I guess for self-hosting, there are a couple of examples I could look at (raco exe, chez-exe, etc).
I had considered working through Build Your Own Lisp, Lisp in Small Pieces, Scheme from Scratch or something similar. Attempting self-study of the dragon book, or perhaps a lighter introduction if anyone has one they like.
Hendrik Boom
Nov 27, 2020, 12:40:24 PM11/27/20
to Racket Users
On Wed, Nov 25, 2020 at 09:46:21AM -0600, Tim Meehan wrote:
> Hi George, thanks for the reply!
>
> I work a bit with hardware, but I'm not terribly good with assembly. I know
> enough about hardware to know how hard this must be to get working - but it
> does interest me a lot. The more I learn, the more respect I have for the
> tools available.
>
> I guess for self-hosting, there are a couple of examples I could look at
> (raco exe, chez-exe, etc).
>
> I had considered working through Build Your Own Lisp
> <http://buildyourownlisp.com>, Lisp in Small Pieces, Scheme from Scratch or
> Hi George, thanks for the reply!
>
> I work a bit with hardware, but I'm not terribly good with assembly. I know
> enough about hardware to know how hard this must be to get working - but it
> does interest me a lot. The more I learn, the more respect I have for the
> tools available.
>
> I guess for self-hosting, there are a couple of examples I could look at
> (raco exe, chez-exe, etc).
>
> I had considered working through Build Your Own Lisp
> something similar. Attempting self-study of the dragon book
> <https://suif.stanford.edu/dragonbook/>, or perhaps a lighter introduction
> if anyone has one they like.
I found a book by Dick Grune et al to be somewhat lighter than the dragon
book. Looking online, I discoered I was thinking of the first edition. I
haven't seen the second edition, but I'd guess the second edition would be
similar, though it has rather more material:
https://dickgrune.com/Books/MCD_1st_Edition/
https://dickgrune.com/Books/MCD_2nd_Edition/
When I saw the first edition, I decided that if I were teaching an
introductory course in compilers, I would use it as textbook.
And there's a lot of other interesting material on that web site.
-- hendrik
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CACgrOxLR%2BYRaG8BuUh54cuykfqDNKvzW-YuQ7CHCNr-1xHYe_w%40mail.gmail.com.
Matt Jadud
Nov 27, 2020, 3:57:39 PM11/27/20
to Racket Users
On Fri, Nov 27, 2020 at 12:40 PM Hendrik Boom <hen...@topoi.pooq.com> wrote:
On Wed, Nov 25, 2020 at 09:46:21AM -0600, Tim Meehan wrote:
I found a book by Dick Grune et al to be somewhat lighter than the dragon
book. Looking online, I discoered I was thinking of the first edition. I
haven't seen the second edition, but I'd guess the second edition would be
similar, though it has rather more material:
https://dickgrune.com/Books/MCD_1st_Edition/
https://dickgrune.com/Books/MCD_2nd_Edition/
When I saw the first edition, I decided that if I were teaching an
introductory course in compilers, I would use it as textbook.
I've been fond of
for a while as a "soup to nuts" overview of computation from the NAND gate up through a simple computer, a simplified assembly language, assembler, compiler, VM, and so on. It's not an advanced text, but it does provide a hands-on bottom-to-top view of the computational world that can help orient someone who is exploring the space.
It's also why I keep wondering when I'm going to break down and pick up a little FPGA board for myself and just play. :)
Cheers,
Matt
Tim Meehan
Nov 27, 2020, 6:41:22 PM11/27/20
to Racket Users
Thanks for the links, Hendrick and Matt!
The holidays gave me some time to learn about things that I had put on the back burner all year, so this is great timing.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAAGM454t_FNXj8RHTbLuC1pe-14i-rF%3DyQ_B%2BmSvoE4DGUyMAw%40mail.gmail.com.
Tim Meehan
Nov 27, 2020, 6:42:21 PM11/27/20
to Racket Users
Hendrik - sorry for misspelling your name 😱.
John Clements
Nov 27, 2020, 7:45:37 PM11/27/20
to Tim Meehan, Racket Users
If you’re specifically interested in
1) Compilers, and
2) Racket,
I think it’s hard to do better than Jeremy Siek’s Essentials of Compilation. He comes from the Indiana group, as, indirectly, does just about everything around here, and his approach is very closely related to Dybvig/Chez, including a nanopass architecture. Shout-outs also to Andy Keep and Abdulaziz Ghuloum, who did a lot of work related to this.
Here’s the link to the most recent course web page:
https://iucompilercourse.github.io/IU-P423-P523-E313-E513-Fall-2020/
… including a link to the book.
I would also be remiss in not mentioning Ben Lerner’s NU compilers course, for which lecture notes are online:
https://course.ccs.neu.edu/cs4410sp20/#%28part._lectures%29
And finally, I want to take a brief moment to impugn the Dragon Book; the last time I checked, I thought that it represented a very outdated approach to writing a compiler. I’m probably biased, but if you want a heavy book on low-level programming, I would go for Keith Cooper’s Compilers book. Jeremy Siek’s book, by contrast, is free, describes how to implement high-level languages such as Racket, and does not contain an encyclopedic discussion of low-level optimization.
Everything here is just my opinion, of course!
John
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CACgrOxKt0oS%3DXGRjujvZ6p9jkKaHS5r44SWVWGw0cu8z%3DOXrpg%40mail.gmail.com.
1) Compilers, and
2) Racket,
I think it’s hard to do better than Jeremy Siek’s Essentials of Compilation. He comes from the Indiana group, as, indirectly, does just about everything around here, and his approach is very closely related to Dybvig/Chez, including a nanopass architecture. Shout-outs also to Andy Keep and Abdulaziz Ghuloum, who did a lot of work related to this.
Here’s the link to the most recent course web page:
https://iucompilercourse.github.io/IU-P423-P523-E313-E513-Fall-2020/
… including a link to the book.
I would also be remiss in not mentioning Ben Lerner’s NU compilers course, for which lecture notes are online:
https://course.ccs.neu.edu/cs4410sp20/#%28part._lectures%29
And finally, I want to take a brief moment to impugn the Dragon Book; the last time I checked, I thought that it represented a very outdated approach to writing a compiler. I’m probably biased, but if you want a heavy book on low-level programming, I would go for Keith Cooper’s Compilers book. Jeremy Siek’s book, by contrast, is free, describes how to implement high-level languages such as Racket, and does not contain an encyclopedic discussion of low-level optimization.
Everything here is just my opinion, of course!
John
e...@disroot.org
Dec 4, 2020, 12:28:02 PM12/4/20
to George Neuner, Racket Users
Hi George,
> [For those about to object: yes, Scheme has a formal denotational definition in contrast to the many languages that are operationally defined by (relatively) informal description of behavior combined with a "reference" implementation. Consider that Scheme's denotational spec is describing the behavior of an abstract machine, and that Scheme implementations are realizations of the machine.]
I was very surprised to learn about this, I always assumed Scheme was "officially" defined with operational semantics.
But you are right, the r7rs small contains the description of the denotational semantics.
Although the domains are not defined excplicitly.
Cheers,
Eugen.
But you are right, the r7rs small contains the description of the denotational semantics.
Although the domains are not defined excplicitly.
Cheers,
Eugen.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/8a2d8868-41b7-7b3c-eba2-2cf0517032a8%40comcast.net.
Reply all
Reply to author
Forward
0 new messages