Tokenizen, nodig of niet

[jvdmeer]

Ik ben als hobby-project bezig met een interpreter voor een gespecialiseerd script. Nu had ik hier op GoT al redelijk vaak gehoord dat je dan het beste het script kan tokenizen alvorens te verwerken.
op internet is een hoop te vinden over tokenizen, maar dan vooral over het 'wat het is' en over 'hoe jet het doet'.

Over het waarom kan ik echter weinig vinden. Wat is het nut van tokenizen? Wat zijn de voordelen als je dit doet?

[Flard]

Ik denk dat het voordeel van tokenizen is dat je enerzijds je grammatica heel goed kunt controleren en beheren. Je hebt immers échte grammaticale regels, waardoor je theoretisch ook complexere constructies kunt ontwerpen (toestaan volgens je grammatica).
Anderzijds kun je je interpreter ook op basis van de tokens zijn commando's uit laten voeren, waardoor je (afhankelijk van je ontwerp) ook een vrij modulaire interpreter kunt schrijven.

Maar goed, je zult moeten afwegen in hoeverre het tokenizen zin heeft. Als je maar een zeer beperkte instructieset hebt, met weinig parameters (of in ieder geval geen moeilijke constructies) dan is tokenizen misschien wat 'overdone'.

[jvdmeer]

Flard schreef op maandag 17 september 2007 @ 10:14:
Maar goed, je zult moeten afwegen in hoeverre het tokenizen zin heeft. Als je maar een zeer beperkte instructieset hebt, met weinig parameters (of in ieder geval geen moeilijke constructies) dan is tokenizen misschien wat 'overdone'.

Mijn doel is wel een gespecialiseerd script, met taalelementen van PHP, pascal, VBS en Python (denk ik).
Voorbeelden:

VBS:
• if...then...elseif...else...
Pascal:
• alle variabelen zijn verplicht strong-typed
• arrays kunnen benaderd worden middels []
Pyhton (denk ik):
• Blokken worden gedefinieerd door hun indentation
dus:

code:

If a=5 then
  doeiets
else
  doeietsanders
  doenogiets
ditaltijdoen

PHP:
• zowel ' als " fungeren als aanhalingsteken. Escapen is niet mogelijk

Daarnaast is er volledige vrijheid in nesting van functies in elkaar indien ze maar het goede type retourneren. Enige beperking is een regellengte van (nu gekozen) 160 tekens.

Ik kan me voorstellen dat tokenizen wist oplevert wanneer regels meer dan eens moet bekijken. Maar ik wil de mogelijkheid bieden om tijdens de uitvoering (in soort van debug-mode) het script te wijzigen in de editor. Zoals vroeger bij MS-Basic.

Met als doel om specifieke bestanden intern te bewerken. (Verder laat ik me er nog niet over uit)

[Janoz]

Je zult je gehele script op 1 of andere manier in het geheugen moeten houden. Een grote string met hierin het bestand is daarvoor niet een handig datatype. Over het algemeen wordt het script omgezet in een syntaxtree. Hoe deze tree eruit ziet hangt af van je syntax specificatie. Het tokenizen levert deze syntaxtree op. Meer is er eigenlijk niet van te maken. Er is niet ehct een handige andere manier om die syntaxtree op te bouwen.

[RayNbow]

Janoz schreef op maandag 17 september 2007 @ 12:00:
Het tokenizen levert deze syntaxtree op.

Erm, niet helemaal...

Program text      -->  Lexer/Tokenizer  -->  Stream of tokens
Stream of tokens  -->  Parser           -->  Abstract syntax tree

[EfBe]

RayNbow schreef op maandag 17 september 2007 @ 12:43:
[...]

Erm, niet helemaal...

Program text      -->  Lexer/Tokenizer  -->  Stream of tokens
Stream of tokens  -->  Parser           -->  Abstract syntax tree

Veel parsers leveren echt geen tree op, omdat die ook weer geinterpreteerd moet worden. Veelal is de parser de plek waar de tokens naar non-terminals worden geconverteerd en tijdens dat process (LL(n)) of na conversie (LR(n)) wordt dan de output ge-emit. Dus wanneer je geen echte analyse hoeft te doen van de tree, levert de parser eerder output dan een tree.

[Grijze Vos]

EfBe schreef op maandag 17 september 2007 @ 13:03:
[...]

Veel parsers leveren echt geen tree op, omdat die ook weer geinterpreteerd moet worden. Veelal is de parser de plek waar de tokens naar non-terminals worden geconverteerd en tijdens dat process (LL(n)) of na conversie (LR(n)) wordt dan de output ge-emit. Dus wanneer je geen echte analyse hoeft te doen van de tree, levert de parser eerder output dan een tree.

Inderdaad, maar hij heeft wel gelijk dat een tokenizer in principe alleen een tokenstream genereert, en niet een tree.

[Janoz]

Misschien had ik inderdaad beter kunnen zeggen dat tokenizing uiteindelijk de syntaxtree oplevert. Het is inderdaad eerder de eerste stap van het proces ipv dat het het hele proces is.

[Grijze Vos]

jvdmeer schreef op maandag 17 september 2007 @ 10:04:
Over het waarom kan ik echter weinig vinden. Wat is het nut van tokenizen? Wat zijn de voordelen als je dit doet?

Je wilt een nieuw abstractie niveau aanbrengen. Als je een syntax boom opbouwt dan bestaan die uit taalconstructies, deze komen uit je stuk code text naar voren als tokens. Je leest een 'I', en je leest een 'F', en vervolgens is dit dus een IF token. Als je niet tokenized dan maak je het parsen gewoon een stuk complexer.

Je schrijft toch ook geen functie van 400 regels, terwijl je het ook netjes in 15 verschillende functies kunt onderbrengen. Het is gewoon een stukje Separation of Concerns.