Escape characters
Community Forums/Monkey2 Talk/Escape characters
| ||
| Can I put it out there that monkey2 should use the \ escape character instead of ~. |
| ||
| Skn3 it gets my vote :D |
| ||
| +1 Although this may break compatibility with Monkey 1 source. You would need to make some kind of fancy converter, but even then I wouldn't trust it. |
| ||
| +1 |
| ||
| I'm OK with this if no one has any objections. Note: Monkey2 will still work with a lot of Monkey1 code, hopefully most. A Version directive will allow you to tell the compiler what version of monkey the source code is, eg: 'top of file... Version 1.0 'non-strict monkey1 ... Print "~qThis is in quotes~q" This is strictly for migration purposes only though...'Version' will go away one day. It probably wont provide 100% compatibility either, but it should help. |
| ||
| Can I put it out there that monkey2 should use the \ escape character instead of ~. Could it be "in addition to" rather than "instead of" for Monkey2? I prefer tilde myself. Maybe some kind of declarative/define to parser? |
| ||
| The version seems like an alright approach, I mean most of the mainstream languages have a legacy dialect lurking in the background too. |
| ||
| I would rather keep Monkey2 clean and have a Monkey -> Monkey2 translator as a separate tool. |
| ||
| I like ~ but I don't know why... either/both would be fine though! |
| ||
| How about // for single line comments and /* */ for multi? Would be awesome not having to type #rem! |
| ||
| I think that, using /* */ for comments, or changing scape characters are quite minor things which I honestly doubt will have any benefit other than requiring more work to do to convert Monkey or BlitzMax code to the new compiler. Also, how would you handle which compiler to use when the directive of version is inside a version specific comment? I think, it would be a good idea to keep both languages compatible at token level (not at semantic level). This, or use different file extensions and assume they're de facto different languages, instead of variations of the same language. If this is changed and languages are not parser compatible at token level, then we may considere them different languages. By the way, using different file extensions is IMHO much better than using a version directive in the header, as at the end, it will be "noise" added to all files, always. By the way: Could it be "in addition to" rather than "instead of" for Monkey2? Please don't. Choose one way or another, but not both. Let's be consistent... |
| ||
| @Mark Sibly: Can we safely assume that using \ will allow the use of hex/octagonal code escape sequences? How about // for single line comments and /* */ for multi? Would be awesome not having to type #rem! Next Skn3 will be asking for curly braces for blocks of code and the omission of the Function/Method and End keywords ;-) |
| ||
| Re: {} braces... Well in an ideal world aye ;)? The idea of different extension is also a good one. I guess it depends really if there are going to be similarities in mojo2 as well? Considering a large chunk of old user code will revolve around mojo, is it worth keeping mojo1 hanging around as well? If mojo2 is going to be more powerful, it might be a bad idea to do legacy support at all. |
| ||
| @dawlane: Next Skn3 will be asking for curly braces for blocks of code and the omission of the Function/Method and End keywords ;-) +1... *cough* :) To be honest I'm caring less and less about backward compatibility. If you want your old Monkey code to run, just use Monkey 1. If you have boilerplate code you want to port to Monkey 2, someone will write a converter. In fact, Monkey 2 could be a new target for Monkey 1. :) |
| ||
| If mojo2 is going to be more powerful, it might be a bad idea to do legacy support at all. I don't follow this logic... ? |
| ||
| @Skn3 - Can I put it out there that monkey2 should use the \ escape character instead of ~. +1 How about // for single line comments and /* */ for multi? Would be awesome not having to type #rem! +1 @ziggy - By the way, using different file extensions is IMHO much better than using a version directive in the header, as at the end, it will be "noise" added to all files, always. +1 Please don't. Choose one way or another, but not both. Let's be consistent... +1 Why choose the suggestions that Skn3 suggested? It helps developers coming from "C" derived languages to have some immediate connection to Monkey 2 when trying it for the first time. This would go a long way to extend a goodwill handshake to developers outside the Blitz community imo. Of course, that is assuming there is a goal of attracting developers outside the current community. Additionally, the C standard comments and escape chars would make things easier when going back and forth between Monkey 2 and any of the "C" derived languages. |
| ||
| About {} : please no. Typing with non-US keyboard sometimes (and in this case!) is very complicated (I need to press SHIFT+ALTGR+รจ) ... not very comfortable. And reading source code is simply a mess (imho) I like a clear and non-interpretable syntax: End Function / End Method etc are clear and precise, while a bunch of }}} are difficult to understand. MonkeyX with 'End' statement did a bad thing compared with Bmax: everytime I need to understand if I'm in a method/a class or a function. the better solution? an IDE that converts all this 'syntax features' in one-standard. So everyone will be happy in writing the code, when the source is reloaded it's 'converted' in the proper - long - syntax ( } will be converted in End Method/End Function/End Class etc) Personally I hacked MaxIDE to type for me the proper 'End Method/End Function/End Type'... my laziness is unlimited. |
| ||
| the punishment for requesting curly braces in Monkey is spending the next 10 years being locked to QWERTZ/AZERTY layout!! Let's see you greek those brackets now 8D plz no // /* */ comments plz no \ escape sequences unless there's a reason to change it (it would've been nice to have been \ in the first place but the only reason to change it now is to make it 'more compatible' with C) plz no curly brace BASIC ppl had to do things the "C" people's way for years, why capitulate over useless syntax changes just for their sake? nooooo, plz no. Maybe reserve curly brace for inline externs to a target language or something!! It's not like we're using them for anything else right now.... |
| ||
| please, this is monkey... from blitz... no // /* */ no {} no ; line endings if you want those things, there are plenty of other languages that have them |
   |