Talk:SyL

Silliness

What does kaksikymmentäneljätuntiaikakausitämänhetkinen do? :) —ehird 05:45, 15 April 2011 (UTC)

Raise an error: Non-CV syllable. —Maharba 21:44, 15 April 2011 (UTC)

Comments

The comment breaks pronounceability, it could be better with

   ko comment sho

   sho bonudo sha a Lojban foreign quote-style comment bonudo sho

and spaces should be insignificant.

(must allocate more consonants...)

--(this comment by SHiNKiROU at 03:44, 17 May 2011 UTC; please sign your comments with ~~~~)

I'd rather not have digraphs. What about reusing ko to end a comment? —Maharba 01:51, 1 June 2011 (UTC)

Numbers

Is hile 0.1 or an error? Also, it would be nice if an implementation was allowed to use any way to implement numbers, including decimals or rationals, not just floating-point. Similarly, it would be nice if it was not the presence of hi that determined whether a number was treated integrally or otherwise, but whether the number has a non-zero fractional part. i.e., lehilala would be the same as le.

While we're at it, why not just let the implementation implement numbers however they want (so long as they can handle non-integral values), and have division be specified as full division, with a separate option being integral division? Heck, you could even just have a separate "floor" function, and the need for integral division would disappear. —ehird 21:12, 6 June 2011 (UTC)

By the way, I am right in thinking that, apart from comments, whitespace is completely ignored, correct? —ehird 21:48, 6 June 2011 (UTC)

Argh, this is false; consider gahalelelu; this is ambiguous (could be gaha lele lu, gaha le lelu). Ugly... —ehird 00:52, 7 June 2011 (UTC)

A proposal, then: Make hu mandatory at the end of all numbers; negation is as simple as gehalahu number, i.e. 0-number. This would, I think, make whitespace irrelevant (again, excepting comments). —ehird 00:57, 7 June 2011 (UTC)

(Oh, and what of lehi? 1.0, or invalid?) —ehird 23:44, 6 June 2011 (UTC)

Updated spec to not mention floating-point, added a required final syllable to all numbers, and clarified that hile and lehi are invalid. Added truncation, floor, and ceiling operators, along with exponentiation, roots, and logarithms for good measure. —Maharba 22:46, 7 June 2011 (UTC)

Great, thanks! :) —ehird 22:58, 7 June 2011 (UTC)

Scoping

The specification implies to me that all variables are global; is this the case? (Even arguments?) —ehird 22:59, 6 June 2011 (UTC)

Nope. Clarified. (Variables declared in other blocks are still global, of course.) —Maharba 22:46, 7 June 2011 (UTC)

So if I use the same name for an argument variable as a global variable, the global is not mutated when I call this function? (And therefore it is actually hidden from the function -- it cannot use it at all, except by calling another function that does not shadow it that returns it.) —ehird 22:58, 7 June 2011 (UTC)

Guess so, unless I add a keyword for global (probably not worth it). —Maharba 01:09, 8 June 2011 (UTC)

Functions

"If the function returns, this is an expression, otherwise it is a statement."

Eurgh -- this means that SyL is not context-free! It makes the grammar and language a lot uglier IMO. Some suggested alternatives:

• A "call function and discard result" statement
• All functions return a value, assumed to be 0 if there is no return clause; calling a function is always an expression, and expressions are valid statements (they are simply evaluated and the results discarded).

—ehird 00:10, 7 June 2011 (UTC)

Added a special value returned as default. —Maharba 22:46, 7 June 2011 (UTC)

Is there any way to distinguish wu from any other value? As far as I can tell, there isn't, which makes it a bit of an oddity -- it has no valid operations, not even to distinguish its type. On the one hand, this probably isn't a problem; on the other, I'm not sure I see the advantage over returning 0. —ehird 22:58, 7 June 2011 (UTC)

Added comparisons that work on wu (and on lists). —Maharba 01:09, 8 June 2011 (UTC)

Broken cat example?

It looks to be missing the block start/end syllables to me. —ehird 00:14, 7 June 2011 (UTC)

Fixed. —Maharba 22:46, 7 June 2011 (UTC)

Great, thanks. —ehird 22:58, 7 June 2011 (UTC)

EOF

EOF has the ASCII-defined value of luha (4).

Actually, ASCII character 4 is EOT (end of transmission), not EOF. It is true that sending EOT with ^D is used to terminate input on Unix terminals, however.

Is there any reason -1 or some other out-of-range value isn't used instead? (Preferably negative, since an implementation might conceivably want to Unicode IO.) That would allow processing of binary files (in implementations that just use raw 8-bit IO), too.

Thanks for your replies to all these comments, by the way! I'm working on a (rather comprehensive) implementation of SyL, and this is really helping. —ehird 22:58, 7 June 2011 (UTC)

It is now -1. I chose 4 because it was the closest ASCII had to a EOF character, but -1 is better. —Maharba 23:17, 7 June 2011 (UTC)

