Proposal, Heirarchical module structure for tools

"Neil Mitchell" <ndmitchellgmail.com> wrote:

> > > So where would the library half of HatCover
vs the program half of
> > > HatCover go?
> >
> >     HatCover     -> Tracing.Hat.Coverage
> >     HatCoverText ->
Tracing.Hat.Coverage.Textual
> >     hypothetical -> Tracing.Hat.Coverage.HTML
> >     hypothetical -> Tracing.Hat.Coverage.Gtk
> 
> Hmm, I don't like that much. I'm not entirely sure
about this whole
> calling console programs "Textual", they
aren't, they are Console
> programs (I object to HatCoverText as well).

Well, "console" is the wrong word as well.  On a
unix machine, there is
only one console, but there may be many textual terminals or
terminal
emulators.

I intended the word "textual" to indicate an API
that produces Strings,
not something that interacts per se with a terminal. 
However, I now
realise that your objection is probably that the text
strings produced
are not pure - they have ANSI terminal colour codes.  Fair
enough.

        HatCoverText -> Tracing.Hat.Coverage.ANSIterm

> It also obscures the fact
> that HTML should be an API (so the Console and Gui can
use it), but
> Gtk will probably be a viewer.

Well, I intended that all of these should be APIs, the ANSI
coloured
text as much as the HTML.  As you say, the actual rendering
of these
belongs elsewhere.  So if there is no particular role for a
GTK API
for hat-cover, it should not exist as a module
Tracing.Hat.Coverage.Gtk.

The rendering might therefore belong in something like
    Tracing.Hat.GtkGUI
which might use APIs from Tracing.Hat.Coverage as well as
Tracing.Hat.Observe, and numerous others as well.

Regards,
    Malcolm
_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

Hi

> I intended the word "textual" to indicate an
API that produces Strings,
> not something that interacts per se with a terminal. 
However, I now
> realise that your objection is probably that the text
strings produced
> are not pure - they have ANSI terminal colour codes. 
Fair enough.

Ah, I thought your intention was to export a
"main" from this -
returning Strings (coloured strings at that) is a perfectly
reasonable
thing to have as an API.

The way I do terminal codes in Hoogle is to define a type,
TagStr:

data TagStr = Str String | Tags [TagStr] | Underline TagStr
| Bold
TagStr | Color Int TagStr

Now instead of dumping out escape codes, I dump out
TagStr's, and then
have a routine that converts from TagStr -> String with
escape codes.
This has the massive advantage that on OS's that don't
support escape
codes, I can use exactly the same generation code, and then
drop the
escape codes very simply.

Perhaps thats a better way to go instead of having an API
that works
in very low level escape code terms.


>         HatCoverText ->
Tracing.Hat.Coverage.ANSIterm

The name ANSIterm makes me uneasy, Terminal perhaps?
ANSIterm just
looks ugly, and the case of it is weird compared to the rest
of
Haskell.

In general we now seem to be pretty much in agreement about
the
proposed structure.

Thanks

Neil
_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

>
> The way I do terminal codes in Hoogle is to define a
type, TagStr:
>
> data TagStr = Str String | Tags [TagStr] | Underline
TagStr | Bold
> TagStr | Color Int TagStr
>
> Now instead of dumping out escape codes, I dump out
TagStr's, and then
> have a routine that converts from TagStr -> String
with escape codes.
> This has the massive advantage that on OS's that don't
support escape
> codes, I can use exactly the same generation code, and
then drop the
> escape codes very simply.

You should note that this is in large part what hat already
does.   
Look at the Highlight Module.

Bob

>>         HatCoverText ->
Tracing.Hat.Coverage.ANSIterm
>
> The name ANSIterm makes me uneasy, Terminal perhaps?
ANSIterm just
> looks ugly, and the case of it is weird compared to the
rest of
> Haskell.
>
> In general we now seem to be pretty much in agreement
about the
> proposed structure.

I can't see any major problems with it.

Bob
_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

Hi,

> You should note that this is in large part what hat
already does.
> Look at the Highlight Module.
>
> >>         HatCoverText ->
Tracing.Hat.Coverage.ANSIterm
> >
> > The name ANSIterm makes me uneasy, Terminal
perhaps? ANSIterm just
> > looks ugly, and the case of it is weird compared
to the rest of
> > Haskell.

In that case how about Tracing.Hat.Coverage.Highlight,
exporting a
data structure one step above the low level escape coded
strings.
Saves us the issue of making an ugly name, and makes it more
useful.

Thanks

Neil
_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

"Neil Mitchell" <ndmitchellgmail.com> wrote:

> > You should note that this is in large part what
hat already does.
> > Look at the Highlight Module.
> 
> In that case how about Tracing.Hat.Coverage.Highlight,
exporting a
> data structure one step above the low level escape
coded strings.

Yeah.  Or
    Tracing.Hat.Coverage.Highlighted
or
    Tracing.Hat.Coverage.Highlit
to make it even clearer.

Regards,
    Malcolm
_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

Highlight is used by all the tools though, so
Tracing.Hat.Highlight  
would make much more sense.

Bob

On 11 Oct 2006, at 15:04, Neil Mitchell wrote:

> Hi,
>
>> You should note that this is in large part what hat
already does.
>> Look at the Highlight Module.
>>
>> >>         HatCoverText ->
Tracing.Hat.Coverage.ANSIterm
>> >
>> > The name ANSIterm makes me uneasy, Terminal
perhaps? ANSIterm just
>> > looks ugly, and the case of it is weird
compared to the rest of
>> > Haskell.
>
> In that case how about Tracing.Hat.Coverage.Highlight,
exporting a
> data structure one step above the low level escape
coded strings.
> Saves us the issue of making an ugly name, and makes it
more useful.
>
> Thanks
>
> Neil
> _______________________________________________
> Hat mailing list
> Hathaskell.org
> http://ww
w.haskell.org/mailman/listinfo/hat

_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

Hi

> Highlight is used by all the tools though, so
Tracing.Hat.Highlight
> would make much more sense.

For the module that gives an abstract data structure for a
"Highlighted expression"

> > In that case how about
Tracing.Hat.Coverage.Highlight

For the module that generates coverage data in a highlighted
data structure.

I think everyone agrees pretty much now 

Thanks

Neil
_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat