Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #3498 > unrolled thread

colorForth markup tags

Back to article view | Back to comp.lang.forth

Contents

  colorForth markup tags Brad <hwfwguy@gmail.com> - 2011-06-23 10:12 -0700
    Re: colorForth markup tags Mux <spam_catcher123@hotmail.com> - 2011-06-23 14:15 -0700
      Re: colorForth markup tags John Passaniti <john.passaniti@gmail.com> - 2011-06-24 16:17 -0700
        Re: colorForth markup tags Brad <hwfwguy@gmail.com> - 2011-06-27 09:53 -0700
    Re: colorForth markup tags Jean-François Michaud <cometaj@comcast.net> - 2011-06-23 15:01 -0700
    Re: colorForth markup tags Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-06-24 10:23 +0000
    Re: colorForth markup tags Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-25 01:35 -0700
      Re: colorForth markup tags John Passaniti <john.passaniti@gmail.com> - 2011-06-25 12:45 -0700
        Re: colorForth markup tags Paul Rubin <no.email@nospam.invalid> - 2011-06-25 13:26 -0700
          Re: colorForth markup tags John Passaniti <john.passaniti@gmail.com> - 2011-06-27 07:39 -0700
        Re: colorForth markup tags Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:24 +0100
    Re: colorForth markup tags Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-06-25 10:21 +0000

#3498 — colorForth markup tags

I would like to represent Forth source as tagged strings rather than
blank-delimited strings, kind of the way colorForth does. But I want
to do it in a such a way that a HTML browser can read it.

The source is still essentially colorForth, but its source encoding
isn't Chuck's compact binary. The interpreter would simply skip over
tags that don't make sense. I could put in anchors, hyperlinks,
graphics, etc. for documentation purposes and not disturb the source.

Instead of BL WORD just providing the next blank delimited string,
NEXT-WORD would also provide an attribute tag to tell how the string
should be handled. There is no STATE, [, ], etc.

I have questions.

Would an HTML editor be sufficient?

Would an XML editor be better at generating the required HTML?

Should I use a CSS, or should the styles be embedded?

-Brad

[toc] | [next] | [standalone]

#3510

On Jun 23, 10:12 am, Brad <hwfw...@gmail.com> wrote:
> I would like to represent Forth source as tagged strings rather than
> blank-delimited strings, kind of the way colorForth does. But I want
> to do it in a such a way that a HTML browser can read it.
>
> The source is still essentially colorForth, but its source encoding
> isn't Chuck's compact binary. The interpreter would simply skip over
> tags that don't make sense. I could put in anchors, hyperlinks,
> graphics, etc. for documentation purposes and not disturb the source.
>
> Instead of BL WORD just providing the next blank delimited string,
> NEXT-WORD would also provide an attribute tag to tell how the string
> should be handled. There is no STATE, [, ], etc.
>
> I have questions.
>
> Would an HTML editor be sufficient?
>
> Would an XML editor be better at generating the required HTML?
>
> Should I use a CSS, or should the styles be embedded?
>
> -Brad

I think the idea is interesting but I can't help but feel it's over-
complicating things just for the hell of it. If anything, colorforth
REDUCES the complexity whereas yours does just the opposite. Just my 2
cents...

-Mux

[toc] | [prev] | [next] | [standalone]

#3530

On Jun 23, 5:15 pm, Mux <spam_catcher...@hotmail.com> wrote:
> I think the idea is interesting but I can't help but feel
> it's over-complicating things just for the hell of it. If
> anything, colorforth REDUCES the complexity whereas yours
> does just the opposite. Just my 2 cents...

ColorForth reduces complexity... if you stay in ColorForth.  The
second you wish to be able to express code outside of the ColorForth
environment, you add complexity because ColorForth chooses it's own
standard.  People talk about how filesystems and standards like
Unicode impose complexity.  Sure, but that complexity allows
interoperability and that grants not only choice, but makes some
things far easier.  ColorForth's simplicity is largely because it is a
closed system that isn't (meaningfully) interoperable with much else.
In that regard, it's easy to come up with simple systems-- you lay
down some arbitrary standards that match your style of work, create a
system around those standards, and then tell people who exist outside
that system that they are suffering from too much complexity.  If they
only adopted your style and work idioms, why they too would have a
simple system.

