Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing Guile Scheme

dthompson.us

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Optimizing Guile Scheme

#31

Post by cardanome »

munificent wrote: post #9

I have such mixed feelings about dynamically typed languages. I've designed a whole pile of hobby programming languages, and dynamically typed languages are at least an order of magnitude simpler to design and for users to learn and start using. At the same time, they inevitably seem to lead to user stories like this where a user really does know exactly what types they're working with and wants the language to know…

I think Common Lisp got it exactly right. Strongly typed dynamic language where you can optionally specify types for the extra performance/correctness if need be (especially with SBCL).

Honestly, I think weak typing is more of an issue than dynamic typing and people cry for static types when they suffer mostly from the former.

Dynamic typing is great because it allows you to have extremely complex types for basically free. It allows for insane expressiveness. It also makes prototyping much easier and does not force you into over-specifying in you types early on. In dynamic language most of your types are the most general type that would work by default while static types forces you to use very specific types (especially when lacking structural typing.)

If you want to allow just half the expressiveness of dynamic languages in your static language you will quickly find huge complexity with dependent types, long compile time, cryptic error messages and whatnot.

Generally, I think gradual typing is rising in popularity for good reason. It allows for quick prototyping but also to drill down on your types when you want to. Best of both worlds.

Re: Optimizing Guile Scheme

#32

Post by whartung »

atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

Part of the problem is that raw Scheme is spectacularly underspecified.

It also doesn't help that Schemes like Guile are also interactive. The domain of an interactive language and a "compiled" language are quite different.

Given the entirety of the program made available to the compiler all at once, there are high level derivations that can happen notably through flow analysis to let the compiler make better decisions. But do that in an interactive environment when the rug can be pulled out of any of the assumption the compiler made, and things get messy quite quickly.

One interesting tidbit for Java is that the developers of the compiler advocate "idiomatic" Java. Simply, write Java like Java, and don't try to trick the compiler. Let the compiler developers trick the compiler.

That's evident here in this article when they wrote the function that tests the types of the parameters. Raw Scheme, naturally, doesn't allow you to specify parameter types, not the way you can in Common Lisp, for example. And, either Guile does not have an specific extension to support this, or simply the compiler looks for this type checking pattern at the top of a function to make optimization determinations. On the one hand, it could be more succinct with a specialized facility, but on the other, this is "just Scheme".

So, in effect by checking for the type of the variable, they're implicitly declaring the type of the variable for the "sufficiently smart" compiler to make better decisions.

The counter example is the "define-inline" construct, and thus not standard Scheme (though readily replaced by a "no-op" macro if one was interested in porting the code).

Re: Optimizing Guile Scheme

#33

Post by wbl »

tmtvl wrote: post #29
eru wrote: post #12

Earlier quoted context omitted.

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

I don't think there's a real 'default' Scheme, like Chez is probably the implementation which generates the fastest code, but if I'm not mistaken it only implements the R6RS spec, Guile is quite performant and supports both R6RS and R7RS Small, Chicken has a bunch of libraries (the 'eggs'), but I think it's R5RS (I may be wrong), and of course GNU/MIT Scheme is what you want to follow along with MIT publications work…

Racket is now built around Chez.

Re: Optimizing Guile Scheme

#34

Post by gus_massa »

tmtvl wrote: post #29
eru wrote: post #12

Earlier quoted context omitted.

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

I don't think there's a real 'default' Scheme, like Chez is probably the implementation which generates the fastest code, but if I'm not mistaken it only implements the R6RS spec, Guile is quite performant and supports both R6RS and R7RS Small, Chicken has a bunch of libraries (the 'eggs'), but I think it's R5RS (I may be wrong), and of course GNU/MIT Scheme is what you want to follow along with MIT publications work…

You can download a package to use R7RS Small in Racket. https://github.com/lexi-lambda/racket-r7rs

Re: Optimizing Guile Scheme

#35

Post by bitwize »

davexunit wrote: post #21
bitwize wrote: post #6

Earlier quoted context omitted.

The slogan I've proposed for the language is "Guile goes with everything." Because Guile was designed from the outset to run embedded or standalone, and to transpile other extension languages to Scheme or a Scheme-compatible representation, I think that fitting. See: https://knowyourmeme.com/memes/guiles-theme-goes-with-everyt...

I think the Guile community of yore would have no idea what Street Fighter was but now we should embrace it as long as Capcom doesn't get mad.

The other Scheme environment I use regularly is Gambit. So, reppin both Marvel and Capcom.

Re: Optimizing Guile Scheme

#36

Post by fwip »

bitwize wrote: post #6
orliesaurus wrote: post #2

As soon as I saw the title, I thought of the streetfighter character, but this was actually an interesting read on a programming language, I had never heard of before

The slogan I've proposed for the language is "Guile goes with everything." Because Guile was designed from the outset to run embedded or standalone, and to transpile other extension languages to Scheme or a Scheme-compatible representation, I think that fitting. See: https://knowyourmeme.com/memes/guiles-theme-goes-with-everyt...

Should it be "Guile Scheme goes with everything" for the rhyme?

Re: Optimizing Guile Scheme

#37

Post by bitwize »

fwip wrote: post #36
bitwize wrote: post #6

Earlier quoted context omitted.

The slogan I've proposed for the language is "Guile goes with everything." Because Guile was designed from the outset to run embedded or standalone, and to transpile other extension languages to Scheme or a Scheme-compatible representation, I think that fitting. See: https://knowyourmeme.com/memes/guiles-theme-goes-with-everyt...

Should it be "Guile Scheme goes with everything" for the rhyme?

Even better.

Re: Optimizing Guile Scheme

#38

Post by eru »

School-Cotton wrote: post #14
eru wrote: post #12

Earlier quoted context omitted.

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

Extremely easy interop with native code is the main selling point of guile IMO. You just link in guile as a library and can have C code call scheme code and vice versa. Makes it great for any native program that needs an embedded scripting language (much like Lua). Does Racket support that use-case?

I haven't done FFI with Racket, but https://docs.racket-lang.org/foreign/index.html looks reasonably approachable?

Re: Optimizing Guile Scheme

#39

Post by School-Cotton »

eru wrote: post #38
School-Cotton wrote: post #14

Earlier quoted context omitted.

Extremely easy interop with native code is the main selling point of guile IMO. You just link in guile as a library and can have C code call scheme code and vice versa. Makes it great for any native program that needs an embedded scripting language (much like Lua). Does Racket support that use-case?

I haven't done FFI with Racket, but https://docs.racket-lang.org/foreign/index.html looks reasonably approachable?

That seems to let you call C functions from Racket, but I don't see how it lets you embed Racket in a C program and call Racket functions from C. So it's at best half a solution, unless I'm missing something.

Re: Optimizing Guile Scheme

#40

Post by eru »

tmtvl wrote: post #29
eru wrote: post #12

Earlier quoted context omitted.

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

I don't think there's a real 'default' Scheme, like Chez is probably the implementation which generates the fastest code, but if I'm not mistaken it only implements the R6RS spec, Guile is quite performant and supports both R6RS and R7RS Small, Chicken has a bunch of libraries (the 'eggs'), but I think it's R5RS (I may be wrong), and of course GNU/MIT Scheme is what you want to follow along with MIT publications work…

Thanks for the context! It's been a while since I did serious work in the Lisps. (I've moved on to the ML family.)

> [...] GNU/MIT Scheme is what you want to follow along with MIT publications working in Scheme (like Structure and Interpretation of Computer Programs, Structure and Interpretation of Classical Mechanics, and The Art of the Propagator).

Definitely, though I suspect if you need a language that's exactly what's written in the text, you are probably missing the point? At least for SICP, I haven't looked into the others as closely. (Part of) the point being learning wider concepts.

I almost feel like you get more out of the book, if you do the exercises in a mix of JavaScript and Python. Not because those are better languages, just the opposite: because it forces you to understand the concepts well enough to translate them.

Post reply on HN