[m-users.] Correct use of solutions.
Mark Brown
mark at mercurylang.org
Mon Jul 31 11:58:56 AEST 2023
On Sat, Jul 29, 2023 at 9:17 PM Sean Charles (emacstheviking)
<objitsu at gmail.com> wrote:
>
> HA! Yes, a poor choice of word, I meant trivial as in I knew how to do it and not spend half an hour in an argument with a compiler.
Better than spending three hours with a Prolog debugger because your
variable wasn't sufficiently instantiated :-P
>
> I've said it before, I have long wanted to write my transpiler, I have working versions in C, Haskell and SWI Prolog but ultimately, the long term robustness I seek and the worries of not having to deal with memory allocation mean that, despite it feeling like doing three rounds with Mike Tyson at times, I am determined to complete the mission!
In all seriousness, I think SWI Prolog is an excellent system with
which to implement a compiler. Even if intending to build a compiler
in Mercury in the long term, rapidly prototyping (parts of) it in
Prolog is often an excellent approach to take in my opinion.
For example, if one wanted to design a novel form of multiple
inheritance in an OO-type language, working out the inheritance
mechanism with a quick Prolog implementation could be very useful
prior to designing the data structures, etc, you would use in the full
implementation. Then there's constraint solvers for program analyses,
and plenty of other benefits.
A little off track for this list, but I thought it worth mentioning
some of Prolog's advantages in this area.
Cheers,
Mark
>
> As an untutored amateur, I absolutely appreciate what the compiler does for me in terms of making me think about what *I* am trying to do. I have barely used any of the advanced features such as high-order functions and type-classing with subtypes etc. I use those when I think they might help.
>
> Sometimes I sit and think for a day or two before resuming coding of my project. I love the Mercury *makes me think* about what I am doing, and I am beginning to understand its internal dialogue too, I think if it was written in plainer more easily assimilated language that would have helped; as I say, I didn't do a CS degree, so a lot of the terminology I have to Wikipedia and go down a rabbit hole for a while, not that I mind! Learning and using Mercury this last couple of years has helped me be a better developer in Python and React by the simple transfer of techniques to other languages, not always straightforward, but it always ends well.
>
> For me, I think that the software industry would be in much better shape if everybody had to use Mercury! I have to maintain a React application as part of my day job, it's a relatively simple UI, it has close to 200,000 files in node_modules. Unreal. And probably unsafe somewhere.
>
> Thanks.
> Sean.
>
>
> > On 29 Jul 2023, at 12:09, Mark Brown <mark at mercurylang.org> wrote:
> >
> > On Sat, Jul 29, 2023 at 6:27 PM Sean Charles (emacstheviking)
> > <objitsu at gmail.com> wrote:
> >>
> >> I've been trying to produce a simple list of strings to output as the response to a command line argument request to list the supported targets of my transpiler, given I have a type and a predicate to return the printable string for the language I thought solutions/2 was my answer, but not so far! Again, it's a mixture of the terminology to my untutored brain and the lack of any really clear guiding examples, in Prolog this stuff is trivial!
> >
> > In Prolog this stuff is usually *concise*, but I wouldn't call it
> > trivial. To verify correctness of bagof, for example, you need to
> > reason about binding patterns and determinism. In the case of
> > solutions/2, Mercury is doing a lot of the work for you, as well as
> > for people reading your code, but like a lot of things in Mercury the
> > benefits come at the cost of restricting yourself to mode-correct code
> > and declaring what you are doing.
> >
> > Whether verifiability is more important than brevity depends on your
> > project, of course. Personally I find thinking to be more of a
> > bottleneck than reading or typing, so it's usually a higher priority.
> > But maybe that is just me!
> >
> > Cheers,
> > Mark
> >
> >>
> >>
> >> % Does -T / --targets.
> >> %
> >> :- type supported_target
> >> ---> language_c
> >> ; language_python
> >> ; language_pythont
> >> ; language_js.
> >>
> >> :- pred show_targets(io::di, io::uo) is det.
> >>
> >> 300:show_targets(!IO) :-
> >> 301: io.format("Available target languages:", [], !IO),
> >> 302: solutions(
> >> 303: (pred(A::out) is nondet :-
> >> 304: target_name(_, A)
> >> 305: ),
> >> 306: Targets
> >> 307: ),
> >> 308: io.print_line(Targets, !IO).
> >>
> >>
> >>
> >> :- pred target_name(supported_target, string).
> >> :- mode target_name(in, out) is det.
> >>
> >> target_name(language_c, "Vanilla C").
> >> target_name(language_python, "Vanilla Python").
> >> target_name(language_pythont, "Typed Python").
> >> target_name(language_js, "Vanilla JavaScript").
> >>
> >> gives me the follwiong output:
> >>
> >> command_line.m:308: In clause for `show_targets(di, uo)':
> >> command_line.m:308: mode error in conjunction. The next 3 error messages
> >> command_line.m:308: indicate possible causes of this error.
> >> command_line.m:308:
> >> command_line.m:303: In clause for `show_targets(di, uo)':
> >> command_line.m:303: mode error in conjunction. The next 2 error messages
> >> command_line.m:303: indicate possible causes of this error.
> >> command_line.m:303:
> >> command_line.m:304: In clause for `show_targets(di, uo)':
> >> command_line.m:304: in argument 1 of call to predicate
> >> command_line.m:304: `command_line.target_name'/2:
> >> command_line.m:304: mode error: variable `V_5' has instantiatedness `free',
> >> command_line.m:304: expected instantiatedness was `ground'.
> >> command_line.m:303:
> >> command_line.m:303: In clause for `show_targets(di, uo)':
> >> command_line.m:303: in argument 1 of clause head:
> >> command_line.m:303: mode error in unification of `LambdaHeadVar__1' and `A'.
> >> command_line.m:303: Variable `LambdaHeadVar__1' has instantiatedness `free',
> >> command_line.m:303: variable `A' has instantiatedness `free'.
> >> command_line.m:308:
> >> command_line.m:302: In clause for `show_targets(di, uo)':
> >> command_line.m:302: in call to predicate `solutions.solutions'/2:
> >> command_line.m:302: mode error: arguments `V_12, Targets' have the following
> >> command_line.m:302: insts:
> >> command_line.m:302: free,
> >> command_line.m:302: free
> >> command_line.m:302: which does not match any of the modes for predicate
> >> command_line.m:302: `solutions.solutions'/2.
> >> command_line.m:302: The first argument `V_12' has inst `free', which does not
> >> command_line.m:302: match any of those modes.
> >> command_line.m:308:
> >> command_line.m:308: In clause for `show_targets(di, uo)':
> >> command_line.m:308: in argument 1 of call to predicate `io.print_line'/3:
> >> command_line.m:308: mode error: variable `Targets' has instantiatedness
> >> command_line.m:308: `free',
> >> command_line.m:308: expected instantiatedness was `ground'.
> >>
> >>
> >> I've read the mercury crash course site with it's 'rows()' but so far drawn a blank...just how simple is it to get a list of possible solutions so that I may print a list of strings representing supported languages?
> >>
> >> Thanks.
> >>
> >> _______________________________________________
> >> users mailing list
> >> users at lists.mercurylang.org
> >> https://lists.mercurylang.org/listinfo/users
>
More information about the users
mailing list