The problem in comp.lang.forth is that words like "complexity" are
talked about as if they are some absolute.  But "complexity" is both
relative to other systems and relative to what you want to do.

I don't feel Brad is over-complicating things at all.  One would
presume that he wants to have readable ColorForth source exist outside
the ColorForth environment.  That might be for communication or to
take benefit of the many tools available outside of ColorForth.
Whatever.  It may be more complicated that staying within the
ColorForth environment, but then again, living life in the open world
is more complicated that existing in a monastery.

HTML editors with class tags to identify different ColorForth syntax
works, but is probably going to be tedious to enter.  An XML editor
and a specific schema for ColorForth would be nicer, and would allow
using tools like XSLT to transform into other forms.

[toc] | [prev] | [next] | [standalone]

#3585

On Jun 24, 4:17 pm, John Passaniti <john.passan...@gmail.com> wrote:
> I don't feel Brad is over-complicating things at all.  One would
> presume that he wants to have readable ColorForth source exist outside
> the ColorForth environment.  That might be for communication or to
> take benefit of the many tools available outside of ColorForth.

I'm referring to colorForth more as an approach than an
implementation. I'm just tossing around ideas, not implementing
anything. Any fool can write a Forth, and many do.

colorForth gave up compatibility with ANS when it made colon non-
smudging. This one design decision facilitated a lot of useful things,
such as multiple semicolons. But I don't want to be tied to the
existing colorForth environment or editor. It might be a good way to
cross compile, with additional attribute tags for the needs of a
tethered system. Source is source, whether it's marked up plain text
or binary colorForth with shannon-coded names.

-Brad

[toc] | [prev] | [next] | [standalone]

#3513

On Jun 23, 10:12 am, Brad <hwfw...@gmail.com> wrote:
> I would like to represent Forth source as tagged strings rather than
> blank-delimited strings, kind of the way colorForth does. But I want
> to do it in a such a way that a HTML browser can read it.
>
> The source is still essentially colorForth, but its source encoding
> isn't Chuck's compact binary. The interpreter would simply skip over
> tags that don't make sense. I could put in anchors, hyperlinks,
> graphics, etc. for documentation purposes and not disturb the source.
>
> Instead of BL WORD just providing the next blank delimited string,
> NEXT-WORD would also provide an attribute tag to tell how the string
> should be handled. There is no STATE, [, ], etc.
>
> I have questions.
>
> Would an HTML editor be sufficient?
>
> Would an XML editor be better at generating the required HTML?
>
> Should I use a CSS, or should the styles be embedded?
>
> -Brad


What are you trying to do exactly?

What I'm sensing you're looking at is trying to see if you can throw a
piece of marked up "colorforth source code" directly at a browser to
have it displayed in full color while still being able to feed the
same source to a refined colorforth compiler/interpreter but what are
you trying to do that for?

If you opt for your solution (marked up colorforth source), what I'm
seeing would happen is that you would have to increase the complexity
of your compiler/interpreter to filter out the junk you don't care
about and you might have to get into considerations of how your marked
up source is formatted to accomodate natural processing with your
compiler/interpreter. So you end up with added complexity in your
compiler/interpreter and potential formatting idiosyncrasies in your
marked up source (if you markup with say HTML).

I usually have a tendency to want to decouple the data from the data
presentation to avoid having to pay attention to filtering out
presentation information when I need to process data. If it's strictly
followed, XML/XSLT shines in this respect.

So you could have your source data be XML marked up source and you
could have 2 pipelines:

XML + XSLT -> colorforth source
XML + XSLT -> HTML

With this approach:

1- The complexity is "spread out" instead of "built in".
2- You end up keeping your colorforth compiler/interpreter as is
(since it would consume actual colorforth source)
3- You can present your source however you want in HTML
4- You don't have to deal with formatting idiosyncrasies in your XML
source because your data wouldn't be mixed up mixed up with data
presentation information and because neither your colorforth compiler/
interpreter nor your brower would have to operate on a common data set
that uses different parsing rules that may not reconcile as cleanly.

Regards
Jean-Francois Michaud

[toc] | [prev] | [next] | [standalone]

#3520

