
Ravi – Lua 5.3 with optional static typing - johlo
http://ravilang.github.io
======
cmrdporcupine
If a type system can be easily escaped, does it really offer you much?

If it's still transformed to run in the runtime of a late-bound dynamic typed
language where the types can't be used by the compiler to produce optimized
code with early-bound type function/method dispatch, does it really offer you
much?

I guess I don't really see optional static typing as giving the best of both
worlds, as it cannot deliver on what a good static type system can give you.

~~~
SwellJoe
Perl 6 has gradual typing that _is_ used for optimizations at run-time. So,
it's possible to use optional types for optimization (even if this particular
implementation doesn't do it yet). And, it sounds like that's actually the
purpose of this project from the description. It doesn't even seem like it's
trying to add types as a method of avoiding errors.

And, the benefits of typed languages aren't necessarily all or nothing, and
they aren't all performance-related. There are many kinds of error that can be
revealed by adding type checks to a program, and just like adding more unit
tests to an existing program can reveal existing bugs, adding type information
could do the same (with arguably less tedium than writing basic unit tests
just to confirm something is behaving correctly with a variety of input).

If I can choose to add types to my function rather than writing unit tests
that test a bunch of different data inputs, I would definitely prefer to add
types. (Now, in the case of some type systems, like Perl 6, you can go crazy
with bounds and other things within the type system itself...so you can not
only say a function receives an Int, it can also say it receives an Int in the
range of -1...43, and nothing else is acceptable). Types are certainly more
fun than fuzz testing everything.

None of those benefits require a program to be all-in on having typed data.

~~~
chenglou
How does Perl's bound check work? If it's compile time then wouldn't you need
some form of dependent types?

------
bitmadness
This is interesting, but the benchmarks suggest that LuaJIT usually does as
good, if not better. So there doesn't seem to be much benefit to the static
types, at least performance-wise.

~~~
sundarurfriend
Yeah, and the page itself further mentions additional benefits that LuaJIT has
that Ravi doesn't, putting LuaJIT even further ahead. As an outsider to Lua, I
assumed I was missing additional context (eg. limitations in applicability of
LuaJIT maybe?) that necessitates the existence of Ravi.

~~~
sitkack
One reason to use (potentially) Ravi over LuaJIT is that LJ has a 2GB memory
limitation.

------
hellofunk
I often wonder if the whole idea of "typing" is the wrong decision in language
design, if we shouldn't come up with something better. Dynamic languages are
often trying to insert some form of typing. Static languages are often trying
to inject tools for heterogenous collections. It's clear there are advantages
to both approaches, yet a languages is usually definitely one or the other,
which seems limiting. Not that I have a solution, but perhaps breaking
programs into primitive types or lack thereof isn't the right approach to the
abstraction.

~~~
naasking
> I often wonder if the whole idea of "typing" is the wrong decision in
> language design, if we shouldn't come up with something better.

Not sure what you mean by "better". A "type" is a proposition about the
program. You can't get more general than that. Any static checking system will
have an interpretation in terms of types, so it's hard to see what could
possibly be better than a type system. There are just different type systems
with different properties.

~~~
hellofunk
Well there is also a fair amount of supportive opinion on the contrary, that
"better" is a system without types altogether, hence dynamic languages.

~~~
duaneb
Dynamic languages have types, too. Even perl has its distinctions between
lists and strings.

------
PicassoCT
Lua is a great little language.

You gain the most from this, if you stay lua-native for the entire time- doing
all calculations in the lua-vm, and are not depending to much on calls into
the underlying c-programm (happy cache misses :( ).

Is there a optimization, that starting from the calls, creates dependancy
trees, which allow to bundle away the calculation and calling of the call into
seperate (pre-existing Tasks), in such a way, that the Result for simple-calls
is in when the programm reaches the call?

------
sitkack
See also [http://terralang.org/](http://terralang.org/)

------
allan_s
Can projects like prosody (an xmpp server) runs on it ? Would it benefits from
it ?

~~~
perlgeek
According to [http://the-ravi-programming-
language.readthedocs.org/en/late...](http://the-ravi-programming-
language.readthedocs.org/en/latest/ravi-overview.html#ravi-extensions-to-
lua-5-3) it seems to have only type annotations for integers and numbers
(which I assume to be floating-point numbers) and arrays thereof.

I guess an XMPP server will deal mostly with strings, so the benefits from
type annotations will be rather small.

