r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Dialects] Questions about how to create dialects

Ladislav
2-Nov-2005
[79]
>> reduce/only [a b c d] [b c d]
== [1 b c d]
Volker
2-Nov-2005
[80]
Maybe we need both reduce? AFAIK currently it is to have a reduce 
which allows keywords.
JaimeVargas
2-Nov-2005
[81]
Ah. Interesting. I think I needed this in the past I didn't know 
it existed.
Volker
2-Nov-2005
[82]
Good idea IMHO. Sadly i managed to crash it in my first try.
JaimeVargas
2-Nov-2005
[83]
I wish build was part of rebol. I find it a lot easier to use than 
compose. Only that slower.
Sunanda
21-Mar-2006
[84]
Bill Gates says "We need dialects"
http://microformats.org

(Actually he said "microformats" -- but I can't see any real difference 
in intent)
DideC
22-Mar-2006
[85]
Hum, not sure it's dialect equivalent. It looks like some "XML samples" 
to replace existing text format (ie iCal => hCalendar)
Maxim
22-Mar-2006
[86]
IMO nothing to do with dialect... AFAICT they are simply structured 
xml definitions...
Allen
22-Mar-2006
[87]
vCard --> iCard --> hCard  ... plenty of alphabet to go for future 
formats ;-)
Maxim
22-Mar-2006
[88]
just keep "R"  for us... we should patent the letter "R"   ;-)
Allen
22-Mar-2006
[89]
Well nothing stopping us from doing the same thing. Just do a like 
for like conversion as they did, but do it into rebol format instead 
of xml or xhtml
Gregg
24-Mar-2006
[90]
Visual Studio is getting DSL support, along the lines of what JetBrains 
has done I think. There's a team blogging about it inside MS, so 
I think Bill and Co. *do* think we need them (they're just doing 
it wrong ;-).
Thør
2-Apr-2006
[91]
initial sync...
Thør
26-May-2006
[92]
.
btiffin
15-Sep-2006
[93]
Requesting Opinions.  Being a crusty old forther, I really really 
miss the immersive nature of the block editor environment.  Coding 
in forth meant never leaving forth.  Editor, debugger, disk drivers 
etc... all forth commands.  No need to ever have the brain exit forth 
mode.  Now that Rebol is my language of the future, I kinda pine 
for the past.  The wonder and beauty of Rebol keeps being interrupted 
by decisions on what to use to edit that last little bit of script. 
 Notepad, Crimson Editor, Rebol editor? A small annoyance but it 
still disrupts the brain from getting to streaming mode.  So now 
to the question.  My first crack at a forth block editor dialect 
failed miserably.  Dialects need to be LOADable for parse to function. 
 Editing source code makes for unloadable situations.  Do I just 
give up on it and learn to live in the third millenium?  Write a 
utility that doesn't use dialects (which seems to unRebol the solution)? 
 I thought I'd ask you guys, just in case there is a light shining 
in front of me that I can't see.  Thanks in advance.
Graham
15-Sep-2006
[94]
forth editors used to access the hard drive sectors directly.  You 
want to do that?
btiffin
15-Sep-2006
[95]
Not really, just emulate the immersiveness.  I dealt with 16 lines 
of 64 characters for so many years that my little utility (in menta-space) 
uses a 32 by 80 character screen but all the output is normal text 
(with those confounded carriage returns).  We used shadows blocks 
extensively and I got so used to the technical docs being single 
letter command away...Just pineing.  Aside from that, is there a 
way to feed the string  $1,000,000  into block parsing?
Graham
15-Sep-2006
[96x2]
block parsing ...
some tricky things as it tries to identify datatypes
btiffin
15-Sep-2006
[98]
yeah exactly.  The unRebol way is to just string parse and then take 
the first token as a command...seems unworthy.  But I am willing 
to put up with a mirage for that immersive looky feely.
Anton
15-Sep-2006
[99]
Well, I've never gone Forth, and I'm not sure what a block editor 
is, but maybe you can benefit from some console commands. I almost 
always use Crimson Editor. I have an EDIT command which launches 
Crimson Editor, and I navigate the filesystem in the rebol console 
using dir-utils.r, which supplies unix-like filesystem commands; 
CD, LS, MV etc.
http://anton.wildit.net.au/rebol/os/windows/edit.r
http://anton.wildit.net.au/rebol/library/dir-utils.r
btiffin
15-Sep-2006
[100]
The Ctrl-E execute trick in Crimson is close but it is still a mental 
context switch.  Editor -> Rebol -> editor -> etc...  My old mantra 
was "Compile Link Go...Away, Go Go Go is much better"
Anton
15-Sep-2006
[101x2]
How do you launch rebol otherwise ?

