lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It seems to me that a special type description DSL is exactly what you need. If I understand correctly, you have no annotation language for directly specifying the types of formal parameters and returns, but can sometimes infer the types of returns. As far as I know, unless a language has been designed from the ground up to have inferrable formal parameter types, inferring these types can be extremely tricky.

Love Studio[1] receives type descriptions of native APIs from XML files. I chose this approach because it is direct; a direct type definition seems preferable to an imperative, untyped program which a type can be inferred from.

However, Love Studio can extract object oriented types from lua programs. It uses a combination of syntax and type annotations; annotations are used for formal parameters, returns, and public fields. Everything else is extracted from syntax, but the particular way in which the syntax is interpreted as an object-oriented type is dependent on a plugin written specifically for whichever class/module system you are using (the only such plugins in existence are the ones I wrote for classic lua modules and Basic Class System[2]).

[1]https://bitbucket.org/kevinclancy/love-studio/wiki/Home
[2]https://bitbucket.org/kevinclancy/basic-class-system

On 8/12/2013 7:18 PM, Jon Akhtar wrote:
I have been for some time wrestling with how to get my Lua IDE [1] to support easy user supplied API definitions when the users may only have documentation to go on.

My initial thought was that since my editor supported type inference of Lua source code. I could reuse that work to allow API's to be defined using Lua. This works. I use it to define the file object in the io library.

given

local a = io.open

typing a(): will provide completions for functions on the object returned by io.open().

The problem with this of course is it is quite complicated by nature, and to top it off my system used the module function as a sort of pseudo keyword in order to reduce the overally complexity of code analysis. For example getting all the Penlight code to understand its own self references took some work - but it did work last time I tried browsing the source.

Couple this with my other great idea to let you provide code documentation using Lua scripts has lead to a system with a steep learning curve, and somewhat unpredictable behavior.

Basically there is a lua script you can supply that will ask you for the parameter info, short-text docs, long text docs, and link to and external source. This has honestly worked really well for me, other people have had trouble understanding it - but it is probably one of the easiest to methods I have seen for solving this part of the problem.

I was wondering what ideas the community may have or know about that would be useful in this regard. All angles of describing an API - but specifically, the OO constructs, that use metatables or plain functions on Class objects to let you create instances of a given class.

These have complex return types, and those return types will also need to be understood by the documentation component. So a list of methods you can call -i isn't enough. You also need to be able to identify these object usages and provide documentation on types they may return, etc.

In my current system - you can provide semantically aware completions using Lua source code. My goal was to reuse the code inference that was providing completions everywhere else - and not require a special type description DSL.

I have changed jobs this year which has meant not working on the plugin, but I'd like to restart. I have discovered I either need help on the project, or need to engage the community more as I design things to ensure that I don't overlook any really great ideas.

Anyhow - thank you in advance for your replies.







[1] https://bitbucket.org/sylvanaar2/lua-for-idea/wiki/Home