Disqus - Latest Comments for JamesIry

Re: Don't use Actors for concurrency

James Iry — Wed, 16 Sep 2015 10:41:34 -0000

Terminology is slightly backwards. Actors are for concurrency (multiple logical threads interacting). Futures are for parallelism (multiple phyiscal processors/cores/whatever running simultaneously). https://mail.haskell.org/pi...

Re: Curry-Howard, the Ontological Ultimate

James Iry — Wed, 15 Oct 2014 15:56:47 -0000

Type safety of a language is usually formally defined as meaning that all programs in that language have preservation and progress properties. Preservation means that as a program is evaluated its static properties remain true and progress means that as it's evaluated it never comes to a point where the next step is undefined. Undefinedness and the static properties of a program are both language defined. Importantly for this conversation though, most dynamically typed languages are type safe in that a) evaluation doesn't break the very few static properties they have and b) they never get stuck in an undefined state during evaluation. That's why it's entirely fair to say that type safety is different from static types

As a trivial example, just about every production programming language prevents writing past the end of an array with a dynamic check. Their static type systems just don't have the horsepower to statically prove that the undefined state of writing to arbitrary memory never happens. Yet they remain safe from that problem.

Ironically, the mainstream programming languages that are deeply type unsafe are in fact statically typed: C and C++.

I bring all this up for two reasons. One, the preservation and progress definition is stronger than what Kell asserts about type safe being the same thing as memory safe. For some language, yes, they might actually be about the same thing. But for, say, a language built on capability safety any escalation of privilege beyond explicit granted capabilities would violate its type safety guarantees because a guaranteed static property would be violated (and again note that some capabilities based languages, like E, are dynamically typed).

The second reason I bring it up is because progress expressly allows for the logical inconsistency of divergence. Progress can still be made in small step dynamics even though a program has an infinite loop or throws an exception. The discussion of the simply typed lambda calculus is a bit beside the point in the context of type safety.

Both the simply typed and untyped lambda calculi are type safe in that they both can be proven to have preservation and progress properties. The fact that expressions in the untyped lambda calculus can get into an infinite loop is a different problem from type safety.

Re: Using Functions to Represent Sets

James Iry — Sun, 24 Aug 2014 14:21:24 -0000

Java isn't that bad. It mainly suffers from lack of type inference or at least a good way to create a type alias

https://gist.github.com/Jam...

Re: Scheme in Scala

James Iry — Fri, 07 Jun 2013 13:00:34 -0000

I found a couple of small things that should help with performance. Pull request is https://github.com/martintr...

Re: Programming languages ranked by expressiveness

James Iry — Mon, 25 Mar 2013 18:40:25 -0000

A (probably good) guess: JavaScript is often used by people who are not experienced programmers and who feel more comfortable with copy/paste than with abstraction.

Re: Scala traits as well-defined modules - And a crime scene investigation ...

James Iry — Fri, 08 Mar 2013 12:04:13 -0000

It doesn't take Scala's abstract vals to demonstrate the problem. Java can exhibit the same behavior. https://gist.github.com/Jam... . It's a tough problem to prevent, and well known in OO circles. The last time I checked every mechanism ever used to prevent that behavior statically also prevented perfectly good code from compiling.

Re: One Div Zero: The Best-Laid Schemes O' Mice An' Constructors Gang Aft Agley

James Iry — Tue, 19 Feb 2013 17:04:42 -0000

Class#getModifiers also does not cause class init. Even if it did, it would share the same potentially fatal flaw as Class.forName: reflective features can be and often are disabled by security managers.

Re: One Div Zero: The Best-Laid Schemes O' Mice An' Constructors Gang Aft Agley

James Iry — Tue, 19 Feb 2013 15:50:39 -0000

checkcast doesn't cause static init to fire. http://docs.oracle.com/java.... I verified by plugging in "Foo2 x = (Foo2)null;" into my sample java code above, inspecting the bytecode to make sure the checkcast was emitted, then running.

Re: One Div Zero: The Best-Laid Schemes O' Mice An' Constructors Gang Aft Agley

James Iry — Mon, 18 Feb 2013 12:50:38 -0000

Of course, but what if the "Foo" has no static fields? There aren't any that guaranteed to be there by the Java spec.

Even in cases where there is one, the JVMs separate compilation model means you should assume that the layout of a 3rd party class can change between compilation and run time so you should bind to as little as possible. If the compiler finds a static field in a third party class and gens bytecode that references it without that being in user code then the user will be VERY confused when the presence or absence of an apparently unreferenced static field breaks binary compatibility as the version of the 3rd party class is changed without recompiling.

Re: One Div Zero: The Best-Laid Schemes O' Mice An' Constructors Gang Aft Agley

James Iry — Sun, 17 Feb 2013 23:30:41 -0000

That's a viable alternative but I don't think I want to go down that route. As it is the compiler already has 2 points where it deals with problematic try/catch. What you're suggesting would add a third point. If I can come up with a clean, efficient solution to this class initialization issue then I could consolidate all the problematic try/catch transformation logic to one place.

Re: One Div Zero: The Best-Laid Schemes O' Mice An' Constructors Gang Aft Agley

James Iry — Fri, 15 Feb 2013 17:08:35 -0000