I've set up my start menu so it's a few key presses away. The sequence 
is: Ctrl-Esc (to open the menu), down right down enter. (Actually 
now I think about it, I can reduce this a little bit.)
I'm actually not using Ctrl-E in Crimson Editor. It's just not as 
simple as launching it yourself, and every editor does it differently.
btiffin
15-Sep-2006
[103]
I have Crimson and Rebol/View as Quick Launch buttons on the windows 
taskbar.  But still...that mental switch.
Anton
15-Sep-2006
[104]
So the mental switch is between the editor and the rebol console, 
being separate applications.
Henrik
15-Sep-2006
[105]
this is not entirely related, I think (I'm only a bit above beginner's 
level, so I may not be understanding your problem right) but I wrote 
a tool some time ago called Tester. It allows you to write code and 
test it directly without leaving the environment. This is not an 
editor per se, but a rigid workflow tool to write and test code. 
You can read about it in the !Tester group.
btiffin
15-Sep-2006
[106x2]
Yep.  A small annoyance...Rebol is more than worth it.  I probably 
just give in to the current state of editor/language being two different 
planes of existence.
Thanks Henrik I'll take a look.
Graham
15-Sep-2006
[108]
you can execute inside the editor
btiffin
15-Sep-2006
[109]
Graham; Yep.  Things are close.  I'll get over it someday.  But can 
you imagine the nirvana of a Rebol console/editor?
Rebolek
15-Sep-2006
[110x2]
there is REBOL console editor in library.
http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rem-ext42.r&sid=mkjym6ig
btiffin
15-Sep-2006
[112]
Thanks Rebolek, I'll take a second look at this app.  I've let the 
discussion move a little too far from Dialecting, so thanks everybody. 
 Just needed to talk a little bit about it.
