Re: about the next version

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

Re: about the next version

Philippe Lhoste
Roberto wrote:
>>>
- standard libraries: standard libraries now use "namespaces". So,
strfind now is str.find, sin is math.sin, fileopen is io.open. Some
basic functions (type, assert, error, etc.) are still global. We also
changed the io library; e.g. files act as objects (f = io.open(...);
f:read(...); f:write(...)).
<<<

I come back to this already old message.
I saw reactions on the length of the standard namespace names (too short),
but none about the compatibility with old code.

Perhaps I missed something, or compability isn't a concern: I feel that the
motto is "Lua must improve, legacy shouldn't be an hinderance", a philosophy
I approve as it avoids monsters like the Win32 API :-)
But I have some scripts around doing some file manipulations, a generic CGI
engine, etc.

So if compatibility with old code is broken, do you think it would be easy
to upgrade old code, either by adding a line including a compatibility layer,
or a Lua program parsing Lua code to replace the obsolete calls (not just a
gsub, to avoid changing strings)?
Or perhaps a special switch for Lua executable, to add the old names to the
list of functions?

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: about the next version

Roberto Ierusalimschy
> Perhaps I missed something, or compability isn't a concern: (?)

It is. Our idea is to provide a compatibility file, in Lua, that build
the old library on top of the new one. Most of its work is simply renaming:

   sin = math.sin
   cos = math.cos
   ...

A few functions need a real "implementation". Follows attached a sketch of
this file.

-- Roberto

-------------------------------------------------------------------
-- Real globals
-- _ALERT
-- _ERRORMESSAGE
-- _VERSION
-- _G
-- assert
-- error
-- metatable
-- next
-- print
-- require
-- tonumber
-- tostring
-- type
-- unpack

-------------------------------------------------------------------
-- collectgarbage
-- gcinfo

-- globals

-- call   -> protect(f, err)
-- loadfile
-- loadstring

-- rawget
-- rawset

-- getargs = Main.getargs ??


function do_ (f, err)
  if not f then print(err); return end
  local a,b = pcall(nil, f)
  if not a then print(b); return nil
  else return b or true
  end
end

function dostring(s) return do_(loadstring(s)) end
function dofile(f) return do_(loadfile(f)) end

-------------------------------------------------------------------
-- Table library
foreach = tab.foreach
foreachi = tab.foreachi
getn = tab.getn
tinsert = tab.insert
tremove = tab.remove
sort = tab.sort

-------------------------------------------------------------------
-- Debug library
debug = dbg.debug
getinfo = dbg.getinfo
getlocal = dbg.getlocal
setcallhook = dbg.setcallhook
setlinehook = dbg.setlinehook
setlocal = dbg.setlocal

-------------------------------------------------------------------
-- math library (change to radians?)
abs = math.abs
acos = math.acos
asin = math.asin
atan = math.atan
atan2 = math.atan2
ceil = math.ceil
cos = math.cos
deg = math.deg
exp = math.exp
floor = math.floor
frexp = math.frexp
ldexp = math.ldexp
log = math.log
log10 = math.log10
max = math.max
min = math.min
mod = math.mod
PI = math.pi
--??? pow = math.pow  
rad = math.rad
random = math.random
randomseed = math.randomseed
sin = math.sin
sqrt = math.sqrt
tan = math.tan

-------------------------------------------------------------------
-- string library
strbyte = str.byte
strchar = str.char
concat = str.concat
strfind = str.find
format = str.format
gsub = str.gsub
strlen = str.len
strlower = str.lower
strrep = str.rep
strsub = str.sub
strupper = str.upper

-------------------------------------------------------------------
-- os library
clock = os.clock
date = os.date
difftime = os.difftime
execute = os.execute --?
exit = os.exit
getenv = os.getenv
remove = os.remove
rename = os.rename
setlocale = os.setlocale
time = os.time
tmpname = os.tmpname

-------------------------------------------------------------------
-- compatibility only
local g = globals
getglobal = function (n) return g()[n] end
setglobal = function (n,v) g()[n] = v end

-------------------------------------------------------------------

local io, tab = io, tab

-- IO library (files)
_STDIN = io.stdin
_STDERR = io.stderr
_STDOUT = io.stdout
_INPUT = io.stdin
_OUTPUT = io.stdout
seek = io.stdin.seek   -- sick ;-)
tmpfile = io.tmpfile
closefile = io.close
openfile = io.open

function flush (f)
  if f then f:flush()
  else _OUTPUT:flush()
  end
end

function readfrom (name)
  if name == nil then
    local f, err, cod = io.close(_INPUT)
    _INPUT = io.stdin
    return f, err, cod
  else
    local f, err, cod = io.open(name, "r")
    _INPUT = f or _INPUT
    return f, err, cod
  end
end

function writeto (name)
  if name == nil then
    local f, err, cod = io.close(_OUTPUT)
    _OUTPUT = io.stdout
    return f, err, cod
  else
    local f, err, cod = io.open(name, "w")
    _OUTPUT = f or _OUTPUT
    return f, err, cod
  end
end

function appendto (name)
  local f, err, cod = io.open(name, "a")
  _OUTPUT = f or _OUTPUT
  return f, err, cod
end

function read (...)
  local f = _INPUT
  if type(arg[1]) == 'userdata' then
    f = tab.remove(arg, 1)
  end
  return f:read(unpack(arg))
end

