User talk:BMO

From Esolang
Jump to navigation Jump to search

Alchemist

I've made a basic Python implementation at https://github.com/pjt33/Alchemist.Py . Feel free to steal the example for the official repo. My interpreter doesn't currently support the command-line options, and I've realised that there's a bug in the lack of prioritisation of Out_atom over +atom. However, I did notice a bug in the grammar you've listed at Alchemist. 

Program = Rules? ('!' Inputs)?
...
Inputs = SimpleAtom ':' Number

doesn't allow for more than one input, but I think the Haskell implementation does (and the name Inputs suggests that it was intended to). Should be an easy fix.

I would like to go one step further and suggest a change in the grammar. Why not change Inputs to 

Inputs = LHS

for more consistency?

One other thing: the Haskell parser defines comments and discards them, but they're not mentioned at all in the spec. There's an easy hack of writing comments as 

Comment -> Out_"Comment text goes here"

but it's not as readable as real comments, and slows down the rule applicability resolution. Cheddarmonk (talk) 23:36, 19 January 2019 (UTC)

Re: Alchemist

First of all, thanks for showing interest in this language! Since this language is still quite new and not a lot of people are using it either, I am open to suggestions or new features to be introduced. That said, there are a few things I will not change since the core-idea of the language should be preserved. But in general things like I/O should not limit the usage of the language, so anyone should feel free to suggest changes.

Command-line flags & comments

I didn't want to add this to the language specs, since they might change from time to time and are not really part of the language. So, imo we don't need to add it to the specification and neither does the Python implementation (or any other, if there are more to come) need to implement them. It might be that you're going to add other helpful flags which too should not influence the specs of the language.

Edit: Let's take the seeding flag -s SEED for example, to implement compatibility between multiple implementations will be a complete night-mare and not worth it.

I would say, the same thing should hold for comments. It's a feature the original implementation supports, but it should stay like that, giving anyone the freedom to: Support it or not, change formatting of comments. I kind of like the idea of using Comment -> Out_"text"! The problem with slowing down rule-resolution could be solved by

  1. Make Comment a reserved key-word: Basically leaving behaviour undefined (such that it can be prohibited to use or simply just removing any rules of that format)
  2. Make an optimizer part of the language spec which removes any rules with atoms that can only come from user inputs. (kind of hacky)

What are your thoughts?

Prioritisation of Out_atom and + atom

Currently it's not specified, but my implementation applies the side-effects left-to-right: 

_ -> b + Out_b + 2b + Out_b

Prints 13 and your implementation seems to do something else (prints 2), I'm puzzled by that output :) I don't have a strong opinion on the expected behaviour of this, can also be left undefined, do you have a sound suggestion?

Grammar for Inputs

Yes, bad mistake on my side: It should indeed support multiple inputs. However I do like the change to Inputs = LHS, I will change that. Thank you for noticing!

--BMO (talk) 14:09, 20 January 2019 (UTC)

I agree that seeding is one thing where compatibility between implementations would be a major headache. The other one is strings: to be honest, I believe that the Python implementation's string syntax isn't 100% compatible with the spec, because Haskell strings seem to support some funky escape sequences. I see that as a technical bug which is unlikely to be exercised in real-world use.
Good point about avoiding slowing down the rule resolution by discarding unreachable rules. There's no need to change the spec to say anything about that. The correct time to do it would be after processing the initial state, from whatever sources: any rule which has an atom in its LHS that is neither present in the initial state nor the RHS of any other rule can be deleted.
My implementation assumes that the atoms on the RHS of a rule are distinct. It probably shouldn't; I'll note that as a bug. It also doesn't support more than one Out_"string" or more than one Out_atom in a single RHS, and doesn't guarantee the order of execution if the RHS contains both types of output. Applying side-effects left to right makes sense; I'll have to rework from an unordered map to a list, but that's not a major difficulty. I'm slightly surprised that your implementation outputs 13 without whitespace separating them, but again I can easily change mine for compatibility. Cheddarmonk (talk) 14:33, 20 January 2019 (UTC)
Oh indeed, strings are another major head-ache and there's no need to generate additional work there (again it's just I/O and not crucial), I'll reword that to reflect potentially different behaviours.
Good thinking about pushing optimization further down the pipe-line, avoiding potential conflicts with user-inputs.
Initially I merged all the atoms on the RHS too, but noticed that the output rules are re-ordered and things got weird there. Atm, I only do so, if there are neither I/O present.
About the 13: I didn't think this through, but I think we can leave it at that: In case someone doesn't want this behaviour it's not a big deal to work around it, however the other way around won't be as simple.
Speaking of I/O rules, the whole thing I implemented yesterday doesn't make sense to me anymore:
_ -> 3b + out
out + b -> Out_b

Will currently output 3, however thinking about it in terms of rules getting applied, it kind of makes more sense to either

  1. randomize behaviour (consumption of b) there or
  2. first consume the atoms and then apply the RHS (in this case consistently outputting 2).

I'm biased towards the second option, but I don't have a strong opinion on that. I'd appreciate your inputs on this. --BMO (talk) 16:07, 20 January 2019 (UTC)

I had understood the second option to be what you said you'd done. It extends the in-order processing to the entire reaction, so it makes sense to me. Cheddarmonk (talk) 17:35, 20 January 2019 (UTC)
Alright, got around to implement these things: Inputs are parsed by the LHS-rule, atoms are consumed before RHS is processed & unnecessary rules are removed. I also introduced a bug in the parser which is annoying. In any case I'll update the wiki-entry. --BMO (talk) 23:27, 20 January 2019 (UTC)
About the Josephus problem, should the expected output not be 28 for 40 3? Is there some other indexing going on? (For example 7 1 prints 6) --BMO (talk) 23:58, 20 January 2019 (UTC)
Zero-indexed. The program is actually a port from the big test case at https://codegolf.stackexchange.com/q/1864/194 Cheddarmonk (talk) 21:59, 21 January 2019 (UTC)
I see, added it to the wiki-page (btw. feel free to edit that article). I also re-visited the parser for the original implementation, tested it thoroughly and everything is behaving well. TIO should update soon (usually Dennis is fast). --(this comment by BMO at 15:46, 23 January 2019‎ UTC; please sign your comments with ~~~~)
Retrieved from "https://esolangs.org/w/index.php?title=User_talk:BMO&oldid=59410"