In article <49a14599-c042-4540-9c78-c5790d60b0a7@v11g2000prk.googlegroups.com>,
Brad  <hwfwguy@gmail.com> wrote:
>I would like to represent Forth source as tagged strings rather than
>blank-delimited strings, kind of the way colorForth does. But I want
>to do it in a such a way that a HTML browser can read it.
>
>The source is still essentially colorForth, but its source encoding
>isn't Chuck's compact binary. The interpreter would simply skip over
>tags that don't make sense. I could put in anchors, hyperlinks,
>graphics, etc. for documentation purposes and not disturb the source.
>
>Instead of BL WORD just providing the next blank delimited string,
>NEXT-WORD would also provide an attribute tag to tell how the string
>should be handled. There is no STATE, [, ], etc.
>
>I have questions.
>
>Would an HTML editor be sufficient?
>
>Would an XML editor be better at generating the required HTML?
>
>Should I use a CSS, or should the styles be embedded?

Leon and I have made a poor mans version of this for colorforth.
It uses the first letter of a word as a tag i.e. : is red.
It was not too much of work, and the plain ascii is much
easier on other tools, e.g. source control.

We have added a syntax coloring to gvim and it looks much
like colorforth screens. The layout of this source is under
control etc. etc.
You may want to start with such a simple system to experiment,
syntax coloring in gvim is a snap.
(Available upon request, just mail me. We would have published
it by now, if GreenArray had endorsed it.)

>
>-Brad

Groetjes Albert
--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#3538

On Jun 23, 6:12 pm, Brad <hwfw...@gmail.com> wrote:
> I would like to represent Forth source as tagged strings rather than
> blank-delimited strings, kind of the way colorForth does. But I want
> to do it in a such a way that a HTML browser can read it.
>
> The source is still essentially colorForth, but its source encoding
> isn't Chuck's compact binary. The interpreter would simply skip over
> tags that don't make sense. I could put in anchors, hyperlinks,
> graphics, etc. for documentation purposes and not disturb the source.
>
> Instead of BL WORD just providing the next blank delimited string,
> NEXT-WORD would also provide an attribute tag to tell how the string
> should be handled. There is no STATE, [, ], etc.
>
> I have questions.
>
> Would an HTML editor be sufficient?
>
> Would an XML editor be better at generating the required HTML?
>
> Should I use a CSS, or should the styles be embedded?
>
> -Brad

I thought colorforth already had an html export function?

[toc] | [prev] | [next] | [standalone]

#3551

On Jun 25, 4:35 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> I thought colorforth already had an html export function?

I don't believe so.  I know there is (or at least was) some cumbersome
process of converting a screen to a PNG image.  Something like insert
a freshly-formatted DOS floppy, execute some code that put an image on
the floppy (by writing a hard-coded directory block with fixed
filename and image file at known, contiguous sectors), remove the
floppy, load on another machine (real or virtual), copy to a new file,
and then use it.  See how ColorForth reduces complexity?  By making
the process of getting code out of that closed system so annoying that
you never want to leave.

If there is a way to export ColorForth code as HTML, it likely takes a
similar process.  And, it is probably unidirectional.

Quite some time ago, back when ColorForth was first discussed, there
were two base ideas that were expressed that I thought were crucial to
understanding it.  They were that color was an obvious but largely
arbitrary choice to attribute words with.  The second was that
ColorForth wasn't intended to be a single thing, but a larger message
(and approach) of empowering programmers to build their own tools from
the ground up that precisely matched their needs.  So one could
reasonably expect to see the color in ColorForth replaced with font
changes or with prefix characters or some other notation.  And that we
wouldn't all be talking about Charles Moore's ColorForth, but our own
variations on that theme, each potentially wildly incompatible with
each other, but each matching our needs and aesthetics.  I think
ColorForth was and still is a great idea and Charles Moore's model for
it serves as a valuable reference as a starting point.

[toc] | [prev] | [next] | [standalone]

#3552

John Passaniti <john.passaniti@gmail.com> writes:
> If there is a way to export ColorForth code as HTML, it likely takes a
> similar process.  And, it is probably unidirectional.

There is an html export feature but yes, it is unidirectional as far as
I know.