function write (...)
  local f = _OUTPUT
  if type(arg[1]) == 'userdata' then
    f = tab.remove(arg, 1)
  end
  return f:write(unpack(arg))
end

Reply | Threaded
Open this post in threaded view
|

RE: about the next version

Nick Trout-4
In reply to this post by Philippe Lhoste
> It is. Our idea is to provide a compatibility file, in Lua, that build
> the old library on top of the new one. Most of its work is 
> simply renaming:
> 
>    sin = math.sin
>    cos = math.cos
>    ...
> 
> A few functions need a real "implementation". Follows 
> attached a sketch of
> this file.

One comment which immediately springs to mind is please don't abbreviate the
module names!

table.foreach
table.getn
debug.getinfo
string.find
string.len

is much clearer and really not that much more effort?

By all means script the implementation simply but please keep the interface
names of the standard library meaningful. str or tab could be any number of
abbreviations.

Regards,
Nick


Reply | Threaded
Open this post in threaded view
|

Re[2]: about the next version

Denis Andreev
NT> One comment which immediately springs to mind is please don't abbreviate the
NT> module names!
NT> table.foreach
NT> table.getn
NT> debug.getinfo
NT> string.find
NT> string.len
NT> is much clearer and really not that much more effort?

I vote for this!

Please.


--Denq


Reply | Threaded
Open this post in threaded view
|

Re: about the next version

D Burgess-2
In reply to this post by Nick Trout-4
I prefer tab, dbg and str!




Reply | Threaded
Open this post in threaded view
|

Re[2]: about the next version

Antonio Scuri
In reply to this post by Denis Andreev
At 16:43 28/5/2002 +0400, you wrote:
NT> One comment which immediately springs to mind is please don't abbreviate the
NT> module names!
NT> table.foreach
NT> table.getn
NT> debug.getinfo
NT> string.find
NT> string.len
NT> is much clearer and really not that much more effort?

I vote for this!

  Another vote.

scuri


Reply | Threaded
Open this post in threaded view
|

RE: Re[2]: about the next version

Martin Stone-3
In reply to this post by Philippe Lhoste
>>NT> One comment which immediately springs to mind is please don't 
>>abbreviate the
>>NT> module names!
>>NT> table.foreach
>>NT> table.getn
>>NT> debug.getinfo
>>NT> string.find
>>NT> string.len
>>NT> is much clearer and really not that much more effort?
v>
v>I vote for this!
>
>   Another vote.

And another.


--------------------------------------------------------------------------------------------------------------------
This e-mail has been received from the Internet, scanned for viruses and forwarded to you after passing Acclaim's entrance criteria.
(acclaimstudios.co.uk)

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: about the next version

Peter Loveday-2
----- Original Message ----- 
From: "Martin Stone" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, May 28, 2002 9:00 AM
Subject: RE: Re[2]: about the next version


> >>NT> One comment which immediately springs to mind is please don't 
> >>abbreviate the
> >>NT> module names!
> >>NT> table.foreach
> >>NT> table.getn
> >>NT> debug.getinfo
> >>NT> string.find
> >>NT> string.len
> >>NT> is much clearer and really not that much more effort?
> v>
> v>I vote for this!
> >
> >   Another vote.
> 
> And another.
> 

Me too. Much nicer.

- Peter



Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: about the next version

Luiz Henrique de Figueiredo
In reply to this post by Philippe Lhoste
>One comment which immediately springs to mind is please don't 
>abbreviate the module names!

It will be impossible to please everyone. Please let's no start a religious
war about this.

Although it's not the best solution, you can always use your own names,
by simply writing things like "string = str" at the top of your programs.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Re[2]: about the next version

Nick Trout-4
> >One comment which immediately springs to mind is please don't 
> >abbreviate the module names!
> 
> It will be impossible to please everyone. Please let's no 
> start a religious
> war about this.
> 
> Although it's not the best solution, you can always use your 
> own names,
> by simply writing things like "string = str" at the top of 
> your programs.

There doesnt seem to be much of a religious war, most people seem in
agreement! :-)

The whole point of a standard library is that you just include the files and
write a script. I dont want to have to write "string = str" at the top of a
file. What you basically encourage there is non standard scripts being
written and everyone having their own coding standards - more difficult to
share/read code.

I dont want to come back to some code 6 months later and have to remember
str is a string, not a stream or a store. When/if the library expands you
may be thankful that the names are clearer as it removes ambiguity when
library names are similar. It may also help in building up a useful reusable
code base.

N




Reply | Threaded
Open this post in threaded view
|

Re[4]: about the next version

Denis Andreev

NT> What you basically encourage there is non standard scripts being written
NT> and everyone having their own coding standards - more difficult to
NT> share/read code.

That is exactily what I think.


--Denq


Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: about the next version

Antonio Scuri
In reply to this post by Luiz Henrique de Figueiredo
At 11:39 28/5/2002 -0300, you wrote:
>One comment which immediately springs to mind is please don't
>abbreviate the module names!

It will be impossible to please everyone. Please let's no start a religious
war about this.

  For me it does not make sense been economic using "tab" instead of "table".

"tab" is ambiguous and has a high probability to change in future versions, "table" is much more user friendly and definitely less ambiguous than "tab". That's why it called people's attention.

These small changes are very simple to be solved but it becomes harder and harder for an application that pass trough several versions of Lua and would like to evolve together with it without rewriting code. OH Here I go again....

  Sorry about the noise...

scuri