Welcome Guest Search | Active Topics | Members | Log In

Propozycja - nowy operator definiujący nazwę pomocniczą STRUCTAS Options · View
tkowals
Posted: Monday, May 07, 2012 4:54:25 PM
Rank: Advanced Member

Joined: 4/8/2006
Posts: 31
Points: 51
Location: PŁ
Witam serdecznie,
z Radkiem Adamusem napotkaliśmy kilka problemów, które skłoniły nas do wytężonej gimnastyki umysłowej. Mamy propozycje, które chcielibyśmy poddać krytyce i przedyskutować na forum.
Na "rozgrzewkę" propozycja nowego operatora w celu rozwiązania problemów z tworzeniem struktur o określonej budowie. Szczegóły:
structas - dokument googledoc

Za zainteresowanie, komentarze i uwagi z góry dziękujemy :)
habela
Posted: Monday, May 07, 2012 6:59:49 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Cześć,
Problem wygląda znajomo. Na przełomie roku natknąłem się na analogiczną sytuację tworząc przykład wirtualnych perspektyw, które m.in. tłumaczyły nazwy podobiektów z polskich na angielskie, zachowując ich pierwotną, zagnieżdżoną strukturę, w której zdarzały się atrybuty opcjonalne i wielowartościowe.
Opisałem to wtedy w naszym wewnętrznym roboczym dokumencie (związanym z zadaniem w projekcie Synat), ale z racji innych spraw wówczas dyskusja się nie rozwinęła. Załączam plik zawierający sekcję na ten temat.
Wnioski mamy zdaje się dość zbieżne. Zwłaszcza w tym, że jest tu pewne pokrewieństwo z groupas.
Mnie (tak w duchu minimalizmu i ortogonalności) nasunął się taki dziki pomysł, aby istniejący groupas potraktować jako złożenie operatorów group oraz as. Wtedy, gdybyśmy potrzebowali zwykłego efektu groupas, to podzapytanie potraktowane (postfiksowym) operatorem group byłoby konsumowane przez operator as, zaś jeśli chodziłoby nam o uniknięcie opisywanego tu problemu, to konsumentem podzapytania z group byłby operator iloczynu kartezjańskiego.
Podkreślam, że było to wszystko bardzo szkicowe i pomysł może okazać się dziurawy. Ale gdyby się udało w ten sposób zaakcentować podobieństwo z groupas, to byłoby to dość zgrabne.

File Attachment(s):
As_Group.docx (17kb) downloaded 15 time(s).


subieta
Posted: Monday, May 07, 2012 7:19:36 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
W swoim czasie (20 lat temu) długo wahałem się czy wprowadzać groupas czy też operator grupowania i zwykły as. Bałem się jednak, że operator samego grupowania nie będzie zrozumiały dla nieco bardziej naiwnych programistów, stąd stanąłem na tej koncepcji, która jest obecnie. Ale oczywiście można do pomysłu podniesionego przez Piotra wrócić.

Natomiast problem z create i sztucznym rozmnożeniem zagnieżdżonych binderów mnie umknął. Jakiś czas temu Tomek Kowalski zwrócił na niego uwagę i wtedy wydawało mi się, że dobrym rozwiązaniem jest użycie groupas zamiast as. Jak się okazało, to zrodziło problem niekompatybilności wyniku z wynikiem dereferencji.

Jakkolwiek nie mam nic przeciwko operatorowi structas, wydaje się on jednak nieco sztuczny. Do rozważenia jest kast bagu na strukturę, co w już ma precedensy (np. kast sekwencji na bag). To rozwiązanie wymagałoby zwyczajnego as. Zauważę, że kastowanie bagu na strukturę jest bardziej ogólne niż structas, może mieć także inne zastosowania (chociaż obecnie trudno mi sobie wyobrazić, do jakich zapytań by się przydało).
radamus
Posted: Tuesday, May 08, 2012 1:20:31 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
subieta wrote:
W swoim czasie (20 lat temu) długo wahałem się czy wprowadzać groupas czy też operator grupowania i zwykły as. Bałem się jednak, że operator samego grupowania nie będzie zrozumiały dla nieco bardziej naiwnych programistów, stąd stanąłem na tej koncepcji, która jest obecnie. Ale oczywiście można do pomysłu podniesionego przez Piotra wrócić.

