In order to survive on this site, challenges must have an objective winning criterion. As our site name indicates, length of code is by far the most common such criterion. Please include an objective winning criterion in the post.

Popularity contests are frequently closed, read the tag info.

"As these are frequently closed, read the tag info and post your challenge to the sandbox first. " I am quite sure that I put it into the sandbox. Do you have any suggestions to improve this challenge?

"just for reference purposes" makes it sound as if readers are expected to already know this.

Thank you, I modified that phrase; do you have any more suggestions? (I think they should know this if they took a look in the H website; this documentation is provided "as-is".)

There are some typos: reference(; the, receved, refelected. The Def usage is not marked down as code. I suggest "backticking" all functions, operators, and symbols.

"The following is a list of all the escape sequences currently available in H." → "The following is a list of all the escape sequences you must implement."

The backslash example output should be in a code block (indent four spaces).

The section "In H, the # token is denote comments that are on their own line. It is not required behind a semicolon, but it is recommended." is unclear. Is anything to the right of a semicolon a comment? Can # always be used instead of ; when at the end of the line? Etc. Also, there can be no recommendations in the spec for an interpreter.

Can there be multiple ;-separated statements on a single line?

After printing the required message, what should the interpreter do when hitting an error?

How should the interpreter react to an odd number of "s in a statement?

What are the whitespace rules in H? Are leading spaces allowed? Will + and = and # always have exactly one space on each side? Will def always have exactly one space on its right? Will input's ; always have 0 spaces on the left and 1 on the right? Etc. etc.

Impressive. No wonder H was never implemented.

@Adám: I will update this to the reference documentation later.

Btw, the documentation falsely claims H is a programming language.

I believe so, as long as that thing at the right of the semicolon is not a command; this will definitely work if you are trying to put multiple commands onto one line. This is very similar to the syntax of C, so I think this should allow multiple commands on one line... Hmm, I think # will help when commenting code blocks, but code after a semicolon will not be commented.

My job is to provide the documentation "as-is"; it is not my job to modify the documentation... H is indeed a programming language, although it provides extremely limited implementations. I found this programming language at beza1e1.tuxen.de/one_letter_proglangs.html.

Let us continue this discussion in chat.

@UserA I think what Adám was referring to is that H isn't a "programming language" in the sense that it has no control flow or way to implement any sort of algorithm.

For example, XML is definitely a "language" but it's not a programming language. H is similar. It can just describe output, but it's definitely not turing complete (or having any control flow whatsoever)

At least as far as Codegolf.se is concerned, the definition of a "programming language" is on this meta post:

But that's being pedantic ;)

As far as your challenge is concerned, one question comes to mind. What's a valid token for the def command?

And also, is it case-sensitive? (for example, is DeF something = 7 valid?)

What should print("test"); print("test again"); do?

I think challenges for implementing languages are generally very hard to specify correctly, unless it's for an extremely restricted esolang (like brainfuck for example. Only 8 single-character tokens to parse)

Scratch that, any challenge about parsing is hard to specify correctly.

@DJMcMayhem The developers of H were planning to add control flow to H, although the extenstions are not yet documented.

I think this should be valid(a unary adder): input(a); input(b); def c = a + b; print(c);

Umm, I think it should be case-sensitive, as all of the commands are in lowercase, and no one tries to do DeF something = 7 before you.

I think "print" should not print a newline, as the Hello world program does not contain a newline. Therefore, your example should print testtest again.

These are all things the challenge needs to specify

I'm just trying to point out that implementing a language like this will have many many many edge-cases, and if you ask people in a challenge to implement it, they will care about every single one.

Yes, I will temporarily put it here, and I will put it into the challenge later...

Just for reference (this is already on the language page): However, we plan to add user input, variables, error-catching statements, goto statements, and conditional execution.

Or another thought. Does print have to take a variable or string? Or could it take an expression? For example input(a); input(b); print(a + b);

Yes, it can of course take an expression. Check this out: print("Hello, world" + "!" + "\n\nThis text is on its own line." + "\n\n\tThis text is indented."); # This is a comment, which is ignored by the interpreter.

This obviously uses expressions.

Oh fair

Or for concatenation, can you concat a string and a variable? What about an integer? input(a); print(a + "6"); print(a + 6); print("7" + 6);

(The group is still developing H, so they will probably add support for variables and numbers...)

No one had done that before. I have no idea.

I think the variable will be substituted as its value...

But is the variable an integer or a string?

No, it isn't. I am guessing the syntax according to other languages (as other languages substitute the variables as their values when they perform their operations). The documentation is very unclear.

BTW I think the CCA Computer Sciences Club can only implement very simple and trivial programs... for example, their BASIC interpreter can only support one useful command: printing to the console. That could possibly be the reason that H was not implemented...

(Uhh, their shell consists of system calls; there is no code by themselves.)

Aha, I have an idea on the issue on concentrating numbers: they should be at first converted to numbers. As for the example print("7" + 6); , the 6 will be converted to the string "6", and then it will be conventrated with 7, which results in "76"; then, 76 will be printed to the console.

For the issue on concentrating where both parameters are integers, the process is similar: take print(1 + 1) as an example. First, both 1's will be converted into their string form; then, they will be concentrated, which results in "11"; finally, that string will be printed into the console.

Oh, in my third comment, I mean string when I said the second "numbers". That should be : Aha, I have an idea on the issue on concentrating numbers: they should be at first converted to strings. As for the example print("7" + 6); , the 6 will be converted to the string "6", and then it will be conventrated with 7, which results in "76"; then, 76 will be printed to the console.

@UserA That's very counterintuitive. input(a); input(b); def c = a + b; print(c); is using + for adding, but input(a); input(b); print(a + b); would use concatenation?

Previously I was trying to make an adder in unary, where adding is simply the concentration of strings.

Take 2+3 in unary as an example. 2 can be represented as "00" in unary, and 3 can be represented as "000" in unary. What happens when they are concentrated together? The string will be "00000"! It contains 5 zeroes. Then, the 5 zeroes will be outputted, which is trivially the result.

I will repeat: I was trying to make an adder in unary.

Both of the will do the same thing as concentrating strings.

My program for unary adding can also be written as: input(a); input(b); print(a + b);, which was mentioned.

I will specify more of my guessed H's syntax: note that inputting for a variable sets that variable in the string form of input.

Oh my bad. I missed the unary part

If no one can suggest anything more to this challenge, I will try to put it as a real challenge (unless someone suggests something subsequently).

@UserA What are you doing posting to main‽ This challenge, if at all viable, is far from done. There are so many open questions. I just didn't have time to state them all yet.

You literally copied my list of issues into the post!

@UserA I was really trying to help you here, but seriously:

You clearly posted while in the middle of developing the challenge.

> Errors for multiple arguments is not even possible, as H does not provide multiple arguments for function calls. The input command provides syntactic sugar, as the prompt is essentially a print command.

What does print("abc","def"); do? How about prompt("abc",var,"def");?

@UserA Oh, now I get it. You copied the entire chat transcript into the sandbox post, so you'd remember to address all the raised issues. That's a good idea. But I'm curious, how did you end up mistakenly posting it to main? It isn't like there is a button to do so.

@Adám Sorry, I accidentally pasted what I copied from the chat into main while I was checking out the changes at main.

@UserA But what were you doing on Main at all?

The absolute mad man

Uh, H does not separate parameters like this using commas; it separates them using semicolons.

I guess H will ignore the parameters after the required parameters. (Due to my experience of Lua)

@UserA Sorry, I forgot, but the question stands, and must be clarified.

Yes; I have possibly clarified it; I will fix your programs: print("abc"; "def"); and input("abc"; var; "def");

@UserA It is a bit confusing. You seem to be mixing up language design with challenge design. For the purposes of the challenge (the only on-topic thing on codegolf.SE), it doesn't matter at all what H will or won't do.

@UserA Don't forget print() and input() and def(var; 42).

I will see how it works on Lua...

@UserA The comma symbol , is used in integer literals, right?

(print() in Lua prints nothing.) Of course commas cannot be used in integer literals.

I will try to fix the integer literal representations.

io.input() also does nothing (surprisingly).

Uh, I will clarify here that def is not a function; it is a keyword. def cannot have parameters.

@UserA How was that of course when the only examples of integers had that?

@UserA That is a very important realisation. In fact, if you ponder upon that, you may conclude that the challenge isn't really viable.

I was trying to fill up everything not in the documentation using assumptions.

@Adám:Do you have more suggestions?

@UserA Lots.

@UserA What does "\r" give?

@UserA It looks like the commas in integers are back.

"\r" could return r. (I think you are making this problem overly specific to make this problem a bad example of a popularity contest.)

@UserA Then you have to specify that.

@UserA No, I'm trying to help you flesh it all out or realise it isn't worth the effort, whichever comes first.

It is worth the effort, in order to find out "why is it impossible to implement such a simple language".

@UserA It isn't impossible, just a lot of work.

I think you only have one suggestion when you said you have "Lots" of suggestions...

@UserA You didn't address whitespace.

Although that is very trivial, I still added this into the problem.

Hmm, do you find any more problems?

@UserA Sorry, I was busy implementing H. How is this?

Sorry for disturbing you. I am taking a look of this interpreter.

I don't think you have required the semicolon at the back of each statement. Other than that, it is great.

I was expecting an implementation to allow typing the program in directly without anything else being typed...

@UserA You have an example that omits the trailing ; and explicitly state it is OK to omit when discussing comments.

@UserA I just defined a function that takes a list of H statements as arguments, assuming the H program would be fetched from a file or some such. I can easily rework my function to any desired format.

Hmm, that example was a demonstration of a syntax error.

@UserA Oh, my bad. Anyway, my interpreter was just a quick mock-up. I've also since fixed a but relating to printing negative numbers.

(As a joke, I have sent your APL implementation to the CCA Computer Sciences Club via e-mail.)

What? I don't think this will work in that implementation: input(name);print(name);

It indeed does not work: check out this.

@UserA No, I also realised I forgot to implement that. The code you sent also has that negative number bug. On sec.

You are preparing for writing the interpreter. That means the development is complete, right?

@UserA Development of the challenge?

Yes, which could signify that I can put the challenge into main.

@UserA What's the rush? And no, I'm using my interpreter development to find potential issues. You didn't implement an H interpreter, did you?

@UserA I need to get to bed, but this version handles the negative number printing and the no-print prompting. I didn't bother checking for trailing semicolons, as it frankly doesn't add anything. There's plenty of undefined behaviour of course. Do you realise how it actually works?