Guile also supports the web at the programming language level(wingolog.org)
wingolog.org
Guile also supports the web at the programming language level
http://wingolog.org/archives/2010/12/17/on-the-new-posix
12 comments
I am really impressed by the level of activity in the Guile source tree. A lot has happened over the last few years. I came back to Guile 1.9 from Guile 1.6 and the difference in speed was significant.
Some might find it ironic that a dynamically-typed language is advocating typing as the solution to bugs. Of course, Lisp has a history of strong runtime typing, and this looks like a good approach to the problem.
One of the things I've always liked about Common Lisp is that you can add type annotations, and the good compilers will try to propagate that information, to speed up the program and to catch bugs at compile-time. If I declare a variable to be of type (integer 0 100), the compiler can try to stick that in a single byte in memory, and/or do runtime checking to make sure nobody puts something negative or greater than 100 into that value. And if I add two such values together, it knows that the result is going to have the type (integer 0 200), even if I don't declare that.
It's nice: a type system that's there when you want it, and stays out of your way. After being exposed to that, I've never really understood what the static-vs-dynamic argument was about. To me, dynamic and static typing looks like a several-dimensional continuum, and where a language falls on that continuum is a matter of taste.
It's nice: a type system that's there when you want it, and stays out of your way. After being exposed to that, I've never really understood what the static-vs-dynamic argument was about. To me, dynamic and static typing looks like a several-dimensional continuum, and where a language falls on that continuum is a matter of taste.
Try programming in Haskell. Pretty much all other statically typed programming languages (except ML etc.) get their type systems wrong because all types are really (or <x> null). That's useless for doing type checking, which is why there doesn't seem to be much of an advantage to static typing. Type classes and Hindley-Milner inference make things really nice to use. But it's really the lack of null that makes Haskell's type system actually useful for things other than catching trivial type bugs.
Haskell's type system catches a lot of bugs, and there are a lot of things right about it, but in practice, the type system often feels like a pain in the ass. I'm tired of being hit with nigh-incomprehensible type errors. I'm very tired of not being able to do printf debugging without using the IO monad and changing all the type signatures, although judicious use of unsafePerformIO helps.
What I really want in a type system is for it to catch bugs, but get out of my way. Haskell is a little too stern for my liking.
What I really want in a type system is for it to catch bugs, but get out of my way. Haskell is a little too stern for my liking.
Debug.trace is the module for you, my friend.
Debug.trace a b = a
and b gets logged to the console. Or maybe it's backwards. I forget.
Debug.trace a b = a
and b gets logged to the console. Or maybe it's backwards. I forget.
It's the opposite way:
Debug.Trace.trace :: String -> a -> a
and if you don't like debug.trace, you can make your own, via unsafePerformIO! hackyDebugTrace s v = unsafePerformIO (putStrLn s >>= \_ -> return v) because all types are really (or <x> null).
Did you miss a word there ? It happens to me all the time.Parse it as lisp.
It's haskell-type-system-speak for "If you declare something to be a String, it really means String or null."
It's haskell-type-system-speak for "If you declare something to be a String, it really means String or null."
The Haskell type for that would be "Maybe String". When you get a Maybe value, the compiler gives an error if you don't deal with the possibility that the value might be Nothing.
I don't think he did... took me a couple of passes, but it parsed in the end.
There's no irony in advocating using a richer array of types in a dynamically-typed language. In fact, static vs dynamic typing doesn't seem apropos here since it's also common in statically typed languages to use strings for everything, leading to the same problems.