#######
#
# E-scripts on Flua, a Forth-like language written on top of Lua, Nasm
# and C.
#
# Note 1: use the eev command (defined in eev.el) and the
# ee alias (in my .zshrc) to execute parts of this file.
# Executing this file as a whole makes no sense.
# An introduction to eev can be found here:
#
#   (find-eev-quick-intro)
#   http://angg.twu.net/eev-intros/find-eev-quick-intro.html
#
# Note 2: be VERY careful and make sure you understand what
# you're doing.
#
# Note 3: If you use a shell other than zsh things like |&
# and the for loops may not work.
#
# Note 4: I always run as root.
#
# Note 5: some parts are too old and don't work anymore. Some
# never worked.
#
# Note 6: the definitions for the find-xxxfile commands are on my
# .emacs.
#
# Note 7: if you see a strange command check my .zshrc -- it may
# be defined there as a function or an alias.
#
# Note 8: the sections without dates are always older than the
# sections with dates.
#
# This file is at <http://angg.twu.net/e/flua.e>
#           or at <http://angg.twu.net/e/flua.e.html>.
#        See also <http://angg.twu.net/emacs.html>,
#                 <http://angg.twu.net/.emacs[.html]>,
#                 <http://angg.twu.net/.zshrc[.html]>,
#                 <http://angg.twu.net/escripts.html>,
#             and <http://angg.twu.net/>.
#
#######







# (code-c-d "flua" "~/LUA/flua-0.03/")
# (code-c-d "flua" "~/flua/")
# (find-fluafile "")
# (find-fluafile "Makefile")



#####
#
# Test to see if the package is OK
#
#####

#*
cd ~/flua/  && rm *.tar.gz
make tgz
rm -R /tmp/flua/
mkdir /tmp/flua/
cd    /tmp/flua/
tar -xvzf ~/flua/flua-0.03.tar.gz
make

#*
# (find-fline "/tmp/flua/")



