This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Language translation proposal 1.4


Marius Vollmer <mvo@dt.e-technik.uni-dortmund.de> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > Michael Livshin <mlivshin@bigfoot.com> writes:
> > 
> > > Ian Bicking <ianb@colorstudy.com> writes:
> > > 
> > > > Should load also potentially take a :language argument?  Maybe this is
> > > > getting to be too many ways...
> > > 
> > > seems like a good idea to me, FWIW.
> 
> I would say hat the syntax understood by `read' is a reader option,
> not an option to `load'.

Indeed so, but there might be a need for an easy way for the user to
explicitly tell Guile which translator to use.

Therefore I think `load-using-language' seems motivated.

> More generally, I think using global, `special' variables for this
> kind of options is not a bad thing.  Yes, global variables have a bad
> reputation, but with namespaces, dynamic-wind, and fluids they should
> be really useful and robust.

It's not possible in this case because the procedure `read' does not
have access to the environment in which it is applied.

That is the reason why I talk in the proposal about read parameters
being associated with the input-port.  (This part of the proposal
should be completed.  I know what should be there but haven't had time
to write it down yet.)

> I don't remember why we didn't use global state for the print-chain.

We had very good reasons for introducing the print-state.

We couldn't associate the print state information with a variable,
because `display' and co donät have access to it.

We couldn't associate it just with the port, because the printing
process might involve using string ports at an intermediate step.


My talk about a symmetric `read-state' is totally flipped out,
though.  The situation is not symmetric for reading.  (It's
anti-symmetric. :)

The read state should be associated with the port directly, and
initialized when the port is created in the normal case, and when the
user uses the "in" repl command to switch module.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]