[KTurtle] OO syntax code in SVN

[Niels Slot]

It has taken me a while (since September), but I finally got my object oriented KTurtle in SVN. The code has been sitting around on my computer for the last few months. And while I planned to clean it up just a little more, it never came to that. For anyone who wants to check it out, the code is in /branches/work/kturtle-objects[1]. This version of KTurtle can run the following code:

forward 100
$x = turtle
$x.forward 50

This will create a second turtle and move it 50 steps forward.

Any comments on the code are welcome.

Cies and Mauricio: Please have a look at it and let me know how you feel about including something like this in 4.3.

Greetings,

Niels

[1]: http://websvn.kde.org/branches/work/kturtle-objects/

[cies]

niels,

congratulations!

i'm currently trying to look at the code (could you give me some
pointers of where the main action is going one, files+methods)

quick question: does this mean we can have multiple turtles? (the
syntax suggests we can have)


about inclusion: im not much against including this, i yet need to
have a look at the code. i wonder though where is stops -- as in: "are
printed strings also going to be objects?"

i think we need to have a policy on this for kturlte and that is quite
philosophical:
- is kturtle an OO language with some syntactic sugar to make it easy entry, or
- is it a procedural (non-OO) lang that has some OO features (mainly
for the turtle)

this is the main issues i'm pondering upon.


please feedback everyone as this is a suff to resolve and reach
(hopefully) consensus on before we reach a 1.0 (or we move the whole
issue to post-1.0, some thing i personally would rather not)



cheers!
_c.

[Niels Slot]

Hi Cies,

I did the branching in two steps. The first commit was a copy of trunk to branches/work. The second commit were my changes. If you want to see the new stuff with the action, check the changes for revision 916536[1].

I've implemented objects as a fifth variable type. So a variable can be a number, string, empty, boolean, or, in my new code, an object. An object currently is a 'pointer' to a turtle which I have in a list in the canvas class. With some parsing changes, a function can now get the object as an extra parameter, allowing it to do something with a different turtle then normally.

As for classification of OO in KTurtle. It would suggest that your second choice applies. We're still a procedural language. But the way of interaction with multiple turtles, looks a lot like working with objects in different languages. It is however not possible to create your own class or have an object of a different type then a turtle.

Niels

[1]: http://websvn.kde.org/?view=rev&revision=916536

2009/1/27 cies <cies....@gmail.com>

[cies]

niels,

thanks for the quick reply im looking at the code changes now.

> I've implemented objects as a fifth variable type. So a variable can be a
> number, string, empty, boolean, or, in my new code, an object.

that's expected behavior i think.

> As for classification of OO in KTurtle. It would suggest that your second
> choice applies. We're still a procedural language. But the way of
> interaction with multiple turtles, looks a lot like working with objects in
> different languages. It is however not possible to create your own class or
> have an object of a different type then a turtle.

i have a bit of a problem with this. it is not helping anyone to learn
the OO paradigm if you cannot make your own classes, and can only do
"OO" on a turtle. can we speak of OO when it is not OO behind the
scenes? i mean 'oriented' implies that there is a certain intention
behind the object approach.

im a big ruby fan, everyone may know. (go ruby!) i _love_ proper OO
designs. i dont think kturtle will every be used for OO-designed
software; not even for any designed software.. it is a sandbox.

so do we need a little syntax addition to kturtle that only works in
one particular area of the language (the turtle), there by basically
making the syntax more exceptional than consistent?

i dont know guys...
i really dont know.

dont get me wrong, i like what you did niels, but i have my
reservations. it make the code of kturtle even more complex (and
exceptional). and does it really help to fullfill kturtle mission?
(mission: making programming super-easy and touchable)


please feedback! i dont know the answer here.

cheers!
_c.

[Clem]

To remind you all, I am the Logo user who maintains the Great Logo
Atlas which is a compendium of information about Logo s living and
dead. I was wondering where this oo pardigm shift was leading. I can't
see any value at all in playing around and introducing a new syntax to
the world, I do think the C++, and Java have probably got the serious
software development market sewn up. Cies states that KTurtle is a
sandtray, and it is statements like that that keep me reading this
group.

