64 bit integer support as a native lua type.

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

64 bit integer support as a native lua type.

Povilas Balciunas
Hello,

i've seen lot's of previous posts about 64bit integer support in lua. Lots of them are really old ones and it's obvious that it would be nice to have this feature in lua. It is also mention in http://lua-users.org/wiki/FeatureProposals
But i haven't seen any solutions yet. As lua 5.3 is emerging, i think it would be wise to raise a request of lua 64bit integer type support in that version.

What do you think about it?

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Choonster TheMage
On 7 September 2013 23:07, Povilas Balciunas <[hidden email]> wrote:

> Hello,
>
> i've seen lot's of previous posts about 64bit integer support in lua. Lots
> of them are really old ones and it's obvious that it would be nice to have
> this feature in lua. It is also mention in
> http://lua-users.org/wiki/FeatureProposals.
> But i haven't seen any solutions yet. As lua 5.3 is emerging, i think it
> would be wise to raise a request of lua 64bit integer type support in that
> version.
>
> What do you think about it?
>
> Thank you.

Lua 5.3.0-work1 uses long long as it default integer type:
https://github.com/lua/lua/blob/master/src/luaconf.h#L387-L389

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Rena
On Sat, Sep 7, 2013 at 9:17 AM, Choonster TheMage <[hidden email]> wrote:
On 7 September 2013 23:07, Povilas Balciunas <[hidden email]> wrote:
> Hello,
>
> i've seen lot's of previous posts about 64bit integer support in lua. Lots
> of them are really old ones and it's obvious that it would be nice to have
> this feature in lua. It is also mention in
> http://lua-users.org/wiki/FeatureProposals.
> But i haven't seen any solutions yet. As lua 5.3 is emerging, i think it
> would be wise to raise a request of lua 64bit integer type support in that
> version.
>
> What do you think about it?
>
> Thank you.

Lua 5.3.0-work1 uses long long as it default integer type:
https://github.com/lua/lua/blob/master/src/luaconf.h#L387-L389


I wonder why not uint64_t?

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Rob Kendrick-2
On Sat, Sep 07, 2013 at 09:38:59AM -0400, Rena wrote:
> On Sat, Sep 7, 2013 at 9:17 AM, Choonster TheMage
> <[hidden email]>wrote:
> >
> > Lua 5.3.0-work1 uses long long as it default integer type:
> > https://github.com/lua/lua/blob/master/src/luaconf.h#L387-L389
> >
> >
> I wonder why not uint64_t?

Lua is written in C89.  Isn't this a C99ism?

(It's sad that Lua's written in C89.  But this isn't a comment on the
authors, but the state of the world's compilers.  There are features in
C11 I'd love to use, but basically only people using clang could ever
build it.)

B.

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Mikhail Gusarov
There is no long long in C89 either.

Best regards,
Mikhail Gusarov.


On Sat, Sep 7, 2013 at 3:58 PM, Rob Kendrick <[hidden email]> wrote:

> On Sat, Sep 07, 2013 at 09:38:59AM -0400, Rena wrote:
>> On Sat, Sep 7, 2013 at 9:17 AM, Choonster TheMage
>> <[hidden email]>wrote:
>> >
>> > Lua 5.3.0-work1 uses long long as it default integer type:
>> > https://github.com/lua/lua/blob/master/src/luaconf.h#L387-L389
>> >
>> >
>> I wonder why not uint64_t?
>
> Lua is written in C89.  Isn't this a C99ism?
>
> (It's sad that Lua's written in C89.  But this isn't a comment on the
> authors, but the state of the world's compilers.  There are features in
> C11 I'd love to use, but basically only people using clang could ever
> build it.)
>
> B.
>

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Rena
In reply to this post by Rob Kendrick-2
On Sat, Sep 7, 2013 at 9:58 AM, Rob Kendrick <[hidden email]> wrote:
On Sat, Sep 07, 2013 at 09:38:59AM -0400, Rena wrote:
> On Sat, Sep 7, 2013 at 9:17 AM, Choonster TheMage
> <[hidden email]>wrote:
> >
> > Lua 5.3.0-work1 uses long long as it default integer type:
> > https://github.com/lua/lua/blob/master/src/luaconf.h#L387-L389
> >
> >
> I wonder why not uint64_t?