Idea operatora structas wpisuje się w tę idee. Oddzielny operator koercji baga na strukturę (powiązany w działaniu z operatorem as) może być trudny do zrozumienia. A operator structas mógłby być, potencjalnie, przedstawiony jako takie połączenie. Sama koercja struktury do baga, rodzi, naszym zdaniem, dużo problemów typologicznych, które zapewne dałoby się rozwiązać, tylko powstaje pytanie czy z pragmatycznego punktu widzenia jest sens budować dosyć skomplikowany mechanizm, gdy tak do końca nie wiadomo do czego to będzie potrzebne (co Pan Profesor był uprzejmy zauważyć).

Rozwiązanie opisane przez Piotra jest próbą rozwiązania tego samego problemu poprzez stwierdzenie, że istnieje odrębny operator grupowania. Szkic opisu nie wyjaśnia, jaki rezultat zwracany jest w wyniku działania tego operatora, ale zakładam, że musiałaby to być struktura (czyli jest to forma syntaktyczna koercji do struktury - no chyba, że należę do grupy naiwnych programistów ;) ). Powoduje to, że złożenie operatorów group oraz as nie działało by tak samo jak operator groupas. W pierwszym przypadku mamy nazwaną strukturę, w drugim nazwaną kolekcję. Sam przykład z dokumentu Piotra:

Code:
Imie as Name group

zakładając, że group zwróci strukturę, daje w rezultacie wynik równoważny do:

Code:
Imie structas Name



Natomiast wykorzystanie osobnych operatorów group oraz as:
Code:
Imie group as Name

da w wyniku inny rezultat (nazwana struktura) od:

Code:
Imie groupas Name

gdzie otrzymamy nazwany bag. Z punktu widzenia działania operatorów nieagebraicznych różnica jest znacząca.

Operator structas jest, naszym zdaniem, rozwiązaniem, które łagodnie wprowadza elementy koercji baga na strukturę (wymuszając nazwanie rezultatu) bez potencjalnych meandrów typologicznych.
Tak na prawdę operator structas był w naszych rozważaniach przystankiem. Nie rozwiązuje on pewnych, istotnych dla nas kwestii, np. przenoszenia informacji o kolejności elementów. Przywołany przez Profesora precedens kastu sekwencji na bag jest z tego punktu widzenia bardziej oczywisty, niż np. kastu z baga na sekwencję czy z baga na strukturę (przy założeniu, ze kolejność elementów w strukturze ma znaczenie).
Kolejny dokument z naszymi rozważaniami w przygotowaniu...
habela
Posted: Tuesday, May 08, 2012 4:33:22 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
No faktycznie, w przyjęciu formuły: groupas = group + as
jest pewien problem.

Przyznam, że jak tego zaproponwanego group nie traktowałem jako operator, który miałby zmieniać strukturę danych podzapytania.
Postrzegałem go, nieco pokrętnie, jako taki operator prewencyjny: "nie iteruj". (Wydaje mi się, że spośród istniejących operatorów, to takim prewencyjnym operatorem (oczywiście służącym czemuś zupełnie innemu) jest ref.)
No tak, ale gdyby on istotnie nie zmieniał bag-a w strukturę, to:
1) wprawdzie utrzymalibyśmy, że groupas = group + as ,
2) ale wtedy dla atrybutów powtarzalnych nie mielibyśmy n pól wewnątrz zawierającego je struct-a, tylko raczej bag-a "zawieszonego" w pojedynczym polu takiego struct-a.
A to byłoby odstępstwem od naszego założenia, że nasze obiekty o atrybutach powtarzalnych czy opcjonalnych zawsze produkują z owych atrybutów płaskie rekordy (o zróżnicowanej liczbie pól).

Więc przyznaję, że w takiej dokładnie formie, jak to opisałem, nie ma sensu tego forsować. Natomiast jestem bardzo przywiązany do takich cech jaki ortogonalność, uniwersalność i spójność nazewnicza - no i z tego punktu widzenia zdecydowanie bardziej przemawia do mnie kast bagu na strukturę.
Poza subiektywno-intuicyjnymi odczuciami, miałby za tym następujące argumenty:
1) structas wymusza swoja konstrukcją podanie nazwy - a mamy już operatory nadania nazwy as i groupas, które dają radę.
2) w niektórych sytuacjach - gdy elementy konwertowanego bagu są już nazwane i tych nazw nie potrzebujemy zmieniać - kast na strukturę uniknie nadmiarowości w kodzie
3) pozostając przy nazwie structas mielibyśmy niekonsekwencję nazewniczą, która trochę utrudniłaby programiście zrozumienie działania:
* groupas nadaje nazwę (tylko opakowuje), zaś structas zmienia też strukturę rezultatu
* struct w structas jest nazwą elementu modelu danych, zaś group w groupas - nie jest.
tkowals
Posted: Tuesday, May 08, 2012 9:13:00 PM
Rank: Advanced Member

