Various questions

[Ivan Čukić]

> So far I've been working with these "nots":
+1 for the items

> * It is not meant to be separate from Qt. Using Qt will make a *lot* of
This one I don't really like all that much, but the reasons behind it are 
sound and I will not complain :)

One additional thing that we'll need to cover at some point is ffi - the way 
to call the C code. (I'm guessing that at this time you're relying on Qt meta-
object system?)

> * first class functions (obviously :)
> * pattern matching and comprehensions
> * processes
> * message queues
> * unit testing framework

 +1

> the usual bookkeeping details of operators, module definition, etc. need to
> be there as well but those are syntactical requirements rather than
> "features".

Custom operators? (so that the message sending operator is not a hard-coded 
into the language syntax, for example)

> > 1. What is the type definition syntax going to be like
> 
> I'm trying to see if it is reasonable to get away without having a complex
> system for this. Haskell's data, for example, is wonderfully powerful but
> also low on the "intuitive" scale for those coming to it from a
> non-functional background.
> 
> If it is possible to get away with just algebraic types and not have a full-
> fledged type syntax that would be wonderful in terms of simplicity. So thus
> far I've been avoiding it altogether ...

We could do something like - define C-like structs, and go for a Either(Int, 
Float, SomeError) as an algebraic type replacement.

> > considered as a more natural way, but since most existing systems are the
> > other way round (erlang, akka, haskell-distributed), I'd advise to follow
> > the established practices.
> 
> tl;dr -> this is because the target audience isn't people who use functional
> languages but people who write in C++.
> 
> This is actually something I consider to be a usability problem with those
> languages.
> 
> In the Algol family, pretty much *everything* is read left-to-right. This

Well, this is debatable.

"Tell Aaron to go pick up the kids" is a completely normal sentence.

The usual object notation of car.turnOn is essentially a message turnOn sent 
to the car. That is, "tell the car to turn itself on", or car ! turnOn, or 
std::cout << "message".

Personally, I can get used to either. But the reason I'm advocating the 
standard approach is simple - it will be easier for funq devs to switch to 
some of the others, and vice-versa.

> > 4. In order to have a simpler parser (and not 3-passes-or-more like
> > khm++),
> > I think it would be wise to prefix function definitions with a keyword,
> > the
> > same for 'variables' and such.
> 
> Can you provide an example of this that would work for you?

I'm currently thinking of a function/lambda definition syntax that would be 
able to cover a lot of evil things. Will post it separately when it is 
finished.

> I have tried "(params) { body }" and people coming from C++ / Java / PHP /
> Javascript etc. seem to get confused by it. Personally I'd prefer the "(..)
> {...}" syntax, but was scared off of it by the results of that testing.

Agreed.


Cheerio,
Ivan


KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ 
gpg key id: 850B6F76, keyserver.pgp.com