Function definition

[Aaron J. Seigo]

On Saturday, July 26, 2014 11:43:27 Ivan Čukić wrote:
> On Saturday 26 July 2014 00:54:33 Aaron J. Seigo wrote:
> > each thing does one thing.
> 
> Except for the equality sign. Is using the same tokens in different places
> that much of a problem? (irrelevant of return type and ->)

The equality sign is a "comparative assignment" operator, so it actually does 
just one thing, though that one thing is a compound action. While it is 
probably unavoidable to have every single operator do just one thing*, the 
more instances of that we avoid the better for the developer.

* conceptually one thing; the '+' operator will be associated with multiple 
operations, technically: 1 + 2, "string" + "concatenation"

> > I do like optional typing of parameters; it adds to the pattern matching
> > capabilities and removes the need to use ugly precondition clauses for it
> > instead. It doesn't really add anything but clarity. So ... added :)
> 
> It adds clarity, and saner compiler messages. Just think of duck-typing
> produced template error messages in C++ (essentially a back-trace of
> executing a template meta-program), as opposed to a regular early bailout
> for an unmatched argument type.

Yeah, very true.

> > want to actually handle that rather than generate another error because
> > the
> > error doesn't match the declared type of a? This path will lead us to
> > "auto" ;)
> 
> I prefer compiler errors to the runtime ones.

I do as well ...

> Library writers will want checks, if the ordinary users will not.

OK, I'm convinced :)

Optional type declarations. Prefixed, however, to make it kind on C++ 
developers. With no type being equivalent to auto.

> > already clear that it is an integer (e.g.). One of the real downsides of
> > 
> > explicit typing is one then needs to track the history of every 
assignment:
> > 	let int a = foo();
> > 
> > does foo() return an int? should we care? what if it returns an error and
> > we
> What if we don't want to handle the error, and do an early bailout if the
> returned thing is not of a required type. 

Early baillout == crash of process

"Let it crash" is a positively awesome way of developing imho as it gets away 
from defensive programming altogether. *But* it means you have to allow the 
developer to write reasonably flexible code so that errors are not created too 
easily.

> > Do prefix tags cause ambiguities that will get in the way of parsing?
> > Every
> > use I've tried thus far seems unambiguous, but maybe I've missed some
> > cases.
> 
> Not ambiguities (at least, I don't see them) - more of a compiler speed
> issue. 

Given the systems that are used for compiling and the simplicity of the rest 
of the syntax, I'm not too worried about this. If the speed is simply not 
suitable, then we can change the placement.

Ah .. perhaps I'm leaving out an important detail here: while this absolutely 
must have a REPL, applications should be compiled to bytecode for deployment. 
I don't want to build an interpreted language, so compile-time is a one-time 
thing and probably happens before the application gets to the user.

Of course, having compile times as close to zero as possible makes for a 
better developer experience and that is an area funq could end up providing a 
better experience of over C++, which could draw developers in. (I would 
actually like to see compile cycles be implicit actions during development: 
either when a file changes on disk or a load-this-file command hits the REPL 
compilation will happen automatically)

So my opinion on this is: let's try and keep it familiar to C++ people and if 
we find that the way to get the needed / desired compile speed is to mess with 
the ordering, then we can do so then.

I fully expect to have a couple releases of the compiler before committing to 
syntax, let alone backwards compatible bytecode.

-- 
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/20140726/1fbeb574/attachment.sig>