Joined: 4/8/2006
Posts: 31
Points: 51
Location: PŁ
Habela wrote:
Natomiast jestem bardzo przywiązany do takich cech jaki ortogonalność, uniwersalność i spójność nazewnicza - no i z tego punktu widzenia zdecydowanie bardziej przemawia do mnie kast bagu na strukturę.

Nie widzę za bardzo w jaki sposób structas miałby być nieortogonalny, a poza tym jakby z SBQL usunąć groupas to okazałby się również całkiem uniwersalny ;). Co do cech to dla mnie ważne są również takie jak prostota, jasna semantyka, koncepcyjna kontynuacja. W tym kontekście wybór właściwego rozwiązania nie jest taki prosty.

Ustaliliśmy na pewno, że problem jest i każdy sporadycznie na niego wpada ;). Natomiast wymienione propozycje rozwiązań chyba nie wydają się wystarczająco przekonujące.
Rozważania o structas doprowadziły nas do jeszcze jednej alternatywnej, bardziej radykalnej, ale nie rewolucyjnej :), propozycji:
Proposal of simplification of the Result domain

Zapraszamy do dyskusji i komentarzy. Z góry dzięki!

PS. Pomysł narodził się z porównania operatorów structas i groupas. Jeżeli kogoś interesują szczegóły tych dywagacji to zapraszam:
structas vs. groupas

subieta
Posted: Thursday, May 10, 2012 12:54:06 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
tkowals wrote:
...jakby z SBQL usunąć groupas to okazałby się również całkiem uniwersalny

Nie mogę się zgodzić. Operator groupas pojawił się jako niezbędny dla pewnych zapytań, których bez tego operatora nie można wyrazić. W szczególności, dotyczy to przetwarzania kolekcji, ktore mogą być puste lub sytuacji, w których wynik obliczonego podzapytania jest następnie uzyty po kropce więcej niż raz. Patrz przykłady E.TC.4 i E.TC.7 z http://www.sbql.pl/Topics/SBQL%20Recursive.html#TransitiveClosures . Atkinson i Buneman w jednym z artykułów skrytykowali SQL za to że nie pozwala na zapis nawet tak elementarnych zapytań jak E.TC.7. Myśląc o tym jak ten problem rozwiązać wpadłem na konieczność dołożenia operatora groupas, ktory wraz z tranzytywnym domknięciem dają odpowiednią moc dla języka zapytań.

Co do rownoważności struktury binderów z tą samą nazwą struct{n(v1), n(v2), n(v3),...} z binderem n{bag{v1, v2, v3, ...}} myślę, że jest to dobre rozwiązanie, które powoduje, że structas może być zastąpiony przez groupas i nie prowadzi to do niekompatybilności argumentu instrukcji create z wynikim dereferencji odpowiedniego obiektu. Nie sądzę abyśmy w tym względzie podłożyli programistom jakąć rafę semantyczną na którą będą się nadziewać. Jest to jakiś kompromis, a zycie zawsze składa się z jakichś kompromisów (a mimo to kończy się fatalnie...).
tkowals
Posted: Thursday, May 10, 2012 1:04:47 PM
Rank: Advanced Member

Joined: 4/8/2006
Posts: 31
Points: 51
Location: PŁ
subieta wrote:
tkowals wrote:
...jakby z SBQL usunąć groupas to okazałby się również całkiem uniwersalny

Nie mogę się zgodzić. Operator groupas pojawił się jako niezbędny dla pewnych zapytań, których bez tego operatora nie można wyrazić.

Oczywiście, zgadzam się. Dodatkowo bez groupas ciężko mi wyobrazić sobie przetwarzania sekwencji. Chodziło mi tylko o to, że w wielu przypadkach structas mogłoby zastąpić groupas. groupas jest bardziej uniwersalny dlatego napisałem to wcześniejsze zdanie z przymróżeniem oka ;).

subieta wrote:
Co do rownoważności struktury binderów z tą samą nazwą struct{n(v1), n(v2), n(v3),...} z binderem n{bag{v1, v2, v3, ...}} myślę, że jest to dobre rozwiązanie, które powoduje, że structas może być zastąpiony przez groupas i nie prowadzi to do niekompatybilności argumentu instrukcji create z wynikim dereferencji odpowiedniego obiektu. Nie sądzę abyśmy w tym względzie podłożyli programistom jakąć rafę semantyczną na którą będą się nadziewać. Jest to jakiś kompromis, a zycie zawsze składa się z jakichś kompromisów (a mimo to kończy się fatalnie...).

