1. dot pre-processor
- Posted by jiri Mar 26, 2009
- 862 views
Thanks, Jeremy, for reviving David's pre-processor. Has it really taken 11 years? I hope it will take much less time to be hard-wired into the interpreter/compiler!
jiri
2. Re: dot pre-processor
- Posted by jeremy (admin) Mar 26, 2009
- 817 views
Thanks, Jeremy, for reviving David's pre-processor. Has it really taken 11 years? I hope it will take much less time to be hard-wired into the interpreter/compiler!
jiri
Jiri, you're welcome. I am not sure how much of it, if any, will be wired into the interpreter/compiler. I certainly like the syntax, but we need to make some OO plans before hardwiring anything in. Discussions about that (if even to include it) will come post 4.0. Then we will talk about the DOT type syntax as well. It's simplicity certainly has a lot going for it.
For now, I am going to use DOT for sure. The way I figure, is if 4.1 comes along and we have a conflicting syntax, I can always switch to the post-translated code, as DOT does a great job of maintaining the source formatting and such, so I've lost nothing in the translation.
Jeremy
3. Re: dot pre-processor
- Posted by Kat Mar 26, 2009
- 883 views
Thanks, Jeremy, for reviving David's pre-processor. Has it really taken 11 years? I hope it will take much less time to be hard-wired into the interpreter/compiler!
jiri
Jiri, you're welcome. I am not sure how much of it, if any, will be wired into the interpreter/compiler. I certainly like the syntax, but we need to make some OO plans before hardwiring anything in. Discussions about that (if even to include it) will come post 4.0. Then we will talk about the DOT type syntax as well. It's simplicity certainly has a lot going for it.
For now, I am going to use DOT for sure. The way I figure, is if 4.1 comes along and we have a conflicting syntax, I can always switch to the post-translated code, as DOT does a great job of maintaining the source formatting and such, so I've lost nothing in the translation.
Jeremy
And adding this DOT processor to the EUINC bat file i call now is easy. Only drawback is the trace window won't display what i actually wrote.
useless
4. Re: dot pre-processor
- Posted by shfrance Mar 26, 2009
- 876 views
I'll risk the flames to make a comment, using Jeremy's words.
"I was not aware that we are bound by our lineage, that's a new rule to me in developing a language."
"I certainly like the syntax, but we need to make some OO plans before hardwiring anything in."
I like the syntax also. I just question if it must be connected to OOP. Grandaddy MicroS did it first, not necessarily best.
5. Re: dot pre-processor
- Posted by jeremy (admin) Mar 26, 2009
- 855 views
I'll risk the flames to make a comment, using Jeremy's words.
"I was not aware that we are bound by our lineage, that's a new rule to me in developing a language."
"I certainly like the syntax, but we need to make some OO plans before hardwiring anything in."
I like the syntax also. I just question if it must be connected to OOP. Grandaddy MicroS did it first, not necessarily best.
It's not connected to OOP, however, if OOP comes to Euphoria, it may use a similar syntax, thus causing a conflict, that's all. I think we need discuss the hard details of OOP and Euphoria before making the interpreter do anything remotely OOP like. For instance, DOT syntax does this:
sequence name = "John" ? name.length() -- Or enum FirstName, LastName sequence person = { "John", "Doe" } printf(1, "Hello, %s! Your last name is %s?", { person.FirstName, person.LastName })
Both of those could very much conflict with OOP, if it were to come to Euphoria.
Jeremy
6. Re: dot pre-processor
- Posted by Kat Mar 26, 2009
- 850 views
Both of those could very much conflict with OOP, if it were to come to Euphoria.
Jeremy
Let me point you to OOEU, which isn't all OO.
useless
7. Re: dot pre-processor
- Posted by DerekParnell (admin) Mar 26, 2009
- 853 views
It's not connected to OOP, however, if OOP comes to Euphoria, it may use a similar syntax, thus causing a conflict, that's all. I think we need discuss the hard details of OOP and Euphoria before making the interpreter do anything remotely OOP like.
I don't think that there is any necessary conflict. Therefore your phrase "thus causing a conflict" should be worded more like "thus might cause a conflict", IMO. However, I agree that a lot of discussion needs to happen before we add built-in OOP facilities into the language.
For instance, DOT syntax does this:
sequence name = "John" ? name.length() -- Or enum FirstName, LastName sequence person = { "John", "Doe" } printf(1, "Hello, %s! Your last name is %s?", { person.FirstName, person.LastName })
Both of those could very much conflict with OOP, if it were to come to Euphoria.
It is possible, I suppose, but in these examples, the 'name' and 'person' objects are sequences and that could be detected at parser time and thus the correct IL code could be generated, and this would not be in conflict with dot notation used in other manners.