Thanks for help: suggest small addition to lang.ref.

[tcklnbrg]

Thanks to all for the help.  I think I finally understand what Mercury
is doing with type definitions.

> you are telling Mercury that you want a type called `classname' which
> denotes a set of terms all of the form:
>         this_is_just_a_functor(<any old string can go here>)
> 
> Now, if you want to attach some meaning to the string, then you need to
> check that when you construct the term:
> 
> :- pred make_classname(string, classname).
> :- mode make_classname(in, out) is semidet.
> 
> make_classname(String, ClassName) :-
>         check_string_has_right_properties(String),
>         ClassName = this_is_just_a_functor(String).
> 
> Now you can pass around things of type classname, and know that if
> this is the only place where you construct classnames then they
> have the right form.

Aha! Relief! finally, this is the explanation I was looking for.  
Thanks very much.  

I think that the above explanation would be a valuable addition to the
language
reference in the section on types.  It would certainly clarify the use
of the
word constructor.

> Maybe we should take this discussion off mercury-users?

I think I will need some advice on using
Mercury's IO---the "no side effects" stuff.

Where should I post my questions?


Thanks again,

Ann Tecklenburg



/**********read if you are curious as to what I am trying to do and
why************************

I want to point out that Mercury is a unique language and that there are
probably only a few dozen people in the world who are proficient in it. 
And there
are no "Mercury for dummies" or "Mercury in a Nutshell" books out there
to help anyone
get started. 

I have used Prolog off and on for 10 years where rule bases were
required.  I have 1500 lines
of Prolog code already running for the current project which describe
Java classes in clausal
form (so this is not really a tokinizing problem) 
and are generating preliminary skeletons of simple code correctly.  

Writing Java is not an option:  Its a defective language, but its class
libraries provide
extraordinary functionality.  It also doesn't build well with a GUI
builder because it is
pattern and rule based.  In fact the explosion of rules and patterns
required to program
Java is humanly unmanageable now and rapidly getting worse. 

What we are finding as well is
that every vendor of class libs is adding their own ad-hoc rules and
patterns with no guarantee
of consistency.  (In fact considering Microsoft's recent mix-ins---a
guarantee of inconsistency.)

Hence the current project:  get the rules and patterns into
a rule base and let it write, or at least provide advice, on writing
correct Java code,
especially for the very large frameworks such as enterprise Java Beans.  

(How large *is* such a framework:  
IBM's San Francisco (the first one) has 300,000 lines of Java now and
will probably
go to nearly 1 million before its done.  In reality, we cannot hope to
encode more than a few
hundred of the simplest and most common of the rules and patterns in
such a framework,
but even that would be very helpful.)

So why don't I just stay with standard Prolog which is certainly
friendlier?:  The potential
size and indeterminacy of the rule base among other things.
I want, once and for all, a tool that can go the distance, without
choking.  

Looking at Mercury's feature set, it seemed possible
that Mercury could address a number of problems, now and in the future.

1) Type checking:  
	The goal was be to reduce the number of lines of Prolog code and
guarantee
	consistent type validation on object construction 
	the way that constructing a new instance of an
	object type would in an 00-language.  
	(After the last replies, I can see that Mercury's types don't work like
	class constructors in an 00-language, as I had thought. So I
	can't use Mercury's types as I had hoped.)
	 
2) Modes (this does appear that it will help), and it helps that the
compiler attempts
	to check determinacy.  

3) C-code integration (very slick!  good job.)  We will eventually have
to put a Java GUI interface onto the rule-set,
and this looks very do-able with Mercury via C and JNI.

4) Speed and "public domain"--- I intend to release this "builder tool"
GPL for use on Linux in particular, 
	and these features are desirable.  BTW, I am doing this completely
without pay, on my own time.

So, it does seem that Mercury has some advantages for the project.


>         [this is a bit frustrating - if you were here, 1/2 an hour
>          in front of a whiteboard, and you'd be happily on your way.
>          email is a difficult medium for this kind of thing]> >

Agreed entirely, but those of us who don't live nearby don't have much
of a choice.


end rant---sorry to be such a bother.
*******************************************************************************************/