Literate Haskell (.lhs) and Haddock - haskell

At the moment I'm only using Haddock but after seeing some really interesting examples (e.g. this gist) of literate Haskell, I'm interested in trying it out in a project.
The questions I got, are:
What do you write as Haddock comments and what do you write in the literate part?
How do you scale literate programming to multiple files? Can anyone point me to an example where literate programming is used in a package with multiple modules? What is your experience of using literate programming in larger packages?
Which flavour (markdown, latex, ...) of literate Haskell is preferred?
Why are you programming in literate Haskell or plain vanilla Haskell? Are you programming in both styles and if so why?
Do you prefer block-style (\begin{code}) or Bird-style (>)? Why?

I used to write a lot of literate programs.
What do you write as Haddock comments and what do you write in the literate part?
The external API documentation goes into the Haddock comments. Everything else goes into the literate part. "Everything else" might include:
Internal invariants of data structures
Why you are doing things this way
What the design of the code is
Why this design was chosen, what other designs were tried and found wanting
How do you scale literate programming to multiple files?
The same way you scale a large LaTeX document to multiple files: one file per module, then a giant file that \includes them all.
Can anyone point me to an example where literate programming is used in a package with multiple modules?
It's not Haskell, but the Quick C-- compiler is a large functional program that is written using literate programming.
What is your experience of using literate programming in larger packages?
Literate programming works very well for documenting tricky, difficult, or complex modules. For most simple modules, the external API documentation (e.g., Haddock) is enough. And no literate program is really going to give you the big picture of a design that contains more than a dozen modules. For that you need other tools and techniques.
Which flavour (markdown, latex, ...) of literate Haskell is preferred?
If you're making such a major investment, I'd definitely go with LaTeX just because of the math capability, and the generally greater power of the tool.
Why are you programming in literate Haskell or plain vanilla Haskell? Are you programming in both styles and if so why?
My Haskell codes are almost always all plain vanilla, for two reasons:
I work with senior people who have more Haskell experience, and they have abandoned literate Haskell. Only the very oldest modules in their system have any chance of being .lhs.
For Haskell, literate programming is kind of superfluous. One of the big benefits of a literate-programming tool is that you are freed from any constraints that the compiler or language definition might put on the order in which your code appears. But Haskell has almost no such constraints: there's no definition before use, and for a typical function definition I have the choice of let-binding or where-binding auxiliary names (or both). Literate programming was never just about fancy comments, and with "literate" Haskell that's about all you get. It's not worth the bother.
Do you prefer block-style (\begin{code}) or Bird-style (>)? Why?
I strongly prefer block style:
It's roughly compatible with every other literate-programming tool on the planet. (Bird tracks are unique to Haskell.)
My editor copes better with block style.

If you intend to share programs on the internet, I've found a combination of literate haskell in markdown style with mathjax to be a great combination. The program "Pandoc" is seriously brilliant for taking this "markdown+lhs" to any format you desire, including PDF or HTML. If you tell Pandoc to output to HTML, you can use the -mathjax (or other similar flags if you prefer) to have your latex math formulas render.
When using this style, I find bird style to be preferable because it just is more readable to me and seems to fit along with the markdown style better.
The great thing about using Pandoc with markdown is that you can add citations to your code, math formulas, and have a really portable format. You can build something that resembles a scientific research paper but is executable and can also be posted to blogs/wikis/websites.
To give an alternative point to Norman where he says that literate programming is useful for clearer code arrangement, it could be argued that Haskell is expressive enough that the problems you solve with the code are actually interesting and can really benefit by being surrounded with explanatory text. Think of a mathematical research paper. Good papers in pure mathematics have a lot of text to explain the motivation or higher-level interpretations of what the mathematical notation means. In a paper about the Navier-Stokes equations, for example, it would be super useful to surround the notation of the equations with text explaining how it relates to Newton's conservation of momentum.
In summary, I have had good success with, and recommend, using markdown+lhs style, dollar signs to embed latex math formulas, bird style, and pandoc. I would recommend writing programs as if they were research papers and treat the haskell itself as you would mathematical expressions in a research paper.

Related

Where to start reading GHC's source code

I'm trying to learn how various aspects of GHC, like type inference, pattern matching, and other code transformations, are implemented.
However the codebase is fairly large and the file names use a lot of acronyms (simpl, stg, stranal...). What do these mean, and how is the code organized?
As hammar says, the GHC commentary is probably the best place to start for learning about GHC itself. This does assume some prior knowledge of compilers in general, but if your primary interest is in modifying GHC you can probably get by with just a basic CS background.
If you're interested more generally in the principles behind GHC, e.g. if you want to learn how to write your own compiler, you'd probably be better served by perusing Simon Peyton-Jones' myriad publications on relevant topics, including an entire book on implementing functional languages and a "tutorial" book that goes through the implementation of a non-strict functional language.
The GHC commentary is a good place to start.

Is there any Template Haskell tutorial for someone who doesn't know Lisp?

I wanted to learn Template Haskell but all tutorials I find either assume that you learned lisp and know what lisp macros are, or that you know some cs theory jargon - things as splices, quasiquotations, etc... - or some theoretical results about macros.
I can't code a single line of lisp (and, though I intend to do this some day, I don't have the time to learn it right now). Haskell is my very first functional language and I learned it to the point that I can regularly code in it, use monads, applicative, understand the type system, etc... but I don't know much (also want to learn but I'm too stupid for it... :P) about the theoretical cs stuff behind it. So I'm oblivious to the jargon I typically find on TH tutorials.
So, the question is: is there a tutorial about TH for someone who code Haskell, not as a professional computer scientist, but just as a guy who uses programming for his daily chores, who learned Haskell as his first functional language? Maybe a introduction to macros and meta-programming that use TH as example?
Thanks all. :)
No, I don't think there are any great introductory tutorials to Template Haskell. The best way to learn is to look at examples, or:
First stab at Template Haskell
The user's manual
Igloo's paper :: PS
I never found Lisp was a requirement, however there is terminology to learn, like for any domain-specific library.
The best introductory tutorials to Template Haskell I know of are two documents by Bulat Ziganshin. The links from the Haskell Wiki seem to be broken at the moment, however you can access them via archive.org:
TH Tutorial
TH Documentation explanation
Also the original paper Template metaprogramming for Haskell by Tim Sheard and Simon Peyton Jones might be helpful:
Abstract
We propose a new extension to the purely functional programming language Haskell that supports compile-time meta-programming. The purpose of the system is to support the algorithmic construction of programs at compile-time.
The ability to generate code at compile time allows the programmer to implement such features as polytypic programs, macro-like expansion, user directed optimization (such as inlining), and the generation of supporting data structures and functions from existing data structures and functions.
Our design is being implemented in the Glasgow Haskell Compiler, ghc.

Are there any special challenges for functional programming in an embedded environment?

