how to prevent bugs without static type checking?

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

how to prevent bugs without static type checking?

乙振斐
Without static type checking, we may send wrong parameters to a function and we cannot find this mistake until the program crashes in run time.
But if it is a huge program, we are not able to cover 100% codes in test, in this situation ,how can we prevent this problem?(say, pass wrong type parameters to a function)

Sorry, I am a new comer with Lua, and it is the first time for me to learn a dynamic language, forgive me if this problem is ridiculous. But it really bothered me for a long time.

Regards,
Zhenfei Yi.
Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Coda Highland
On Mon, Oct 22, 2012 at 9:07 PM, 乙振斐 <[hidden email]> wrote:

> Without static type checking, we may send wrong parameters to a function and
> we cannot find this mistake until the program crashes in run time.
> But if it is a huge program, we are not able to cover 100% codes in test, in
> this situation ,how can we prevent this problem?(say, pass wrong type
> parameters to a function)
>
> Sorry, I am a new comer with Lua, and it is the first time for me to learn a
> dynamic language, forgive me if this problem is ridiculous. But it really
> bothered me for a long time.
>
> Regards,
> Zhenfei Yi.

It's a tradeoff. The downside is that you don't have a "compile time"
at which to find type errors. The upside is that you can have "duck
typing", which means that an object only has to expose a certain
common API in order to be an acceptable parameter rather than having
to deal with some strict, static polymorphism.

That said, there are static analysis tools for Lua that do allow you
to annotate functions with information so you can get the security
where you need it.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Rena
In reply to this post by 乙振斐

On 2012-10-23 12:07 AM, "乙振斐" <[hidden email]> wrote:
>
> Without static type checking, we may send wrong parameters to a function and we cannot find this mistake until the program crashes in run time.
> But if it is a huge program, we are not able to cover 100% codes in test, in this situation ,how can we prevent this problem?(say, pass wrong type parameters to a function)
>
> Sorry, I am a new comer with Lua, and it is the first time for me to learn a dynamic language, forgive me if this problem is ridiculous. But it really bothered me for a long time.
>
> Regards,
> Zhenfei Yi.

You can check with type() if you want to verify. Usually you shouldn't need to though. If something needs to be a number or string, use tonumber/tostring() or implicit conversions; if it's an object, just check if it has the methods you're interested in.

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

William Ahern
In reply to this post by 乙振斐
On Tue, Oct 23, 2012 at 12:07:11PM +0800, 乙振斐 wrote:
> Without static type checking, we may send wrong parameters to a function
> and we cannot find this mistake until the program crashes in run time.
> But if it is a huge program, we are not able to cover 100% codes in test,
> in this situation ,how can we prevent this problem?(say, pass wrong type
> parameters to a function)

The size of the program doesn't matter unless you're trying to add tests to
existing code. For new code, as long as you write tests at the same time you
write the code, then it's not a problem.

It's like washing dishes. If you leave them to pile up, it's a chore. If you
wash the dishes right after you use them, it's not much trouble.

But you should design your code with run-time errors in mind, e.g. by
checking for pcall failures. You should make catching, reporting, and
debugging errors easier to do at run-time, instead of relying on the
compiler or post-mortems.

There are other techniques. In a recent library I had to deal with optional
timeouts. I used a pattern like:

        function foo(query, timeout)
                local deadline = timeout and timeout + monotime()

                ...

                if deadline then

                ...

There are two pertinent characteristics here. First, I can pass nil or false
as `timeout', and it'll just work--it's a little lenient with the type.
(Note also that the arithmetic operation will coax number strings into
number values.)

Second, if `timeout' is the wrong type it fails early in the function, and
unconditionally. If someone passes the wrong type it'll blow up sooner
rather than later. That often makes any bug more likely to be caught during
QA testing.

I'm sure other people have similar patterns and habits.

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

