[m-users.] Correct use of solutions.
Sean Charles (emacstheviking)
objitsu at gmail.com
Mon Jul 31 15:59:51 AEST 2023
> On 31 Jul 2023, at 02:58, Mark Brown <mark at mercurylang.org> wrote:
>
> 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
Time spent in SWI-Prolog debugger is always enlightening about Prolog and the port system. But, yes!! This is one of the reasons I like Mercury is that if it won't compile, you can't run and be left wondering why your devilishly deep and twisted predicates have decided to fail on you and not say why or where!
>
>>
>> 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.
Agreed. The SWI-Prolog version I completed a few years back gave me a few ideas I've transported across to the mercury system, especially regarding the 'type map system' I am implementing to reduce coding effort and also some ideas on passing chains of 'environments' around so that things like lexical scoping rules etc can be applied. And I pretty much figure out how my symbol table and function definition table is going to work too. More people should get into Prolog, once the penny drops about things like backtracking, and declarative style thinking, it becomes a "Wow!, it does that for me?" moment.
>
> 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.
>
Good feedback etc is always welcome!!
> 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