I had been pondering a future directions myself: what if you could
compile KTurtle to speak alternative language. A switch so kturtle
uses the current syntax- or a switch so it will speak UCB Logo - or in
this case a switch so it will speak oo. To me this has the advantage
that it would bring KTurtle back into the Logo Tree and reconnect it
with the considerable repository of freeware CS Course ware. We would
have a sand tray where functional, procedural and oo paradigms can be
practised.

My usage of Logo was extensive, students would gain fluency in MSWLogo
syntax, then any new concept that they needed to learn would be mocked
up in Logo. The concept being understood we would move to the real
world target language and and perfect the syntax. OO was a problem as
the intellectual leap was just too far.

If however we could stay in the same sandtray, oos could be
effectively discussed.

As a learning tool, it would be important that the oo language was
flexible enough to demonstrate the rich varieties of interpretations
of OO., ie each of Deborah Armstrong's quarks. At the very least we
would need something Java like and Javascript like. It would be
tempting just to include a dot syntax but this is rather pointless
educationally.


Clem

[cies]

thanks for your feedback.

as mentioned i also think that just putting dots on a turtle object is
not "a way forward".
is we want to go OO in a way that we can 'help people understand OO'
we should at least enable users to make their own objects -- this
needs a _lot_ of refactoring of the kturtle interpreter (high costs --
i dont think we have the developer time to do so).

after too many people complain to me (personally) that kturtle claims
to be logo but doesnt adhere XYZ standard/implementation, i broke with
'LOGO'. i dont claim kturtle to be LOGO any longer, kturtle's syntax
has since then evolved to be more 'common'. (like {} for scope, $x for
vars, etc)

i really like what niels did, and what it makes possible, but im
afraid that we dont have any OO philosophy so im a little hasitant.


learning OO is maybe better to be learned using python or ruby.
kturtle is a language for a very small niche, early-education, comes
with its own GUI, has a translatable syntax, and gives errors (and
help) in the programmers own language. i think our strengths and
opportunities are in this dimension, not in different programming
paradigms (that is something for an advanced course covering several
languages, imho).



cheers,
_cies.

[Mauricio Piacentini]

cies wrote:
> thanks for your feedback.
>
> as mentioned i also think that just putting dots on a turtle object is
> not "a way forward".
> is we want to go OO in a way that we can 'help people understand OO'
> we should at least enable users to make their own objects -- this
> needs a _lot_ of refactoring of the kturtle interpreter (high costs --
> i dont think we have the developer time to do so).
>
> after too many people complain to me (personally) that kturtle claims
> to be logo but doesnt adhere XYZ standard/implementation, i broke with
> 'LOGO'. i dont claim kturtle to be LOGO any longer, kturtle's syntax
> has since then evolved to be more 'common'. (like {} for scope, $x for
> vars, etc)
>
> i really like what niels did, and what it makes possible, but im
> afraid that we dont have any OO philosophy so im a little hasitant.
>
>
> learning OO is maybe better to be learned using python or ruby.
> kturtle is a language for a very small niche, early-education, comes
> with its own GUI, has a translatable syntax, and gives errors (and
> help) in the programmers own language. i think our strengths and
> opportunities are in this dimension, not in different programming
> paradigms (that is something for an advanced course covering several
> languages, imho).

Well, it is difficult to comment, specially since I have not helped
Niels with it. I like the idea of multiple turtles very much, and I
think it helps fullfill KTurtle's mission, by making it more interesting
to young students. We can couple it with a new command to let people set
the turtle's sprite art (via svg files) and suddenly a lot of
opportunities will open up, even with small games and things like that.

But I do not think using dot syntax helps here. I would prefer to keep
it procedural. So we would not loose the work Niels did to support
multiple turtles in the canvas area, but I was thinking about two new
commands: one to create a new turtle, and another to start "speaking" to
it. The canvas class would keep a pointer to the current turtle, and
almost no additions or changes to the language would be needed. There
would be no object types or changes to the interpreter, only two or
three new commands. So it would be something like:

//operating on the main (default) turtle
forward 100
turnleft 30
//the next line creates a new turtle and gives it a name
createturtle "daisy"
talkto "daisy"
forward 100
turnleft 30
//we need to define a name for the default turtle,
// here I called it simply turtle
talkto "turtle"
turnright 10
forward 10
talkto "daisy"
backward 10
hide

In this mode, the "show" and "hide" commands will simply operate on the
turtle we are currently talking to, no changes needed.