spir ☣
In reply to this post by 乙振斐
On 23/10/2012 06:07, 乙振斐 wrote:
> Without static type checking, we may send wrong parameters to a function
> and we cannot find this mistake until the program crashes in run time.
> But if it is a huge program, we are not able to cover 100% codes in test,
> in this situation ,how can we prevent this problem?(say, pass wrong type
> parameters to a function)
>
> Sorry, I am a new comer with Lua, and it is the first time for me to learn
> a dynamic language, forgive me if this problem is ridiculous. But it really
> bothered me for a long time.

First, this is a relevant question, in fact one often discussed in programming
circles. There is certainly no good answer, even less a solution. Maybe 3 points
can be helpful (from my personal experience in both dynamic and static
languages), or not:

1. fields of errors
There are several kinds or fields of errors which i classify as:
* Programming errors, which prevent a program to work, either at "decoding" time
by the machine, the language implementation (also in dynamic language), or at
runtime when the wrong piece of code is executed.
* Logical errors, meaning the program is correct but does not express what you
actually mean, or should mean. For instance, a sort function that does not sort
properly.
* Conceptual errors, where your conception of what the program should mean is wrong.

Type errors are a subtype of programming errors. The difference with them in
dynamic languages is that they happen at runtime. But they do happen, most
often, because if a pice of data is of the wrong type, commonly any later
operation with it will fail. The issue is partly that a bit of time is lost (you
get the error later), partly that it is met only if the code path is run, and
more problematically that it may happen at a distant place in code (and in your
mind) from the actual source of the issue. Thus, we may have to think hard; this
is for me the true problem with type errors in dynamic languages.
However, type errors are not at all the most difficult ones in general, not the
ones that eat our time, and probably not even the most common ones. Typically we
(I mean, I) spend most of our time with logical and conceptual errors --the kind
prevailing depending on the size of the project and previous knowledge in the
domain.

2. way of thinking
I noticed the following: after programming for a long time only in dynamic
languages, when I then switch to static typing, for a while I have about no type
error (at compile-time, indeed); then they start to happen, and finally I have
many. I think, maybe, after some time we start "programming-thinking"
differently. Dynamic programmers may have a clearer awareness about types --that
is, ultimately, the meaning of symbols-- and unconsciously pay more attention to
their coherence in the model. Conversely, after some time, static programmers
may start to rely on the machine to do this job; and it does it well, provided
your typing is correct and clear. They become so-to-say lazy about that, not
uselessly spending their "neuronic power" in what a machine can do (better).
Both are good, in my opinion.

3. trade-off
Finally, there is a trade-off of flexibility (and simplicity, and conciseness)
versus security (and comfort, and laziness). Both are good, again.
Unfortunately, we cannot yet have both...
I guess it's not a question of technology, and in particular optional
static-typing is not the right future of programming. Rather, there may be
something basically wrong in our way of thinking about programming. (Maybe what
we need is a kind of semantic types, embedding meaning in symbols, but I don't
know exactly what this should mean... ;-).

Denis

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

David Collier
In reply to this post by 乙振斐


> *From:* ÒÒÕñì³ <[hidden email]>
> *To:* <[hidden email]>
> *Date:* Tue, 23 Oct 2012 12:07:11 +0800
>
> Without static type checking, we may send wrong parameters to a
> function
> and we cannot find this mistake until the program crashes in run
> time.
> But if it is a huge program, we are not able to cover 100% codes in
> test,
> in this situation ,how can we prevent this problem?(say, pass wrong
> type
> parameters to a function)
>
> Sorry, I am a new comer with Lua, and it is the first time for me
> to learn
> a dynamic language, forgive me if this problem is ridiculous. But
> it really
> bothered me for a long time.
>
> Regards,
> Zhenfei Yi.
>
>
> --
> *Included Files:*
> am2file:001-HTML_Message.html

I think you'll find this answer to a similar question I posed a couple of
weeks ago very relevant

====================== copy follows ========================
On Wed, Oct 3, 2012 at 3:08 PM, Thijs Schreijer <[hidden email]>
wrote:

> >
> > I suppose I could write a function "checkargs"
>
> iirc the Sierra Wireless folks did something like that.
>

