Various questions

Fri Jul 25 11:47:49 UTC 2014

On Friday, July 25, 2014 11:50:15 Ivan Čukić wrote:
> Hi Aaron,
> 
> > Variables are single-assignment (you can't assign a different value to a
> > variable once it is set) and typing is inferred (but not dynamic, due in
> 
> One of the things you always mentioned is that one of the most important
> parts of the project statement is 'what this is *not*'. So, I guess we
> should discuss it for this project as well.

Agreed ...

So far I've been working with these "nots":

* It is not meant to be a perfect functional language with all the bells and 
whistles. Simplicity in learning and use trumps complex features. A "proper / 
complete" functional language takes too much learning investment and would, I 
fear, produce an odd mix in a combined C++/QML/funq project.

* It is not meant to be the absolutely fastest runtime out there. While I am 
confident it can be better than, say, Erlang's performance when it comes to 
numeric code and string handling, the goal is not to compete in head-to-head 
benchmarks with C++ or Java. It just has to be performant enough to allow 
typical end-user applications to run smoothly on small-ish devices (e.g. a 
hig-end modern smart phone or a low-end netbook). Scientific computing this is 
not :) So when usability or other pragmatics threaten performance by a few %, 
that's ok.

* It is not meant to be separate from Qt. Using Qt will make a *lot* of things 
much easier in the implementation phases, such as not needing to write our own 
platform independent networking code. Since it is also a goal to make using 
funq with QML natural and enjoyable, we need permission to make the design 
work well for that use case even if it means reducing how "generic" the 
language is for use without Qt.

(As with everything else at this stage, these are not set in stone; they are 
simply what I've been using so far to guide me)

> BTW, is funq going to have an introductory page somewhere?

There is also the README.md file in the top level, but it's very conceptual 
rather than providing an actual introduction. 

There is docs/core_principles.md which is also not really a proper 
introduction but a summary of pages of brain dumps in my paper notebooks. (I 
probably need to go over that document again at this point to make sure 
everything in there is still accurate)

A proper introduction page is needed, but I've working "backwards" towards 
that so far. After lots of sketching and notes on paper, I started with a 
fairly random collection of syntax examples and kept massaging them until they 
didn't look completely like mutant horrors, then started "documenting" the 
syntax with natural language (in the docs/ directory) which led to much more 
mutant-removal .. eventually things will be settled enough that a proper intro 
page can be done. Hopefully sooner than later ...

> And now, a set of completely unrelated questions:
> 
> 0. The desired features should be separated into the core language features,
> and those provided by libraries. That way, we are not going to end up with
> a language that is good only for one thing.

Absolutely. The language itself should be very sparse and relatively 
featureless, with libraries providing everything that is "actually useful" 
such as displaying/logging output (e.g. for debug/warnings), networking, file 
access, database querying, etc.

The core features I want to see in the language include:

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

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

If anyone has anything to add to that list of core features, now is a great 
time :)

As for user tinerface, as far as I'm concerned that is QML. funq needs to have 
excellent support for defining and mutating QAbstractItemModels which will be 
one of the primary bridges between funq and QML. The other main bridge will 
have to come in the form of a funq<->QmlItem bridge ... I haven't gotten to 
fleshing out specifics of that, and so only have a vague idea of what it what 
will be required to allow (for instance) properties in QML to be bound to 
values that are set from funq code.

> 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 ...

That isn't to say it won't happen later, I just want to see how far we can get 
without the complexity of one. 

> 2. Algebraic types definition and support (basic structures like {string,
> string} only go so far)

Things I know will be in funq:

* Lists with members of variable type
* Structs .. er .. records :)

I have not yet gotten to defining how the latter will look yet. I called them 
"struct" since that is hopefully more familiar to C/C++ people than "record", 
but a rose by any other name ....

Algebraic types are an underspecified area of funq so far as I've been focused 
on base language syntax and the process model so far. If you want to take a 
swing at this and come up with a syntax draft, that'd be awesome :)

> 3. This one could have gone into the syntax discussion
>  Why is the receiver of a message on the right side? I do get that it can be
> 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 
keeps things simple due to consistency: you can read every line using the same 
reading direction and see what the code is doing one "word" at a time.

When directionality changes based on the operators or purpose of the code, one 
needs to first look at the whole statement and then choose their direction of 
reading. This may not sound like much to ask, and personally I got very used 
to it with the various functional languages I've been kicking around this 
year, but the difference in ease of use that comes from a consistent read 
direction became evident to me in early testing with people.

This seems to be a matter of habituation rather than a real human limit. 
(There are even human writing systems where the read direction changes; e.g. 
words are written one direction and numbers the other!)

So originally I had funq with the "usual" direction for message passing 
(receiver on the left, sender on the right) and comprehensions (value on the 
left, source list on the right) .. but found it was much less clear to those 
coming from a C/C++ type background . Simply reversing the direction made it a 
lot more obvious .. and since "learn it quickly, feels as familiar as 
possible" is an important goal for future adoption rates, I went with a 
consistent LtoR read direction even though it is not consistent with what 
functional languages usually do.

> 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?

> 5. I'm spoiled by \x -> body (haskell) and (arguments) -> body (like in
> coffeescript) something for lambda definitions. fun(...) { } seems like an
> javascript-inspired overkill.

You have no idea how many times I've done a global replace of "func" with "" 
in my text editor ;)

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.

I'll take this to a new thread.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://kde.org/pipermail/funq-devel/attachments/20140725/b8f995f2/attachment.sig>