--> edrx (edrx@200.240.18.96) has joined #forth
--- Topic for #forth is : puts 0 parse type cr ; puts Hello, World!
--- Topic for #forth set by cleverdra at Sat Jul  7 11:17:52
<MrReach> hiya, edrx
<cleverdra> Perl itself is fairly portable.  pcre is theoretically so.  ed's is as portable as unix(!)  the GNU regexp library is as portable as GNU, probably.  FOSM's is ANS Forth, and small enough and simple enough and cool enough that porting it won't be too difficult.
<cleverdra> hello edrx.
--- cleverdra gives channel operator status to edrx
<edrx> hi all
<edrx> Who or what is FOSM?
<MrReach> <cleverdra> ftp://ftp.forth.org/pub/Forth/Applications/fosm1v1.zip
<MrReach> <cleverdra> http://www.forth.org/ftpsearch.html is somewhat useful.
<cleverdra> FOSM's documentation is quite informative.
<edrx> I just got rid of a difficult presentation that I had to give at the university and now I can resume working in Flua
<cleverdra> Flua?
<edrx> it is quite non-standard, and I'd like to make it support ANS Forth words at some point
<edrx> a variante of Forth, with a byte-oriented inner interpreter
<cleverdra> Oh, cool.  How does that work?
<cleverdra> I mean, with only 256 values as a range, I don't understand how byte-oriented inner interpreters work.
<edrx> I'll explain the byte-orientation stuff in a moment... currently flua is a Lua program that interprets a string as a Flua program and generates a nasm file that will then be converted to real bytecode, and C file for the engine
<edrx> and a nice thing about generating nasm is that is it easy to generate a nice .lst file
<cleverdra> Yes.  A perl program named perpol generates nasm from Forth source.
<edrx> perpol was my first inspiration :)
<cleverdra> Oh =)  I know you!
<edrx> http://angg.twu.net/LUA/flua-0.02/
<cleverdra> You wrote braincram, right?
<edrx> no, that was not me...
<edrx> are you the author of perpol?
<edrx> (look at the .bytecode.lst files in that dir)
<cleverdra> Oh, when you said "first inspiration", I thought you meant that you'd written it first.
<edrx> no, I started several years ago with the byte-orientation idea (first with a PFE extension) but perpol's idea of using nasm made everything much easier
<edrx> I'm fixing something in my home page, brb
<edrx> fixed it - take a look at http://angg.twu.net/LUA/flua-0.02/flua-demos.lua.html#flua_demo2
<edrx> and at its bytecode.lst file
<edrx> heads (CFAs) are one-byte long each
<edrx> a word may have several heads
<edrx> a variable (FOO in the example) has three heads
<edrx> 10 &FOO !  works as  10 FOO!
<edrx> after that FOO returns 10
<edrx> some primitives (look at the "db SF_TOS" in the .lst file, for example) are one byte long
<edrx> some others have only two-byte versions
<edrx> the inner interpreter must cope with that, of course - it reads the first byte and it is too high then it consults the table of one-bye instructions
<edrx> s/it is/ if it is/
<edrx> the syntax of the flua code in the example is far too weird, I haven't had time to put it in a more modern, more Forth-like form
<edrx> % SQUARE : DUP * ;  will become  % SQUARE COL: DUP * ;  where I still want to write it using the old, low-level syntax
<edrx> but there will be also a  : SQUARE DUP * ;  form
<edrx> and the nicest thing about Flua is that it is very easy to create words that parse the following bytes as immediate data, like <.">
<edrx> due to the RSR words
<edrx> but I'll only describe that if you are listening :)
* cleverdra nods.
<cleverdra> I'm listening =)  I was distracted just now with a question in #Perl.
<cleverdra> The definitions do look different.  Why are you changing : to COL:, there?
<edrx> because the "compiler" in Lua was very low-level at first
<edrx> "%" parsed the next word and declared the next address as being the definition of that word
<cleverdra> I figured that.  : just turns the compiler on?
<edrx> there is no compiler, everything is immediate (that was just a very early prototype)
<cleverdra> I'm afraid that I don't quite understand this lua source.
<cleverdra> Oh.
<edrx> because if the RSR words and other weirdnesses of multi-headed words I couldn't figure out a nice syntax, so I decided to start with a low-level thing and let the ideas about syntax come later
<edrx> the RSR trick is the following... lemme start with the definition of <."> as an example...
<edrx> there is a third stack, called the "streams stack"; >S and S> move a value between that stack and the data stack
<cleverdra> OK.
<edrx> as you execute <."> the RSR trick (that I'll describe in a moment...) moves the address past the place where <."> was called to the streams stack;
<edrx> then S<."> is executed, and when S<."> ends the top word in the streams stack is moved back to the return stack, so we return to the new position stored in that value.
<edrx> that makes it very easy to define words like S2<."> , that do two S<.">s in sequence...
<edrx> and, as you can see, the definition of <."> is just one byte long - the RSR: head
<cleverdra> Yes, that's cool =)
<edrx> following it there is a standard COL: head, that will be executed with top return address already moved to the S stack, and when it return the top address at the return stack is the address of a special routine that moves the top of S back to R.
<edrx> that's it. And the nasm/.lst thing was a sort of a proof of concept that it would be easier to understand the bytecode generated by a Forth if we could see it in such a format... I was never able to understand the format to which GForth compiles, btw.
--- MrReach is now known as MrSeattle
<edrx> oh, and I like to have the dictionary in a separate area... if a program gets to a stable state where it doesn't need the interpreter anymore then it is trivial to throw out the dictionary.
<edrx> I'm going to use Lua for the dictionary/interpreter things
<cleverdra> That's kinda wierd.  OK.
<edrx> demo5 is already able to call lua words from flua
<edrx> and standard C words, like strlen
<edrx> it's the anti-eForth approach :)





#  Local Variables:
#  coding:               utf-8-unix
#  End: