Re: [Kidbasic-devel] Bug, Feature and Translation

[Ian L. <dr...@gm...>]

Sorry, still not convinced :-)

This hypothetical example:

IF a < b THEN
  print "a is less than b"
  print "the statement was true"
ELSE
  print "a is greater than b."
  print "the statement was true."
ENDIF
  print "Now we are out of the conditional."
  end

Can be written as:

IF a < b THEN GOTO doIfTrue
  print "a is greater than b."
  print "the statement was false"
  goto myEndif
doIfTrue:
  print "a is less than b."
  print "the statement was true"
myEndif:
  print "Now we're out of the conditional."
  end

This second example only requires one more line than the previous
example, and is a much better example of how the computer actually
operates.  Not only that, but including ENDIF would necessitate using
it every time, so simple IF statements would look like this

IF a < b THEN
  print "a is less than b"
ENDIF

instead of the much simpler

IF a < b THEN print "a is less than b."

I just think the second one-liner is much more intuitive, and probably
a more common case in simple programs than performing multiple actions
after an IF.

-Ian



On 12/11/06, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> shell access is fine now, I updated the German command reference.
>
> It would be great if you could separate the texts out of the lisp
> program - I could adapt my translation relatively fast to the new file
> format. For the svn directory I would like to suggest
> branches/devel/doc. In that directory the lisp program and the
> translation files could reside.
>
> The POLY plans sound good. The POLY command is indeed not too easy to
> use right now.
> I like the "unnamed array" idea - but it should be possible to use
> variables for the individual values. I am not sure whether one still
> should be forced to pass the number of sides to the program - I could
> live without this. I could also imagine an (optional) syntax
> [[0,0],[0,100],[100,0]]. Internally this could be treated as list (I
> really don't thing about nested arrays) and would be absolutely
> identical to [0,0,0,100,100,0], but it would be more clear what the
> different points are.
>
> I knew in advance that you would not like the IF/THEN ELSE ENDIF. Anyway
> I would like to make some points to convince you (maybe):
> - Sometimes GOTO/GOSUB will not help, you need to have more than one
> command in the THEN branch. I know that this is possible by using : to
> separate the commands, but this is ugly.
> - There is already the case of a command with a "body": the FOR/NEXT
> command.
> Maybe the ELSE is really not needed, but I think the ENDIF _is_ needed.
>
> Best regards,
> Immo
>
> Am Mon, 11 Dec 2006 09:20:53 -0800
> schrieb "Ian Larsen" <dr...@gm...>:
>
> > Hello,
> >
> > I've changed the permissions on the shell account so you should be
> > able to write the files that are there currently.
> >
> > Feature requests:
> > Filled POLY shouldn't be difficult.  I'd like to re-work the POLY
> > command anyway so that it uses some type of list, instead of having to
> > fill an array to use it.  We'll keep the original functionality, too,
> > but I think it's a bit involved for a simple command.
> >
> > What this will mean is that a "list" type will be added to Basic256,
> > or it will be possible to define an unnamed array, like this: [1, 30,
> > 4, 5].  Any additional ideas are welcome.
> >
> > Sound is a top priority, as soon as I find the time to do it.  Break
> > points are a great idea that many people have requested, so they'll be
> > next.  The U/I improvements all sound like good ideas to me, too.
> >
> > > - The IF/THEN statement could get an ELSE and an ENDIF.
> >
> > I'd rather not.  I think it's instructive to have to use GOTO as
> > opposed to higher level constructs so kids can figure out what the
> > computer's actually doing.
> >
> > The lisp program wouldn't be as difficult to use as you think.  I can
> > separate it into two files: the first would be the actual program that
> > reads and outputs the html, and the second would be the kbcommand
> > portion that just has the documentation in it.  So the files would be:
> >
> > generate.lisp (translators wouldn't touch this.)
> > translation_en.lisp (translators change the English portions to
> > chosen language)
> >
> > That way, to do a translation you'd just need to copy the
> > translation_en.lisp and alter any english string.  This would allow me
> > to change generator.lisp to whatever format I want, and it would still
> > use the translation without modification.
> >
> > -Ian
>