• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

Scot
22-Dec-2012
[278]
Andreas:  Sorry. I wasn't really commenting as much on Make-Doc-Pro 
as the impending realization that we are going to see a ton of forks 
branching off.  Make-Doc and Make-Doc-Pro have been associated in 
my mind with the "official" RT over the years. 


Hopefully the R3 team will be able to keep this thing focused.  Still 
not sure who those people are.  As long as Mark Down is pure Rebol, 
I suppose I don't have much preference.  Rebol has always taken the 
high road, so if MDP is better, I think we should stick with it. 
 Widespread adoption has never been as important as top quality better 
design.


If we continue to adopt whatever is widespread we'll end up losing 
everything that is better.  Amiga OS, Be OS, QNX Nutrino, etc.  All 
far better OS designs than Unix and Windows NT.  What do we end up 
with?  Unix and NT and of course the dreaded DOM (don't try to convince 
me that a flavor of Linux is anything more than a Unix OS).


So better is better.  If MDP is better, then we should adopt it, 
not because it is widespread, but because it is better.
Robert
22-Dec-2012
[279]
The thing is that MD markup is supported by quite some Wiki engines 
etc.
Henrik
22-Dec-2012
[280]
MDP struggles with markdown syntax. We talked about rewriting it 
with a cleaner implementation.
Scot
22-Dec-2012
[281]
I write my code in Rebol, because the concepts behind Rebol are the 
most advanced and human centered I've found (I have written code 
in 30 languages and now that I've seen the source I code I can tell 
you it is by far the most elegant thing I've ever seen.
AdrianS
22-Dec-2012
[282]
Henrik: So MDP was intended to parse Markdown syntax to a certain 
degree?
Scot
22-Dec-2012
[283]
Robert:  Do it.  Make MDP cleaner.  Then we make a Wiki that uses 
the cleaner MDP.  Or fix MarkDown so it is better than MDP.
AdrianS
22-Dec-2012
[284]
Scot, any markup could be parsed/processed by Rebol. So my question 
here was about the syntax/features.
Henrik
22-Dec-2012
[285x3]
AdrianS: I'm not sure of the origins, but it has some problems with 
nested styles, using them inside () and use of styles with no spaces.
You can't inline URLs either.
I would like to see an MDP that was built on top of markdown, which 
then utilizes headlines, TOC and glossary.
Scot
22-Dec-2012
[288]
AdrianS:  That is a better question.  What have we learned about 
the approach taken by MDP versus MarkDown.  I am personally much 
more inline with the approach taken by MDP.  It hasn't been attended 
to in quite some time.
Robert
22-Dec-2012
[289]
The MDP code is quite a bit a mess. So, perhaps it's better to reuse 
the name as mark-down-pro
Scot
22-Dec-2012
[290]
Now we can attend to the things that were elegantly conceived but 
never really developed.  MDP is one example.  I like the exclusivist 
nature of Rebol.  I like the fact that I can do my architecture from 
back to front without ever leaving Rebol.
AdrianS
22-Dec-2012
[291]
Well, if the Markdown syntax is too limited, there's also MultiMarkdown 
which has the benefit of being a superset of Markdown.
Henrik
22-Dec-2012
[292]
Yes, Make Doc Pro really doesn't scale well.
Scot
22-Dec-2012
[293]
So what would it take to make a Make Doc that can scale?
AdrianS
22-Dec-2012
[294x2]
I think you keep mixing up the implementation of processing any of 
these markups being done in Rebol (which you prefer, and I don't 
question this) with the actual markup.
Sorry, that was addressed at you, Scot.
Henrik
22-Dec-2012
[296]
Scot, it has to be rewritten. The code is a mess. So, we could start 
with a pure markdown parser and build on top of that.
Scot
22-Dec-2012
[297x2]
AdrianS:  Not mixing at all.  I am done with taking something like 
MarkDown which is limited in syntax and "adding features" to make 
it do more things.  That's how the beast we call the DOM came to 
be.  An awful thing.  You can't talk about the syntax without talking 
about the design of the parser.  They can't be separated.
That's the whole point of dialects.  MDP is a dialect of Rebol.  
It needs attention.
Henrik
22-Dec-2012
[299]
I'm not sure what markdown has to do with the DOM?
AdrianS
22-Dec-2012
[300]
Hmm, I think you are in fact mixing up implementation with syntax. 
Are you saying that MakeDoc markup is not something that can/should 
be able to be processed by non Rebol tools?
Scot
22-Dec-2012
[301]
Whew!  Not being clear.  The DOM is the result of taking a simple 
Hypertext engine and trying to turn it into a application architecture. 
 Everyone adopted it because it was widespread, not because it was 