Indeed we have, and usage proves that it's an excellent API documentation
(terse, readable, extensible, and you have to keep it up-to-date with the
code). Eventually I'd like to hack Eclipse's type inference system so
that
it could use it to gather hints.

Here it is, no dependency beyond lua.h:

https://github.com/SierraWireless/luasched/blob/master/c/checks.c

--
Fabien Fleutot
+---
| 33 chemin de Mange-Pommes
| 31520 Ramonville Saint-Agne -- France
| mobile: +33 6 28 06 09 97
| office: +33 5 61 00 06 49
| home: +33 5 61 75 05 67


--
*Included Files:*
am2file:001-HTML_Message.html

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Enrico Tassi
In reply to this post by spir ☣
On Tue, Oct 23, 2012 at 10:29:10AM +0200, spir wrote:

> 2. way of thinking
> I noticed the following: after programming for a long time only in
> dynamic languages, when I then switch to static typing, for a while
> I have about no type error (at compile-time, indeed); then they
> start to happen, and finally I have many. I think, maybe, after some
> time we start "programming-thinking" differently. Dynamic
> programmers may have a clearer awareness about types --that is,
> ultimately, the meaning of symbols-- and unconsciously pay more
> attention to their coherence in the model. Conversely, after some
> time, static programmers may start to rely on the machine to do this
> job; and it does it well, provided your typing is correct and clear.
> They become so-to-say lazy about that, not uselessly spending their
> "neuronic power" in what a machine can do (better).
> Both are good, in my opinion.

I fully agree, and I've the same experience switching back and forth
between OCaml and Lua (and C sometimes).

Hence, the only true advantage I see of static typing is when you do
true research, i.e. you have no clear idea about the right data
structure (or the right approach) to solve your problem. In this case
you continuously refine your data structure, and a static type checker
is invaluable in driving you trough the code, pointing out all the
places where you actually make assumptions on the underlying data
representation.

This never happens if you know how to tackle your problem in the first
place, and you start with the right data structure from the very
beginning.

Cheers
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Roberto Ierusalimschy
> Hence, the only true advantage I see of static typing is when you do
> true research, i.e. you have no clear idea about the right data
> structure (or the right approach) to solve your problem. In this case
> you continuously refine your data structure, and a static type checker
> is invaluable in driving you trough the code, pointing out all the
> places where you actually make assumptions on the underlying data
> representation.

In my opinion, a true advantage of static typing is when you do
maintenance. If you have more than a few lines of code, and you have to
change a little any data structure, "a static type checker is invaluable
in driving you trough the code, pointing out all the places where you
actually make assumptions on the underlying data representation."

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Enrico Tassi
On Tue, Oct 23, 2012 at 11:00:53AM -0200, Roberto Ierusalimschy wrote:
> In my opinion, a true advantage of static typing is when you do
> maintenance. If you have more than a few lines of code, and you have to
> change a little any data structure, "a static type checker is invaluable
> in driving you trough the code, pointing out all the places where you
> actually make assumptions on the underlying data representation."

Yes and no. I know your opinion is the most widespread one but I tend to
disagree.

According to my experience, once you get your data structures right, you
start piling up abstractions and define clear interfaces that hide the
data representation (I mean, an opaque datatype in ML terminology).
Hence, when you decide to make a minor change to your datatype, you
seldom alter the interface, and the type checker catches errors
within the module that defines the data structure only.
The errors that are eventually intruced by your change in other modules
are now part of another category, they are not syntactic any more in
some sense. Of course, if you alter the interface, types kick in again,
but you don't do that while do maintenance, or better, you avoid that as
much as possible.

My impression is that when people get their datatypes almost right, they
are so fed up of compile time errors that they hide their types behind an
abstract interface so that any other minor change does not require to
go trough the whole code base. In this sense type checking gets less
relevant, whilst being still useful.

Ciao
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Roberto Ierusalimschy
> According to my experience, once you get your data structures right, you
> start piling up abstractions and define clear interfaces that hide the
> data representation

Experiences vary :) You need *a lot* of discipline to define and
keep clear interfaces that do not leak. (Moreover, because typical
dynamically typed languages are interpreted, people sometimes avoid
piling up abstractions for the sake of speed. Each intermediate function
counts, so there is a big incentive not to abstract... And there is
no type system to help keeping proper abstraction boundaries.)


> (I mean, an opaque datatype in ML terminology).

Could you say instead "in Python/Lua/Perl terminology"?  ;)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Enrico Tassi
On Tue, Oct 23, 2012 at 01:14:30PM -0200, Roberto Ierusalimschy wrote:

> > According to my experience, once you get your data structures right, you
> > start piling up abstractions and define clear interfaces that hide the
> > data representation
>
> Experiences vary :) You need *a lot* of discipline to define and
> keep clear interfaces that do not leak. (Moreover, because typical
> dynamically typed languages are interpreted, people sometimes avoid
> piling up abstractions for the sake of speed. Each intermediate function
> counts, so there is a big incentive not to abstract... And there is
> no type system to help keeping proper abstraction boundaries.)

Sure, I'm not saying you should use Lua as if it was OCaml.

I'm sort of claiming that adding static types to Lua would not make it
better suited to write large software, that is the contrary of what is
usually believed. The benefits would be minimal.

Writing good interfaces is hard, your are right!  But if you can't
define decent interface/boundaries between your modules you are unlikely
to build up a huge system, no matter if these boundaries are checked at
run time or at compile time or not checked at all.

Maybe a way to rephrase my opinion is that types help you to reach a
point where your understanding of the problem is such that you can write
down decent interfaces. After that point, types don't matter that much,
since you are not going to break these interfaces that often.

> > (I mean, an opaque datatype in ML terminology).
>
> Could you say instead "in Python/Lua/Perl terminology"?  ;)

Hum, I guess the closest concept is an "object" accessed only trough the
method/members that are meant to be used.
In Lua you could use an empty proxy table for example, or follow the
"just don't do it" philosophy and give funny names to private data.

Cheers
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Geoff Leyland
In reply to this post by David Collier
On 23/10/2012, at 11:04 PM, David Collier <[hidden email]> wrote:

>>> I suppose I could write a function "checkargs"
>>
>> iirc the Sierra Wireless folks did something like that.
>
> Indeed we have...

If you're talking about run-time rather than static type-checking, then [1] shamelessly copies the sierra wireless solution, except that it runs as a debug hook, reads documentation comments rather than requiring a check function and is in Lua as opposed to C (nothing against C, just that a Lua-only solution doesn't require compilation).


    --- prints the string s n times
    -- @tparam number n how many times to print the string
    -- @tparam string s the string to print
    function printn(s, n)
      for i = 1, n do print(s) end
    end

    printn(10, "hello")


    $ lua -largcheck test/ldoc.lua
    lua: test/ldoc.lua:8: bad argument #1 to 'printn' (string expected, got number '10')


It's not as polished as the Sierra solution yet, and currently quite slow (as hooks in Lua tend to be), but I like that the comments double as documentation comments.

cheers,
Geoff


[1] https://github.com/geoffleyland/argcheck
Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

steve donovan
On Tue, Oct 23, 2012 at 7:58 PM, Geoff Leyland
<[hidden email]> wrote:
> It's not as polished as the Sierra solution yet, and currently quite slow (as hooks in Lua tend to be), but I like that the comments double as documentation comments.

Man, that really is a cool dual-use of doc comments!

Would be useful to harmonize with tools like LDoc  - @tparam of course
is a LDoc extension directly inspired by Sierra Wireless' contribution
to that project.  LDoc makes it straightforward to add aliases, so
that you can say '@string' rather than '@tparam string', and these are
useful enough that I think they should come with the kit.

Because the truly cool thing is that it gives people _another_ good
reason to use doc comments....

