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

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

I'm sorry, I didn't explain that correctly.

The way the parser works, it's either one way or the other.  If you
include ENDIF you can't have the option to leave it out in the
program, because the parser will never know when your conditional
ends.

It has to either assume the IF ends at the end of the line, or else
you have to explicitly tell it where the conditional ends, every time.

There may be a sort of compromise here, if we add a special command
for defining the beginning of a block:

IF a < b THEN DO
 print 1
 print 2
 print 3
ENDIF

But I'll have to take a look at that and see it that's possible to implement.

-Ian



On 12/12/06, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> of course I meant that the variant without ENDIF would be possible,
> too. But anyway, I was just a proposal and you are the project lead. At
> least I tried :-).
>
> Best regards,
> Immo
>
> Am Mon, 11 Dec 2006 15:07:32 -0800
> schrieb "Ian Larsen" <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
> > >
>