specs

[RE01 Rice Brian T. EM2]

> I am afraid I can't agree on this :-(. The linear text based format is
> just one way of representing the information. And to me it does not
> matter. What matters is the semantics behind the syntax. I can imagine
> an interface to Lisp which would enable you to handle "graphical"
> items such as arrow instead of linear text. 
> 
you have a good imagination, because that's NOT Lisp.  that's something
else.  Lisp is based on symbols of text.  that's like stating that a diagram
of a BASIC program makes a visual language.

> And in many domains, arrows are probably not the best to visualize
> information. 
> 
arrows are _not_ the user interface, and they are not a first-order
visualization method.  instead, the structure of an arrow system would be
the information presented, and this, although preferrably visual, would
definitely _not_ be best displayed as arrows only, or even mostly arrows.

> I advocate the complete separation of semantics and representation of
> information. One piece of information can be visualize in many
> different ways, depending of the preferences of the user.
> 
how is this different than what i advocate?  what "is" semantics anyway,
other than the syntax of concepts?  what is representation other than the
syntax of communication?

>     Brian> another thing is that some of the abstraction operators for
>     Brian> which i'm developing explanations do a lot of
>     Brian> 'cross-cutting' that would result in an overload of
>     Brian> identifiers.  
> Overloading of identifiers looks like a syntactical problem to me. And
> I think I have already expressed my opinion on syntactical problems. :-)
> 
NO.  you're completely missing the point.  i don't mean overloading
operators as is done in current languages.  i refer to gargantuan symbol
tables required by a Lisp evaluator to emulate this system.  also, you
shouldn't gloat so about an argument which is narrow-minded, since it proves
something only in a domain limited to a fragment of an ontology.

> Infinitary structures means infinite quantity of information. And this
> is a problem anyway if you consider that we only have finite amunt of
> memory. 
> 
did i say STORE infinitary structures?  no.  i referred to reasoning about
infinitary structures and postulating statements about their elements.

> And if you mean that prolific arrow structure might lead to
> performance problems, let me tell you something : I think the same
> about performance problems than about syntactical problems :-) (it
> comes after semantic related problems).
> 
you divide your world into 'syntax' and 'semantics', and i will watch you
chase your tail as you watch your goal recede from view.