So I'm starting to get a feel for what sets functional programming apart from imperative programming. So like any good convert I'm looking at things with the Haskell hammer and trying to imagine how my embedded programming work could be shaped as appropriate nails for that tool.
So that got me thinking about this question. Is the embedded environment a special case of general computing in the eyes of functional programming or is it just another form of the general case? Is the challenge all in the IO? My embedded work usually entails about 90 - 95% peripheral IO work and the last little bit of stuff being what algorithm work I can fit onto it and still make it back to my IO in time. Does that sort of work make a functional program unsuited to my needs?
Finally, if there are any projects to embedded Haskell projects you could suggest, that'd be greatly appreciated. Thanks.
There are a number of promising projects for bringing functional programming to the embedded programming world.
It seems like a common approach is to take advantage of the type safety and other correctness features of but to abandon heavyweight runtime like ghc. As a result of abandoning the run time, you give up features like garbage collection. Instead, embedded Haskell projects use embedded DSL languages that output real time C code.
Embedded projects using mix C, C++ and Haskell code, rather than being pure functional projects. The C code produced from the Haskell code is not idiomatic C code so collaborators on the project typically need to be familiar with Haskell syntax to participate.
Galois's Copilot project is one the mode extensively documented embedded Haskell projects.
http://corp.galois.com/blog/2010/9/22/copilot-a-dsl-for-monitoring-embedded-systems.html
Copilot uses the Atom DSL which seems popular
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/atom-0.0.2
There is also a moderately active Google Group
https://groups.google.com/forum/#forum/fp-embedded
Personally I found Haskell.Atom quite lacking. It's not functional programming it's an EDSL in a functional language. You are limited to the constructs of that EDSL. No higher order functions, list comprehensions and all the other things that make functional programming so succinct and enjoyable. It may be fun for exceptionally small projects (like blinking a LED) but to me it seems the code you write (not only the generated C-code) will grow exponentially compared to the functionality it provides.
If you want to go the functional route I suggest reading this paper by Malcolm Wallace. It's a bit dated but at least it describes in quite a detail how to do low-level I/O, IRQ-handling and so on in a pure functional language (Gofer, a Haskell-dialect).
Update: There's also a quite new research project with the goal to make a functional systems programming language based on Haskell, Habit. Unfortunately it seems to exist mostly in theory.