Beyond primitive types we get the 'type description' problem.  Say
someone defines a type Foo, somewhere. A useful discipline is to use
named types as much as possible in code, because it's easier to
document.

But checking an argument of type 'Foo' requires some assumptions about
how objects are organized - they have a metatable yes, but where to
put the type's name? E.g. in Penlight the convention is that
getmetatable(obj)._name will be the name of the class, but this only
happens automatically if using the 'class.Frodo()' syntax.  So even in
one library it's not a guarantee!

Another approach is explicit type description, e.g {string...} is a
table of strings, {name=string,age=int} is a structure, and so forth.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Geoff Leyland
On 24/10/2012, at 8:47 PM, steve donovan <[hidden email]> wrote:

> On Tue, Oct 23, 2012 at 7:58 PM, Geoff Leyland <[hidden email]> wrote:
>
>> It's not as polished as the Sierra solution yet, and currently quite slow (as hooks in Lua tend to be), but I like that the comments double as documentation comments.
>
> Man, that really is a cool dual-use of doc comments!

Thanks!

> Would be useful to harmonize with tools like LDoc

Absolutely.  I couldn't agree more.  It would be a disaster if it didn't.

(by the way, my preferred syntax for parameter annotations is inline with the arguments, to save repeating myself:

foo(
 a, -- string
 b) -- integer

Which LDoc *almost* supports.  I had a look at LDoc internals and got nowhere, so I pinged you on github.  If you can show me around I'll try to put together LDoc patches)
 
> LDoc makes it straightforward to add aliases, so
> that you can say '@string' rather than '@tparam string', and these are
> useful enough that I think they should come with the kit.

I saw those in the LDoc manual, and it could be difficult if nonstandard aliases were defined, but standard ones would be good.  I guess argcheck could read the same config file as LDoc and get the same set of aliases?

> Because the truly cool thing is that it gives people _another_ good
> reason to use doc comments...

I know!  I've been gratuitously commenting code since I wrote it.  Trouble is, it's slooooow.  It should be possible to compile the checks after the first time around and that might help.

> Beyond primitive types we get the 'type description' problem.  Say
> someone defines a type Foo, somewhere. A useful discipline is to use
> named types as much as possible in code, because it's easier to
> document.
>
> But checking an argument of type 'Foo' requires some assumptions about
> how objects are organized - they have a metatable yes, but where to
> put the type's name? E.g. in Penlight the convention is that
> getmetatable(obj)._name will be the name of the class, but this only
> happens automatically if using the 'class.Frodo()' syntax.  So even in
> one library it's not a guarantee!

At the moment it tries mt.__type, mt.__typename, mt.__typeinfo[type] (but not mt._name - I missed that!), then searches for globals and upvalues with the same name as the type and checks if they match the metatable.  You could easily make "type detectors" pluggable.

> Another approach is explicit type description, e.g {string...} is a
> table of strings, {name=string,age=int} is a structure, and so forth.

Yes, working out what this should look like would be well worthwhile.
I stole 1..5 for ranges from lapp, and I've been toying with the idea of going all Eiffel and contractual and allowing general constraints on parameters.  I don't know that there's a way to catch the return values of a function with a hook for postconditions though.

Cheers,
Geoff
Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

spir ☣
In reply to this post by steve donovan
On 24/10/2012 09:47, steve donovan wrote:

> On Tue, Oct 23, 2012 at 7:58 PM, Geoff Leyland
> <[hidden email]> wrote:
>> It's not as polished as the Sierra solution yet, and currently quite slow (as hooks in Lua tend to be), but I like that the comments double as documentation comments.
>
> Man, that really is a cool dual-use of doc comments!
>
> Would be useful to harmonize with tools like LDoc  - @tparam of course
> is a LDoc extension directly inspired by Sierra Wireless' contribution
> to that project.  LDoc makes it straightforward to add aliases, so
> that you can say '@string' rather than '@tparam string', and these are
> useful enough that I think they should come with the kit.
>
> Because the truly cool thing is that it gives people _another_ good
> reason to use doc comments....
>
> Beyond primitive types we get the 'type description' problem.  Say
> someone defines a type Foo, somewhere. A useful discipline is to use
> named types as much as possible in code, because it's easier to
> document.
>
> But checking an argument of type 'Foo' requires some assumptions about
> how objects are organized - they have a metatable yes, but where to
> put the type's name? E.g. in Penlight the convention is that
> getmetatable(obj)._name will be the name of the class, but this only
> happens automatically if using the 'class.Frodo()' syntax.  So even in
> one library it's not a guarantee!

On one hand, if you want to type-check, there should a constraint or discipline
on the way to indicate types in your code; I mean for custom ones. Preferably,
just a field in the metatable, yes. But there must be a way to indicate to the
checker where to search; it must be parameterised on this point.

> Another approach is explicit type description, e.g {string...} is a
> table of strings, {name=string,age=int} is a structure, and so forth.

I don't get that. How will the checker know, from this, where to find types?

> steve d.

d

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

Philippe Lhoste
In reply to this post by Enrico Tassi
On 23/10/2012 14:28, Enrico Tassi wrote:

> I fully agree, and I've the same experience switching back and forth
> between OCaml and Lua (and C sometimes).
>
> Hence, the only true advantage I see of static typing is when you do
> true research, i.e. you have no clear idea about the right data
> structure (or the right approach) to solve your problem. In this case
> you continuously refine your data structure, and a static type checker
> is invaluable in driving you trough the code, pointing out all the
> places where you actually make assumptions on the underlying data
> representation.
>
> This never happens if you know how to tackle your problem in the first
> place, and you start with the right data structure from the very
> beginning.

I see two problems with this approach:
- You are a good programmer. In a real team, there can be beginners, or not so good coders...
- Unless you document very well your data structure (I guess you do), and document well
the type of your parameters, etc., it can be hard to use the API.

Java is verbose and rigid and all, but at least it safer for large teams of various levels
of coders because it brings lot of safeguards, thanks to the type system.

Scala is a language with an even stricter type system (not far of Haskell), preventing
even more errors but making it hard to use by beginners...

On the other end of the scale, PHP is a dynamic language that grown organically, with
functions provided by various sources, and doc not always at the level wanted by strict
users. At least, it has a system of comments of the doc helping to understand corner cases...

I don't say that a dynamic language prevents to make large softwares, but it is a bit
harder: you need discipline and knowledge, to enforce conventions that are otherwise
enforced by the language: document thoroughly each parameter and return value, write lot
tests to ensure everything works as expected, etc.

Of course, you write lot of tests for statically typed languages like Java, but somehow
you can skip some kind of tests needed by dynamic languages, like seeing what happens if
you pass a parameter of the wrong type, etc.
Of course, you need to document your statically typed program too, and actually having the
types defined might push some coders to be lazy about documenting: I have seen rigorous
Lua programs, and awful Java code!

Another point: I see that an IDE like Eclipse can benefit from static typing by
auto-completion, database of types and functions, early error catching, thorough static
analysis of code (eg. Findbugs and similar), accurate refactoring and some other
advantages. It can make easier to explore a large code base, too, particularly when the
documentation of types and functions is lacking, missing or obsolete...

These functionalities might be possible in dynamic languages (there are good tools for
Lua), but require a bit more efforts, I think, and might be less thorough.
On the other hand, a less verbose and less rigid syntax requires less typing (on
keyboard!) anyway... :-)

