digitalmars.D - Syntax question...
- RA (27/27) Oct 30 2006 charset="iso-8859-1"
-
Jarrett Billingsley
(118/118)
Oct 30 2006
"RA"
wrote in message - %u (11/11) Oct 30 2006 Thanx for the reply Jarret, I was beginning to feel a little ignored the...
- Jarrett Billingsley (26/46) Oct 30 2006 If this message that I'm replying to is rich text, then it looks through...
- Jarrett Billingsley (4/6) Oct 30 2006 I meant to say that it looks *fine*. If a message were looking at me
- RA (13/13) Oct 31 2006 Addendum to my previous post\ranting...
- RA (58/64) Oct 31 2006 == Quote from Jarrett Billingsley
- Jarrett Billingsley (40/132) Nov 01 2006 An admirable goal.
- Hasan Aljudy (4/36) Oct 30 2006 If you just want to create D with different syntax, I think you can
- BLS (13/13) Oct 31 2006 To pick up Hasan's idea :
charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was curious about how hard it would be to create a different = =93language front end=94 for D? =20 Since you (Walter) have made the compiler front end (lexer, parser, etc) source code available, would it be possible for someone to modify it and create a different = (for example, something=20 more like VB) language syntax that would still work with the back end compiler? =20 I realize most of you long time C\C++ programmers probably couldn=92t = see any need for=20 such a thing, but others of us (at least me) would prefer something not quite as cryptic=20 as C like syntax. =20 I=92ve never written a compiler\lexer\parser\etc. so I don=92t know what = all would be involved=20 in creating a different syntax. In theory, it doesn=92t seem like it = should be =93all=94 that hard=85 But then, naivet=E9 is great isn=92t it. :-)
Oct 30 2006
"RA" <ra wolven.net> wrote in message news:mailman.2.1162241354.24029.digitalmars-d puremagic.com... --------------------------- I was curious about how hard it would be to create a different "language front end" for D? Since you (Walter) have made the compiler front end (lexer, parser, etc) source code available, would it be possible for someone to modify it and create a different (for example, something more like VB) language syntax that would still work with the back end compiler? I realize most of you long time C\C++ programmers probably couldn't see any need for such a thing, but others of us (at least me) would prefer something not quite as cryptic as C like syntax. I've never written a compiler\lexer\parser\etc. so I don't know what all would be involved in creating a different syntax. In theory, it doesn't seem like it should be "all" that hard. But then, naiveté is great isn't it. J --------------------------- (as a side note, it's kind of .. etiquette here to use plain text messages. some newsreaders don't take kindly to the HTML messages.) It shouldn't be too incredibly difficult. Probably the main problem would be coming up with some new syntaxes for things which commonly don't exist in Basic languages, or for which there's no clear standard. For example, in a lot of Basic languages I've used, arrays are indexed with parentheses, but that would mean that you wouldn't be able to have opCall and opIndex/IndexAssign in the same class, so we'd have to use the C-style square brackets for that. Another big problem is that some things that look cryptic in C-style syntax would look just as cryptic in Basic-style syntax, but with words instead of symbols. So you wouldn't really be gaining that much. Although, when it really comes down to it, Basic and C syntaxes aren't too different. You've got basically all the same control structures, just with "control .. endcontrol" rather than "control { .. }". Lastly there's the issue of case sensitivity. I know a lot of Basic languages are not case sensitive, and so foo, Foo, and FOO are all the same thing. But they're all different in D. The same goes for the control structures -- if we _did_ make this DBasic dialect case sensitive, would we make the keywords and control structures all lowercase, camelcase, or all caps (AAAAAAGH!)? So.. let's see what we've got. Assuming that we decide that the DBasic dialect would be case-sensitive, with camelcase keywords.. Import std.stdio Function main(args As Char[][]) As Void writefln("Hello World, Reloaded") 'auto type inference and built-in foreach For Each(argc, argv; args) 'Object Oriented Programming Dim cl As CmdLin = New CmdLin(argc, argv) 'Improved typesafe printf writefln(cl.argnum, cl.suffix, " arg: %s", cl.argv) 'Automatic or explicit memory management Delete cl Next Each 'Nested structs and classes Struct specs 'all members automatically initialized Field count As Int Field allocated As Int End Struct 'Nested functions can refer to outer 'variables like args Function argspecs() As Specs Local s as Specs* = New specs 'no need for '->' s.count = args.length 'get length of array with .length s.allocated = TypeOf(args).sizeof 'built-in native type properties For Each(argv; args) s.allocated += argv.length * TypeOf(argv[0]).sizeof Next Each Return *s End Function 'built-in string and common string operations writefln("argc = %d, " ~ "allocated = %d", argspecs().count, argspecs().allocated); End Function Class CmdLin Private Field _argc As Int Private Field _argv As Char[] Public: 'constructor Me(argc As Int, argv As Char[]) _argc = argc _argv = argv End Me Function argnum() As Int return _argc + 1 End Function Function argv() As Char[] return _argv End Function Function suffix() As Char[] Local suffix As Char[] = "th" Select(_argc) Case 0: suffix = "st" Break Case 1: suffix = "nd" Break Case 2: suffix = "rd" Break Default: Break End Select Return suffix End Function End Class Though when you're dealing with something like Foo!(delegate int(int[char[]] arr) { return arr["hi"]; }); That would end up as.. 'For lack of a better template instantiation syntax.. Foo!(Delegate(arr As Int[Char[]]) As Int Return arr["hi"] End Delegate) That's a little cryptic too..
Oct 30 2006
Thanx for the reply Jarret, I was beginning to feel a little ignored there... And sorry bout the html stuff. I didn't realize there would be a problem until I saw my post on here, then I changed my email settings. I set them to rich text. Can this news group handle that or should I just set it to plain text? You gave some great samples there of VB style code, but I was just using VB as an example... it's not really what I'm wanting to do. Basically, I want a "new" syntax. Although it would borrow heavily from other languages that make sense to me. So what exactly does not "too incredibly difficult" mean? Which would be easier, modifying the existing front end source code, or doing as Hasan suggested and writing a front end for the D front end... I don't really like that concept, but maybe it would be easier?
Oct 30 2006
"%u" <ra wolven.net> wrote in message news:ei68it$2e9a$1 digitaldaemon.com...Thanx for the reply Jarret, I was beginning to feel a little ignored there... And sorry bout the html stuff. I didn't realize there would be a problem until I saw my post on here, then I changed my email settings. I set them to rich text. Can this news group handle that or should I just set it to plain text?If this message that I'm replying to is rich text, then it looks through my reader and on the web interface. Have a look at your original post through the web interface (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digital ars.D&artnum=43421) and you'll see why HTML posting is generally discouraged :SYou gave some great samples there of VB style code, but I was just using VB as an example... it's not really what I'm wanting to do. Basically, I want a "new" syntax. Although it would borrow heavily from other languages that make sense to me.What kind of syntax are you thinking? (I'm genuinely interested :) )So what exactly does not "too incredibly difficult" mean? Which would be easier, modifying the existing front end source code, or doing as Hasan suggested and writing a front end for the D front end... I don't really like that concept, but maybe it would be easier?Well the front end source is... kind of messy, to say the least. Thankfully about all you'd have to mess with are the lexer and parser bits (lex.c and parse.c, imagine that), which aren't _too_ bad. Once you've got yourself a nice Basic-style lexer/parser set up, you could compile GDC with it and test it out. Of course, that might be a bit daunting, so.. What Hasan suggested is certainly not a bad idea either, and would also mean you wouldn't have to recompile the D compiler in order to get it to work. However, it would involve writing a backend for your frontend which would produce the appropriate D code, which could be a bit tricky, but not so bad if you're not worried about it producing the nicest-looking D code. Although the nice thing about this approach is that your DBasic frontend could be written in whatever you want, instead of being limited to C++ as with the other approach. In any case, it would be nice to have some kind of D grammar to start from, so you'd know what all the various language constructs your new syntax would have to support, rather than picking out all the grammar bits from the D spec. There _is_ one somewhere, but (1) I don't know if it's kept entirely up to date and (2) don't know what it's called or where it is. :|
Oct 30 2006
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message news:ei6a3b$2ffm$1 digitaldaemon.com...If this message that I'm replying to is rich text, then it looks through my reader and on the web interface.I meant to say that it looks *fine*. If a message were looking at me through my newsreader.. :S
Oct 30 2006
Addendum to my previous post\ranting... I can understand that back when computers were quite limited on memory, processing power, etc., that we had to make things as "efficient" as possible, thereby semi-forcing humans to adapt to the machine. Abbreviate everything, use hieroglyphics and compression to save space, batch processing, utilize as little as possible to get the job done... But those days have been gone for a while now, and I think it's time we make the machine adapt to the human way of looking at things. Another thing that drive me nuts is Zero based indexing. That's just sick, wrong and lazy on the lanuguage\compiler programmers part. There is no such thing as bucket\dog\tree number 0. 0 means NONE, notta, zip, zilch. It DEFINATELY doesn't (and shouldn't) mean "the first" of a number of items... Ahhh, I feel better now... :)
Oct 31 2006
== Quote from Jarrett BillingsleyWhat kind of syntax are you thinking? (I'm genuinely interested :) )In any case, it would be nice to have some kind of D grammar to start from, so you'd know what all the various language constructs your new syntax would have to support, rather than picking out all the grammar bits from the D spec. There _is_ one somewhere, but (1) I don't know if it's kept entirely up to date and (2) don't know what it's called or where it is. :|== Quote from Jarrett Billingsley The kind of syntax I'm thinking of would be one that would be easily readable and understood by virtually any programmer. It would be more verbose than C\C++\D\etc.. and cleaner and more logical than VB. Simple, readable, logical and consistent would be the primary goals. I would try to use generally understood words and symbols except where they just don't make sense unless you've been "educated" as to their meanings within a particular language. Obviously, that's not a completely achievable goal, but a worthwhile target in my opinion nonetheless. Here are a few examples. I think ==, &&, ||, etc. suck. = means equal, not ==. I would change the & and | symbols to something new. I would change the * to the "normal" multiplacation symbol (little x floating midline), the / to the normal divide symbol, the ! to the normal not equal (equal with a diagonal slash thru it, and I would use the ascii decimal 171 and 187 ((hex 00AB and 00BB) they look like small << and >>) as the "literal" identifiers instead of quotation marks... and so forth and so on. Things like "If a !<= b" just don't make any sense to me. I think it's much clearer and correct as "If a > b". Anyone that would use !<= is just being perverse IMO... :) I would use; Do, DoWhile, DoUntil, EndDo, EndDoWhile, EndDoUntil, If, EndIf, BegFunction, EndFunction, BegProp, EndProp, etc... I liked and applauded your "no need for '->'" comment in your VB example. I've been an application programmer for over 20 years. For the first 10 years I worked on the IBM S\36 and AS\400 using RPG. The next 10 years was programming Windows using Visual RPG (kind of a cross between freeform RPG and VB). One thing I've noticed over the years is that with each new generation of programming languages and operating systems, I keep getting moved closer and closer to system level programming. As a supposedly "high level" programmer, personally, I find that annoying. The fact that I "can" write my own string object is entertaining (if I felt like it), but the fact that I HAVE to absolutely sucks. Nice features that were built into the OS and language\compiler I used 15 years ago have dissappeared and now I have to do them MANUALLY. That sux. Memory management? Garbage collection? Ten years ago, I had no idea what that meant. I didn't NEED to because the OS and compiler took care of it for me... AUTOMATICALLY! God, what a novel concept. A few things I've noticed mentioned on the forums here... integer, double, float, unsigned integer, decimal, and on and on. WTH is that about? All I want is a NUMBER with nine digits and two decimals... you can store it in memory ANY DAMN WAY you like, but I don't NEED to know or care about it. And I damn sure don't want to have to manually convert "cast" it to make my math work. I think Walter mentioned that no one has a nice data file handling system. Other than the AS\400 and ASNA's duplication of that file system on Windows, I've never seen anything "nice". MSSQL, MySQL, etc... are a royal pain in the hiney, anything but nice. I've come to the conclusion that the only reason those things are used is because MOST programmers have never worked on a "nice" system with a "nice" OS, language and database. Anyway... enough ranting. :) I really like what I've read on here about Walters tossing of "legacy" compatibility and ignorant "features" of C++ when designing D. And trying to make it more modern with garbage collection, eliminating pointers (although it sure seems to have a lot of support for them), etc.. I just personally don't care for the syntax. But given my background, I think that's understandable. I think it would be great to give D a second syntax that would be "easier" to learn\understand for people that aren't coming from a C What do you think?
Oct 31 2006
"RA" <ra wolven.net> wrote in message news:ei8ij4$21ql$1 digitaldaemon.com...The kind of syntax I'm thinking of would be one that would be easily readable and understood by virtually any programmer. It would be more verbose than C\C++\D\etc.. and cleaner and more logical than VB. Simple, readable, logical and consistent would be the primary goals. I would try to use generally understood words and symbols except where they just don't make sense unless you've been "educated" as to their meanings within a particular language. Obviously, that's not a completely achievable goal, but a worthwhile target in my opinion nonetheless.An admirable goal.Here are a few examples. I think ==, &&, ||, etc. suck. = means equal, not ==. I would change the & and | symbols to something new. I would change the * to the "normal" multiplacation symbol (little x floating midline), the / to the normal divide symbol, the ! to the normal not equal (equal with a diagonal slash thru it, and I would use the ascii decimal 171 and 187 ((hex 00AB and 00BB) they look like small << and >>) as the "literal" identifiers instead of quotation marks... and so forth and so on.I don't know how I'd type any of those, though. Now you're getting into APL territory ;)Things like "If a !<= b" just don't make any sense to me. I think it's much clearer and correct as "If a > b". Anyone that would use !<= is just being perverse IMO... :)Actually !<= is not necessarily "not less than or equal" -- it's a special operator for comparing floating point numbers which takes into account NaNs. But again, typing the "not less than or equal" character on a keyboard is not very easy, nor is it probably supported under many fonts or under ASCII.I would use; Do, DoWhile, DoUntil, EndDo, EndDoWhile, EndDoUntil, If, EndIf, BegFunction, EndFunction, BegProp, EndProp, etc... I liked and applauded your "no need for '->'" comment in your VB example.Oh, I didn't make that -- that was in the original D example (have a look on the intro page of the spec). There's no -> in D either.I've been an application programmer for over 20 years. For the first 10 years I worked on the IBM S\36 and AS\400 using RPG. The next 10 years was programming Windows using Visual RPG (kind of a cross between freeform RPG and VB). One thing I've noticed over the years is that with each new generation of programming languages and operating systems, I keep getting moved closer and closer to system level programming. As a supposedly "high level" programmer, personally, I find that annoying. The fact that I "can" write my own string object is entertaining (if I felt like it), but the fact that I HAVE to absolutely sucks. Nice features that were built into the OS and language\compiler I used 15 years ago have dissappeared and now I have to do them MANUALLY. That sux. Memory management? Garbage collection? Ten years ago, I had no idea what that meant. I didn't NEED to because the OS and compiler took care of it for me... AUTOMATICALLY! God, what a novel concept.I think what's really happened is that there are still high-level languages, but low-level languages have come into their own so much that they're now popular for things like app development. Back in the late 70s, early 80s, what languages were there? You had the _really_ low level ones used for writing OSes, and then the much higher-level ones (like Smalltalk etc.) used for writing more interesting programs. But now the low-level languages have taken on many features from the high-level ones and have become more useful for things other than raw hardware access. There are still plenty of high-level languages that don't have explicit memory management or the need to program your own String object, e.g. Java,A few things I've noticed mentioned on the forums here... integer, double, float, unsigned integer, decimal, and on and on. WTH is that about? All I want is a NUMBER with nine digits and two decimals... you can store it in memory ANY DAMN WAY you like, but I don't NEED to know or care about it. And I damn sure don't want to have to manually convert "cast" it to make my math work.Well D is a _systems_ programming language and not necessarily a numerical or financial programming language. As such, having precise control over the number of bits and format of any given number is crucial for proper interfacing with various APIs. An eleven-digit fixed-point number doesn't mean much to most OSes and libraries, and so having such a type in D would not make sense either.I think Walter mentioned that no one has a nice data file handling system. Other than the AS\400 and ASNA's duplication of that file system on Windows, I've never seen anything "nice". MSSQL, MySQL, etc... are a royal pain in the hiney, anything but nice. I've come to the conclusion that the only reason those things are used is because MOST programmers have never worked on a "nice" system with a "nice" OS, language and database. Anyway... enough ranting. :) I really like what I've read on here about Walters tossing of "legacy" compatibility and ignorant "features" of C++ when designing D. And trying to make it more modern with garbage collection, eliminating pointers (although it sure seems to have a lot of support for them), etc..Again, the support for pointers is because lots of systems code needs them. D thankfully provides enough other abstractions, however, so that most of the time you need not deal with them. About the only time I use pointers is with the associative array "in" operator and allocating structs on the heap, things which don't happen _too_ often.I just personally don't care for the syntax. But given my background, I think that's understandable. I think it would be great to give D a second syntax that would be "easier" to learn\understand for people that aren't coming from a C What do you think?I think you're entirely justified in your opinion, and a language like that which you describe would probably be very useful to a lot of people. However, I don't know if D is really the right language to try to fit to your vision. You could change the syntax, but if you can't change the semantics, you won't be any closer to your dream. Have a go at making your own language then. It's fun, and that's from experience ;)
Nov 01 2006
If you just want to create D with different syntax, I think you can write a stand-alone parser then use it convert your other-syntax code to D syntax. RA wrote:I was curious about how hard it would be to create a different “language front end” for D? Since you (Walter) have made the compiler front end (lexer, parser, etc) source code available, would it be possible for someone to modify it and create a different (for example, something more like VB) language syntax that would still work with the back end compiler? I realize most of you long time C\C++ programmers probably couldn’t see any need for such a thing, but others of us (at least me) would prefer something not quite as cryptic as C like syntax. I’ve never written a compiler\lexer\parser\etc. so I don’t know what all would be involved in creating a different syntax. In theory, it doesn’t seem like it should be “all” that hard… But then, naiveté is great isn’t it. J
Oct 30 2006
To pick up Hasan's idea : You can create a Translator from a BASIC like language to D without programming by using a tool named Depot4. (works quit nice to translate higher level languages 4GL / domain specific languages to lower level languages 3GL f.i. D) All you have to do is do describe to source and target language in annotated EBNF. A simple sample : The Depot4 homepage : http://www.math.tu-dresden.de/wir/depot4/ Good luck. Björn
Oct 31 2006