good at appications.
AdrianS
22-Dec-2012
[302]
Uhhh...
Scot
22-Dec-2012
[303]
MDP is a dialect of Rebol.  It takes advantage of what Rebol does 
well.  Is Markdown a dialect of Rebol.  Is the syntax optimized to 
play well with rebol?  That is my question.  If not then we need 
somethign that plays well with REBOL.  We can alway output MarkDown 
if somebody really wants it.
Henrik
22-Dec-2012
[304x2]
Scot, MDP is string parsed and markdown is string parsed as well. 
MDP actually works by first converting line by line into another 
dialect, which then is parsed to HTML.
MDP is string parsed
 - and this part is actually a big mess.
Scot
22-Dec-2012
[306]
I've spent a lot of time with MDP, written a whole distributed application 
with pages based upon the principles of MDP.  The biggest mess in 
MDP is the need to make HTML pages, which is a fossil and pretty 
awful, but widespread.  People need HTML so we output that.  People 
may want PDF, or RTF or Postscript or MarkDown, or whatever.  Those 
parts will always be a mess because the formats of all those outputs 
are a mess.
Henrik
22-Dec-2012
[307x2]
I've also spent quite a lot of time with MDP as well building now 
around 2 megabytes of manuals with it, and I spent some time adding 
new features to it. I wanted to add a glossary feature, but it's 
quite strained with what we can do now. The HTML part is not so bad. 
The line parser is much worse, both because we are running out of 
space for sensible inline rules (which all are one-char and markdown 
doesn't have this limitation), and the code itself is not very well 
organized.
I would gladly toss out the MDP parser for a clean markdown parser.
AdrianS
22-Dec-2012
[309]
wouldn't Carl's original makedoc.r be convertible with not too much 
effort?
Henrik
22-Dec-2012
[310]
I think it has fewer inline rules.
Gregg
22-Dec-2012
[311]
Gabriele also did a variation for Qtask. Not sure about compatibility, 
but it would be more modern, and likely a very clean implementation.
Chris
22-Dec-2012
[312]
Gabriele's MD3 is fairly awesome, imo. Very easy to build MakeDoc 
'dialects'.
Andreas
22-Dec-2012
[313]
Has MDP ever been really associated with RT? I always thought it 
ways Robert's creation. Whereas MakeDoc and MakeDoc2 where Carl's 
stuff.
Chris
22-Dec-2012
[314x2]
No, I don't believe it was.
It is a superset though, iirc -- any MD(2) document can be processed 
by MDP.
AdrianS
22-Dec-2012
[316]
we should probably try to make it clear for newcomers when we mean 
MakeDoc(2) vs Markdown, which some people might think MD refers to
Chris
22-Dec-2012
[317x2]
Scot, on generation: Gabriele's FSM emitters (particularly for HTML) 
are the most elegant solution to this I've seen. I use it often.
Adrian, I'm not certain, but I believe the settled extension (and 
I suppose shorthand) for MakeDoc is .rmd (Rebol MakeDoc).
AdrianS
22-Dec-2012
[319]
I just meant in here - someone dropping in/by might get confused 
when there are references to MD
BrianH
23-Dec-2012
[320]
Could you all please test the https://github.com/BrianHawley/r3-bh/tree/length-embedded-script
fix? Carl wants more testers before he accepts the https://github.com/rebol/r3/pull/40
pull.
Andreas
23-Dec-2012
[321]
Could you maybe write up some testcases?
BrianH
23-Dec-2012
[322x2]
The only externally visible change is that sys/load-ext-module and 
sys/load-module return 3 values instead of 2. If you don't have any 
code that calls those functions directly, then all working code won't 
be affected. The only code outside of sys-load.r that could hypothetically 
call those functions would have been written by Ladislav for include, 
or Saphiron for their encapper, but even then it's unlikely. Andreas, 
you could grep Saphiron's sources to tell me if those functions are 
referenced outside of sys-load.r.
The only behavioral change is that length-specified embedding works. 
It was documented before, but didn't work because the code above 
sys/load-header didn't support it. With this it does.
Andreas
23-Dec-2012
[324x2]
Where is "length-specified embedding" documented?
I fear that with the pull request as-is, even basic script execution 
is broken:
$ cat foo.r 
REBOL [] print 42
$ ./r3 foo.r 

** Script error: select does not allow integer! for its series argument
** Where: make either either -apply-
** Near: make system/standard/script [
    title: select first code '...

>>
BrianH
23-Dec-2012
[326x2]
I don't even know anymore. I'll write some example code. If your 
script dowsn't have length: some-integer in its header, it won't 
be affected.
Alright, let me check that.