Now, I mostly coded in statically typed languages for a living, and I don't have much
experience in large programs written in dynamically typed languages, so my view is biased.
But it is not a bashing of the dynamic languages, for sure! ;-)

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --


Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

steve donovan
In reply to this post by Geoff Leyland
On Wed, Oct 24, 2012 at 10:29 AM, Geoff Leyland
<[hidden email]> wrote:
> foo(
>  a, -- string
>  b) -- integer

Yeah, I support this pattern with the last comment _before_ the
closing parens - should not be difficult to check for this case, which
reads better anyhow.

> I saw those in the LDoc manual, and it could be difficult if nonstandard aliases were defined, but standard ones would be good.  I guess argcheck could read the same config file as LDoc and get the same set of aliases?

Next release (soon!) will define the primitive types as tparam
aliases, so @string, etc. (@int is interesting one, since you apply an
additional custom constraint here, very useful)

> I know!  I've been gratuitously commenting code since I wrote it.  Trouble is, it's slooooow.  It should be possible to compile the checks after the first time around and that might help.

What could work is if there's an argcheck option to run a preprocessed
version, with explicit type asserts (they can all be on the same line
as 'function' so no line number confusiions)

> At the moment it tries mt.__type, mt.__typename, mt.__typeinfo[type] (but not mt._name - I missed that!), then searches for globals and upvalues with the same name as the type and checks if they match the metatable.  You could easily make "type detectors" pluggable.