What language to learn after Haskell? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
As my first programming language, I decided to learn Haskell. I'm an analytic philosophy major, and Haskell allowed me to quickly and correctly create programs of interest, for instance, transducers for natural language parsing, theorem provers, and interpreters. Although I've only been programming for two and a half months, I found Haskell's semantics and syntax much easier to learn than more traditional imperative languages, and feel comfortable (now) with the majority of its constructs.
Programming in Haskell is like sorcery, however, and I would like to broaden my knowledge of programming. I would like to choose a new programming language to learn, but I do not have enough time to pick up an arbitrary language, drop it, and repeat. So I thought I would pose the question here, along with several stipulations about the type of language I am looking for. Some are subjective, some are intended to ease the transition from Haskell.
Strong type system. One of my favorite parts of programming in Haskell is writing type declarations. This helps structure my thoughts about individual functions and their relationship to the program as a whole. It also makes informally reasoning about the correctness of my program easier. I'm concerned with correctness, not efficiency.
Emphasis on recursion rather than iteration. I use iterative constructs in Haskell, but implement them recursively. However, it is much easier to understand the structure of a recursive function than a complicated iterative procedure, especially when using combinators and higher-order functions like maps, folds and bind.
Rewarding to learn. Haskell is a rewarding language to work in. It's a little like reading Kant. My experience several years ago with C, however, was not. I'm not looking for C. The language should enforce a conceptually interesting paradigm, which in my entirely subjective opinion, the C-likes do not.
Weighing the answers: These are just notes, of course. I'd just like to reply to everyone who gave well-formed responses. You have been very helpful.
1) Several responses indicated that a strong, statically typed language emphasizing recursion means another functional language. While I want to continue working strongly with Haskell, camccann and larsmans correctly pointed out that another such language would "ease the transition too much." These comments have been very helpful, because I am not looking to write Haskell in Caml! Of the proof assistants, Coq and Agda both look interesting. In particular, Coq would provide a solid introduction to constructive logic and formal type theory. I've spent a little time with first-order predicate and modal logic (Mendellsohn, Enderton, some of Hinman), so I would probably have a lot of fun with Coq.
2) Others heavily favored Lisp (Common Lisp, Scheme and Clojure). From what I gather, both Common Lisp and Scheme have excellent introductory material (On Lisp and The Reasoned Schemer, SICP). The material in SICP causes me to lean towards Scheme. In particular, Scheme through SICP would cover a different evaluation strategy, the implementation of laziness, and a chance to focus on topics like continuations, interpreters, symbolic computation, and so on. Finally, as others have pointed out, Lisp's treatment of code/data would be entirely new. Hence, I am leaning heavily towards option (2), a Lisp.
3) Third, Prolog. Prolog has a wealth of interesting material, and its primary domain is exactly the one I'm interested in. It has a simple syntax and is easy to read. I can't comment more at the moment, but after reading an overview of Prolog and skimming some introductory material, it ranks with (2). And it seems like Prolog's backtracking is always being hacked into Haskell!
4) Of the mainstream languages, Python looks the most interesting. Tim Yates makes the languages sound very appealing. Apparently, Python is often taught to first-year CS majors; so it's either conceptually rich or easy to learn. I'd have to do more research.
Thank you all for your recommendations! It looks like a Lisp (Scheme, Clojure), Prolog, or a proof assistant like Coq or Agda are the main langauages being recommended.
I would like to broaden my knowledge of programming. (...) I thought I would pose the question here, along with several stipulations about the type of language I am looking for. Some are subjective, some are intended to ease the transition from Haskell.
Strong type system. (...) It also makes informally reasoning about the correctness of my program easier. I'm concerned with correctness, not efficiency.
Emphasis on recursion rather than iteration. (...)
You may be easing the transition a bit too much here, I'm afraid. The very strict type system and purely functional style are characteristic of Haskell and pretty much anything resembling a mainstream programming language will require compromising at least somewhat on one of these. So, with that in mind, here are a few broad suggestions aimed at retaining most of what you seem to like about Haskell, but with some major shift.
Disregard practicality and go for "more Haskell than Haskell": Haskell's type system is full of holes, due to nontermination and other messy compromises. Clean up the mess and add more powerful features and you get languages like Coq and Agda, where a function's type contains a proof of its correctness (you can even read the function arrow -> as logical implication!). These languages have been used for mathematical proofs and for programs with extremely high correctness requirements. Coq is probably the most prominent language of the style, but Agda has a more Haskell-y feel (as well as being written in Haskell itself).
Disregard types, add more magic: If Haskell is sorcery, Lisp is the raw, primal magic of creation. Lisp-family languages (also including Scheme and Clojure) have nearly unparalleled flexibility combined with extreme minimalism. The languages have essentially no syntax, writing code directly in the form of a tree data structure; metaprogramming in a Lisp is easier than non-meta programming in some languages.
Compromise a bit and move closer to the mainstream: Haskell falls into the broad family of languages influenced heavily by ML, any of which you could probably shift to without too much difficulty. Haskell is one of the strictest when it comes to correctness guarantees from types and use of functional style, where others are often either hybrid styles and/or make pragmatic compromises for various reasons. If you want some exposure to OOP and access to lots of mainstream technology platforms, either Scala on the JVM or F# on .NET have a lot in common with Haskell while providing easy interoperability with the Java and .NET platforms. F# is supported directly by Microsoft, but has some annoying limitations compared to Haskell and portability issues on non-Windows platforms. Scala has direct counterparts to more of Haskell's type system and Java's cross-platform potential, but has a more heavyweight syntax and lacks the powerful first-party support that F# enjoys.
Most of those recommendations are also mentioned in other answers, but hopefully my rationale for them offers some enlightenment.
I'm going to be That Guy and suggest that you're asking for the wrong thing.
First you say that you want to broaden your horizons. Then you describe the kind of language that you want, and its horizons sound incredibly like the horizons you already have. You're not going to gain very much by learning the same thing over and over.
I would suggest you learn a Lisp — i.e. Common Lisp, Scheme/Racket or Clojure. They're all dynamically typed by default, but feature some sort of type hinting or optional static typing. Racket and Clojure are probably your best bets.
Clojure is more recent and has more Haskellisms like immutability by default and lots of lazy evaluation, but it's based on the Java Virtual Machine, which means it has some odd warts (e.g. the JVM doesn't support tail call elimination, so recursion is kind of a hack).
Racket is much older, but has picked up a lot of power along the way, such as static type support and a focus on functional programming. I think you'd probably get the most out of Racket.
The macro systems in Lisps are very interesting and vastly more powerful than anything you'll see anywhere else. That alone is worth at least looking at.
From the standpoint of what suits your major, the obvious choice seems like a logic language such as Prolog or its derivatives. Logic programming can be done very neatly in a functional language (see, e.g. The Reasoned Schemer) , but you might enjoy working with the logic paradigm directly.
An interactive theorem proving system such as twelf or coq might also strike your fancy.
I'd advise you learn Coq, which is a powerful proof assistant with syntax that will feel comfortable to the Haskell programmer. The cool thing about Coq is it can be extracted to other functional languages, including Haskell. There is even a package (Meldable-Heap) on Hackage that was written in Coq, had properties proven about its operation, then extracted to Haskell.
Another popular language that offers more power than Haskell is Agda - I don't know Agda beyond knowing it is dependently typed, on Hackage, and well respected by people I respect, but those are good enough reasons to me.
I wouldn't expect either of these to be easy. But if you know Haskell and want to move forward to a language that gives more power than the Haskell type system then they should be considered.
As you didn't mention any restrictions besides your subjective interests and emphasize 'rewarding to learn' (well, ok, I'll ignore the static typing restriction), I would suggest to learn a few languages of different paradigms, and preferably ones which are 'exemplary' for each of them.
A Lisp dialect for the code-as-data/homoiconicity thing and because they are good, if not the best, examples of dynamic (more or less strict) functional programming languages
Prolog as the predominant logic programming language
Smalltalk as the one true OOP language (also interesting because of its usually extremely image-centric approach)
maybe Erlang or Clojure if you are interested in languages forged for concurrent/parallel/distributed programming
Forth for stack oriented programming
(Haskell for strict functional statically typed lazy programming)
Especially Lisps (CL not as much as Scheme) and Prolog (and Haskell) embrace recursion.
Although I am not a guru in any of these languages, I did spend some time with each of them, except Erlang and Forth, and they all gave me eye-opening and interesting learning experiences, as each one approaches problem solving from a different angle.
So, though it may seem as if I ignored the part about your having no time to try a few languages, I rather think that time spent with any of these will not be wasted, and you should have a look at all of them.
How about a stack-oriented programming language? Cat hits your high points. It is:
Statically typed with type inference.
Makes you re-think common imperative languages concepts like looping. Conditional execution and looping are handled with combinators.
Rewarding - forces you to understand yet another model of computation. Gives you another way to think about and decompose problems.
Dr. Dobbs published a short article about Cat in 2008 though the language has changed slightly.
If you want a strong(er)ly typed Prolog, Mercury is an interesting choice. I've dabbled in it in the past and I liked the different perspective it gave me. It also has moded-ness (which parameters need to be free/fixed) and determinism (how many results are there?) in the type system.
Clean is very similar to Haskell, but has uniqueness typing, which are used as an alternative to Monads (more specifically, the IO monad). Uniqueness typing also does interesting stuff to working with arrays.
I'm a bit late but I see that no one has mentioned a couple of paradigms and related languages that can interest you for their high-level of abstraction and generality:
rewriting systems, like Maude or ELAN;
Constraint Handling Rules (CHR).
Despite its failure to meet one of your big criteria (static* typing), I'm going to make a case for Python. Here are a few reasons I think you should take a look at it:
For an imperative language, it is surprisingly functional. This was one of the things that struck me when I learned it. Take list comprehensions, for example. It has lambdas, first-class functions, and many functionally-inspired compositions on iterators (maps, folds, zips...). It gives you the option of picking whatever paradigm suits the problem best.
IMHO, it is, like Haskell, beautiful to code in. The syntax is simple and elegant.
It has a culture that focuses on doing things in a straightforward way, rather than focusing too minutely on efficiency.
I understand if you are looking for something else though. Logic programming, for instance, might be right up your alley, as others have suggested.
* I assume you mean static typing here, since you want to declare the types. Techincally, Python is a strongly typed language, since you can't arbitrarily interpret, say, a string as an number. Interestingly, there are Python derivatives that allow static typing, like Boo.
I would recommend you Erlang. It is not strong typed language and you should try it. It is very different approach to programming and you may find that there are problems where strong typing is not The Best Tool(TM). Anyway Erlang provides you tools for static type verification (typer, dialyzer) and you can use strong typing on parts where you gain benefits from it. It can be interesting experience for you but be prepared, it will be very different feeling. If you are looking for "conceptually interesting paradigm" you can found them in Erlang, message passing, memory separation instead sharing, distribution, OTP, error handling and error propagation instead of error "prevention" and so. Erlang can be far away from your current experience but still brain tickling if you have experience with C and Haskell.
Given your description, I would suggest Ocaml or F#.
The ML family are generally very good in terms of a strong type system. The emphasis on recursion, coupled with pattern matching, is also clear.
Where I am a bit hesitant is on the rewarding to learn part. Learning them was rewarding for me, no doubt. But given your restrictions and your description of what you want, it seems you are not actually looking for something much more different than Haskell.
If you didn't put your restrictions I would have suggested Python or Erlang, both of which would take you out of your comfort zone.
In my experience, strong typing + emphasis on recursion means another functional programming language. Then again, I wonder if that's very rewarding, given that none of them will be as "pure" as Haskell.
As other posters have suggested, Prolog and Lisp/Scheme are nice, even though both are dynamically typed. Many great books with a strong theoretical "taste" to them have been published about Scheme in particular. Take a look at SICP, which also conveys a lot of general computer science wisdom (meta-circular interpreters and the like).
Factor will be a good choice.
You could start looking into Lisp.
Prolog is a cool language too.
If you decide to stray from your preference for a type system,you might be interested in the J programming language. It is outstanding for how it emphasizes function composition. If you like point-free style in Haskell, the tacit form of J will be rewarding. I've found it extraordinarily thought-provoking, especially with regard to semantics.
True, it doesn't fit your preconceptions as to what you'd like, but give it a look. Just knowing that it's out there is worth discovering. The sole source of complete implementations is J Software, jsoftware.com.
Go with one of the main streams. Given the resources available, future marketability of your skill, rich developer ecosystem I think you should start with either Java or C#.
Great question-- I've been asking it myself recently after spending several months thoroughly enjoying Haskell, although my background is very different (organic chemistry).
Like you, C and its ilk are out of the question.
I've been oscillating between Python and Ruby as the two practical workhorse scripting languages today (mules?) that both have some functional components to them to keep me happy. Without starting any Rubyist/Pythonist debates here, but my personal pragmatic answer to this question is:
Learn the one (Python or Ruby) that you first get an excuse to apply.

