Quali sono le applicazioni degli alberi di rose?

Di recente ho scoperto la struttura dei dati del roseto, ma appena uscendo da una datadefinizione di Haskell e dalla sua minuscola descrizione di Wikipedia , ho qualche problema a capire quali applicazioni potrebbe avere un roseto.

Per riferimento, la datadefinizione di Haskell :

data RoseTree a = RoseTree a [RoseTree a]

Per chi non ha familiarità con Haskell - è una definizione di tipo di dati ricorsivo con un tipo arbitrario a, in cui il costruttore del tipo è fornito con un letterale di tipo aseguito da un elenco di tipi facoltativamente vuoto RoseTreesullo stesso tipo a.

Come la vedo:

• Questa struttura di dati non è ordinata per impostazione predefinita (anche se presumo che la maggior parte delle applicazioni pratiche implementa una qualche forma di ordinamento per la ricerca)

• La struttura dei dati non impone un numero fisso di nodi per livello in nessun punto, tranne la radice globale, che deve avere un singolo nodo

Data la minima quantità di informazioni, ho difficoltà a capire quando si potrebbe usare questo tipo di albero.

Oltre alla domanda nel titolo, se la ricerca è effettivamente implementata nella maggior parte delle applicazioni di un albero di rose, come si fa?

Sembra che tu abbia una mentalità eccessivamente "strutture dati e algoritmi". Non tutti gli alberi sono una specie di albero di ricerca. Le strutture di dati sono spesso progettate per corrispondere o acquisire aspetti di un modello di dominio.

Le espressioni S sono quasi esattamente alberi di rose. (O meglio, direi che in genere sono pensati come alberi di rose. Wikipedia ha ragione nel dire che sono più simili a alberi binari, ma quelle che potresti definire espressioni "S" corrette sono solo leggermente diverse dagli alberi di rose.) Ad ogni modo, puoi usarli come una rappresentazione generica per un albero di sintassi astratto. Il vantaggio di ciò è che puoi facilmente scrivere operazioni generiche, ad esempio "trova tutte le variabili" o "parametri di scambio" o "rinomina questo simbolo". È anche estensibile in quanto l'aggiunta di un nuovo tipo di nodo alla sintassi astratta spesso non richiede davvero alcuna modifica. Gli svantaggi sono che non ci sono davvero vincoli, quindi non ti impedisce a priori di scrivere sciocchezze. Ciò può essere mitigato per gli utenti mediante tecniche standard di tipo di dati astratti, ma l'implementatore di trasformazioni e simili devono occuparsi della rappresentazione non strutturata anche se "sanno" che l'input è strutturato tramite un invariante di tipo di dati. Naturalmente, quando quella certezza è fuori luogo (forse perché le cose sono cambiate), gli errori tendono ad essere imprevedibili e difficili da eseguire il debug.

In pratica, mentre il Data.Treemodulo nelle librerie standard fornisce un albero di rose, quasi nessuno lo usa nella comunità di Haskell. La definizione di tipi di dati personalizzati che catturano esplicitamente i vincoli è così semplice che non vi è motivo di utilizzare un tipo di libreria generico. Inoltre, ci sono state molte ricerche e pratiche sull'esecuzione di operazioni generiche rispetto a tipi personalizzati, il che elimina molti dei vantaggi dell'utilizzo di una rappresentazione generica. Infine, gli Haskeller tendono ad essere molto a favore di vincoli espliciti e forzati e sono disposti a pagare per ottenerlo.

Per rispondere alla tua ultima domanda, spesso la ricerca di un AST non è importante e / o si presume che gli AST siano abbastanza piccoli da consentire il solo passaggio a piedi. Certo, non è raro raccogliere le definizioni in una struttura di dati separata con riferimenti nell'AST che potrebbero essere visti come una sorta di indice. Allo stesso modo, alcuni passaggi di ottimizzazione costruiranno (solitamente localmente e temporaneamente) indici per semplificare e velocizzare il loro funzionamento. La struttura dell'AST corrisponde all'input e quindi non può essere "ribilanciata" o qualcosa del genere. Pertanto, è raro che l'AST stesso contenga informazioni di indicizzazione o informazioni per facilitare la "ricerca".