Jesteśmy dokładanie takiego samego zdania jak Pan Profesor.
tkowals
Posted: Thursday, May 10, 2012 5:00:43 PM
Rank: Advanced Member

Joined: 4/8/2006
Posts: 31
Points: 51
Location: PŁ
subieta wrote:

W szczególności, dotyczy to przetwarzania kolekcji, ktore mogą być puste lub sytuacji, w których wynik obliczonego podzapytania jest następnie uzyty po kropce więcej niż raz. Patrz przykłady E.TC.4 i E.TC.7 z http://www.sbql.pl/Topics/SBQL%20Recursive.html#TransitiveClosures .

Gwoli ścisłości, to wydaje mi się, że structas poradzi sobie bez problemu z wymienionymi przykładami. Wyniki structas i groupas różnią się, ale po wrzuceniu na ENVS zwracają dokładnie to samo przy wiązaniu nazwy (oprócz przypadku sekwencji!). Nazwa może być wiązana wielokrotnie dopóki bindery znajdują się na ENVS. Sprawę wiązania nazwy w przypadku, gdy kolekcja jest pusta trzeba rozwiązać tak samo jak jest to zrobione przy operatorze as: mimo, że na ENVS nie ma binderów, to kontrola typologiczna umożliwia uniknąć fałszywego wiązania i zwracany jest pusty bag.
Oczywiście za wiele nie wnosi to do naszej, może oprócz tego, że faktycznie operatory są bardzo podobne i przy przyjęciu uproszczenia, które zaproponowaliśmy, groupas jest uogólnieniem (prawidłowo obsługuje sekwencje) i krokiem do przodu w stosunku do structas.
radamus
Posted: Thursday, May 10, 2012 6:40:21 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
subieta wrote:

Co do rownoważności struktury binderów z tą samą nazwą struct{n(v1), n(v2), n(v3),...} z binderem n{bag{v1, v2, v3, ...}} myślę, że jest to dobre rozwiązanie, które powoduje, że structas może być zastąpiony przez groupas i nie prowadzi to do niekompatybilności argumentu instrukcji create z wynikim dereferencji odpowiedniego obiektu. Nie sądzę abyśmy w tym względzie podłożyli programistom jakąć rafę semantyczną na którą będą się nadziewać. Jest to jakiś kompromis, a zycie zawsze składa się z jakichś kompromisów (a mimo to kończy się fatalnie...).


Dochodzi tu jeszcze jeden problem - sekwencje a co za tym idzie informacja 'kolejność jest ważna'. Nasze uproszczenie ma na celu również rozwiązanie tego problemu.

W przypadku struktur informacja taka nie jest wprowadzana explicite. Można, na poziomie semantyki, założyć, że kolejność w strukturze jest istotna, albo że nie jest. Nawet jeżeli założymy, że jest ważna, to z punktu widzenia ENVS nie ma ona znaczenia (jest gubiona w chwili wykonywania operacji nested, której argumentem jest struktura). Może mieć ona oczywiście znaczenie w kontekście operatora porównania struktur.
W takiej sytuacji może się okazać, że
struct{n(v1), n(v2), n(v3),...} jest równowazny n{bag{v1, v2, v3, ...}} gdy kolejność nie jest ważna
struct{n(v1), n(v2), n(v3),...} jest równowazny n{sequence{v1, v2, v3, ...}} gdy kolejność jest ważna

Dlatego wydaje mi się, rozważania te powinny nas doprowadzić do inwalidacji rezultatu struct{n(v1), n(v2), n(v3),...} w ogóle. Taki rezultat jest po prostu niepoprawny (jaki jest jego typ - record{n:typv1; n:typv2; n:typv3; ...}?)

Jeżeli takie założenie poczynimy i zostaniemy tylko przy postaciach: n{bag{v1, v2, v3, ...}} oraz n{sequence{v1, v2, v3, ...}} możemy, tak jak pisaliśmy w dokumencie "Proposal of simplification of the Result domain", wprowadzić do języka schematu możliwość deklarowania czy zmienna (pole rekordu) reprezentuje kolekcję czy sekwencje.

Code:
record Publication {
        title:string;
        author:string[1..*] ordered;
        keywords:string[0..*];
}


Wówczas w wyniku dereferencji przykładowego obiektu otrzymamy rezultat:

Code:
struct {
      title("Decomposition of SBQL Queries for Optimal Result Caching"),
      author(sequence{"Piotr Cybula","Kazimierz Subieta"}),
      keywords(bag{"OODBMS", "SBQL", "optimization", "caching"})
   }



Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.125 seconds.