au miau <squeak at abv.bg> wrote:
	i find [Haskel]] implementation too complex (i'm possibly 
	wrong but it seems to me like PL/I of functional
	programing )

As a Haskell programmer, Haskell *implementation* is none of my business.
(For complex, take a look at GCC some time.  And that's simple compared
with a top line commercial C compiler.  Then go away and have nightmares
about Fortran 95.)  Haskell is a very small language compared with PL/I
and is vastly simpler to *use*.

Of particular note is that there is no "Haskell VM".  Of the four Haskell
systems on my machine, two have VMs (different ones) and two don't.  For
a similar language, Clean, there has never been a VM, it's native code only.

I once used to use Poplog.  (In fact, there's still a Poplog system on my
machine, as part of the SPARK static checker for highly safe Ada.)  That
had Pop-11, Prolog, Common Lisp, and ML all in the same box calling each
other with native data structures.  It was quite well engineered, but the
Prolog performance was stunningly bad compared with Prolog-only systems.
You could even mix languages in a single source file.

Many Prolog programmers these days use Emacs as their development
environment.  They don't expect Prolog and Emacs lisp to run in the same
address space.  They expect Emacs to do its thing in one address space and
send messages to a Prolog system in another address space.

Prolog shares with Lisp and Smalltalk and Pop-11 the fact that it's a
dynamic language.  The system expects you to add and change code even
while a program (to the limited extent that such a thing exists) is running;
it expects to have to support fix-and-continue debugging.

Haskell is not in that spirit (although Hugs and hbi try to provide a
sort of ersatz REPL).  Haskell is an edit/compile/run design, and it is
not an optional aspect, it's built into the type system (although not quite
as strongly as it is in Clean).  It is also an important aspect of Haskell
(and Clean) that every part of the program is type checked to make sure it
all fits together.  Without having an Object type which the "Haskell" code
could do little or nothing with, it's hard to see how to integrate Haskell
and Squeak semantically.

If someone wants a functional language embedded in Squeak, ML would be
a better (call by value, strict execution order, has exceptions that aren't
too complicated to fit into Smalltalk) fit except that it also is strongly
statically typed, making it a poor fit for Smalltalk.  (How well it could
fit into StrongTalk I know not.)

A Scheme or Lisp dialect could fit quite nicely.
Scheme has Boolean (#t #f), numbers similar to Smalltalk, vectors similar
to Smalltalk Arrays (except for being 0 origin), '() empty list which
could be nil, symbols (which are distinct from strings, but we could work
around that), and pairs (which are just another class, right? and not a
large one at that).  The one thing Scheme has which could be hard is
full closures, but then there's the BC work in Squeak which would fix that.

Continuations are the thing that Scheme has which would not fit into
Squeak without a great deal of work, but "escape continuations only" is
a fairly common Scheme implementation restriction; many Schemers could
live with that.

I'm not sure what you'd do about Scheme's "hygienic macros", which are
_extremely_ useful.  They do imply a file-based "compilation" approach.
Perhaps they could be attached to classes somehow.

The big problem in all of these things is *NOT* switching from one VM to
another, but finding a way to coherently integrate the *semantics* of the
languages involved in a way that preserves the strengths and character of each.

An approach that might be rather less work would be to build IDE tools
in Squeak but to run the actual other-language code in another process.