The problem with seeing Plan 4 as a bug fix is that I wouldn't ALWAYS make this translation. It would only be done when try/catch is used as an argument to the constructor. So from a user point of view order of evaluation would change depending on something seemingly irrelevant.

For Plan 4 to be a bug fix I'd have to always use locals for constructor args and that would lead to bigger classfile sizes.

Re: Heroku | Cedar Goes GA

James Iry — Thu, 24 May 2012 17:56:59 -0000

Performant is a perfectly cromulent word.

Re: One Div Zero: Type Errors as Warnings

James Iry — Thu, 02 Feb 2012 19:11:25 -0000

I want the compiler to emit exception code in its output, not monkey with my source code. That would be a pain in the ass.

Re: One Div Zero: Type Errors as Warnings

James Iry — Fri, 06 Jan 2012 16:25:40 -0000

I'm not talking about modifying source code, I'm talking about the object code (byte code, machine code, whatever) emitted by the compiler.

Re: One Div Zero: Type Errors as Warnings

James Iry — Fri, 06 Jan 2012 16:15:35 -0000

The reason for the sophistication in SPJ's discussion about wrappers that throw exception is just that Haskell is lazy and can get away with some things that won't fly in strict languages. GHC doesn't have to do those wrappers, but it can so why not?

Re: One Div Zero: Type Errors as Warnings

James Iry — Fri, 06 Jan 2012 16:07:01 -0000

Around 27:00 SPJ responds to a question about optional typing with something related to what I'm talking about and then makes it clear that it's not optional typing because some programs that would work under optional typing won't work under his proposed scheme.

Re: One Div Zero: Type Errors as Warnings

James Iry — Fri, 06 Jan 2012 15:54:36 -0000

"My project is to automatically detect Composite design pattern in Java 1.4 source code." He wanted to do analysis on the code, not deploy it. I'm not clear on why he need to compile unless he was analyzing the byte code and accidentally wrote "source code" but either way I don't think that's an example of your nightmare scenario. I've put other comments into the article.

Re: One Div Zero: Sleep Sort! With Actors! For No Reason!

James Iry — Sat, 18 Jun 2011 01:13:08 -0000

Oooh.

Re: http://james-iry.blogspot.com/2007/10/monads-are-elephants-part-3.html

James Iry — Wed, 15 Jun 2011 16:29:19 -0000

Nope. That would make the types wrong. The unit for Option is Some

scala> def f(x : Int) : Option[String] = Some(x + "a")

f: (x: Int)Option[String]

scala> Some(1) flatMap f

res0: Option[java.lang.String] = Some(1a)

scala> f(1)

res1: Option[java.lang.String] = Some(1a)

Compare with your alternative

scala> Some(f(1))

res2: Some[Option[java.lang.String]] = Some(Some(1a))

Re: One Div Zero: Why Eager Languages Don't Have Products and Lazy Languages Don't Have Sums

James Iry — Wed, 11 May 2011 11:07:22 -0000

Dan Doel's comment is that cleaner way to describe the differences and why in some sense it's technically accurate to say that design choices mean that a language "doesn't have sums or products."

Re: One Div Zero: Why Eager Languages Don't Have Products and Lazy Languages Don't Have Sums

James Iry — Wed, 11 May 2011 11:05:09 -0000

Of course Haskell "has sum types" in its library and of course SML "has products types" in its library. This article is an attempt to explain what Dr. Harper was getting at. However, Dan Doel's comment has put me to shame.

Re: One Div Zero: Why Eager Languages Don't Have Products and Lazy Languages Don't Have Sums

James Iry — Wed, 11 May 2011 10:57:38 -0000

This comment is fascinating. Dr. Harper isn't the first person from whom I've heard "lazy languages have products but not sums" and the argument I've seen is the fst (a, b) = a business. I don't think I've ever seen anybody carry it on to (fst p, snd p) = p.

Re: One Div Zero: Why Eager Languages Don't Have Products and Lazy Languages Don't Have Sums

James Iry — Tue, 10 May 2011 00:46:07 -0000

@MarkusQ , the same objection holds for the eager language problem with products - the invariant holds up just fine as long as we ignore 0's (bottom). Bob Harper's point, I think, is that there's a nifty duality here where bottom causes problems in invariants in different but equal ways for both eager and lazy languages.

@Vlad patryshev , I'm not as versed in category theory as you are. But it is related to the same kind of dualities (sum is often called coproduct). However, in this case we don't even need infinite co-data structures like stream to see the differences.

@Pelotom true, I linked to another article to talk more about bottoms. I didn't want to go back over the same territory.

Re: http://james-iry.blogspot.com/2009/05/erlang-is-not-functional.html

James Iry — Fri, 28 Jan 2011 10:23:44 -0000

Even at the time I wrote this Scala supported curried function definition. It's in my footnote.

Re: One Div Zero: The Read Eval Print Lie

James Iry — Wed, 19 Jan 2011 11:36:47 -0000

Nifty. From the README at http://neugierig.org/softwa...

"== How it works
The approach is surprisingly simple: for each line of code you enter, we compile a shared object in the background. If the compilation succeeds, the object is loaded into a child process via dlopen()."