I wrote such a debugger as part of my PhD work. It is called hsdebug and you
can read the Haskell Workshop paper on it here:
http://www.cambridge.intel-research.net/~rennals/hw2003.pdf
Unfortunately, HsDebug depends on Optimistic Evaluation, and it seems unlikely
that Optimistic Evaluation
I've no idea what state the speceval_2 branch is in. It's where Robert
was working on optimistic evaluation. I'll let him comment.
[snip]
| ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
| Optimistic Evaluation does not currently support native code
| generation
DRiFT will let you do that, by deriving get_ and set_ methods, but other
than that, no. THere was discussion about a year ago (I think) about
this, with proposed syntax for something, but it never really got off the
ground. You can probably google for it with my name and some other
[snip]
No, optimistic evaluation does not work well with interact, because it
causes the input stream to be evaluated (and therefore demanded) earlier
than you would expect. This is the problem: interact exposes more than
just non-strictness, it exposes laziness.
In Robert Ennals
Karl-Filip Faxen wrote:
| Yes, things are clearer and I rather like the idea.
| The only thorny issue is that the update function for
| field 'wibble' is formed from but not equal to the
| field name itself.
This could be solved by having an abstract type Field
thusly (*):
[snip]
I'd like to add a voice of dissent here.
I would much prefer it if Haskell didn't add specific extensible records
support - even if it could be done without breaking backwards compatibility.
This is because I believe that extensible records encourage poor style. They
encourage people to
Hi!
So in summary, here is my proposal:
No specific extensible records system.
Define record update to be a function just like record selection is.
Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1,
[EMAIL PROTECTED] (Ketil Z. Malde) writes:
Robert Ennals [EMAIL PROTECTED] writes:
BTW, isn't this more or less exactly what Simon suggested (at the very
top of this thread)?
Not really, no.
I assume you mean the system suggested by Peter Thieman, outlined in the
initial email
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
Shouldn't that rather be:
class HasWibble a where
wibble :: a - Int
set_wibble :: a - Int - a
class HasWobble a where ...
Or even:
class HasWibble a b | a - b where
wibble ::
[snip]
If you're using an eager haskell implementation which does some speculative
evaluation of things that look cheap and that you might want to evaluate, the
answer is probably no. (Because, having decided to do some speculative work
in the absence of a demand, it might decide it has
[resending this mail from a different address as it didn't seem to get
through the first time. I apologise if you see multiple copies.]
[snip]
If you're using an eager haskell implementation which does some
speculative evaluation of things that look cheap and that you might want
to evaluate,
Well, for the most part, LaTeX only provides common operators. One problem, I
came across some weeks ago, is that it is *not* possible to define his/her own
operators (or, at least, that Lamport's LaTeX - A Document Preparation
System doesn't tell you how you can define them).
It's
I know this is slightly off topic but...
Does anyone know if there are any papers published anywhere on strictness
annotations?
It seems that it would be nice to be able to cite a paper on the concept, but,
as far as I can tell, no such paper exists.
-Rob
Robert,
Strictness annotations were proposed for Haskell in the paper
Implementing Haskell Overloading by Lennart Augustsson.
http://citeseer.nj.nec.com/augustsson93implementing.html
It only has a small section on strictness annotations but this is as close
as I can get to your
Robert Ennals [EMAIL PROTECTED] wrote:
Surely that problem only arises if one insists on encoding all the relevant
information inside a string.
This is pretty much the only option, because translators
and programmers are different people. Translators can deal with
simple text files
Martin Norbäck [EMAIL PROTECTED] wrote:
I agree that i18n needs positional arguments.
What's wrong with simply doing like this:
printf I have %. %. %..[trained, show 1, Jedi]
printf %2. %3. %1. I have. [trained, show 1, Jedi]
Nothing is exceptionally wrong with it, except it's
Robert Ennals [EMAIL PROTECTED] wrote:
I personally much prefer the syntax currently used in Haskell, which is also
essentially what is used in most other recent languages, including Java, C++,
and (god help me) Perl.
In the example given, I could write:
I have ++ action
I searched on google, but had no luck.
My program is an implementation of
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
in haskell, and the dictionary read in is rather large
(900Kb) so I assume most of the space should be [[Char]]
Zxxx is the way GHC encodes operator names
But, to answer your emmediate question:
ZMZM = [] - The list Nil constructor
Z1T = ( ) - The 1-tuple constructor
IIRC, the 1 is the number of commas, so Z1T is the *pair* constructor.
The comments in OccName.lhs say:
[copying direct from the file]
Before
On Wed, 25 Apr 2001, Robert Ennals wrote:
Thus if we want to inherit our implicit paramater, we would have:
f ?y x = (x :: Int) + ?y
I like the current solution better. They are called implicit parameters
because they are, well, implicit :-)
The semantics is still implicit.
When
On Sun, 7 Jan 2001, Sebastien Carlier wrote:
Sometimes I need to write code which looks like this:
do x - m1
let y = unzip x
... -- never using x anymore
I thinks the following extension to do-notation would be useful:
pat - exp1 # exp2 ; exp3
would be
to
keep note of all the names that are currently in use, and whenever a name
is displayed, qualify it enough to distinguish it from all other names that
could occur.
[snip]
--
Robert Ennals - 0798-904-3486 - http://thor.cam.ac.uk/~rje33/
23 matches
Mail list logo
