On Mar 20, 11:12 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> I want to point out that what you've done here is semantic sugar. You've
> hidden the stack mechanics with code that shows the meaning and that
> doesn't show the mechanics.
Yes. In the contexts being discussed, involving someone seeing code
and
saying, "that's an unreadable language" ... which could be someone
working through a tutorial on their own initiative, and getting to
a certain stage, and saying, "well, never mind this!" ...
.... that was the complaint, in reality, wasn't it? That the stack
noise
is not saying "what to do", but rather, "how to do it"?
Now, as I noted, the main reason you would draw a box directly
with two pairs of diagonal points on the stack rather than using
a turtle is because drawing a box is not the only way you use
that pair of points defining a box, so you need to be able to
translate from a diagonal pair to any arbitrary side.
That's what makes BOX a higher level definition rather than just a
primitive where you only care what it does, not how it does it.
If you need to know how to get whichever edges you want, BOX
do***ents that.
So if faced with that, words to perform those specific diagonal->edge
conversion tasks are called for.
Indeed, well do***ented code will have the words translating from
stack manipulations to the four edges of a rectangle in one section,
the words using the rectangular logic in a later section, and the
TOC at the beginning will direct the person to the latter section
to see the various rectangular words ...
.... and that section would include a reference back to the section
containing the implementation details of the rectangular edge
words, "for those who wish to see the implementation details".
> This makes the upper-level code more readable, which is usually a good
> thing. But it doesn't address Douglas's main concerns. You still had to
> figure out ROT DROP TUCK etc and make sure they work before you could
> hide them.
Yes. But this is getting two distinct issues confused together ...
which has
been happening a lot in this thread.
(1) If its an issue of someone coming across code, then there has to
be more
code available that is broken up into commented sections with a TOC at
the
beginning that directs people to the sections with the "main
logic" ...
which is readable code. The need there, clearly, are tools that allow
someone to more easily section working code and put that TOC in
place,
combined with a working public repository that gives an actual
incentive
to improve the ability to understand what published code is doing. I
would
suggest that "-[ --[ ---[" and a sensible style guide is the core of
that.
(2) If it is an issue of someone working through a tutorial, there's
no issue ...
as individual tasks, working out "how do you do ( a b c -- a b a ) and
how
do you do ( a b c -- c b c )" as a natural part of a module on working
out
stack gymnastics and saving the result by giving it a name so you
don't have
to do that work more than once. Then drawing distinct edges of a box
given
the diagonal points is a distinct module that builds on that ... but
need not
be the following module, some other module that requires similar
manipulation
might intervene that uses them first.
One of the optional exercises in the BOX drawing module could be to
copy out
the primitives out in terms of their underlying definitions, to
reinforce the
benefit of defining in readability of building the components to
handle
the problem in the terms of the problem.
> A Forth newbie would have to get the concepts and apply them
> to make it work, while in other languages this complication would simply
> not exist.
Every general purpose tool has complications. If the goal is to teach
them
how to program in a stack-based, incremental compiler language
without
these complications, define that educational or dedicated-purpose
language and introduce them to that. I would suggest doing it at the
outset
with a typed stack of cell pairs, where type 0 is a null string,
positive
type numbers up to a string limit are strings, and negative type
numbers go
through the primitive types ... which are by value if they are
contained
in a cell and by pointer if not ... and then are allocated to
structures
and objects as they are defined, and with a secondary stack that is
accessible in interpreted mode.
It might also be convenient to have an explicit scope stack for
structured
programming, so that they can be expressed more easily in PN rather
than RPN.
Dialect interference is minimized if they are have a distinctive
ideography.
> They might have type-cast variables in place of a stack, and
> they have a lot of extra bother in there which they've already learned
> to ignore. Or they might have locals.
> You have to think to re-order the stack. You don't much have to think to
> use variable names. The compiler does it for you.
But there are lots of gotcha's there too ... most people using
computers
do not know any programming at all, so the question is whether this
is for converting people who have already invested in learning an
Algol language or for providing a skill to those who have not already
made that investment.
There has been a lot of appeals to "Forth newbies" as if that defines
a coherent group, when the term just reifies a negative ... not
experienced and comfortable with Forth. It leaves entirely undefined
everything you need to know to know where the potential audience is
starting from, and without know that, there is no way to specify
what is the most effective way of introducing Forth to them.
> Semantic sugar means people don't have to think as much when they read
> the code. But you have to think at least as much when you write it.
Except factoring out stack manipulations means you can work on
the stack manipulation independent of the word in which it is
used.
Something along the lines of ...
: sview" CR .S ." -- " [CHAR] " EVALUATE .S ;
.... gives a testbed for playing around with different combinations
of stack operations and seeing what they do.
> People generally don't like lots of mindless boilerplate they have to
> type out to get stuff done. But stuff they have to think about is even
> worse.
What is the scenario here?
(1) Coming across the code. There's no need to type out mindless
boilerplate.
Just conditionally compile the section of code you want, and use the
words.
That does imply an ability to conditionally compile at a section
level,
but I am not worried about getting to that point with Niclos, so for
a
a library collection that is willing to assume "big Forth's" all
around it
ought to be a cinch.
(2) Modules in a tutorial. Those are distinct tasks to learn. If the
tutorial is
well designed, working out how is done as an exploration, then saved
in a file
and called up as "finished work" when used in later modules.
|