Optionally, we could add a command to remove a turtle, but I do not
think it is really necessary, as we could simply hide it. If we want
one, it could be

removeturtle "daisy"

For all the other commands (pen for example) we could take two routes:
keep different states for each turtle, or keep a global canvas state. I
would prefer to keep it global, as it is more procedural to me, but both
could be handled more or less easily without changes in the language or
interpreter, only keeping states in the canvas class for each turtle.

The other command I was thinking about in the past was one to change the
svg element or image, and coupled with this ability to talk to multiple
sprites we could implement small games and animations. I was thinking
about a

setImage "bird"

function that would operate on the current turtle. With it (and the
talkto or tell command) we could do something like is described in the
Up and Away section at the bottom of this page:

http://el.media.mit.edu/logo-foundation/logo/turtle.html

I think something like this still keeps the procedural model pretty much
in check, while expanding the features of the program a little bit and
adding several new dimensions for teachers to exercise.

But there are two separate issues. Anywasy, I can volunteer to work a
little bit on it for 4.3, specially if we take this route where most of
the work is concentrated on the canvas and QGV, as my grasp of the
interpreter is not good enough to work on stuff like implementing new
object types :) I leave these more complex bug fixes to you guys!

Best regards,
Mauricio Piacentini

[Niels Slot]

Nice to see some feedback.

You guys are right in the fact that my code isn't a true OO implementation, far from it. It currently is not much more then a dot notation for multiple turtles. I think this can have some value. It could teach someone that a variable, followed by a dot, means do this with that variable. I agree on the fact that, if we want OO, we should do it in a proper way. Just like Cies I am a big fan of Ruby, and the way it deals with objects and classes. It will however require a lot of work. Far too much then we can manage.

The idea of connecting KTurtle with different Logo dialects, making KTurtle speak different languages, would be possible when looking at the architecture. Right now we have the interpreter almost completely separated from the GUI. This therefore might be something to investigate, or at least thinks about, in the future.

Mauricio's syntax suggestion looks nice. It's kind of the same as we discussed last Akademy. It would not be very hard to implement, because it's a lot easier then my current code. There would be no need for an extra object type or a dot like syntax. Two new methods and some state variable would be enough. We can use my approach on multiple turtles. Although we might have the change it from number based to name based. (That would be replacing a QList by a QHashMap.)

I wonder if we're going to run into problems related to this state variable, the one which records which turtle we are using at that moment. How would we do that? As a sort of global variable? And is that something we want?

Niels

2009/1/27 Mauricio Piacentini <piace...@kde.org>

[Niels Slot]

Within a hour of coding, I've implemented a part of what Mauricio suggested. When the attached patch is applied to KTurtle trunk, it should allow the following script to run:

forward 200

createturtle "niels"

talkto "niels"

forward 50

You should see two nice turtles on the canvas, with one named after me :).

Currently the attached patch only allows some basic commands to affect the second turtle. Commands like 'turnleft', 'turnright', 'go', 'center', 'forward' and 'backward' should work, I haven't tested them all though. Extending this to the other commands should be really easy. I also need to implement some checks. It would now for example be possible to create two turtles with the same name.

As earlier, feedback is welcome.

Niels

2009/1/27 Niels Slot <niel...@gmail.com>

[Mauricio Piacentini]

Niels Slot wrote:
> Within a hour of coding, I've implemented a part of what Mauricio suggested.
> When the attached patch is applied to KTurtle trunk, it should allow the
> following script to run:
>
> forward 200
>
> createturtle "niels"
>
> talkto "niels"
>
> forward 50
>
> You should see two nice turtles on the canvas, with one named after me :).
>
> Currently the attached patch only allows some basic commands to affect the
> second turtle. Commands like 'turnleft', 'turnright', 'go', 'center',
> 'forward' and 'backward' should work, I haven't tested them all though.
> Extending this to the other commands should be really easy. I also need to
> implement some checks. It would now for example be possible to create two
> turtles with the same name.
>
> As earlier, feedback is welcome.

Woohoo!! Very cool, Niels! I would see if I can help with designing a
way to store the turtle state in the canvas. And what would be the name
of the default turtle? Or we just use talkto "turtle" ? Maybe talkto
"cies" could be included as an easter egg? :)

Regards,
Mauricio Piacentini

[Niels Slot]

Storing the state in the canvas isn't actually needed that much. Right now I keep the other turtles in a QHash<QString, Turtle*>. The turtles are already an object. The state of these turtles, direction and position, are stored in that object, so no problem there. Talkto currently sets a pointer 'currentTurtle', which point to the old regular 'turtle' or to one of the turtles in the hash.

It might be an idea to have an extra inspector window, like now we have a way to show the current variables and functions, we might want to show the turtles and their positions.

The default turtle currently doesn't have a name as it's not in the hash. A default name of 'turtle' or 'default' would be possible. Or it could be that talkto without an argument sets it to talk to the default turtle. I don't really have an opinion on this yet. Suggestions are welcome.

Easter eggs might be fun. Converting a picture of Cies to SVG and making it show up with a 'talkto "cies"' and 'show' :).

Niels

2009/1/27 Mauricio Piacentini <piace...@kde.org>

[cies]

i dont know guys..

> extra inspector window [...] to show the
> turtles and their positions.

doesnt sound like a good idea to me.

multiple turtles is a neat feature.

about the syntax, my take is go full procedural, reasoning:
if we cannot deliver full-OO -- lets not deliver any OO.


we dont use the word "turtle" in any of the command, do we?
(i never wanted to do so because we might get different 'sprites' later)
so adding the commands "clonesprite" and "talkto" is maybe a good one.
2 extra keyword that do everything. no names :-)
talkto 0 # talk to the default sprite
talkto 1 # first clone, etc.

i think that makes most sense if we _really_ want multiple sprites --
quite a nice feature.

buttt... i think there is more important features to implement for kturtle:
- contextual help still not in
- errors tab could get some beautification (like spacing the errors
table nicely)
- contextual error help would be a killer
- maybe even the variables tab should have contextual help
(so it is integration with the help system where is see most low
hanging fruit for making steps towards kturtle 'goal' of making
programming something dead easy to start with)


besides that we have some bugs piling up...

the big change is in the interpreter though -- i would love to have a
generated parser, and if i look at the design of KJS i see many room
for improvement on the interpreter side (the ruby i wrote for
definitions.rb is, ehhh, not the prettiest to say the least). the main
thing we have to do _before_ the interpreter can get an other big
cleanup:

unittest



that are the priorities the way i see 'm..

dont worrie KTurtle is a free software project -- together with make
kturtle's future, so if you have a different idea about the priorities
for future development of kturtle, please post it here :-)



thanks guys!
_cies.

[Mauricio Piacentini]

cies wrote:
> i dont know guys..
>
>> extra inspector window [...] to show the
>> turtles and their positions.
>
> doesnt sound like a good idea to me.
>
> multiple turtles is a neat feature.
>
> about the syntax, my take is go full procedural, reasoning:
> if we cannot deliver full-OO -- lets not deliver any OO.
>
>
> we dont use the word "turtle" in any of the command, do we?
> (i never wanted to do so because we might get different 'sprites' later)
> so adding the commands "clonesprite" and "talkto" is maybe a good one.
> 2 extra keyword that do everything. no names :-)
> talkto 0 # talk to the default sprite
> talkto 1 # first clone, etc.
>
> i think that makes most sense if we _really_ want multiple sprites --
> quite a nice feature.

I am not sure if it is easier for children to remember the index of each
turtle or to call them by name. Some research using similar languages
shows that some use indexes, while others use names. The ones that use
indexes do not usually require a create command, you just start talking
to the other turtles, for example

talkto 1
show
...
talkto 0

So no need to create them. Our code could be easily adapted for this, by
checking if a given turtle exists, and if not creating it. These
languages usually have a limit for the number of turtles, around 1024.

Another approach is to create the sprite using a command. There are
several implementations for this, using variations of:

NEWTURTLE
CREATESPRITE
SETSPRITE

But if we really want to keep it dead simple, maybe just document that
internally we have up to 1024 turtles, and only the first one is shown
by default. To use the others, just

TALKTO 1
SHOW

and here you go. So no concept of "creation" of objects, and no explicit
turtle in the command.

>
> buttt... i think there is more important features to implement for kturtle:
> - contextual help still not in
> - errors tab could get some beautification (like spacing the errors
> table nicely)
> - contextual error help would be a killer
> - maybe even the variables tab should have contextual help
> (so it is integration with the help system where is see most low
> hanging fruit for making steps towards kturtle 'goal' of making
> programming something dead easy to start with)

Yes, this would be really useful.

> besides that we have some bugs piling up...
>
> the big change is in the interpreter though -- i would love to have a
> generated parser, and if i look at the design of KJS i see many room
> for improvement on the interpreter side (the ruby i wrote for
> definitions.rb is, ehhh, not the prettiest to say the least). the main
> thing we have to do _before_ the interpreter can get an other big
> cleanup:
>
> unittest
>
>
> that are the priorities the way i see 'm..
>
> dont worrie KTurtle is a free software project -- together with make
> kturtle's future, so if you have a different idea about the priorities
> for future development of kturtle, please post it here :-)

I am not really an expert in computer languages or interpreters, so my
ability to help here is a bit limited... I can see also that some
features (like implementing SETSHAPE to change the turtle graphics)
would open up a lot of new potential, but also several new problems. It
has to be done in a way that does not affect the portability of code,
for example. I will write a proposal for it.

Regards,
Mauricio Piacentini

[ugol]

> > the big change is in the interpreter though -- i would love to have a
> > generated parser, and if i look at the design of KJS i see many room
> > for improvement on the interpreter side (the ruby i wrote for
> > definitions.rb is, ehhh, not the prettiest to say the least). the main
> > thing we have to do _before_ the interpreter can get an other big
> > cleanup:

hi,
I am giving a kturtle course to primary school kids, and it's going
very well. I'll write on my experience as soon as possible (it's 5
lessons per 3 classes divided in 3 groups, so I'll finish in the next
2 months). In the meanwhile, to give back something and not to be
evil, I can help with the interpreter :)
I didn't look deeply at the actual kturtle code so f.e. I don't know
how it leverages kate for syntax higlighting: I started writing a lex/
yacc one, but I could use antlr as well. Antlr is java oriented and
has a c library, but I have used only the java code. Lex/Yacc is
somewhat dated but it's still probably better than antlr for c code
and there is a lot of documentation around (and good books too, like
"modern compiler implementation in c").
I'm not in kde programming, so i can write a fast and easily testable
interpreter, but I still don't know how to wire it with real drawing
commands.

ciao,
uL

http://blog.ugolandini.com

[cies]

hi ugo!

great news.. i really like to hear from users, and what better to hear
than from a user that is interested in becoming contributors. :-)

so you want to contribute on the parser.
i think you have chosen yourself the hardest task to crack. i have
tried several times to make a generated parser for kturtle, but no
success so far. the pitfalls are:
- full unicode support (not all parger generators do so)
- keywords are in XYZ language, so _never_ known on compile time
- the .turtle files are now in a i18nized format, but the localized
script is executed (we need to know the actual i18n keywords to
generate proper error messages and for use in the inspector)
- no unittest harness, so you will not know when you break something.

there is a parser genertor in KDE kdev-PG, read more about it here:
http://apaku.wordpress.com/category/kde/page/4/

the fact that the keywords are not knows on compile time is not much
of a problem as the lexer/tokenizer can spit out 'tokens' that _are_
known at compile time. yet in my experience this made the generated
parser quite a bit more complex (especially given that we want
i18nized error messages giving details info about the place and nature
of the error.
then there is the fact that every node in the AST contains information
about the bit code that it represents. this is needed to do all the
nice highlighting tricks.


ugo, dont let my list of dangers scare you -- i just want to make sure
you well prepared for the task.

:-)

i would love to see that mess of a parser being cleared up with a nice
BNF specification of turtle language.


good luck man!

_cies.



p.s.: with all the beautiful test framework i see in ruby-land lately
(rspec, cucumber stories, etc.), and the simplicity of rake tasks, i
am very tempted to invest in a rake/rspec-based solution for both the
definitions.rb and the unittest suite. good that my job ends in a week
or so :-P

[ugol]

> i think you have chosen yourself the hardest task to crack. i have
> tried several times to make a generated parser for kturtle, but no
> success so far. the pitfalls are:

did you try with lex&yacc? Do you have partial solutions code?

> - full unicode support (not all parger generators do so)

