World: r3wp

Version 0.3.0 of BBC BASIC uploaded. Added the rest of the string 
handling: LEFT$, MID$, RIGHT$, STRING$ and INSTR. Added ON, that 
can change the order of execution. Added DIM, which implement arrays. 
Both for integers, reals and strings. To run:
>> do http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.r

List of keywords: http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.html

Arrays are indexed from zero. Arrays can also be used to index other 
arrays. Example:

>dim name$(4)
>dim a(1,1)
>name$(3)="Joe"
>a(1,0)=3
>print name$(a(1,0))
Joe

BBC BASIC v. 0.4.0 uploaded. Added procedures and local variables 
(DEF PROC, ENDPROC and LOCAL). Added TIME, RND and EVAL. Added better 
error handling. Next thing will be functions, but I'll test procedures 
some more first. The implementation is based on this user guide: 
http://www.nvg.ntnu.no/bbc/doc/BBCUserGuide-1.00.pdf

It's now almost 1400 lines of REBOL source. But still only 4922 bytes 
compressed.

Example use of local variables. In line 70, 'a' is local, because 
it's a parameter to the procedure, 'b' is still global. After line 
80, 'b' also become local to the procedure. After returning from 
the procedure, both 'a' and 'b' are set back to their global values. 
In 'proctest', 'a' could have been called anything without changing 
the global 'a'.

>> do http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.html
Script: "BBC BASIC" (27-Jul-2007)
BASIC v. 0.4.0 

>auto
   10 a=42
   20 b=1
   30 proctest(a)
   40 print "line 40 : a=";a " b=";b
   50 end
   60 def proctest(a)
   70 print "line 70 : a=";a " b=";b
   80 local b
   90 a=2:b=2
  100 print "line 100: a=";a " b=";b
  110 endproc
  120 0
>50end
>run
line 70 : a=        42 b=         1
line 100: a=         2 b=         2
line 40 : a=        42 b=         1

Ups, the line
>50end

after the program shouldn't have been there, so forget that (even 
if it works with it included).

There still need to be work done on formatted output (PRINT and INPUT 
statements).

So far, I've allowed keywords to be either UPPER- or lower-case. 
I think, I have to restrict them to UPPER-case like in traditional 
BASIC. Problem is with variable names being assigned by the LET statement. 
If I define a variable "length":
LET length=10

and then use it in some expression, the first part of the variable 
name is being recognized as the LEN function. In the original BBC 
BASIC, the above LET statement is ok, while you can't write:
LET LENGTH=10

, which will give a syntax error. I conclude, I have to restrict 
keywords to UPPER-case and then check, when the variables are being 
defined, so their names don't collide with keywords.

This probably the same reason, words are separated by space in REBOL.

This *is* ...

It's rather difficult to implement functions (user functions, which 
the BBC BASIC language support), with the implementing method, I've 
choosed. Problem is, that the return point need to be saved, while 
the function code is running. The problem is the same with statements 
like GOSUB and PROC (procedures), but so far, I've just put some 
restrictions on those. In this basic, more than one statement can 
be on each line, if they're separated by colons, ':'. The way it's 
implemented, this example give a syntax error:
GOSUB 100:PRINT "I'm back"

My implementation require, that the return point is the next line. 
That isn't good enough with functions, because they're used in the 
middle of other statements. Examples:

PRINT FNone_function, FNanother_function
IF FNmyfunc=42 THEN PRINT "It's 42!"


The return point for those need to be in the middle of a statement, 
in the middle of a line. So I'm at a point, where I consider another 
implementation of all the statements (more like a real emulation 
of the BBC computer) or if I just should say "the heck with it" and 
move on to some other language or another version of a new BASIC 
language.

Comments!?

Comments, hmmm.  You've done an awesome job John.  I learned Z-80 
assembler back on my TRS-80 before I did much BASIC.  When they finally 
got a computer class in my high school for ninth graders, I was already 
in grade 12 and laughed at the BASIC.  So, instead of having me whining 
and whinging all class, I got to write a student database program 
in assembler for my electronics teacher on the Commodore PET.  Never 
been a fan of BASIC, but what you've done can only attract a larger 
REBOL audience so well done.  If you can make it compatible enough 
to run old DOS frogger.bas you may have a demo that gains worldwide 
attention.


