OpenEuphoria

Re: . or : for namespace?

• Posted by CChris <christian.cuvier at agri?ultu?e.gouv.fr> May 06, 2008
• 812 views

Mike wrote:
> 
> CChris wrote:
> > 
> > Mike wrote:
> > > 
> -- snip
> > > Now, here is an example of how silly it can get:
> > > 
> > > include file.x as b
> > > sequence a
> > > ..
> > > 
> > > a.b.c
> > > 
> > > What does this mean? it really means <drum roll>  a . b:c
> > > 
> > >   !GASP!
> > > 
> > > If the dot is used for namespaces, sequence access, also using dots, will
> > > be
> > > fraught
> > > with such perils.
> > > 
> > > If there is to be *any* hope of using dot notation generally, I would
> > > really
> > > love to
> > > see someone try and explain away the above example.
> > > 
> > > I am sure there will be people who would prefer to use . as namespace but
> > > they
> > > would also
> > > like to use . for sequence access. Insisting on the former will jeopardize
> > > the
> > > latter.
> > > 
> > > or am I mistaken about this?
> > > 
> > > 
> > > regards,
> > > Mike
> > 
> > I'm not getting your point.
> > 
> > A namespace delineates a chunk of code (currently, that must be an entire
> > file
> > (sigh)) in which some identifiers are.
> > In structured access for sequence, the structure type delineates a chunk of
> > code (the field list declaration) in which some identifiers are.
> > 
> > Why does the difference matter?
> > 
> > CChris
> 
> It potentially attracts major obsfucation, eg:
> 
> a.b.c.d could mean..
> 
> a[b][c][d]  or  a:b[c][d] or  a[b:c][d]  or  a[b][c:d]  or a:b[c:d]
> 
> It is true that, technically, such a system could work because the compiler
> has
> enough info to figure it all out. But, we're not machines.
> 
> This example assumes that we are accessing Euphoria sequences and that we
> really
> want to have the freedom to put namespace references anywhere in the
> dot-chain,
> not just a single one right at the head of the dot-chain. And even then,
> ambiguity
> remains, eg..
> 
> a.b.c.d could mean..
> 
> a[b][c][d]  or  a:b[c][d]
> 
> 
> However, things appear less problematic for future genuine (C) structures,
> because,
> as you point out, the field declarations are specified. Nevertheless, there
> may be
> instances where it would be useful to mix structure fields and normal
> variables
> (which may include namespaced references) along the same dot-chain. Some
> structures
> contain arrays. Wouldn't it great to be able to iterate over such a thing
> using
> a
> for loop? Eg:
> 
> struct complex
>   double real
>   double img
> end struct
> 
> struct any
>   list complex[256]
> end struct
> 
> any ptr = address()
> 
> for i = 1 to 256 do
>    ptr.i.real = whatever_real()
>    ptr.i.img = 0.0
> end for
> 
> 
> So, basically we have :
> 
> obsfucation OR lack of freedom + nice looking 
> 

Where?
Namespaces are not that many. Do you mean you don't know which identifier is a
namespace? Really?

CChris

> vs
> 
> clarity + freedom - looks
> 
> 
> (the freedom referred to is a future freedom affected by design decisions
> being
> made now)
> 
> regards,
> Mike
> 
> PS: I hope my examples are clear enough