ok, I don't know how well lex&yacc cope with that. Antlr does, but I
don't know very well the c part of antlr... doing it with antlr would
mean also to have a GUI to edit the grammar, which is a very good
thing (antlrworks).

> - keywords are in XYZ language, so _never_ known on compile time

That's what I am thinking about right now!

> - the .turtle files are now in a i18nized format, but the localized
> script is executed (we need to know the actual i18n keywords to
> generate proper error messages and for use in the inspector)

I don't understand this point :(

> - no unittest harness, so you will not know when you break something.

yes, but consider that the interpreter is very hard to test if it's
not done to be testable. To be testable, you could have f.e. a visitor
that makes testable actions. A simple idea:

given the input:
"
learn poly $x {
$y = 360/$x
repeat $x {
fw $y
tr $y
}
}

poly 4
poly 10
"

after the "testing" visit, you have back a string with:

"
repeat 4 fw 90 tr 90
repeat 10 fw 36 tr 36
"

then you can simply check the string to test the code

>
> there is a parser genertor in KDE kdev-PG, read more about it here:http://apaku.wordpress.com/category/kde/page/4/

i'll have a look at it

> the fact that the keywords are not knows on compile time is not much
> of a problem as the lexer/tokenizer can spit out 'tokens' that _are_
> known at compile time. yet in my experience this made the generated
> parser quite a bit more complex (especially given that we want
> i18nized error messages giving details info about the place and nature
> of the error.

I didn't really started to think about that, but I'll try to find a
simple solution.

> then there is the fact that every node in the AST contains information
> about the bit code that it represents. this is needed to do all the
> nice highlighting tricks.

do I have to look at the code to find these info or are documented
somewhere?

> ugo, dont let my list of dangers scare you -- i just want to make sure
> you well prepared for the task.
>
> :-)

it's your job to scare a potential contributor, but not too much :)

ciao,
uL

[cies]

On Fri, Feb 6, 2009 at 9:07 PM, ugol <ugo.l...@gmail.com> wrote:
> did you try with lex&yacc? Do you have partial solutions code?

yeah i tried, didn't hold on to the code though (it became a mess)

>> - full unicode support (not all parger generators do so)
>
> ok, I don't know how well lex&yacc cope with that. Antlr does, but I
> don't know very well the c part of antlr... doing it with antlr would
> mean also to have a GUI to edit the grammar, which is a very good
> thing (antlrworks).

i also dont know. ideally it is close to Qt, using QString for
unicode, etc. i dont know how all the options deal with that.
when i used lex/yacc my lexer was giving tokens to the parser so the
parser never saw any string. this became a pain as everything was
written in c and i had to wrap the whole thing up in order to keep
track of the original-unicode-sting, line/col numbers, etc.

>> - keywords are in XYZ language, so _never_ known on compile time
>
> That's what I am thinking about right now!

the parser will not really see them as it parses from tokens. yet all
the info on a token (unicode string, line/col/length/etc.) should be
kept somewhere. there is a challenge.

>> - the .turtle files are now in a i18nized format, but the localized
>> script is executed (we need to know the actual i18n keywords to
>> generate proper error messages and for use in the inspector)
>
> I don't understand this point :(

what i mean is similar to what i just mentioned already. most
languages use(d) plain ascii, only supply a line/col when an error
occured and have a 1-1 relation between the tokens and their "look"
(i.e.: TOK_PRINT always looks like "print")

kturtle is different: it wants to highlight the keyword while
executing so the AST needs to contain more info about the nodes
(line/col/length) and there is no 1-1 relation between the tokens and
their "look" (the keyword are translated/abbreviated).

>> - no unittest harness, so you will not know when you break something.
>
> yes, but consider that the interpreter is very hard to test if it's
> not done to be testable. To be testable, you could have f.e. a visitor
> that makes testable actions. A simple idea:
>
> given the input:
> "
> learn poly $x {
> $y = 360/$x
> repeat $x {
> fw $y
> tr $y
> }
> }
>
> poly 4
> poly 10
> "
>
> after the "testing" visit, you have back a string with:
>
> "
> repeat 4 fw 90 tr 90
> repeat 10 fw 36 tr 36
> "
>
> then you can simply check the string to test the code

i wrote a simple testing framework like that. there is still some
commandline (unittesting) mode to kturtle because of that. im
interested in writing some ruby scripts to make a nice rake/rspec
based testing framework for kturtle.

