Empty list types

[Eddie Epstein <ea...@gmail.com>]

Thilo,

I'm trying to resolve minor differences between C++ and Java formats
for XMI serialization. The scenario is that an FS list type is
declared to have mutiple referenced allowed and the tail of an NE FS
list points at an Empty FS list type.

In Java the EmptyFsList type instance is serialized and the tail
points at that FS.
In C++ the Empty FS list type is dropped and tail="".

Does tail=null mean the same thing as tail pointing at an empty list
type? If not, what value does the empty list type have over just
having the tail (or head) feature set to null?

Thanks,
Eddie

Re: Empty list types

[Eddie Epstein <ea...@gmail.com>]

The need for empty and non-empty types seems much more confusing to
me, but as always, beauty is in the eye of the beholder. :)

On 8/10/07, Thilo Goetz <tw...@gmx.de> wrote:
> Eddie Epstein wrote:
> > But car and cdr have such an intuitive feel :)
> >
> > OK, a name is just a name. But how about moving the head and tail
> > features to the main list types, INTEGER_LIST, FLOAT_LIST, etc. and
> > deprecating the EMPTY and NON_EMPTY types? Existing code could
> > continue to work, new code would be simpler and lists easier to
> > understand.
> >
> > Eddie
>
> I don't think that existing code will necessarily continue
> to work.  Some code might rely on the fact that the plain list
> types don't have any features.  Also, new lists would look
> differently, and old code certainly wouldn't be able to handle
> those new kinds of lists.
>
> There's also an argument for not using null as end-of-list
> marker.  It makes writing some code simpler and more elegant
> (as long as you created the lists yourself and know that
> there's no null at the end).
>
> --Thilo
>
>

Re: Empty list types

[Thilo Goetz <tw...@gmx.de>]

Eddie Epstein wrote:
> But car and cdr have such an intuitive feel :)
> 
> OK, a name is just a name. But how about moving the head and tail
> features to the main list types, INTEGER_LIST, FLOAT_LIST, etc. and
> deprecating the EMPTY and NON_EMPTY types? Existing code could
> continue to work, new code would be simpler and lists easier to
> understand.
> 
> Eddie

I don't think that existing code will necessarily continue
to work.  Some code might rely on the fact that the plain list
types don't have any features.  Also, new lists would look
differently, and old code certainly wouldn't be able to handle
those new kinds of lists.

There's also an argument for not using null as end-of-list
marker.  It makes writing some code simpler and more elegant
(as long as you created the lists yourself and know that
there's no null at the end).

--Thilo

Re: Empty list types

[Eddie Epstein <ea...@gmail.com>]

But car and cdr have such an intuitive feel :)

OK, a name is just a name. But how about moving the head and tail
features to the main list types, INTEGER_LIST, FLOAT_LIST, etc. and
deprecating the EMPTY and NON_EMPTY types? Existing code could
continue to work, new code would be simpler and lists easier to
understand.

Eddie

On 8/10/07, Thilo Goetz <tw...@gmx.de> wrote:
> Eddie Epstein wrote:
> > On 8/9/07, Thilo Goetz <tw...@gmx.de> wrote:
> >> I guess there isn't much difference in UIMA, except maybe some
> >> annotator code of course may rely on the difference.  On a conceptual
> >> level, the difference might be that you think of a list whose tail
> >> is null as being open, unfinished.  If on the other hand you've
> >> explicitly set it to be the empty list, that's it, it ends there.
> >
> > The list design would be significantly simpler with just a single list
> > type for each primitive range type, for example just FSList, with a
> > head feature and a tail feature that points at another FSList instance
> > or null to mean no more.
> >
> > Actually, I'm confused with the feature names; if head points at an
> > instance of the primitive data, why isn't it called something like
> > "data" and tail something like "nextElement"?
>
> Sure, we could have called them that.  Those names have a long tradition
> in certain near-extinct programming languages and paradigms.  We could
> have called them car and cdr, but I always found head and tail more
> intuitive ;-)
>
> For computer science historians: http://en.wikipedia.org/wiki/Car_and_cdr
>
> --Thilo
>
> >
> >> So if at all possible, the difference should be preserved.  Does
> >> this happen only for empty lists, or maybe also other types that declare
> >> no features?
> >
> > Just for empty lists.
> >
> > Eddie
>

Re: Empty list types

[Thilo Goetz <tw...@gmx.de>]

Eddie Epstein wrote:
> On 8/9/07, Thilo Goetz <tw...@gmx.de> wrote:
>> I guess there isn't much difference in UIMA, except maybe some
>> annotator code of course may rely on the difference.  On a conceptual
>> level, the difference might be that you think of a list whose tail
>> is null as being open, unfinished.  If on the other hand you've
>> explicitly set it to be the empty list, that's it, it ends there.
> 
> The list design would be significantly simpler with just a single list
> type for each primitive range type, for example just FSList, with a
> head feature and a tail feature that points at another FSList instance
> or null to mean no more.
> 
> Actually, I'm confused with the feature names; if head points at an
> instance of the primitive data, why isn't it called something like
> "data" and tail something like "nextElement"?

Sure, we could have called them that.  Those names have a long tradition
in certain near-extinct programming languages and paradigms.  We could
have called them car and cdr, but I always found head and tail more
intuitive ;-)

For computer science historians: http://en.wikipedia.org/wiki/Car_and_cdr

--Thilo

> 
>> So if at all possible, the difference should be preserved.  Does
>> this happen only for empty lists, or maybe also other types that declare
>> no features?
> 
> Just for empty lists.
> 
> Eddie

Re: Empty list types

[Eddie Epstein <ea...@gmail.com>]

On 8/9/07, Thilo Goetz <tw...@gmx.de> wrote:
> I guess there isn't much difference in UIMA, except maybe some
> annotator code of course may rely on the difference.  On a conceptual
> level, the difference might be that you think of a list whose tail
> is null as being open, unfinished.  If on the other hand you've
> explicitly set it to be the empty list, that's it, it ends there.

The list design would be significantly simpler with just a single list
type for each primitive range type, for example just FSList, with a
head feature and a tail feature that points at another FSList instance
or null to mean no more.

Actually, I'm confused with the feature names; if head points at an
instance of the primitive data, why isn't it called something like
"data" and tail something like "nextElement"?

> So if at all possible, the difference should be preserved.  Does
> this happen only for empty lists, or maybe also other types that declare
> no features?

Just for empty lists.

Eddie

Re: Empty list types

[Thilo Goetz <tw...@gmx.de>]

Eddie Epstein wrote:
> Thilo,
> 
> I'm trying to resolve minor differences between C++ and Java formats
> for XMI serialization. The scenario is that an FS list type is
> declared to have mutiple referenced allowed and the tail of an NE FS
> list points at an Empty FS list type.
> 
> In Java the EmptyFsList type instance is serialized and the tail
> points at that FS.
> In C++ the Empty FS list type is dropped and tail="".
> 
> Does tail=null mean the same thing as tail pointing at an empty list
> type? If not, what value does the empty list type have over just
> having the tail (or head) feature set to null?

I guess there isn't much difference in UIMA, except maybe some
annotator code of course may rely on the difference.  On a conceptual
level, the difference might be that you think of a list whose tail
is null as being open, unfinished.  If on the other hand you've
explicitly set it to be the empty list, that's it, it ends there.

So if at all possible, the difference should be preserved.  Does
this happen only for empty lists, or maybe also other types that declare
no features?

> 
> Thanks,
> Eddie