• Advertisement

# CL, Scheme, OCaml, or other?

This topic is 3700 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

I'd like to learn a new language that'll broad my horizon, that isn't a descedant of C. Right now, I'm really leaning toward Common Lisp, and have started reading a few tutorials on it. I've heard Scheme is another dialect of Lisp, and is often recommended over CL for game development, but I'm not sure why. Other languages that spark my interest are OCaml, Smalltalk (because of its influence over Objective-C), and F#. What would people suggest to help me become a better programmer, and for game development? Thanks, Jedd [Edited by - bronxbomber92 on January 1, 2008 5:24:29 PM]

#### Share this post

##### Share on other sites
Advertisement
Quote:
 Original post by bronxbomber92I'd like to learn a new language that'll broad my horizon, that isn't a descedant of C. Right now, I'm really leaning toward Common Lisp, and have started reading a few tutorials on it. I've heard Scheme is another dialect of Lisp, and is often recommended over CL for game development, but I'm not sure why.

I'm not sure why either. Scheme's a very elegant language, but standard Scheme alone isn't very practical. I can see why it'd be suggested over Common Lisp if what you wanted was to learn functional programming though(*).

Quote:
 Other languages that spark my interest are OCaml, Smalltalk (because of its influence over Objective-C), and F#.

Smalltalk has had influence over much more than just Objective-C, Ruby being one the most obvious languages. [smile]

Quote:
 What would people suggest to help me become and better programmer, and for game development?

Any of these languages will do as far as becoming a better programmer is concerned. For game development, F# strikes me as the most practical, but it has its own set of issues: it requires a .NET environment, it had a problematic licence WRT FOSS when I looked at it months ago, the .NET framework is inherently imperative, and I don't know if it runs on Mono yet (meaning you'd be stuck on Windows, which may or may not be a problem to you).

I'm personally very fond of OCaml and Smalltalk, but they aren't exactly popular, so finding libraries — especially cross-platform ones — or some features (Unicode, i18n, l10n, ...) can be problematic at times. It's also worth noting that, out of all these languages, only Common Lisp and (ANSI) Smalltalk are ANSI standards. Common Lisp also has an extraordinary FFI.

(*) This isn't to imply than functional programming isn't possible in Common Lisp, but rather than it isn't idiomatic Common Lisp.

EDIT: typo

[Edited by - let_bound on January 1, 2008 10:58:08 PM]

#### Share this post

##### Share on other sites
I recommend Haskell. It's neat for doing things like this.

#### Share this post