Technically, back to your point, (having sadly only glossed over 
your codebase), what if you tricked the "line" internals say with 
pair! or decimal! keeping your own sub-lines invisible to the user?


And if you start up a Forth dialect...I'm in.   Or at least will 
show a keener interest watching a guru at work   :)

Thanks for the input! I thought about something similar, having a 
sub-pointer as you speak of. It could work. But I got the feeling, 
it'll be a better design, if it's done like the original, using an 
internal format with byte-code for the keywords. I have to judge, 
how much work it is.


I'm interested in Greggs original ideas, which got me going with 
this, to implement different languages. I'll consider Forth as the 
next one.

Forth has a very (untouchable actually) immersive feel to it.  As 
long as you avoid working with the sad sad current trend of text 
file forth, everything you do in Forth is Forth.  Editor commands...Forth, 
disk management Forth, debugger Forth, locate and cross reference, 
Forth.  Anyway I'm still questing for a REBOL enviroment that allows 
that immersive feel.  No brain switching to Editor, back to console 
command brain, then another brain switch to file manager, bobloblaw. 
 Mondo powerful when you can keep your brain in one mode for a full 
eight hours.  Even building Forth was Forth.  I do kinda miss it, 
but only for semimental reasons.  REBOL is just too cool to think 
about going back.

John, it sounds great. I'm just totally strapped for time, or I'd 
be in there baning on it and learning from what you've done.

What is a good Forth version as a reference system? ANS Forth? I 
also need a place to look, where the language is explained in a clear 
and short form.

http://www.retroforth.org/
http://www.colorforth.com/cf.html
http://www.xs4all.nl/~thebeez/4tH/4thide.htm
http://maschenwerk.de/foerthchen/

http://www.fig-uk.org/byof.htm
http://www.complang.tuwien.ac.at/forth/threaded-code.html

http://www.amresearch.com/starting_forth/
http://thinking-forth.sourceforge.net/
http://www.ultratechnology.com/1xforth.htm

http://c2.com/cgi/wiki?ForthLanguage

I have a lot more links here as well, but the best reference may 
be Brian, since he was a real live Forth user. I also have a couple 
books on my shelf, but...

Leo Brodie's books, Starting Forth and Thinking Forth, are the seminal 
works on the language.

You beat me to it Gregg.  Starting Forth by Leo Brodie.  It includes 
the old school (and really the only reason to use Forth) block editor. 
 Without the block editor Forth is pretty much just another language, 
with it (and after getting used to EDLIN style editing), you get 
the immersive holy grail.  Thinking Forth is quite a bit more cerebral, 
but I know it's been made available in PDF, but I found this...

http://home.iae.nl/users/mhx/sf.htmlso far.

Never mind the link so much.  just a dup of one of Greggs.

I never got into Forth more than playing around, but I *love* the 
idea of the immersive experience. REBOL is that in many ways for 
me, because I can think about so many things using REBOL as a context. 
I think the idea of dialects could lead us to domain specific environments 
that are like Forth, in that they are highly focused and immersive.

Forth Inc will send you a copy of of Swiift   http://www.forth.com
 it has a block editor, but they've moved away from supporting it 
so they could 'do Windows'...a pity.  And wait...did I say Forth 
was "just another language"?  Where did THAT come from?   Long live 
REBOL.  :)

:-)

Ok, I'll read some more of this. I've already started a dialect (more 
like an intepreter as with BASIC). I'll have a real REBOL dialect 
(that can be used in the middle of REBOL scripts) in mind as well, 
as I go along.

[InfoQ Article]

Language-oriented programming : an evolutionary step beyond object-oriented 
programming?
http://www.infoq.com/news/2007/09/Language-oriented-programming


Fowler defined this concept as “the general style of development 
which operates about the idea of building software around a set of 
domain specific languages”.

According to Martin Fowler object-oriented 
domain modelling allows to “build up a vocabulary” but the grammar 
– ways to combine these vocabularies – is not defined; DSLs add this 
grammar side. Therefore language-oriented programming inducts “this 
shift of moving from thinking about vocabulary, which is objects, 
to the notion of a language that combines vocabulary and grammar.”

Interesting article Richard.

I wonder of any of those well versed in languages (Greg, btiffin, 
Geomol, Max to name a few) would want to respond to this posted question 
related to the above article  "What language you would use to develop 
DSL?" ?