Lua is written in C89.  Isn't this a C99ism?

(It's sad that Lua's written in C89.  But this isn't a comment on the
authors, but the state of the world's compilers.  There are features in
C11 I'd love to use, but basically only people using clang could ever
build it.)

B.


But why is it that when a compiler lacks support for a feature that's been standard for years/decades, we just accept it and avoid using that feature, instead of considering it a buggy compiler and bugging the maintainers?

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

steve donovan
On Sat, Sep 7, 2013 at 4:25 PM, Rena <[hidden email]> wrote:
> But why is it that when a compiler lacks support for a feature that's been
> standard for years/decades, we just accept it and avoid using that feature,
> instead of considering it a buggy compiler and bugging the maintainers?

Because the big boy that doesn't want to play C99 is MS; they have
said that they really aren't interested in C that much.

However, 'long long' is definitely supported in the latest MSVC
compiler - it used to be something like _int64.  Portable code is
often a mess of #ifs for a reason ;)

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Rena
On Sat, Sep 7, 2013 at 10:38 AM, steve donovan <[hidden email]> wrote:
On Sat, Sep 7, 2013 at 4:25 PM, Rena <[hidden email]> wrote:
> But why is it that when a compiler lacks support for a feature that's been
> standard for years/decades, we just accept it and avoid using that feature,
> instead of considering it a buggy compiler and bugging the maintainers?

Because the big boy that doesn't want to play C99 is MS; they have
said that they really aren't interested in C that much.

However, 'long long' is definitely supported in the latest MSVC
compiler - it used to be something like _int64.  Portable code is
often a mess of #ifs for a reason ;)


Hmm, but MSVC isn't the only compiler for Windows...

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Rob Kendrick-2
In reply to this post by Rena
On Sat, Sep 07, 2013 at 10:25:28AM -0400, Rena wrote:

> > (It's sad that Lua's written in C89.  But this isn't a comment on the
> > authors, but the state of the world's compilers.  There are features in
> > C11 I'd love to use, but basically only people using clang could ever
> > build it.)
> >
> > B.
> >
> >
> But why is it that when a compiler lacks support for a feature that's been
> standard for years/decades, we just accept it and avoid using that feature,
> instead of considering it a buggy compiler and bugging the maintainers?

I look forward to the results of you bugging Microsoft on this subject :)

There are also issues outside compiler maintainership.  A foolish
company, some years ago, decided to base their system calls and API on
C++.  This has the hilarious* consequence that they're still stuck on
GCC 2.95.

B.

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Steve Litt
In reply to this post by Rena
On Sat, 7 Sep 2013 10:40:24 -0400
Rena <[hidden email]> wrote:

> On Sat, Sep 7, 2013 at 10:38 AM, steve donovan
> <[hidden email]>wrote:
>
> > On Sat, Sep 7, 2013 at 4:25 PM, Rena <[hidden email]> wrote:
> > > But why is it that when a compiler lacks support for a feature
> > > that's
> > been
> > > standard for years/decades, we just accept it and avoid using that
> > feature,
> > > instead of considering it a buggy compiler and bugging the
> > > maintainers?
> >
> > Because the big boy that doesn't want to play C99 is MS; they have
> > said that they really aren't interested in C that much.
> >
> > However, 'long long' is definitely supported in the latest MSVC
> > compiler - it used to be something like _int64.  Portable code is
> > often a mess of #ifs for a reason ;)
> >
> >
> Hmm, but MSVC isn't the only compiler for Windows...

Along those same lines Rena, Windows no longer has the preeminent
position it once had, back in the days when they could force my client
to tell me to pick MS C over Turbo C.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

William Ahern
In reply to this post by Rob Kendrick-2
On Sat, Sep 07, 2013 at 03:44:29PM +0100, Rob Kendrick wrote:

