But, there's nothing wrong with trying. :-)

Since you stated that unification -- when done correctly -- is powerful, do you know of any web resources that discuss or explain the proper way of implementing the feature?

...or maybe a good book? I'm thinking of purchasing either Modern Compiler Design since it has sections on functional and logic based interpreters, but the reviews of it [on Amazon] are fairly mixed. Any suggestions?

-Steven

Without any knowledge of both Prolog and Haskell:

I want to point you to the Ruby language.

Its a very high level OO language and takes the best of perl, python, java and a couple of others. Ruby has no primitives (like java), everything is a objekt. It allows the overloading of signs (+/-/*) and has extremely powerfull iteration constructs (maybe compareable to Haskell's). There are implementations for all noticeable platforms and also a Java port (JRuby). One subproject tries to put Ruby on top of the proposed Perl6 VM. Even without it: Ruby can use perl modules without hassles.

...just my 2 cent.

Ruby may work, but Haskell and Prolog both work on different paradigms than standard structured languages like Perl, Python, etc.

With Prolog, you basically give it a "knowledge base", ask it questions, and let it infer what is true or various relationships. The programmer doesn't have to mess with implementation details such as how to search through the knowledge base or match queries. You just give it what you want to find, and it does the rest.

Haskell works in a ... similar fashion [in regards to avoiding messy details], but allows the programmer a lot more flexibility when defining functions. For example, I am sure you have played with or have seen an implementation of quicksort in some structured language; a nice ugly mess. Here is quicksort in Haskell:

quickSort [] = []
quickSort (x:xs) = quickSort [y | y <- xs, y < x] ++ [x] ++ quickSort [y | y <- xs, y >= x]

Two lines that are fairly easy to understand. ^_^

My initial goal is to merge the strengths of the two languages that I think are most useful: the inferencing ability of Prolog; and, primarily, the list comprehension features of Haskell. If I can build an interpreter that manages the above, I will start adding more features from each language.

On the other hand, Ruby could be used to make an implementation of the interpreter. That might make an interesting project one day. :smirk:

-Steven

Perhaps you should read about the Constraint Logic Programming paradigm, it could give you some nice ideas to include in your language. It is a more powerful reasoning method than Prolog's, basically consists in a branch&bound depth-first search with forward-looking and intelligent backtracking.

Constraints look very interesting and seem like they would fit in as an interesting component. Just to make sure I understand what you're thinking, take a look at the following and let me know if it fits with your thoughts.

Let me think of a trivial example and some syntax. Hrmm... Never using that paradigm before, it is difficult for me to think of one. Well, I will have to do some programming in a language like Eclipse before I can implement something like that. Maybe a feature for version 2?

If I understand correctly, constraints define variables based on their relationship with other variables. Is that right?

As far as implementing the language goes, I plan on reading some in-depth material about both the Warren and Vienna Abstract Machines this weekend to fine tune my thoughts.

-Steven

Constraints are best used with multi-valued variables, i.e. variables with domains bigger than 2. First you define which variables exist and which are their domains, and then you add constraints that forbid some combinations of values to occur simultaneously.

A trivial example? Suppose you have two series A and B of "nucleotide" variables: A1 A2 A3 A4 ... and B1 B2 B3 B4 ... Each of this Ai and Bi variables have the same domain = {adenine, thymine, guanine, cytosine}.

Then you want to match the two series and add a "base pair" constraint between variable A1 and B1, another similar constraint between A2 and B2... Each constraint allows the variables to take only these value pairs: (Ai=adenine, Bi=thymine) (Ai=thymine, Bi=adenine) (Ai=guanine, Bi=cytosine) or (Ai=cytosine, Bi=guanine). All these constraints are equal except for the variables involved.

So if you later assign Ai with value adenine, you can propagate the constraint and prune from Bi the values adenine, guanine and cytosine which are not supported. In this example this leaves you with only 1 value left in the domain of Bi so you can also assign Bi with the value thymine.

If you ever reach a state with an empty domain, for example if Bi was previously decided not to be thymine, you have to backtrack and erase the decision to assign Ai with adenine.

Note that if later in the program you want to try and match the chain A with B shifted one place, i.e. clean the constraints Ai-Bi and put a new constraint between each Ai with B(i+1), then it is a different "constraint problem" and you have to restart the "constraint solver" procedure - the information gathered through the previous solution search is no longer applicable to this new problem.

That was the perfect example for me; thank you so much. I now understand what constraints are and how useful they can be. My mind is now in a similar state to when I first learned of functional programming after about seven years of imperative programming. Wow. :satisfied grin:

Tomorrow I present my project to the chair of the Computer Science Department for final approval. Methinks that adding constraints to the language will make an excellent project for the summer or fall semester.

On another note, does the syntax of the language bother anyone? Specifically the fact that a predicate can return a list? I'm afraid that some people -- especially those with a strong Prolog background -- may find that notion uneasy.

Thanks again!

-Steven

Note that your language contains both predicates and functions. A clever idea would be to cleanly distinguish them.

You can define a Boolean type for predicates, and a typecast from empty and non-empty function returns to boolean. The typecast may be implicit (maybe in the :- operator?) or explicit.

I was thinking about that as I lay in bed this morning. My initial idea was to allow predicates to return lists, but my teacher was having trouble with that. So I started thinking of implementing predicates as a boolean function [easily definable in Haskell] with the ability to unify with other predicates, which actually seems to be easier from an implementation standpoint.

Boy, aren't the things I think about in bed oh-so interesting? :rolleyes:

-Steven