On 2017-11-07 17:42, Mike Kerner via use-livecode wrote:
No, the ERP is written in HP BASIC, so I would want to emulate the
language, given the breadth and number of programs. I was thinking
about
writing wrappers for the various commands and functions of the
language,
but it won't be easy, no matter what I do.
In this case 'ease' is probably related to the breadth of the language
and how complex individual commands/functions are - if you have a good
architecture for the emulator, most of the work will be in recreating
that functionality, rather than the parsing/execution mechanism.
There are also binary resources that I would have to have recreated
such as
forms and dialogs, and I would have to take the db schemas and convert
them
to a modern database, which seems like the least work of this entire
silly
idea.
From what you've said it doesn't sound like a silly idea at all.
Would it be less work to rewrite it? I doubt it. Would it be less
effort
to cough up for an off-the-self ERP package? Possibly, but the one
piece
that is extremely valuable is the payroll piece, because it is so
expensive
to hire a service or to pay for someone else's payroll software. For
example, look at the time and attendance piece. I was able to write a
timeclock app that runs on a tablet for a tiny fraction of what it
would
cost to replace the existing timeclocks. Timekeeping software is also
crazy expensive, and payroll is akin to highway robbery.
If it is a system you've been maintaining for 30 years, then I suspect
you are correct - it won't be less work to rewrite as you'll spend a lot
of time making things work as they did before... After all, I suspect
that after 30 years working on it even you can't remember where all the
bodies are buried!
(I certainly find zombies popping up now and again to bite me in the
LiveCode engine from things I've done in the past!)
Would it be easier to try to build an emulator in Xojo? I've thought
about
it, but before I add yet another development tool to the mix, here, I
thought I'd chase this idea, first.
Well I can certainly say that LiveCode is perfectly capable, and indeed
very good for writing compilers/interpreters because of the way its
arrays work (copy-on-write in particular), and the ability to pass
references to array elements to functions. (I've writing a few such
things in the last 12 months - the SVG compiler being the most recent
example).
I'd generally recommend using a LiveCode array to represent the source
structure (after parsing - which will be a tree), and then write a
recursive evaluator for it, threading through the node which is being
executed and a mutable context array which contains all the current
execution state:
on langExecute @xContext, pNode
- dispatch to do what you need to do for node, using state from
xContext
end langExecute
If you can figure out how to map the source language to (essentially) a
sequence of command invocations, then you can write the each piece of
functionality provided by the language (i.e. the bits other than
variable manipulations and control transfer) as a single handler which
takes the xContext parameter.
Okay, so all the above is a bit vague - but it is just to give an idea
of how I've found the best way to structure such things in LiveCode.
Warmest Regards,
P.S. Do you have the online links for the reference manuals? I'm
intrigued...
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
