bkil vs. programming

I've minified  bkil-open: edu/ai/nanochess.hs  to 19 effective lines of code in Haskell, and I'm running out of ideas. The goal was to construct a tiny snippet of code that illustrates a real chess engine instead of the ever boring 8-queens. It still wouldn't fit on a black board properly without further pruning. At the same time, trivial concurrency has been introduced to bkil-open: edu/ai/minichess.lhs , which seems to give it a linear boost. My next step in the area is to add interaction and eventually introduce a more advanced algorithm like alpha-beta to gain playable speed on a full board with complete rules.

Do you prefer laziness or ease of compiler implementation and proof of correctness? Haskell feels very comfortable to me, and I can write some beautiful code in it. Laziness could introduce some complexity to reason about temporary memory usage. It's the same reason I like Erlang: quick, dirty, but also elegantly minimalistic and predictable. I haven't tackled OCaml ( yet ;->). Do you think it worths it? OCaml vs. Haskell discussion at Y-Combinator Haskell performance is on par with OCaml (shootout.alioth.debian.org) do note, that the Haskell compiler and solutions have evolved since then

Because of popular demand, I have ported the previous example to Erlang using it's built-in GS package. Enjoy! :-D All code and text in this post is Copyright (c) bkil.hu [also known as bkil], 2009; and is licensed under the GNU GPL v2. Refer to the standard license texts from June 1991 for exact conditions. Here is an example link: http://www.gnu.org/licenses/gpl-2.0.html Here's the core (simbins.erl): -module(simbins). -export([radix/3, binaries/2, simbins/1]). %% Radix conversion with LSB output. radix(_,0,_) -> []; radix(R,W,N) -> [N rem R | radix(R, (W-1), (N div R))]. %% A full-matrix transpose stub. transpose([H|T]) when is_list(H) -> Append = fun(V, M) -> lists:zipwith(fun(E,L) -> [E|L] end, V, M) end, Vector = fun(L) -> lists:map(fun(E) -> [E] end, L) end, [RH|RT] = lists:reverse([H|T]), lists:foldl(Append, Vector(RH), RT). %% 'binaries' is a solution to Paul R. Potts's idea. %% Prepend `lists:reverse( ` to get MSB. bi...

I've been browsing Mr. Paul R. Potts's blog when I stumbled across a simple, yet neat idea. I was not quite satisfied with the lengthy solution given, so I decided to construct something similar looking from scratch. I'm using the Hugs and GHC built-in HGL/Graphics.SOE package. See the result below. Expect to see more later. All code, text and the 5 images in this post are Copyright (c) bkil.hu [also known as bkil], 2009. I place the images in the public domain. The code and text are licensed under the GNU GPL v2. Refer to the standard license texts from June 1991 for exact conditions. Here is an example link: http://www.gnu.org/licenses/gpl-2.0.html Here's the core (Simbins.hs): module Simbins where import Data.List(transpose) -- Radix conversion with LSB output. radix _ 0 _ = [] radix r w n = (n `mod` r : radix r (w-1) (n `div` r)) -- 'binaries' is a solution to Paul R. Potts's idea. -- Prepend `reverse . ` to get MSB. binaries w = transpose . map (radix ...

A friend of mine has developed a new LISP-like language to assist in constructing lazy algorithms and the like. He also gives some examples like Peano axiomatic integers. Here's the link: http://gergo.erdi.hu/elte/2008-1-haskell/clazy/

I find people who are fluent in specialized and high level languages to have written interesting articles and done nice projects with a much higher probability than the average. :) Anyway, my current interest is in how you can define GUIs with functional languages. I have done a web search recently on the topic but have to sadly acknowledge that the ones of the highest abstraction level are not currently of production quality. Maybe it would be best to hack some functions of my own fulfilling my needs and opt for wxHaskell. Does it worth it? I need to give it a try. http://web.cs.wpi.edu/~cs4536/c06/Assignments/hwk2.html nice functional programming assignments http://www.lassila.org/blog/archive/2006/05/fun_with_lazy_e_1.html working on LISP laziness http://common-lisp.net/project/clazy/ LISP laziness project http://www.haskell.org/haskellwiki/Stack_overflow laziness is not always a bliss http://web.cecs.pdx.edu/~mpj/cs557/week07.pdf Mark P. Jones: "Lazy Evaluation: Strict Ev...

Well, actually it is, but never mind. :) At first, I thought one had no choice but to migrate to Haskell or Clean if in a need for programming in an elegant manner. Fortunately, I since then have found some languages that would also do the trick. I plan to review most of these based on some criteria, preferably through a real-life problem set. Maybe I will initially base my research on the ready-made solutions found at the great language shoot-out game. As you probably already know, Haskell (and Clean) allow the expression of deep thoughts with very conscious syntax (and semantics) for most domains. Erlang is also nice, though a bit LISP-like on the syntax side (read: crude). I still need to learn a few more languages that are said to be pretty interesting. As I've heard OCaml (ML) and maybe Python could be good candidates. Now, before you come up with the valid argument that powerful language-extending features and Turing-completeness make this a non-issue, I am not sure if I woul...

This is nearly a trivial project, really. However, I do plan to achieve the most general implementation feasible. What needs to be done are the following. * Internal representation of the game state (board, turn); * Presentation to the user (only coordinates at first); * Input from the human player (coordinates); * Generating valid steps for the AI (simple enumeration at first); * Heuristic function for the AI (something wired-in at first); * AI core: minimax at first, alpha-beta with some simple ordering and pruning later on; * Simple interface that enables a GUI at a later date.

I made a few functional oriented and list processing functions for bash. Nothing serious, and it's very slow for practical use. Profiling tells that the head and tail operators are the bottleneck, so forking them off to a different process would help. Though I don't feel an urge to update it that way, as this was made just for the fun of it! Another upgrade would involve updating the free form recursive data structure to something faster, or doing less and/or faster conversion. A last resort would be writing hard-coded implementation for the core functions like map, foldl and filter. I also have the choice of moving to the very powerful (and speedy) Bash syntax. These are all viable, but would degrade the elegance of the library as a whole, so I'm hesitant to apply them. And don't forget, that it's a much more sane solution to embed O/S functions, or even a full-blown bash into a fully capable language, instead of the other way around. I've been thinking along t...