Re: [GF] The Maybe type

23 views
Skip to first unread message

Krasimir Angelov

unread,
May 10, 2013, 5:12:43 AM5/10/13
to gf-...@googlegroups.com
Hi John,

While the Maybe module might be usable in some situations, there is a good reason why something like this is not used for the adjectives in English. In general the main limiting factor for the size and for the performance of a grammar is the number of parameters that a given lincat has. If we use Maybe instead of a string this can in the worst case double the size of the compiled grammar. The compiler is trying to minimize the overhead but it is always a good idea to help with this.

Best Regards,
  Krasimir


2013/5/9 John J. Camilleri <jo...@johnjcamilleri.com>
Hi all,
When writing a resource grammar, I find that having record fields which may be empty is quite a common occurrence. For example, some adjectives in English have a morphological comparative ("happy - happier") while others don't ("expensive - more expensive"). I normally encode this as a string and a boolean, since it is a bad idea to match on the emptiness of the string itself. But this is precisely like the Maybe type in Haskell. So I wrote a resource module which models this.
The Maybe.gf file is attached; below is an example of its use.
I'm surprised no one's done this before actually! Comments are welcome. If you like it, I suggest we include it in the Prelude folder of the RGL.

Abstract

abstract Test = {
  cat
    A ; N ; Phr ;
  fun
    caviar_N, pizza_N : N ;
    expensive_A, good_A : A ;
    more : N -> A -> N -> Phr ;
}

Concrete

concrete TestEng of Test = open Prelude, Maybe in {

  lincat
    A = {
      posit : Str ;
      comp : MaybeS
      };
    N   = SS ;
    Phr = SS ;

  lin
    caviar_N = ss "caviar" ;
    pizza_N = ss "pizza" ;

    expensive_A = {
      posit = "expensive" ;
      comp = NothingS ;
      } ;

    good_A = {
      posit = "good" ;
      comp = JustS "better" ;
      } ;

    more = \n1,a,n2 ->
      let
        cmp : Str = fromMaybeS ("more" ++ a.posit) a.comp
      in
      ss (n1.s ++ "is" ++ cmp ++ "than" ++ n2.s) ;
}

Testing in shell

Test> l more caviar_N good_A  pizza_N 
caviar is better than pizza

Test> l more caviar_N expensive_A  pizza_N 
caviar is more expensive than pizza

--
 
---
You received this message because you are subscribed to the Google Groups "Grammatical Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gf-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

John J. Camilleri

unread,
May 10, 2013, 5:19:02 AM5/10/13
to gf-...@googlegroups.com
Thanks for your reply, Krasimir.
However I'm not sure what you mean by parameters in this case. The way I see it, using the Maybe type is essentially replacing this record pattern:

{ s : Str ; hasS : Bool }

with this one

{ s : { inner : Str ; exists : Bool } }

which is "one level deeper". Is this worse than the former one?

Krasimir Angelov

unread,
May 10, 2013, 5:59:17 AM5/10/13
to gf-...@googlegroups.com
2013/5/10 John J. Camilleri <jo...@johnjcamilleri.com>

Thanks for your reply, Krasimir.
However I'm not sure what you mean by parameters in this case. The way I see it, using the Maybe type is essentially replacing this record pattern:

{ s : Str ; hasS : Bool }

with this one

{ s : { inner : Str ; exists : Bool } }

which is "one level deeper". Is this worse than the former one?


Yes. The two defininitions that you gave will be essentially equivalent. My point is whether you can remove the parameter 'exists' at all. This is what is done by having "more expensive" as a morphological form of expensive. In this way the lincat will be:

lincat A = {posit : Str; comp : Str};

i.e. there are not parameters in this case. Of course there are cases when the use of parameters is unavoidable and then the Maybe type may become useful.

John J. Camilleri

unread,
May 10, 2013, 6:20:17 AM5/10/13
to gf-...@googlegroups.com
Aha, now I see your point. Yes, in the example I gave your solution would work and would of course be more efficient since there would be no need for the Boolean field. I guess the Maybe type should be seen as a drop-in replacement for when you already have a boolean paired with another type (and you know the boolean is essential).
One could further argue that using the Maybe type doesn't really make your code any shorter ultimately. But I still think it's sometimes nice to trade width for depth in the record structure, when fields are coupled together in this way. 
Reply all
Reply to author
Forward
0 new messages