Logical Languages - Prolog or Lisp/Smalltalk or something else?

So, I am writing some sort of a statistics program (actually I am redesigning it to something more elegant) and I thought I should use a language that was created for that kind of stuff (dealing with huge data of stats, connections between them and some sort of genetic/neural programming).
To tell you the truth, I just want an excuse to dive into lisp/smalltalk (aren't smalltalk/lisp/clojure the same? - like python and ruby? -semantics-wise) but I also want a language to be easily understood by other people that are fond of the BASIC language (that's why I didn't choose LISP - yet :D).
I also checked Prolog and it seems a pretty cool language (easy to do relations between data and easier than Lisp) but I'd like to hear what you think.
Thx
Edit:
I always confuse common lisp with Smalltalk. Sorry for putting these two langs together. Also what I meant by "other people that are fond of the BASIC language" is that I don't prefer a language with semantics like lisp (for people with no CS background) and I find Prolog a little bit more intuitive (but that's my opinion after I just messed a little bit with both of them).
Is there any particular reason not to use R? It's sort of a build vs. buy (or in this case download) decision. If you're doing a statistical computation, R has many packages off the shelf. These include many libraries and interfaces for various types of data sources. There are also interface libraries for embedding R in other languages such as Python, so you can build a hybrid application with a GUI in Python (for example) and a core computation engine using R.
In this case, you could possibly reduce the effort needed for implementation and wind up with a more flexible application.
If you've got your heart set on learning another language, by all means, do it. There are several good free (some as in speech, some as in beer) implementations of Smalltalk, Prolog and LISP.
If you're putting a user interface on the system, Smalltalk might be the better option. If you want to create large rule sets as a part of your application, Prolog is designed for this sort of thing. Various people have written about the LISP ephiphany that influences the way you think about programming but I can't really vouch for this from experience - I've only really used AutoLISP for writing automation scripts on AutoCAD.
At the risk of offending some, I have a hard time reconciling "easily understood by other people that are fond of the BASIC language" with any of the languages you mentioned. That's not intended as a criticism, but as an observation that each of the languages you mention has a style and natural idiom that's quite different from that of BASIC.
Smalltalk - pure OO from the ground up, usually (e.g. Squeak) coupled with an integrated environment that is simultaneously the IDE and the runtime. IOW you enter the Smalltalk VM and work inside it rather than just writing a text that is "source code".
LISP - much closer to functional programming (although with imperative overtones); the prefix notation is the first barrier to most people who "like" other languages, but the concept and use of macros is a much more substantial one.
Clojure - The combination of LISP, OO, and JVM integration makes this one even less BASIC-like.
Python and Ruby - I lump these together (at the risk of further annoying fans of either ;-) because they are both OO language with distinct notations that will take an outsider a bit of learning curve. The use of indentation-only for control nesting in Python and the Perl-like use of special characters in Ruby are often points of the complaint by newcomers. Although both can be written in an imperative style, that would be considered non-standard by seasoned users.
Prolog - This is the most unlike BASIC of all languages mentioned. All of the other languages you mentioned can be (ab)used in a semi-procedural style, but that is essentially impossible in Prolog. It requires a thorough understanding of, and comfort with, recursion to do anything non-trivial.
Code written with a "native accent" in essentially all of these languages (but especially Prolog, IMHO) will make use of idioms and concepts that are outside the norm for conventional BASIC programming. Put another way, if you pick one of these and then write code "with a BASIC accent" you've pretty much wasted the benefits that the language can offer.
I believe that all of them are worth learning for the concepts they can teach (or at least reinforce, depending on your background). But the similarity to Language X (for a wide range of values of X) is not what you'll get.
I can answer you partially
(aren't Smalltalk/Lisp/Clojure the same? - like python and ruby? -semantics-wise)
No, it is not. Smalltalk is OO language with message pass instead method calls. Lisp is Lisp ;-) It means truly functional language with the powerful macro system, OO support which is never seen in other languages (in CL) and many more features. Closure is Lisp-like language without many Lisp features but good integration to JVM. It's not supporting tail call optimization for example. And python or ruby are classic imperative OO languages with some limited functional ability. Note word limited. For example, Guido doesn't like functional programming and removed some functional features in version 2.5 and 2.6.
If you familiar with imperative procedural programming as in Python and you want to change your paradigm you should make your decision carefully.
Prolog is a very different language. It can be very hard to grasp, mainly because it relies heavily on recursion to do very basic tasks. If you are really willing then give it a go. It can be very powerful because it allows to expess relationships and solve complicated problems simply, typical examples are Towers of Hanoi or quicksort. It will change the way you think, which can be difficult if you are used to imperative languages.
If you're interested in Prolog then there's a free version of Visual Prolog available and the commercial version is reasonably priced.
It's a strong type offshoot of Prolog so isn't your classic implementation of the language, but has a respectable history - Borland marketed the DOS ancestor of it as Turbo-Prolog back in the late '80s.
It's also Windows only, but can be used to create standard Windows DLLs so you can link your code into a 'normal' windows programming language. I've never used the package in anger myself, but I did a couple of Prolog courses at Uni so have downloaded it from time to time to play with and look for possible uses and it looks solid enough. Might be just the set of cogs you're looking for.

Resources