[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Desired Lua Features
- From: steve donovan <steve.j.donovan@...>
- Date: Mon, 29 Jan 2018 13:02:11 +0200
On Mon, Jan 29, 2018 at 12:32 PM, Grey Knight
> Well if we had filters I would want maps and all the rest too! I've got a
> library for doing things like this already though, I don't think syntax is a
> good way to go here. Note that it's not syntax in Rust either.
Exactly - I have pl/seq for that style as well. The Rust for-statement
is here leaning on a very feature-ful Iterator type.
> wouldn't be sure how to make it work when e.g. I have some table which I'm
> treating as an object of a specific type. Maybe a __type metafield can
> give a string name for its type.
It's a surprisingly tough problem. Because we use these implicit,
ad-hoc types - how to specify them so we don't lose all that wonderful
flexibility? I believe the TypedLua research project has some
interesting things to say about possible solutions. That's why I said
demands for class _syntax_ got overwhelming. In the case of Lua, there
is little agreement on how to _define_ 'classes', so some extra
annotation is needed - this is a `Cat`.
Of course, we are free to do run-time checking (there's some very cute
libs out there for that) but in a semi-ideal world, we'd like a
preprocessor which _does_ some typechecking based on signatures, so it
becomes a compile-time error to put strings into integers and so
forth. (It is possible that I've become addicted to the safety belt
of strong typing. But too far down that road, we end up with something
very different from Lua. I think statically-typed scripting languages
are an interesting space to explore, though - e.g. Lily)