inclusive-lower-bound, exclusive-upper-bound (was Re: Range Operation pre-PEP)

Andrew Maizels andrew at one.net.au
Wed May 16 01:50:35 CEST 2001


Greg Ewing wrote:
> 
> Andrew Maizels wrote, giving examples of code where requiring
> explicit line continuation markings would be tedious:
> >
> >         for i in item
> >         where i.custnum = c.custnum and
> >               i.duedate < today - 60 and
> >               i.open <> 0:
> >             over60 += i.open.
> >         end.
> 
> A couple of ideas come to mind:
> 
> * Allow implicit line continuations anywhere you have what
>   is obviously a syntactically incomplete structure (e.g.
>   an expression ending with a binary operator).

I've thought about that, but I'm not sure how well this will fly with
the average programmer.  I think Icon does this.

> * Allow a statement to have indented continuation lines.

No, indentation is out.  It works well enough in practice (most of the
time), but I just don't like it.
 
> >         if over60 > 50 then do:
> 
> Do you really need both "then" and "do" there? Seems a
> tad wordy to me.

Well, "then" is followed by a single statement.  "do: .. end." can be
used anywhere to enclose a block of code.  They're Pixy's curly brackets
or indenting.  Blocks can also be labeled and have variables and
transactions scoped to them.  I'm looking at a full block implementation
like Smalltalk, but that will have to wait a bit.  (Pixy uses curly
brackets for its include file/pre-processor syntax.)
 
> By the way, I really like the idea of having relational
> DB constructs integrated with the language. Few things
> suck more ferociously than embedded SQL, in my opinion!
> I wish you luck!

I've been programming in the Progress 4GL for [mumble] years, and it's
really good with this.  I'm looking to extend this so that it will work
with any data collection, not just database tables, including
user-defined classes, so you'll have a unified syntax for selection,
joining and sorting data from any source.

I've been looking for a language better than Progress for doing the sort
of work I do (accounting, customer service and billing systems) for
several years.  While Progress is very powerful, it's slow, proprietary,
and has limited extensibility (it's not object oriented).  I've settled
on using Python as an extension language for Progress, and have been
successful with this for the past two years or so.  Now, though, I'm
going to take a shot at rolling my own.

In the above example, Progress would say "for each item", automatically
allocating a database buffer with the same name as the table.  I don't
think this will work in a more general-purpose language, which is why
I've gone for the "for [element] in [collection]" syntax.

I'll drop a note in comp.lang.python when I've got something working. 
It'll be on-topic, since the first version of Pixy will be at least
partly implemented in Python :)

Andrew.
-- 
There's only one game in town.
You can't win.
You can't break even.
You can't quit the game.		-- The four laws of thermodynamics.



More information about the Python-list mailing list