Various questions

[Aaron J. Seigo]

On Friday, July 25, 2014 14:29:23 Ivan Čukić wrote:
> One additional thing that we'll need to cover at some point is ffi - the way

Yep.

> to call the C code. (I'm guessing that at this time you're relying on Qt
> meta- object system?)

That will be one bridge that needs to be in place, but that's a VM thing 
rather than a language level construct .. and making those metaobjects behave 
reasonably like functional objects will be interesting.

I do think it makes sense to allow calling out into C/C++ code directly (too 
many useful libraries out there..) and is something I'm still researching. 
This wouldn't be very complicated if it weren't for the process, variable and 
memory models. :)

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

I'd like to avoid custom operators due the complexity it can land the user in. 
The idea of being able to avoid hard-coding the message send operators is 
reasonable, though. Would have to think about how exposed such a feature would 
be (or need to be) and the impact it would have at compile- and run-time

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

+1

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

Yes, this describes the order of operations in the syntax .. but the order of 
the human reading it is still LTR, even with std::out. I'm trying to optimize 
for developer reading direction and don't quite care as much for notation 
order. I suspect that the "odd" operator order of iostreams (right-to-left) 
was motivated by this same principle: the developer reads from left-to-right 
the order that things will appear. 

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

This is true; but I'm more concerned about getting people to use funq in the 
first place.

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

Look forward to it :)

-- 
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/a196ec95/attachment.sig>