EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Why we want Lua on the IOC
From: Ben Franksen <[email protected]>
To: <[email protected]>
Date: Thu, 23 Feb 2017 23:00:21 +0100
Some people (Ralph?) mentioned that embedding Lua on EPICS IOCs might be
a good idea, perhaps even as a replacement for the iocsh. Prompted by
this I have been reading up on Lua, which, until now, I had dismissed as
yet another boring dynamically typed imperative/OO language (yawn). I
was wrong.

Yes, the language is procedural, imperative, with some OO features,
nothing spectacular. But it does have a number of features that make it
particularly suitable for EPICS. First of all, it has been designed from
the ground up for embedding in a host program. It is very small and
light-weight, so could easily run on 'real' IOCs, even on small devices.
Its language features have been carefully selected to offer only what
can be easily interacted with from a host program written in C. The
language itself is extremely simple, very much suitable for users who
are not professional programmers (constrast that with Unix shell
programming). The syntax is not whitespace (layout) sensitive, allowing
to write and execute simple programs on a terminal without any advanced
line-editing features; yet semicolons between statements are optional
(like in Eiffel, if anyone rembers that one). It has first class and
anonymous functions but provides syntactic sugar for the conventional
style of (named) function definitions. Registering C functions for Lua
(from the host program) is a straight forward exercise, requiring less
boilerplate than for the iocsh. Lua supports one and only one structured
data type, the table, which is enough for programming inside Lua. The
host program can add abstract data types and can even overload operators
or table key selection for them, giving users an OO-like API due to
support for first class functions.

Given appropriate support from the host (EPICS base) it could be used to
write simple "EPICS scripts" to be executed directly by the (Lua) shell,
for instance to access and manipulate the database (static and dynamic);
or one could conditionally configure a driver with different parameters,
depending on a configuration option; or start sequencer programs in a
loop. I would even consider adding a sequencer-like extension.

The only downside I can see at the moment (others will surely provide
more) is that strings must be quoted, which is a bit inconventient for
an interactive shell. (At least, as in Perl and in contrast to Python,
you can use identifiers (barewords in Perl speak) as table keys.)

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


Replies:
RE: Why we want Lua on the IOC Mark Rivers

Navigate by Date:
Prev: Jenkins build is back to normal : epics-base-3.16-linux32-test #44 APS Jenkins
Next: RE: Why we want Lua on the IOC Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Jenkins build is back to normal : epics-base-3.16-linux32-test #44 APS Jenkins
Next: RE: Why we want Lua on the IOC Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024