If I had to quickly pick an order;  REBOL, Forth, SNOBOL, Lisp.  
If I was told I HAD to do it in a class based object oriented language 
I'd probably pick SmallTalk ... no ... I'd probably just leave.  
To be honest, I've rarley seen a DSL that didn't require a programmer 
to script it anyway, so... I find the whole thing kind of moot.  
Moot is the wrong word.  A non-coder MIGHT be able to VID up a GUI 
but I doubt it would do much...or by the time they were done, the 
non-coder would have unknowningly become a coder.  I've not seen 
a DSL I'd turn over to Bob the manager to write progams in.  Even 
languages written to be specific; Erlang for telephony, Forth for 
telescopes, are still programmer languages. REBOL comes soooo close 
to being a data language that humans can use...but unfortunately 
nope;  Programmers required.  The magic all happens when you can 
build up layers, and stand on the shoulders of giants.  Something 
hardware engineers have been doing since day 1...programmers might 
learn by day 32'767 if we get lucky.  No doubt our smartest programmers 
will be fussing with strings 50 years from now with the same basic 
problems and mind sets faced 50 years ago.

A. It doesn't matter what language you use.  That's like two kids 
that speak English saying.. "lets invent a new language..  what language 
should we use to invent it with?"

I'm going to try to make time to respond on the ML later today. It's 
a good topic.

It matters if it's a dialect Terry. If you wanted to create a special 
language to discuss neclear physics, do you think it would make a 
difference if you based it on a Mathematical foundation versus Basque?

Read this today, re programming language choice; http://www.paulgraham.com/icad.html
  Down near the bottom is the Appendix: Power. and leads to http://www.paulgraham.com/accgen.html
 I can read the languages he uses as examples, but only a few of 
them come close to the readability of   foo: func [n] [func [i] [n: 
n + i]]  or am I just too sucked into REBOL/Think?  It's too bad 
the page has extra space around the brackets, as at a quick glance 
REBOL would be in the top four shortest. It's as quick grokable (meaning 
a quick glance implies a function returning a function that accumulates) 
 as Dylan, LUA, Javascript and NewtonScript.  And who uses Javascript? 
 :)

hmm, but  foo: func [n] [func [i] [n: n + i]] is wrong

foo: closure [n] [func [i] [n: n + i]] is necessary for this to work 
reliably

example:

    f1: foo 1 f2: foo 2

    f1 1

should yield 2, not 3!

another reliable implementation not using closure: foo: func [n] 
[use [m] [m: n func [i] [m: m + i]]]

Learn something new here everyday.  :)

In this context I am not going to offer the Curl examples for DSL 
and pass-the-proc except to say that ... no , I won't say that either 
;-)

But Gregg, the reference was towards a "language that combines vocabulary 
and grammar"...  sounds more like "Energy equals mass times the speed 
of light squared", rather than E = MC2

I understand; my point was that mathematics, as a foundation, allows 
you to express things in a domain that Basque, historically, does 
not. A DSL doesn't *have* to be an extension or outgrowth of an existing 
language, but that can often help. In order for tha that to work, 
you need to choose a base language that suits your needs.

Has anyone written a dialect to capture live sports action?  Here 
are some examples of the types of items needed to be captured...

Volleyball... http://www.wnmu.edu/athletic/stats/07vb/29wnmu.htm#GAME.PLY

Hockey... http://www.nhl.com/scores/htmlreports/20072008/PL030416.HTM

Soccer... http://www.uefa.com/competitions/ucl/fixturesresults/round=15109/match=301604/report=mbm.html

what would the dialect do?

What I am going to attempt is a dialect that will respond to single 
key-strokes to tell the story of a match and at the same time capture 
the statics for the live game.  Hopefully the end result  will lead 
to many different tools based on this data such as statistics visualizations 
in the form of data summaries/reports and charts.

It looks pretty parse friendly.

The sport I am most interested in doing this for is Volleyball as 
I have experience coaching this sport.

Yes, I was thinking parse would likely be the way to go.

Each skill would be given a character on the keyboard and would expect 
it to be followed by a player number and the level of success of 
the player attempting the skill.

As I haven't worked much with Dialects I wasn't terribly sure how 
to start, so was looking for some dialect examples that might influence 
my starting point.