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

What Every C Programmer Should Know About Undefined Behavior #2/3

blog.llvm.org

Post reply on HN
Print view View original

1–10 of 45 posts

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#2

Post by fragsworth »

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#3

Post by bhickey »

fragsworth wrote: post #2

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

Can you elaborate on your question?

I don't think what you're saying is intrinsic to FP. There are static analysis tools for non-functional languages. At the end of the day, everything is getting turned into an abstract syntax tree, so style should be irrelevant.

Do you mean pure (side-effect free) functional languages?

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#4

Post by Rusky »

fragsworth wrote: post #2

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

It's more an advantage of very-specifically designed languages like Haskell, some of which happen to be functional because part of the reason they can be specified in so much detail is because of the lack of side effects.

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#5

Post by fragsworth »

bhickey wrote: post #3
fragsworth wrote: post #2

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

Can you elaborate on your question? I don't think what you're saying is intrinsic to FP. There are static analysis tools for non-functional languages. At the end of the day, everything is getting turned into an abstract syntax tree, so style should be irrelevant. Do you mean pure (side-effect free) functional languages?

Yes, I was thinking of something like Haskell.

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#6

Post by jowiar »

fragsworth wrote: post #2

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

The relevant element of FP is statelessness. That said, statelessness could easily be considered a leaky abstraction because, at some point, the machine you are working on has state. Your machine has CPU registers and memory and such, so the entire "statelessness" of FP is subject to the underlying system-level implementation.

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#7

Post by perlgeek »

fragsworth wrote: post #2

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

To a big part the ability to optimize stems form a static and very detailed type system.

In Haskell you happen to know about statelessness from the types, which is an additional bonus. But other statically type languages like Eiffel are also pretty well optimizable.

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#8

Post by Peaker »

fragsworth wrote: post #2

Kind of off topic, but I am curious: is this one of the advantages of functional programming - the notion that you can prove or disprove certain things about the code and therefore optimize the compiler, based on such proofs, to your heart's content?

The more advanced of a type system you have, the more you can optimize indeed. A nice example of this is the zip function.

In Haskell:

    zip :: [a] -> [b] -> [(a, b)]
    zip [] _ = []
    zip _ [] = []
    zip (x:xs) (y:ys) = (x,y) : zip xs ys
Note how each iteration needs to check both lists for emptiness.

In a more advanced type system (or using more advanced type hackery in Haskell) you can have length-indexed lists. That is: lists that have 2 type parameters or "indexes" instead of 1. The 1 is usually the type of element inside the list, the extra 1 is a natural number indicating the length of the list.

So the function zip becomes something like:

    zip :: List N a -> List N b -> List N (a, b)
    zip [] [] = []
    zip (x:xs) (y:ys) = (x,y) : zip xs ys
The compiler checks the code and verifies, at compile-time, that both the input lists and the resulting list are all of the same length. This also means that you only need one runtime emptiness check instead of 2. If the N is concretely known at compile-time, you may need 0 (though that case might be caught by inlining/loop unrolling optimizations anyway).

Re: What Every C Programmer Should Know About Undefined Behavior #2/3

#10

Post by defen »

CamperBob wrote: post #9

What would possess someone to write if (i = buffer) ... instead of if ((i = sizeof(buffer)) ?

Working within the "contrived example" framework, it would have made a little more sense if buffer were a pointer rather an array, in which case you wouldn't be able to use "sizeof".
Post reply on HN