NewsForumsCodeLogsGallerySpecsSearch

possibility to use { and } brackets

Community Forums/Monkey2 Talk/possibility to use { and } brackets

GC-Martijn(Posted 2015) [#1]
Maybe its a one day work to make it possible to use brackets.
To say in the compile, if I see the { then use THEN and if I see } then use END


if (1>2) {
  print "bla";
}

Or like this:

if 1>2 {
 Print "bla"
}

if 1>2 {Print "bla"}

if 1>2 {
 Print "bla"
}else{Print "la"}

And for the old code the old syntax

If 1>2 Then
  Print "Bla"
End


The next things is maybe to make it possible to use && ||

if(test=1 && test2=2){
bla
}


EdzUp(Posted 2015) [#2]
Why not just use C++?


GC-Martijn(Posted 2015) [#3]
I don't understand your answer, because do you mean "don't use monkey" or is it possible to include the monkey libs in combination with C++ or other languages like C# ?

At the moment my primary languages are javascript, C#, nodejs

But maybe like I said its simple for mark to make that an option.
I understand why you don't want to do that, because you will get different code styles.
But for me its, like using C# a little


PixelPaladin(Posted 2015) [#4]
In my opinion curly braces would make monkey less readable.
But they could be used for map declaration (similar to python):
Local myMap := {"foo" : 1, "bar" : 2}



dmaz(Posted 2015) [#5]
for me, no curly brackets or required semi-colons is one of the best things about monkey and the other languages Mark wrote.

(I do like the for map declarations)


Beaker(Posted 2015) [#6]
I like the monkey syntax and everything, but I would happily use curly brackets (as an option only, and maybe even just the closing bracket!) mostly cos I hate typing unnecessary stuff. Also, I've often thought it would be great if Mark made a compiler that let you choose your own coding style, but it can be converted to Blitz/Monkey style in the IDE on request (for posting on forums etc).


Neuro(Posted 2015) [#7]
I'm indifferent but wouldn't mind the curly brackets or semi colon either. But then again this is MX2 so there should be some differentiation from other languages.


Danilo(Posted 2015) [#8]
Looking at the syntax requests, it should be C#, Java, Lua, BASIC, Python, and probably some others - all at the same time. An Uber-language. :)


Nobuyuki(Posted 2015) [#9]
-1. The only thing I'd be okay with using curly braces for are for "magic" blocks which wouldn't make sense to use traditional BASIC block markers for, like single-line statements. The big ones being mainly the places VB.NET uses curly braces for now -- initializers and tuples (KV pairs). The syntax is as follows (VB.NET 2010+):

'Simple container initialization
Dim MyList as New List(Of String) = {"A", "B", "C"}

'Initializing class members by name
Dim MyThing as new Thing With {.Name = "something", .Value = 42}

'Initializing generic collections by KV pair
Dim MyMap as New Dictionary (Of String, String) From {{"Name", "something"} , {"Value", Str(42)}}


'Thing class from 2nd example above
Class Thing
  Public Name as String, Value as Integer
End Class


I'd also be okay with curly braces being used to help make anonymous function syntax clearer. But any other use resembling that in c-like languages would allow for poor habits, making code less readable, even by Monkey's lax standard.

P.S. You've probably noticed that VB.NET's initializer syntax is kinda all over the place and has a lot of ways to do basically the same thing. This is because each way comes from a different period in VB's lifetime, with From being the latest syntax. We could definitely do better than this, and probably have a more consistent (while still flexible) initializer syntax. Curly braces may have a role to play yet!


Danilo(Posted 2015) [#10]
MonkeyX already uses brackets [ ] for array init, so why use curlies for lists and maps?

And about the languages mix-up mess:
In my opinion it would be better to write 2 or 3 compiler frontends, if that is what users really want.
Let's say a MonkeyX-follower with BASIC-like Syntax, and a C-family language like C# for example.
2 separate and different input-languages, that translate to the same internal AST, share the same backend,
and share the same library system.

Think of combinations like VB.NET / C#, Delphi / C++Builder, NSBasic..AppStudio (JavaScript + VisualBasic-like).


Nobuyuki(Posted 2015) [#11]
@Danilo: I wonder if there'd be an easy way to know at compile time what type to assign an anonymous collection written using curly-brace syntax -- if so, then there wouldn't be a need to have a separate initializer syntax for arrays using square brackets. It seems cleaner in my mind to separate out the array retrieval and slicing functionality from initialization by using a different pair of brackets for initialization. Imagine using square brackets for generic collection initialization -- I'm sure that would be a lot hairier to lex considering what all it's already used for.


Danilo(Posted 2015) [#12]
@Nobuyuki:
You are right.
var := {"A", "B", "C"}
or
var := ["A", "B", "C"]
could be a list or array. The compiler doesn't know what you want, so there must indeed be a way to differentiate it.


PixelPaladin(Posted 2015) [#13]
@ Danilo: MonkeyX already uses brackets [ ] for array init, so why use curlies for lists and maps?

Is it a list or an array?
Local foo := [1, 2, 3]

This is much clearer:
Local foo := [1, 2, 3]       ' -> integer array
Local bar := {1, 2, 3}       ' -> List<Int>
Local map := {1:"a", 2:"b"}  ' -> Map<Int, String>

Lists and maps are more dynamic data structures, so they should both use curly braces. Arrays are more static.
Edit:
Looks like I was a few seconds too slow ^^


Danilo(Posted 2015) [#14]
One-for-all would probably require to say what you want, like
Local foo := Array of [1, 2, 3]       ' -> integer array
Local bar := List of [1, 2, 3]        ' -> List<Int>
Local map := Map of [1:"a", 2:"b"]    ' -> Map<Int, String>

Local foo := Array of {1, 2, 3}       ' -> integer array
Local bar := List of {1, 2, 3}        ' -> List<Int>
Local map := Map of {1:"a", 2:"b"}    ' -> Map<Int, String>

But that's just like giving the exact type of the variable declaration, reversed.


Nobuyuki(Posted 2015) [#15]
@PixelPaladin: I like the syntax you proposed the best so far, although the second example could be any number of generic containers. Perhaps containers should have some sorta shared base or something? I wouldn't want to initialize something like that as a List<T> by default, but that's only because I hardly use them in my code. I'd have to specify Stack<T> explicitly. Maybe this can be avoided with an abstract container base, but it doesn't necessarily solve the late-bound type ambiguity... It just forces you to declare the container type :)

Dynamic-typed languages can handle this stuff a lot easier, which is pretty useful when using an anonymous variable for a generic container class in a place other than a simple var declaration. Someone more clever than I must know of some techniques to infer a proper type at compile time for most scenarios...

Local reversedStack:IntStack = Reverse( {1,2,3,4,5} )

'Somewhere else....
Function Reverse:ContainerBase<T>(Input:ContainerBase<T>)
  'Do reversing stuff
End Function



PixelPaladin(Posted 2015) [#16]
I think List<T> And Map<T1,T2> should be the default. But it could be possible to specify any other class, too.
Local foo := {1, 2, 3}           ' -> List<Int>
Local bar:IntStack = {1, 2, 3}   ' -> IntStack
or:
Local bar := IntStack {1, 2, 3}  ' or something similar

It could be possible to use any class as long as this class implements a Push() method (or Set() method for maps).
Local foo:Something = {x, y}
' translates to
Local foo := New Something ; foo.Push(x) ; foo.Push(y)

Local bar:SomethingElse = {a:b, c:d}
' translates to
Local bar := New SomethingElse ; bar.Set(a, b) ; bar.Set(c, d)



dmaz(Posted 2015) [#17]
+1 what PixelPaladin just said... that's very nice!


GW_(Posted 2015) [#18]
I just want to drop my 2 cents that curly braces are a bad idea. It's very un-blitzy and imo would ugly-up the syntax. The language need less <shift>tokens not more of them.


Shinkiro1(Posted 2015) [#19]
I am strongly against the OPTION of curley braces.

I prefer the language without them, but if they would be in the language, at least enforce them.


JoshKlint(Posted 2015) [#20]
No please don't.


PixelPaladin(Posted 2015) [#21]
Okay, this also works without curlies ...
Local a := [1, 2]
Local b:IntList = [1, 2]
Local c:IntMap<String> = [1:"foo", 2:"bar"]

' translates to:

Local a:Int[] = [1, 2] ' array is default
Local b := New IntList ; b.Append(1) ; b.Append(2)
Local c := New IntMap<String> ; c.Set(1, "foo") ; c.Set(2, "bar")

But I still think curly braces would look better for list and map declarations.

By the way - Curly Brace from Cave Story is really cool ^^


Samah(Posted 2015) [#22]
As much as I love declaring blocks with braces, I don't think it works with the "feel" of Monkey.
However, PixelPaladin: +1 to this:
Local foo := [1, 2, 3]       ' -> integer array
Local bar := {1, 2, 3}       ' -> List<Int>
Local map := {1:"a", 2:"b"}  ' -> Map<Int, String>



Rumphiz(Posted 2015) [#23]
+1 for curlys, I'd like verbosity linked to frequency of usage, so very rarely used keywords - knock yourself out with 20 characters, very frequently used - reduce them to symbols. Monkey/Blitz has always stuck a nice balance and I know it'll never happen but this one change I would welcome.


GC-Martijn(Posted 2015) [#24]
i thought that more people disliked the extra more characters typing.
for me the code is better to read, less is more (and faster to create)

maybe a ted preprocessor that converts it first.


PixelPaladin(Posted 2015) [#25]
What is more or less to type?

Function Foo:Void()\n
 \t Print("hello")\n
End\n
' 40 characters

Function Foo:Void(){\n
 \t Print("hello")\n
}\n
' 39 characters (+ more shift key usage -> harder to type)


Many people use curlies like this:

Function Foo:Void()\n
{\n
 \t Print("hello")\n
}\n
' 40 characters (+ shift)

Function Foo:Void() {\n
 \t Print("hello")\n
}\n
' 40 characters (+ shift)


Python style indentation would be less typing:
Function Foo:Void()\n
 \t Print("hello")\n
' 36 characters



GC-Martijn(Posted 2015) [#26]
if 1=1 then
bla
end

if 1=1{
bla
}

OR

if (1=1){
bla
}


python is oke, i did use that for some simple scripts


Nobuyuki(Posted 2015) [#27]
I stand by my previous statement that allowing braces anywhere other than single-line initializers and anonymous functions will lead to mutant c-like code which would be annoying to read for people who hate that style.


PixelPaladin(Posted 2015) [#28]
This is valid monkey code:
if 1=1
    Print "Foo"
end



GC-Martijn(Posted 2015) [#29]
yea but it would be nice for me personaly to use with {} because that is my personal style that i use for several years, in c# and javascript.


PixelPaladin(Posted 2015) [#30]
here a simple comparison:

monkey:
if 1=1
foo "bar"
end
-> 21 characters
-> 23 key hits (US keyboard layout)
-> 24 key hits (german keyboard)


c/c++:
if(1==1){
foo("bar");
}
-> 24 characters + hard to type
-> 32 key hits (US)
-> 35 key hits (DE)


python2:
if 1==1:
	foo "bar"
-> 20 characters
-> 23 key hits (US)
-> 25 key hits (DE)


python3:
if 1==1:
	foo("bar")
-> 21 characters
-> 26 key hits (US)
-> 28 key hits (DE)


This would be one less character but hard to type and hard to read (compared to normal monkey):
if 1=1{
foo "bar"
}
-> 20 characters + hard to type
-> 24 key hits (US)
-> 25 key hits (DE)


Monkey wins ^^
(Correct me if I'm wrong with the key counts.)

@GC-Martijn: don't get me wrong - I like {}'s in other languages. I just think they don't fit together with monkey.


Shinkiro1(Posted 2015) [#31]
Alright, after trying to write actual code in monkey using braces I now think they are actually terrible.
They are fine in C like languages but for monkey they just don't fit together with the other things.

try it if you don't believe me


dmaz(Posted 2015) [#32]
a point though from a line of one of Mark's posts, monkey2 will require perens for function calls so...
if 1=1
foo("bar")
end
-> 26 characters
-> 22 key hits (US)

I've come around to the python style for monkey2
if 1=1
	foo("bar")
-> 19 characters
-> 23 key hits (US)



PixelPaladin(Posted 2015) [#33]
monkey2 will require perens for function calls

Which is a good decision.

still acceptable:

python3:           | monkey2:
if 1==1:           | if 1=1
    foo("bar")     | foo("bar")
                   | end
===================|===================
21 characters      | 22 characters
26 key hits(US)    | 26 key hits(US)


I've come around to the python style for monkey2

Looks nice - but it may be better suited for the zebra language :)


Samah(Posted 2015) [#34]
@Nobuyuki: I stand by my previous statement that allowing braces anywhere other than single-line initializers and anonymous functions will lead to mutant c-like code which would be annoying to read for people who hate that style.

+1

@Shinkiro1: Alright, after trying to write actual code in monkey using braces I now think they are actually terrible.
They are fine in C like languages but for monkey they just don't fit together with the other things.

Yep. XD

@PixelPaladin: @GC-Martijn: don't get me wrong - I like {}'s in other languages. I just think they don't fit together with monkey.

Agreed.