That's the way to go!  Sigh, we really do suffer for a lack of OOP
conventions....

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

steve donovan
In reply to this post by Philippe Lhoste
On Wed, Oct 24, 2012 at 10:59 AM, Philippe Lhoste <[hidden email]> wrote:
> Another point: I see that an IDE like Eclipse can benefit from static typing
> by auto-completion, database of types and functions, early error catching,

When I was learning Java properly Eclipse was fantastic - it had more
structural insight into my own code than I had, and would suggest
intelligent ways to resolve errors. Suddenly having to maintain a
20KLOC program went surprisingly well (my colleague had run off to
join a monastery *)

So the work that Sierra Wireless is doing with the Eclipse foundation
is important.  They are using doc comments to complement pure
structural analysis of Lua.

And it's true, much work is done with non-genius teams who need such
assistance to get productive.

steve d.

* True story. Although the clients were engineers who designed using
huge spreadsheets, and they couldn't read Java. Lua would have been a
better match actually, since it looks just like their beloved VBA.

Reply | Threaded
Open this post in threaded view
|

RE: how to prevent bugs without static type checking?

Thijs Schreijer
In reply to this post by Geoff Leyland
> Behalf Of Geoff Leyland
> Sent: woensdag 24 oktober 2012 10:29
> Subject: Re: how to prevent bugs without static type checking?
>
> > On 24/10/2012, at 8:47 PM, steve donovan <[hidden email]>
> > wrote:
>
> > Beyond primitive types we get the 'type description' problem.  Say
> > someone defines a type Foo, somewhere. A useful discipline is to use
> > named types as much as possible in code, because it's easier to
> > document.
> >
> > But checking an argument of type 'Foo' requires some assumptions about
> > how objects are organized - they have a metatable yes, but where to
> > put the type's name? E.g. in Penlight the convention is that
> > getmetatable(obj)._name will be the name of the class, but this only
> > happens automatically if using the 'class.Frodo()' syntax.  So even in
> > one library it's not a guarantee!
>
> At the moment it tries mt.__type, mt.__typename, mt.__typeinfo[type]
> (but not mt._name - I missed that!), then searches for globals and
upvalues
> with the same name as the type and checks if they match the metatable.
> You could easily make "type detectors" pluggable.
>

I think this could combine very well with this message;
http://lua-users.org/lists/lua-l/2012-10/msg00122.html 

If the "typical" library by Rob Hoelz can be combined with my "typex"
library, then that could pretty much fill this gap.

A preprocessor that can be run on the command line (similar to LuaCov usage)
would be nice then to prevent extra manual steps in the process


Reply | Threaded
Open this post in threaded view
|

Re: how to prevent bugs without static type checking?

steve donovan
On Wed, Oct 24, 2012 at 11:43 AM, Thijs Schreijer
<[hidden email]> wrote:
> If the "typical" library by Rob Hoelz can be combined with my "typex"
> library, then that could pretty much fill this gap.

I'd like to harmoize Penlight with this, and fill in MT.__type.
Standards are a good thing!

However, is the idea that __type (or tostring(__type)) should always
resolve to a sensible name for a type?

steve d.

123