last time i looked at it i had things like the execution-test you
mention, but you could also test the AST directly, and the most simple
of all is the 'output test'.

>> there is a parser genertor in KDE kdev-PG, read more about it here:http://apaku.wordpress.com/category/kde/page/4/
>
> i'll have a look at it

this beast is written qt-style. if im not mistaking the qt/nokia
gangsters are also maintaining a PG these days. may be worth checking
what they are upto aswel. im looking at the antlr website now, they
say the c taget is cpp compatible, but that would need a lot of glue
code to make it behave like nice (qt-like nice) cpp code. they say a
pure cpp one is coming late '08.

>> then there is the fact that every node in the AST contains information
>> about the bit code that it represents. this is needed to do all the
>> nice highlighting tricks.
>
> do I have to look at the code to find these info or are documented
> somewhere?

just look at the AST of kturtle (the Node object form the tree),
somehow the parser should parse the turtle code into such a tree.

> it's your job to scare a potential contributor, but not too much :)

i wouldn't li... BOOOOO!

(you saw that coming right?)



cheers,
_c.



> ciao,
> uL
> >
>

[cies]

i didnt have a look at it recently, but this is the parser used by the trolls.

http://labs.trolltech.com/page/Projects/Compilers/QLALR


the kdev-PG supposedly has some features this one doesnt have.


with PGs and kturtle, in my opinion, the relevant questions is: after
my parser is generated, how much work does it take me from there to
get it to work in the existing codebase of kturtle.


i looked at some language implementations and i specifically like the
KJS implementation, nice and clean.

_c.

[ugol]

> > what i mean is similar to what i just mentioned already. most
> > languages use(d) plain ascii, only supply a line/col when an error
> > occured and have a 1-1 relation between the tokens and their "look"
> > (i.e.: TOK_PRINT always looks like "print")
>
> > kturtle is different: it wants to highlight the keyword while
> > executing so the AST needs to contain more info about the nodes
> > (line/col/length) and there is no 1-1 relation between the tokens and
> > their "look" (the keyword are translated/abbreviated).

yes, with antlr it's not a problem. You have a Token class
automatically added to the AST, and in the Token you do have all these
info. Abbreviation is also not a problem, because it's in the grammar
[tr|turnright]. The only real problem seems to be the translation.
One possible approach could be to have another parser translating in
the canonical form (let's say the canonical form is the english one)
before passing it to the interpreter. IF the translator is smart
enough to maintain the same token coordinates (ie line no, col, etc.)
with some padding, that'll do the trick and the highlighting would
continue to work.

uL

[cies]

please have a look at the existing kturtle code..
it accomplishes this already! (obviously)

welcome to the tokenizer:
http://websvn.kde.org/trunk/KDE/kdeedu/kturtle/src/interpreter/tokenizer.h?view=markup

it spits tokens, which are small classes
http://websvn.kde.org/trunk/KDE/kdeedu/kturtle/src/interpreter/token.h?view=markup

tokens contain all that stuff.. line/col/category.

the tokenizer is used by the highlighter! "WHAT?!!" you may ask --
"yes...", like to say it: kturtle reuses the tokenizer for
highlighting the code --> never any highlighting error --> wow.

so.. the parser gets some token objects and creates the node tree
(keeps those tokens in the tree for reference in case of highlighitn
the current keyword etc.) of errors.
now most parser i've seen do not allow you to use token classes. they
are used to (linear programming style) call a bunch of methods in
order to 'get' the line/col/etc data.
so either we need a cooler-than-usual parser, or we need to write a
wrapper around the parser so i believes it is in lineair land while it
is actually dealing with objects.

i think the token objects are quite cool -- and used all over the kturtle code.
the tokenizer is not much of a problem (even in the parser bizz you
see many prefer a hand crafter lexer/tokenizer in specific cases).

so, if you write a parser it basically parses the token stream by the
tokenizer into a node tree. in other words, i'd not rewrite
token(izer).{cpp,h}, but easily kill the whole structure of
parser.*/executer.*/nodetree.*

i really like the design of KJS:
http://websvn.kde.org/trunk/KDE/kdelibs/kjs/

i quite sure the devs of that are helpfull in guiding you with a few
decisions down the road..

good luck man!
_c.