Re: [Chicken-hackers] conditionals in .egg files

[Jörg F . Wittenberger]

On Sep 28 2018, Peter Bex wrote:

> On Fri, Sep 28, 2018 at 08:28:21PM +0200, Jörg F. Wittenberger wrote:
> > One more idea: How about an entry indicating the version of the egg file
> > syntax?
> >
> > Having something to cond-expand is nice. But it might be hard to settle 
> > with a final version without unduly delaying CHICKEN 5.
> >
> > This leaves us with changing semantics of many eggs over time. With a an
> > entry like
> >  (egg-version "1.X") future changes could easier apply backward 
> > compatible processing for old eggs.
>
> I'm not sure how useful that would be.  Usually we'd keep backwards
> compatibility, which should be easy: only introduce new forms.

Which creates bloat and the need to keep backward compatibility.

Having a syntax version would make it easy to spot what is deprecated or no 
longer working. We could essentially grep for eggs needing attention. 
Without one ends up debugging.

First and foremost the idea wanted to pave a way to experiment with syntax 
which we might eventually NOT want to support anymore. And remove support 
soon. So chicken-install could evolve faster than once every major chicken 
release. This scenario would exacerbate the need to locate a few eggs 
depending on syntax avail in a (short) time range.

> Coupled with a deprecation phase for forms that disappear, and our
> slow release process, I'm sure people will have no good excuse to
> not upgrade :)
>
> The problem with old versions of chicken-install would be they don't
> understand those new forms.  But for those I guess you'd just pin
> the version of the egg to an older one.

The old chicken-install is IMHO a no brainer: just complain about new 
syntax version.

At the other hand: if the plan for cond-expand is to actually allow every 
component of the egg file to be conditioned on features, the idea is mood.

But than I wonder, maybe we should enable let-syntax too. ;-) /runs and 
hides/

Best

/Jörg