##### Share on other sites
Scheme's nice, but I'm not a great fan of the syntax (yes, I have actually used it). However, in terms of being able to redefine pretty much everything (with a vastly more powerful macro system than in any other language I've encountered), it's really interesting. Incidentally, the standard computer science text Structure and Interpretation of Computer Programs is freely available online and uses Scheme as its operative language. It's probably not the best way of learning the language, but if you want to learn it alongside some solid computer science, then it's worth considering.

Of your listed ones, I'd go for O'Caml (and then, I'd go for F#; the two languages share a common subset, but F# also has access to the .NET framework). I don't know much about either of them other than what I've read about them, and what I could surmise from reading source written in them.

That said, I would strongly recommend you consider Haskell. It's achingly elegant for most things and has a very pleasant syntax. Lazy evaluation is also a very handy thing in most cases.

#### Share this post

##### Share on other sites
Personally, I prefer Scheme over Common Lisp mainly because of the macro system. I really do love define-syntax [grin], although my institution is big into Scheme so I guess I've been biased from the start.

Some Scheme resources if you decide to go that route:
Petite Chez Scheme - the compiler I use for school
Ikarus - another Scheme compiler, and it's FAST [inlove]
The Scheme Programming Language, 3rd Ed. - an awesome book on Scheme.

Those are what I've used here at uni.

Hope that helps,
Aviosity

#### Share this post

##### Share on other sites
Thanks guys.

aviosity - Doesn't both CL and Scheme have a macro system? It's about all I hear about Lisp, being a "programmable programming language."

I can't really see the advantages of Scheme because Lisp supposedly has better standard libraries, faster compiler and better OpenGL bindings. Hmm, I'll check out Scheme more though.

Edit - What are the disadvantages and advantages of each language?

[Edited by - bronxbomber92 on January 2, 2008 6:09:20 PM]

#### Share this post

##### Share on other sites
Quote:
 Original post by bronxbomber92Edit - What are the disadvantages and advantages of each language?

The differences between Scheme and Common Lisp language-wise are essentially that Scheme has first-class continuations and CL does not. The macro systems also differ - Scheme's is hygienic and CL's is unhygienic (the way you use them is different; Scheme's is "safe" and CL's is not, but CL's allows transformations that Scheme's does not). Scheme code also tends to be written in a functional style, CL less so, but this is idiomatic rather than anything to do with the languages themselves (CL has a lengthier syntax for dealing with first-class functions, though).

Scheme is the simpler and more expressive language because it has first-class continuations, so it can express all of the language features (and libraries) of CL - CLOS, conditions, etc. CL's advantages are its larger set of standard libraries and its implementations/tools, which in practice might make it a better choice, depending on the project.

OCaml and Haskell are quite different from CL and Scheme - they are (statically) typed with algebraic types, polymorphism and type inference. Haskell has non-strict evaluation (most languages have strict evaluation) and referential transparency.

[Edited by - Rebooted on January 2, 2008 7:59:09 PM]

#### Share this post

##### Share on other sites
It seems like Lisp is the language I should get into. I like it's builtin libraries, and tools - makes it easier to get into.

Thanks for all the info! Oh, which is the best OpenGL binding for Lisp? I found this: http://common-lisp.net/project/cl-opengl/, but I don't know if there are any newer/better bindings available?

#### Share this post

##### Share on other sites
With regards to F# let_bound: Ive had F# running on Mono on linux since a pretty early version. So you wont be stuck on Windows if you decide to write in F#. Heck Ive even had it running on my Pocket PC :).

It is true that .NET is still quite Object oriented, dynamic and all that but at the end of the day a language is merely an abstraction. Hiding the unnecessary and unimportant details. A semantic covering. So long as they can give me my first class functions at good performance, I dont care about much else.

#### Share this post

##### Share on other sites
Quote:
 Original post by Rebooted...OCaml and Haskell are quite different from CL and Scheme - they are (statically) typed with algebraic types, polymorphism and type inference. Haskell has non-strict evaluation (most languages have strict evaluation) and referential transparency.

Seeing as the thread is dead. Would you happen to know the history of the term? Why are they called algebraic types?

#### Share this post

##### Share on other sites
Quote:
 Original post by DaeraxSeeing as the thread is dead. Would you happen to know the history of the term? Why are they called algebraic types?

There is an algebra of types, with sum as choice (Either), product as pairing (,) and exponential as the function type (->). You'll be familiar with this from CCCs in category theory. Algebraic data types are sums-of-products.

This is useful because it allows you to do things like calculate when two types are isomorphic and calculate the derivative (as in calculus) of a type to obtain a Zipper.

Regular inductive types subsume sum so it is not built into ML, but product is. Coinductive types like Charity's subsume product, so tuples don't have to be built in either. In categorical semantics, an inductive data type is an initial algebra for an endofunctor and a coinductive type is a final coalgebra for an endofunctor.

#### Share this post

##### Share on other sites
Quote:
Original post by Rebooted
Quote:
 Original post by DaeraxSeeing as the thread is dead. Would you happen to know the history of the term? Why are they called algebraic types?

There is an algebra of types, with sum as choice (Either), product as pairing (,) and exponential as the function type (->). You'll be familiar with this from CCCs in category theory. Algebraic data types are sums-of-products.

Yeah essentially discriminated unions. Which is simple enough but I do not still see algebra as fitting.

Quote:
 This is useful because it allows you to do things like calculate when two types are isomorphic and calculate the derivative (as in calculus) of a type to obtain a Zipper.

That is some crazy stuff, made me go dizzy. So many strange concepts and connections, overwhelming. Will take me some time before I can comprehend that. I am actually in the process of self learning type theory.

Quote:
 Regular inductive types subsume sum so it is not built into ML, but product is. Coinductive types like Charity's subsume product, so tuples don't have to be built in either. In categorical semantics, an inductive data type is an initial algebra for an endofunctor and a coinductive type is a final coalgebra for an endofunctor.

Wait. Are inductive data types recursive types? How do inductive types subsume sum? Via simply adding recursion? Then they need not be algebraic. Checking wiki it looks like an "algebraic datatype" is a type formed in terms of some F-Algebra which is in turn defined in terms of an endofunctor which takes a generic X to 1 + X in our category (here X may or may not be formed by a product), hence the initiality in the Category of F-Algebras. Since F-Algebras are generalizations of Universal Algebras which generalize quaternions I can see an analogy from algebraic types to multiplication with integers so the term algebra makes sense here.

They call types formed in that manner algebraic Datatypes. Where do inductive types fit in this? What additional structure do inductive types add to algebraic datatypes

#### Share this post

##### Share on other sites
Quote:
 Original post by DaeraxWait. Are inductive data types recursive types?

Yes. I think 'inductive type' is a synonym for 'algebraic type', although Charity's inductive types aren't quite the same as ML's algebraic types. Algebraic types are inductive and their dual in Charity are coinductive.

Quote:
 How do inductive types subsume sum?

In Haskell syntax:
data Sum a b where  Left  :: a -> Sum a b  Right :: b -> Sum a b

If you have coinductive/coalgebraic types too, then product is:
codata Product a b where  First  :: Product a b -> a  Second :: Product a b -> b

Quote:
 I do not still see algebra as fitting.
How come?

This is the relationship between type theory and category theory as I understand it:

• Types are objects. Functions are morphisms. Type constructors are functors. Parametricity is connected to naturality.

• 1 is the unit type, 0 is the bottom type, * is pairing, + is choice, exponential is the function type.

• An algebraic type is an initial algebra for an endofunctor. It has some construction operations and a fold to destruct it by structural recursion.

• A coalgebraic type is a final coalgebra for an endofunctor. It has some destruction operations and an unfold to construct it by guarded corecursion.

Update: Apparently 'inductive types', as found in Charity are less expressive than full algebraic types in Haskell. An inductive type is a fixed point of a functor, and nested types cannot be expressed in this way. So algebraic types are more expressive than inductive types and coalgebraic types are more expressive than coinductive types.

[Edited by - Rebooted on January 3, 2008 7:01:49 PM]

#### Share this post

##### Share on other sites
Quote:
 Original post by RebootedThis is the relationship between type theory and category theory as I understand it:Types are objects. Functions are morphisms. Type constructors are functors. Parametricity is connected to naturality.1 is the unit type, 0 is the bottom type, * is pairing, + is choice, exponential is the function type.

Yeah but you're interpreting the Type Theory as a Category there or synonymously, constructing a category from your type theory. But the notion of an 'algebra' is still too far for me. As well, a sum of products is just a discriminated union so that doesnt bring the idea of an algebra much close on its own.

Quote:
 An algebraic type is an initial algebra for an endofunctor. It has some construction operations and a fold to destruct it by structural recursion.A coalgebraic type is a final coalgebra for an endofunctor. It has some destruction operations and an unfold to construct it by guarded corecursion.

This is the part I get as I stated in my last post. that algebraic types are constructed/interpretable in terms of an F-Algebra.

So that must mean the term's origin was motivated by categorical concepts?

#### Share this post

##### Share on other sites
Quote:
 Original post by DaeraxYeah but you're interpreting the Type Theory as a Category there or synonymously, constructing a category from your type theory.
Well the way categorical semantics works is by interpreting types as objects and terms as morphisms of some category.

Quote:
 So that must mean the term's origin was motivated by categorical concepts?
I'm not sure.

I know that early versions of ML only had primitive sum and product types and you had to encode everything in terms of them.

Algebraic data types cropped up later, and I don't think they were initially called "algebraic data types". Maybe they were only given the name "algebraic" when category theory started having an influence on PLT and the connection to initial algebras was seen. The dual coalgebraic types were definitely pulled straight from category theory, along with monads.

#### Share this post

##### Share on other sites

• Advertisement
• Advertisement
• ### Popular Tags

• Advertisement
• ### Popular Now

• 9
• 11
• 21
• 10
• 14
• Advertisement