Rebolek
15-Sep-2006
[113]
btfiffin: I'm not sure how it works with latest REBOL, I had some 
problems. If it does not work, contact me privately, I have patched 
version
btiffin
15-Sep-2006
[114]
Rebolek; Cool, thanks.
Volker
15-Sep-2006
[115]
I am not sure where your focus is.
Editor-dialect: put the edited code in strings, like
[ #1 {io-code} #2 {gui}]

Patch the inbuild editor to load and store there, instead iof storing 
to files.

And from the console a simple "ed #2" would edit it. but still in 
a seperate window.

Console: Or is it about that seperate window, do you want inside 
that rebol-console-window? More work, but rem-edit does that, maybe 
its author would help with fixing.
btiffin
15-Sep-2006
[116x2]
Sorry for the confusion here.  A forth "block" editor, uses a 1K 
chunk of disk as 16 lines of 64 characters.  There are forth words 
for the editor e.g.  9 LIST ( list block 9)     3 T ( Highlight line 
3)  P newword: ( n - n) DUP . ;   ( place the text "newword: ..." 
to end of command line onto line 3.  What you get is an editor that 
uses the same language that you are programming in.  Immersive.
Sorry Technically Inaccurate Typo.  newword: DUP . ;  would not compile 
in forth.  : newword DUP . ;  is correct.  Long Live Rebol.
Volker
16-Sep-2006
[118]
rebol [
    Title: "Immersive" 
    Usage: {
>> fed
fed> p 3 This is a demo line, its not loadable :)
p with 3 " This is a demo line, its not loadable :)"
fed> print "This is pure rebol"
This is pure rebol
fed> "this too"
== "this too"
fed>
}
] 
ctx-fed: context [
    arg-lens: [p 2] 
    line: cmd: none 
    last-err: none 

    p: func [lineno line] [print ["p with" lineno mold line] exit] 
    t: func [lineno] [print ["t with" lineno] exit] 
    e: func ["format err"] [throw last-err] 
    do-line: func [line /local arg-len-pos res] [
        set [val rest] load/next line 
        either arg-len-pos: find/skip arg-lens val 2 [
            cmd: reduce [val] 
            loop arg-len-pos/2 - 1 [
                set [val rest] load/next rest 
                append cmd val
            ] 
            append cmd rest
        ] [
            cmd: load/all line
        ] 
        bind cmd self 
        case [
            error? set/any 'res try [do cmd] [
                probe disarm last-err: res
            ] 
            value? 'res [print ["==" mold :res]]
        ]
    ] 
    rebol/words/fed: func [] [
        forever [
            do-line ask "fed> "
        ]
    ]
] 
fed
Gregg
18-Sep-2006
[119]
Clever as ususal Volker! I think that's the right idea as well; just 
use the console with the expected commands built in, including block 
I/O. LOADability is important for REBOL dialects, but that doesn't 
mean you can't write an interpreter that parses strings if that's 
what you want and need. Personally, I greatly prefer true dialects 
for the power they provide.


Ultimately, Brian, a dialect should be what you want it to be, and 
the more interactive things are, the better (IMO). I'd love to see 
more interactive dialects like this.
btiffin
19-Sep-2006
[120x2]
Hey, thanks for the interest Volker.  And Gregg thanks for the comments. 
 But I'm still kinda stuck on an editor dialect that could handle 
random text in a parse block.  Even the nifty fed above will break 
on   "p $10,000,000" as rebol can't quite form a money value out 
of $10,000,000.  So the basic question exists.  Is there a way to 
block parse random potentially unloadable text?
Sorry Volker, missed the lineno arg to the p command.  Nice.
Anton
20-Sep-2006
[122]
Brian, I think you would have to write your own load-parser, that 
can, first of all, match brackets [] {} "", including escaping strings, 
"^"", load well-formed rebol values etc.. as well as be able to handle 
non-matching brackets and ill-formed rebol values.
This is a tough job.

The essence of the problem is that if the file is not fully loadable, 
then you can't be sure that *any* part of it that you might be looking 
at is a properly formed value. For example, if there is one extra 
unmatched } at the end of the file, does that imply that the whole 
lot was supposed to be a string ? Would that mean that all the prior 
text shouldn't be treated as individual values then ?
Gregg
21-Sep-2006
[123]
My preference is to use block parsing whenever possible, and trap 
errors so you can warn if something isn't valid. Block parsing is 
just so much more powerful than string parsing, it's hard to give 
it up.


Of course, there are improvements I would like to see, so more "normal" 
text can load successfully; things like 50%, or 33MPH. Maybe R3 and 
custom datatypes will offer something in the area of expanded lexical 
forms. In any case, we should identify the most important things 
that don't load today and see if RT can do something about them. 
:-)
Maxim
21-Sep-2006
[124]
funny, in experience, I find it easier in many cases to do a hybrid 
model.  one where you load the string into some block you can then 
more easily parse.  There are many kinds of real-world data which 
is not easily loadable in REBOL and in cases where you must make 
a dialect over some outside data... blocks are rarely useable.
Gregg
21-Sep-2006
[125]
Agreed. What I often do is "parse" the data, using standard string 
manipulation, not really thinking as a dialect, and then writing 
a dialect against the loaded data.
Maxim
21-Sep-2006
[126x2]
exactly.
the hybrid model is much easier to "Get things done"
btiffin
21-Sep-2006
[128]
So the pros don't seem to mind a string parse followed by a block 
parse?