Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 1

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  schemat danych
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
1
Content available remote Types and Type Checking in Stack-Based Query Languages
EN
In this report we propose a new approach to types and static type checking in object-oriented database query and programming languages. In contrast to typical approaches to types which involve very advanced mathematical concepts we present a type system from the practitioners' point of view. We argue that many features of current object-oriented query/programming languages, such as ellipses, automatic coercions and irregularities in data structures, cause that very formal type systems are irrelevant to practical situations. We treat types as some syntactic qualifiers (tokens or some structures of tokens) attached to objects, procedures, modules and other data/program entities. Such syntactic qualifiers we call signatures. We avoid the simpleminded notion that a type has some internal semantics e.g. as a set of values. In our assumptions a type inference system is based on predefined decision tables involving signatures and producing type checking decisions, which can be the following: (1) type error, (2) new signature, (3) dereference, coercion and/or delegation of a type check to run-time. A type inference decision table is to be developed for every query/programming operator. Type inferences are implied by the stack-based approach (SBA) to object-oriented query/programming languages. Static type checking is just a compile time simulation of the run-time computation. Thus the type checker is based on data structures that statically model run-time structures and processes, that is: (1) metabase (internal representation of a database schema, a counterpart of an object store), (2) static environment stack (a counterpart of run-time environment stack), (3) static result stack (a counterpart of run-time result stack) and (4) type inference decision tables (a counterpart of run-time computations). Then, we present the static type check procedure which is driven by the metabase, the static stacks and the type inference decision tables. To discover several type errors in one run we show how to correct some type errors during the type check. Finally we present our prototype implementation showing that our approach is feasible and efficient with moderate implementation effort.
PL
W raporcie proponujemy nowe podejście do typów i statycznej kontroli typologicznej w obiektowych językach zapytań/programowania. W przeciwieństwie do podejść wykorzystujących zaawansowane koncepcje matematyczne prezentujemy tu pozycję praktyków. Wiele cech obecnych języków zapytań/programowania, takich jak elipsy, automatyczne koercje oraz nieregularności struktur danych, powodują, że bardzo formalne systemy typologiczne nie odpowiadają praktyce. Proponujemy typy jako syntaktyczne kwalifikatory (znaki lub struktury znaków) przypisane do obiektów, procedur oraz innych bytów programistycznych. Takie kwalifikatory nazwaliśmy sygnaturami. Unikamy popularnego punktu widzenia, w którym typ posiada wewnętrzną semantykę, np. w postaci zbioru wartości. System wnioskowania o typie jest oparty na tabelach decyzyjnych działających na sygnaturach i generujących decyzje w zakresie kontroli typologicznej, które mogą być następujące: (1) błąd typologiczny, (2) nowa sygnatura, (3) dereferencja, koercja i/lub oddelegowanie kontroli typu do czasu wykonania. Tablice decyzyjne powinny być sporządzone dla każdego operatora występującego w zapytaniach/programach. Wnioskowanie o typie jest implikowane przez podejście stosowe (SBA) do obiektowych języków zapytań/programowania. Statyczna kontrola typologiczna symuluje podczas kompilacji tę sytuację, która zajdzie podczas czasu wykonania. Stąd kontroler typów jest oparty na strukturach danych, które statycznie modelują struktury i procesy czasu wykonania, tj.: (1) metabaza (wewnętrzna reprezentacja schematu, odpowiednik składu obiektów), (2) statyczny stos środowiskowy (odpowiednik stosu środowiskowego), (3) statyczny stos rezultatów (odpowiednik stosu rezultatów), (4) tablice decyzyjne wnioskowania o typie (odpowiednik operatorów). Następnie prezentujemy procedurę statycznej kontroli typów, której działanie jest oparte na metabazie, statycznych stosach i tabelach decyzyjnych. Aby wykryć wiele błędów typologicznych w jednym przebiegu pokazujemy, jak należy skorygować pewne błędy typologiczne podczas kontroli typologicznej. Na końcu prezentujemy prototypową implementację pokazującą, że nasze podejście jest osiągalne i efektywne przy umiarkowanym wysiłku implementacyjnym.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.