J
Jacek Generowicz
Peter Maas said:Oh. Thanks for correcting me and my apologies to Jacek.
No probs.
I should have read the thread from the beginning but it was way too
long.
.... I know the feeling
Peter Maas said:Oh. Thanks for correcting me and my apologies to Jacek.
I should have read the thread from the beginning but it was way too
long.
[François Pinard]Suddenly backtracking out of a complex involvement for restarting
in a new direction, for the above project at least, requires a lot
of state resumption, and doing this cleanly in Python implies a
rather strict and burdening discipline about where and how the state
information is kept.
Would such a problem be solvable if you could pickle a "running"
generator?
So, is there some deep philosophical (as opposed to implementation
detail) flaw in the picklable generator idea?
[François Pinard]Suddenly backtracking out of a complex involvement for restarting
in a new direction, for the above project at least, requires a lot
of state resumption, and doing this cleanly in Python implies a
rather strict and burdening discipline about where and how the state
information is kept. While tractable, this is not as comfortable as
I would have liked it...
It may be possible to do what you want to do using only generators.
continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<store continuation away for future use>
else:
<function completed, carry on>
Dunno if this helps or not....
[Christopher T King]
It may be possible to do what you want to do using only generators.continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<store continuation away for future use>
else:
<function completed, carry on>
If the generator gets exhausted, what would be the purpose of saving it?
said:I would presume chained generators might ease control of the flow, at
least to a certain extent, but would not help so much for complex state
resumption, especially when state is shared between parts of the program.
Siegfried Gonzi said:I am not an expert in CLOS programming. But what are the disadvantages of not having a meta-object protocol? What
is hard to realize then?
So, it is up to you to decide if is something worthy or not to learn.
(I mean, Fortran is not even OO but works pretty well for numerical
tasks).
Siegfried Gonzi said:I am not an expert in CLOS programming. But what are the
disadvantages of not having a meta-object protocol?
What is hard to realize then?
As of the 2003 standard, Fortran supports OOP, including inheritance.
The NAG Fortran compiler is not a full F2003 compiler, but it has the
OOP features -- see http://www.nag.co.uk/nagware/NP/NP50_announcement.asp
.
Fortran 95 supports object-based programming -- there is no
inheritance, but you can define data types with public and private
members, and these data types can be used as procedure arguments.
But I agree with your main point -- you can write good numerical
software in Fortran without OO.
what are the disadvantages of not having a meta-object protocol?
What is hard to realize then?
I do not grasp why one would implement an object system without a
perceived valuable meta object protocol.
I posted ("Bigloo and the lack of a MOP") some questions on
comp.lang.scheme because I do not grasp why one would implement an
object system without a perceived valuable meta object protocol.
I mean what are the motivations behind such adventures.
Jacek said:You appear to have gone from not seeinig the point of a MOP, to not
seeing why one would implement an object system without one, in under
29 hours, 16 minutes and 53 seconds. Must be some sort of world
record. (Mechele's answer must have made a huge impression on you.)
Why pick on Scheme?...
you should post the same questions on
newsgroups talking about C++, Java ...
Michele said:Coming back to the original poster, I don't think that Bigloo object
system is crippled because it lacks a MOP: but in that period of time
I wanted to learn CLOS and not Meroon, so I did not consider Bigloo
further. That's all.
Siegfried Gonzi said:You know the sentence is not meant as you read it.
Why do you insist that I personally "perceive" a MOP valuable?
Why not?
Jacek said:I should have said: "Your question isn't really relevant to Scheme"
and left it at that.
Siegfried Gonzi said:a) Yes it is not essentially related to Scheme. You are right, but:
b) However, it is related to Bigloo and MEROON. Do you know any Java
programmers who knows MEROON.
My interest actually was: Bigloo and its connection to this MOP stuff. And
to my knowledge Bigloo is Scheme.
Jacek Generowicz said:OTOH, given that Scheme has no object system, and yet, most
implementations do have one, it is probably of general interest on
c.l.s.
But this thread has made me aware of Meroon, and that
- it is ported to many Schemes (including Bigloo, so Bigloo's object
system not having a MOP becomes a non-issue)
- it has CLOS-like generic functions
- it has a MOP
... which (if the blurb is to be believed) makes Scheme altogether
more interesting for me ... and I might just consider it in future
projects ...
... so I thank you for making me aware of Meroon.
Yes, I got curious and I would like to look at it too, if I had the time!
Jacek Generowicz said:... which (if the blurb is to be believed) makes Scheme altogether
more interesting for me ... and I might just consider it in future
projects ...
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.