> On Sat, Sep 07, 2013 at 10:25:28AM -0400, Rena wrote:
> > > (It's sad that Lua's written in C89.  But this isn't a comment on the
> > > authors, but the state of the world's compilers.  There are features in
> > > C11 I'd love to use, but basically only people using clang could ever
> > > build it.)
> > >
> > > B.
> > >
> > >
> > But why is it that when a compiler lacks support for a feature that's been
> > standard for years/decades, we just accept it and avoid using that feature,
> > instead of considering it a buggy compiler and bugging the maintainers?
>
> I look forward to the results of you bugging Microsoft on this subject :)
>
> There are also issues outside compiler maintainership.  A foolish
> company, some years ago, decided to base their system calls and API on
> C++.  This has the hilarious* consequence that they're still stuck on
> GCC 2.95.
>
> B.

Don't leave us hanging! Which one?


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Rob Kendrick-2
On Sat, Sep 07, 2013 at 04:32:01PM -0700, William Ahern wrote:

> > There are also issues outside compiler maintainership.  A foolish
> > company, some years ago, decided to base their system calls and API on
> > C++.  This has the hilarious* consequence that they're still stuck on
> > GCC 2.95.
>
> Don't leave us hanging! Which one?

Be.

B.

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

David Demelier
In reply to this post by Rena
2013/9/7 Rena <[hidden email]>:

> On Sat, Sep 7, 2013 at 10:38 AM, steve donovan <[hidden email]>
> wrote:
>>
>> On Sat, Sep 7, 2013 at 4:25 PM, Rena <[hidden email]> wrote:
>> > But why is it that when a compiler lacks support for a feature that's
>> > been
>> > standard for years/decades, we just accept it and avoid using that
>> > feature,
>> > instead of considering it a buggy compiler and bugging the maintainers?
>>
>> Because the big boy that doesn't want to play C99 is MS; they have
>> said that they really aren't interested in C that much.
>>
>> However, 'long long' is definitely supported in the latest MSVC
>> compiler - it used to be something like _int64.  Portable code is
>> often a mess of #ifs for a reason ;)
>>
>
> Hmm, but MSVC isn't the only compiler for Windows...
>

But it's the best supported one.

--
Demelier David

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

liam mail

On 9 September 2013 12:07, David Demelier <[hidden email]> wrote:
But it's the best supported one.

Don't make me laugh. We are talking about C99 features and it is 2013! 

Having said that they think we have been good boys and want to revert their previous advise of "we recommend that you consider using a different compiler such as Intel or gcc"[1] when they announced something about some C99 features coming soon, maybe on the horizon at some point.[2]


--Liam
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

David Demelier
2013/9/9 liam mail <[hidden email]>:
>
> On 9 September 2013 12:07, David Demelier <[hidden email]> wrote:
>>
>> But it's the best supported one.
>
>
> Don't make me laugh. We are talking about C99 features and it is 2013!
>

Yes, and C is old and no new project is using it. Even the popular
Linux distributions and *BSD do not provide C11 features while we are
already in 2013. But C++11 is already shipped with a lot of operating
systems, why? because C++ is evolving and more and more projects are
using it.

C is painful, you can't write any portable program without requiring a
bunch of libraries or reimplementing the same thing each time. "Oh let
see how library `foo' will handle lists", "Ah library `baz' are using
they own linked lists, it will be painful to mix them". Hash map in C?
Really?

Why do you think C++ came with all of its standard library? C is dying
and it should be used only when you can't use something else (embedded
system? kernel?).

I was a very fan of C before, but I really get bored of writing or
rewriting these kind of stuff each time I switch to a new project or
create a new library. There is even no good way to build strings in C.
C is great for very low level development and suit perfectly for a
operating system kernel, but not for a new project. Then, I completely
agree that some developers don't want to spend time implementing a
standard than almost no one will use since modern C++ and other
languages have features that you won't want to reimplement in C.

Object orientation, templates, namespaces, lambdas, STL, smart
pointers... All of these things will never get me back to C :-). Also,
I really not recommend a user to do C anymore.


> Having said that they think we have been good boys and want to revert their
> previous advise of "we recommend that you consider using a different
> compiler such as Intel or gcc"[1] when they announced something about some
> C99 features coming soon, maybe on the horizon at some point.[2]
>



