phil hunt philh at comuno.freeserve.co.uk
Tue Feb 5 15:26:03 EST 2002

On Tue, 05 Feb 2002 05:36:47 GMT, Courageous <jkraska at san.rr.com> wrote:
>I've come up with this concept that I'm calling "lingos": the name
>was chosen to evoke the idea of defining one's own lingo as a subset
>of the language. I'm still very much in the concept definition stage.
>I'm certain of little, but I'm certain that I want lingos to have
>at least the following properties.
>1. Lingos must be understood natively by the parser. No preprocessor
>front-ends or any other hack.

Why do you want this? Isn't it just an implementation detail?
I can see advantages in having it implemented as a preprocessor --
you could look at the preprocessor output and see what Python is 
generated. This might help with debugging complex macros.

>2. Lingos must be "hygienic". For those unfamiliar with the term,
>this means that names and symbols in the macro definition must not
>permute or modify the symbols in the namespace of the caller except
>where such a possibility is explicitly expressed: i.e., only the
>arguments to the macro itself can be permuted.

What if a macro needs to create local variables in its expansion?
Perhpas they could be called something like _lingos_local_xxx ?

>3. Lingos should be able to modify arguments as if the code in the
>lingo were used in place of the lingo itself. 

This would probably make more sense to me if you gave an example.

>I suppose that this
>is a fancy way of saying that one additional level of referentiality
>is supported. 

What's that meant to mean?

>4. Lingos should be able do deal with _code itself_ as a parameter.

Again, please give an example.

>This affords the opportunity to have lingos masquerade as proper
>Python block forms.
>5. Lingos might be able to support serial lingo forms, where one
>lingo knows how to aggregate multiple lingos into one lingo
>invocation. What I mean by this last is easier to describe by


>Discarding the issue of special symbols for the moment, here are
>some possible lingos by example:
>1. Here "invariant" is a lingo macro which has 0 expression arguments
>   and 1 code argument:
>	invariant:
>		dosomething()

What is that meant to do?

>2. Here "unless" is a lingo macro taking 1 expression argument and 1
>   code argument:
>	unless i < 3:
>		dosomething()
>3. Here "factor" is a lingo macro taking 1 expression argument and
>   no code argument:
>	result = factor 17

Why not factor(17) ?

>4. Here "do" is a lingo macro taking 0 expression arguments, a code
>   argument, and acting as an aggregator for exactly 1 "while" lingo
>   form:
>	do:
>		dosomething()
>	while i <10

IMO it is more Pythonic to say:

      while i <10                                                                                        

And it is even more Pythonic to say:

   while 1:
      if i >= 10: break

>So. That, at last, brings me to the point of this message. Ideas?
>Feedback? This has been an interesting experiment so far, I'm just
>wondering how many folks find this sort of thing interesting and if
>anyone has any input.

I think Python could benefit from a macro system. But the devil's
in the details.

===== Philip Hunt ===== philh at comuno.freeserve.co.uk =====
Herbivore, a zero-effort email encryption system. Details at:

More information about the Python-list mailing list