You can look at html-ized colorforth code of the rom code in the GA144
nodes here:

  http://greenarrays.com/home/documents/greg/code/af-35f-g144a12-PD.zip

The html file is inside the zip, along with some other stuff.

[toc] | [prev] | [next] | [standalone]

#3575

On Jun 25, 4:26 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> There is an html export feature but yes, it is
> unidirectional as far as I know.

And I'm pleased to see that I'm wrong regarding file management-- at
least for exporting.  Apparently when they decided to host (Color|
Array)Forth on Windows, they provided interfaces to allow file
access.  Good for them, and much better than the "put in a formatted
floppy" model when it was running on raw hardware.

[toc] | [prev] | [next] | [standalone]

#3578

On 2011-06-25 20:45:38 +0100, John Passaniti said:

> On Jun 25, 4:35 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>> I thought colorforth already had an html export function?
> 
> I don't believe so.  I know there is (or at least was) some cumbersome
> process of converting a screen to a PNG image.  Something like insert
> a freshly-formatted DOS floppy, execute some code that put an image on
> the floppy (by writing a hard-coded directory block with fixed
> filename and image file at known, contiguous sectors), remove the
> floppy, load on another machine (real or virtual), copy to a new file,
> and then use it.  See how ColorForth reduces complexity?  By making
> the process of getting code out of that closed system so annoying that
> you never want to leave.
> 
> If there is a way to export ColorForth code as HTML, it likely takes a
> similar process.  And, it is probably unidirectional.
> 
> Quite some time ago, back when ColorForth was first discussed, there
> were two base ideas that were expressed that I thought were crucial to
> understanding it.  They were that color was an obvious but largely
> arbitrary choice to attribute words with.  The second was that
> ColorForth wasn't intended to be a single thing, but a larger message
> (and approach) of empowering programmers to build their own tools from
> the ground up that precisely matched their needs.  So one could
> reasonably expect to see the color in ColorForth replaced with font
> changes or with prefix characters or some other notation.  And that we
> wouldn't all be talking about Charles Moore's ColorForth, but our own
> variations on that theme, each potentially wildly incompatible with
> each other, but each matching our needs and aesthetics.  I think
> ColorForth was and still is a great idea and Charles Moore's model for
> it serves as a valuable reference as a starting point.

Haveing it represented as different fonts in a standard editor would 
IMHO be far easier. But why do that when you can throw away all your 
existing editors, and their macros, and design a custom keyboard that 
dosn't actually map onto the same chars of a standard keyboard and 
needs the chops of an idiot savant to learn it... ;)

Chris

[toc] | [prev] | [next] | [standalone]

#3540

In article <49a14599-c042-4540-9c78-c5790d60b0a7@v11g2000prk.googlegroups.com>,
Brad  <hwfwguy@gmail.com> wrote:
>I would like to represent Forth source as tagged strings rather than
>blank-delimited strings, kind of the way colorForth does. But I want
>to do it in a such a way that a HTML browser can read it.
>
>The source is still essentially colorForth, but its source encoding
>isn't Chuck's compact binary. The interpreter would simply skip over
>tags that don't make sense. I could put in anchors, hyperlinks,
>graphics, etc. for documentation purposes and not disturb the source.

Assuming at some point you want to run the code, I think
this is overly ambitious.

You don't want to put all that effort into a moving target.

(What we have here now.)
Using .cfs sources works as follows:
 You have ASCII sources (.cfs) equivalent to colorforth by prefixes
 gvim handles prefixes giving the illusion of seeing in colorforth,
   so there: at least one main stream editor to comfortably
   edit colorforth source
 You can transform the source into blocks.
 You can combine those blocks with a main system (patched to suit)
 You can than run the main system

Whenever GreenArrays comes out with a new main system, you have
to patch it again. Then you have to debug your interface.

Even with this minimal system we didn't manage to find the
time to do the patch again with the latest system GreenArrays
releases. You don't expect the changes to be documented at the
programmers level, do you?

I estimate that you're better off, just rewriting colorforth
in C without the Huffman encoding and weird keyboards.
I'm serious.
(Of course if you're just looking for a really demanding challenge,
be my guest!)

Leon is currently writing a simulator for F18 to replace Green
Arrays' . That is also challenging, but at least it is not
a moving target.

>-Brad


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web