--
Demelier David

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

steve donovan
On Mon, Sep 9, 2013 at 2:27 PM, David Demelier <[hidden email]> wrote:
> Object orientation, templates, namespaces, lambdas, STL, smart
> pointers... All of these things will never get me back to C :-). Also,
> I really not recommend a user to do C anymore.

But everything has a cost. In particular, hard to interface a C++
codebase without effectively writing a C interface.

Without shared libstdc++, executables are enormous, otherwise the new
shiny features need an updated libstdc++ on target computers,

Just pointing out that every rainbow has a dark side.  C++11 is very
cool, but there are good reasons why solid infrastructure stuff is
done in C.

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Javier Guerra Giraldez
In reply to this post by David Demelier
On Mon, Sep 9, 2013 at 7:27 AM, David Demelier <[hidden email]> wrote:
> Yes, and C is old and no new project is using it.

talk for yourself.  all my Lua extensions are either C or LuaJIT ffi
(which inherits lots of it's semantics from C)


 > I really not recommend a user to do C anymore.

I do.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Tim Hill

On Sep 9, 2013, at 6:57 AM, Javier Guerra Giraldez <[hidden email]> wrote:

> On Mon, Sep 9, 2013 at 7:27 AM, David Demelier <[hidden email]> wrote:
>> Yes, and C is old and no new project is using it.
>
> talk for yourself.  all my Lua extensions are either C or LuaJIT ffi
> (which inherits lots of it's semantics from C)
>
>
>> I really not recommend a user to do C anymore.
>
> I do.
>
> --
> Javier
>

+1 here too.

The basic idea of OO is great, and the core C++ is pretty useful too, but C++ has become bloated, complex, and dangerous. The compilers are huge and slow, the runtime is absurd, and the syntax reminds me more of Malbolg than any other language I know. For a language that is 30+ years old, C has been stable and robust, and it's flaws at least have the virtue of being well known.

--Tim


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit integer support as a native lua type.

Andrew Starks


On Monday, September 9, 2013, Tim Hill wrote:

On Sep 9, 2013, at 6:57 AM, Javier Guerra Giraldez <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;javier@guerrag.com&#39;)">javier@...> wrote:

> On Mon, Sep 9, 2013 at 7:27 AM, David Demelier <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;demelier.david@gmail.com&#39;)">demelier.david@...> wrote:
>> Yes, and C is old and no new project is using it.
>
> talk for yourself.  all my Lua extensions are either C or LuaJIT ffi
> (which inherits lots of it's semantics from C)
>
>
>> I really not recommend a user to do C anymore.
>
> I do.
>
> --
> Javier
>

+1 here too.

The basic idea of OO is great, and the core C++ is pretty useful too, but C++ has become bloated, complex, and dangerous. The compilers are huge and slow, the runtime is absurd, and the syntax reminds me more of Malbolg than any other language I know. For a language that is 30+ years old, C has been stable and robust, and it's flaws at least have the virtue of being well known.

--Tim


There are a couple of threads that are going now (tostring, expressions) that are... "like" this one. 

C is a system language. C++ is an application language. Some people use it as a system language, but I firmly believe that the designation is informative and when it's violated, you end up with libraries that have APIs that are very difficult to work with. 

Imagine the Lua list were the C list, circa mid-eighties. "We don't even have a hash object. We don't have objects!" 

What would such an abstraction look like? How often would one need to take it apart or re-do it for a more specific purpose at the binding or application level?

C is the most popular language in the world, if measured by lines of code RUNNING, for an excellent reason: it doesn't do more than it should for what it is. 

Let higher level tools represent models and low level languages represent systems. C is awesome for that and is really beautiful when used that way. 

In the same way, expecting Lua to always be "correct" in every single case, puts it on the wrong level. It should *behave* consistently and correct, but sometimes that must mean that it isn't implemented in that way. Lua should be pragmatic, but not unhelpfully so. 

In my very humble opinion (and despite my own transgressions into discussions on its redesign :), it gets this balance perfectly... Except when it prompts strings to numbers. .)

-Andrew