OpenEuphoria

Re: Revised Namespace Proposal

• Posted by Igor Kachan <kinz at peterlink.ru> Jul 09, 2001
• 427 views

Robert Craig writes:

> > include file.e  as legal_old_name&any_delimiter_is_new_element
> >
> > My question is - is it a complex solution for the parser?
> 
> I'm not sure what you are asking.
> You seem to be suggesting that we should allow
> more than just ':' as a delimiter on qualified names.


Yes, I try to get more than just ':' as a delimiter
on qualified names and get available maximum of new
syntax and keyword abilities now.

The most real new candidates to delimiters are
'.' , '^' , '!', '~' , '@',  '%' ,'$' , '|' , '`'. 

But delimiter may be almost any sign (not letter, not
digit and not underscore), I am sure now.


> This would confuse people, and could confuse the parser
> as well. Imagine if '+' or '-' or '*' or '&' or '/'
> were allowed as a delimiter:
> 
>  x = y+z  -- Is that actually y:z or y + z ???


Before you ask yours -- Is that actually y:z or y + z ???
interpreter prints 3 error messages about the bad syntax
and 2 run time error messages without any confusion
on your example  

To be accurate in the frame of my question about 
the Eu parser, see please below :

----file.e
global integer y
----end of file

----prog.ex
include file.e as a+    --  this is delimiter + 
integer x, y, z
    z=1
    y=2
  a+y=3                 --  this is resolved names conflict
    x=a+y+z+y           --  this is the wonderful expression
----end of file

Well, I think I am not extravagant enough to choice
'+' as a delimiter, but why not *other convenient*
signs above ?  Or just '.' and ':' ?


> By the way, it is *not* now legal to create symbols
> that contain ':', e.g.
> 
>      integer asdf:xxx   -- this is illegal


Yes, Rob, I know, thank you.


> The rules for forming an identifier remain the same.
> We have just created a new kind of "qualified symbol"
> that consists of:
>       identifier:identifier


This is the main point. The first part of this new
kind of "qualified symbol" *and* delimiter both keep
too little functional amount of work to be done,
I think.

The identifier&delimiter construction may be not just
a name's prefix now. If you have the new keyword 'as'
in Eu, this construction may be a kind of namespace
operator or special mark up operator.

See what I want now, my appetite grows, sorry, but
this is an example of a flexibility, when you can 
*define* *two* or *one* delimiters 
with the 'as' operator :


                        include|blank|file.e|blank|as|blank|
  delimiter|qualifier|delimiter|blank|

                        include|blank|file.e|blank|as|blank|
            qualifier|delimiter|blank|

                        include|blank|as|blank| 
            qualifier|delimiter|blank|

                        include|blank|file.e|blank|


---my_lib_file.e
global integer My -- in the current file, scope to the 'include as a:' 
    My=0          -- this is My #1


include as
a:                -- *see one delimiter*
global integer My -- in the current file, scope to the 'include as b:'
    My=1          -- this is My #2
    

include as
b:                
global integer My -- in the current file, scope to the end of file
    My=2          -- this is My #3
---end of file    -- this scheme allows merge libraries into
                  -- standard big one.


---my_main_file.ex
integer My        -- this is My #4, 
include my_lib_file.e as :a.     -- *see two delimiters*
    My=3          -- My #4
  a.My=4          -- My #1
a:a.My=5          -- My #2   -- see basic-like "label" a: in file.e
b:a.My=6          -- My #3   -- see basic-like "label" b: in file.e

? {My, a.My, a:a.My, b:a.My}
---end of file

And if you can *define* the *delimiters* with "as" command
and parse them, various notations of some other languages
become available in Eu, if you want these
all notations 

Rob, I know that scheme above and real coding
of interpreter are too different things,
but that scheme may be useful too, as
many others, I think.

The new key idea is *defining* of the *delimiters*
with 'as' command. There may be two delimiters 
in this scheme -- the first and the second 
in the order of blanks from left to right.
And any pair from the set of legal new delimiters
may be parsed and compiled into the internal code
just as 'a' and 'b' to get the new identifier
from the qualifier and the qualified name.

Rob, is this idea too complicated thing for 
updating the existent parser and compiler?

Sorry, I know, this *concrete* question is not
simple, so, this is the last *my question* on this
subject and I am patient to wait and get an answer
when 2.3 is ready 


Thanks.

Regards,
Igor Kachan
kinz at peterlink.ru