Great! Any thoughts on my comments on scoping and the default function result? —ehird 00:24, 8 June 2011 (UTC)

Does this ehird guy ever stop??

As far as I know, there are only two remaining parts of the language that make whitespace significant in any way:

The keyword we begins a block, which is a newline-separated set of statements.

(which, I think, could simply be omitted, since statements now have unambiguous endings)

and the comment syntax. I think ko would work well to end a comment like you said, although this does mean that you wouldn't be able to use any word with "ko" in it in a comment:

ko here's where we handle knockouts ko

doesn't do what you'd expect. This kind of irks me, but I don't see any alternative other than picking a longer, less likely ending delimiter.

(Silly idea: What if comments had to obey the CV rule?) —ehird 02:50, 8 June 2011 (UTC)

You'll note that I changed the comment keyword to wi, so just replace all the kos there with wi. One more place where whitespace may be significant: the argument list when defining a function. Because of the problem you mentioned, I hesitate to use a keyword to end a comment. How's the implementation going? (Wow...zero flow between sentences.) —Maharba 03:48, 8 June 2011 (UTC)

The argument list could quite easily be solved by a keyword that acts as a comma of sorts, of course.

If the comment delimiter was, say, wiko or similar, then there'd be pretty much no risk of any text triggering it. To be honest, the question is whether comments are part of the syntax or just lexical niceties. That is, consider the following text:

ke pabi luroh wi test
a

Does this break the CV rule, or parse correctly? If comments are considered to be completely stripped before any parsing is done, and we assume that all whitespace is completely irrelevant beyond that, it parses. Otherwise, it doesn't.

I realise this is essentially pulling hairs, but IMHO one of the main elements to the appeal of SyL is its "pronounceability" -- the idea that you could have a function definition in a single word, say. (It reminds me of polysynthetic languages somewhat.) And whitespace-dependence breaks that.

Re the implementation: I had suspended work on it until that clarifications about scoping, since it affects the structure in quite a major way, but I should have something working within a day or two. The plan is a compiler with multiple backends done in a wonderfully overkill style, including a full FFI. —ehird 04:35, 8 June 2011 (UTC)

In fact, I propose that "ya" is used to separate argument names, as it is in function calls. —ehird 10:10, 8 June 2011 (UTC)

Changed the "null return value" to yi and using wu as a general comma (builtin calls, function defs, function calls). Made comment keyword two syllables with different start/end keywords. Any more thoughts? —Maharba 14:13, 8 June 2011 (UTC)

I think you can actually remove the mandatory terminal symbol from numbers now, since things are always separated fully. —ehird 14:24, 8 June 2011 (UTC)

I'll keep it, just in case. This is an esolang, after all. It doesn't have to make sense. —Maharba 19:43, 8 June 2011 (UTC)

About parsing syllable split around a comment: I think that whitespace will not be allowed within a syllable. That guarantees that syllables won't be "broken". —Maharba 14:13, 8 June 2011 (UTC)

Agreed, it's a bit of an edge-case. Personally, I'm just going to skip all whitespace entirely. By the way, the implementation is going quite well; I put the parser on hold until the syntax stabilises a bit, but I've got a complete abstract representation, the beginnings of a pretty good simple optimiser, and am working on some form of abstract virtual machine for the backends to take. —ehird 14:24, 8 June 2011 (UTC)

Great! What language are you writing the parser/interpreter/compiler in, anyway? —Maharba 19:43, 8 June 2011 (UTC)

Haskell -- "parser/interpreter/compiler" is right; I've started to lose track of how this thing actually implements the language already. :) But I've defined an abstract virtual machine for a subset of SyL programs (integers only and no functions) and am going to write an x86 assembly backend as soon as I have an AST → VM compiler function. —ehird 20:06, 8 June 2011 (UTC)

Typing

Just like comparisons on different types have undefined behaviour (or is it meant to be "unspecified result"? Can comparing two values of different types cause your toaster to explode, or is it simply allowed to yield whichever of true and false the implementation desires?), am I correct in thinking that e.g. performing arithmetic with non-arithmetic types is also undefined behaviour? (For instance, would it be acceptable for a SyL (non-)program with an error of this type to continue executing with incorrect results?) —ehird 14:29, 8 June 2011 (UTC)

I'd leave it up the implementation, so the programmer should be aware that their code won't work right if they do compare different types (except with Equals, of course). For arithmetic on unsupported types, same deal. By the way, what do you think about using Plus and Times for list/string concatenation and repetition, respectively? —Maharba 19:43, 8 June 2011 (UTC)

Sure, that would be acceptable. I note that if there was a keyword denoting "empty list", you could create a list by simply assigning a variable in the usual way. On the other hand, this is an esolang; since it's not a tarpit, it almost feels traditional to have one completely nonsensical, unorthogonal design decision. And that's a compliment. :) —ehird 20:06, 8 June 2011 (UTC)

Added list arithmetic. Since I already had a built-in for concatenation, I changed it to random access. —Maharba 20:33, 8 June 2011 (UTC)