RE: character syntax

2002-02-08 Thread Simon Marlow


 itz All this taken together, I mean, _really_, is the lexical
 itz structure of Haskell a botch, or what?
 
 Jon No. Innovative. All the problems described in this thread reflect
 Jon unwarranted assumptions inherited in emacs. It's plainly possible
 Jon to parse Haskell, and not hard either.
 
 First, parsing of a complete program (eg. by a compiler) is quite
 different from parsing a buffer that is being edited by a human.  The
 latter is hard, even for fairly well-specified languages.
 Irregularities only make it harder.

For syntax highlighting you only need to lexically analyse the buffer, not parse it.  
Haskell's lexical syntax is parseable by regular expressions, which means it shouldn't 
be hard to plug a syntax highlighter for Haskell into just about any editor.

I don't understand why you say that parsing a buffer being edited by a human is hard - 
perhaps doing incremental lexing is slightly harder than whole-file lexing, but not 
that much harder.  The state of a Haskell lexer can be represented with a little 
trickery by an integer, so it isn't hard to cache the lexer's state at the beginning 
of each line.  I did this once as an experiment when I added Haskell syntax 
highlighting to one of the KDE editors (I forget which).

The problem is not Haskell, it's emacs.  Emacs's syntax highlighting has fairly 
deeply-wired-in assumptions about C-like languages (eg. last I looked you still 
couldn't support nested comments properly in font-lock).

Cheers,
Simon
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe



Re: character syntax

2002-02-08 Thread Jorge Adriano

On Friday 08 February 2002 14:35, Ketil Z. Malde wrote:
 Jorge Adriano [EMAIL PROTECTED] writes:
  Haskell looks nice... Isabell looks beautiful :-)

 I'm not familiar with Isabell, but aren't we comparing apples and
 oranges here?  E.g. you can prettify .lhs pretty nicely with one of
 the LaTeX packages available.

Well yes :-)
You said Personally, I think the Haskell syntax is beautiful, and in my 
answer I talked about the way it looked on Xemacs, not the syntax. 
But not sure if we are talking about the same thing here, how do you prettify 
the .lhs files? Are you talking about the dvi you get in the end or the way 
it looks while editing the code? 

  And no, I don't have the time to do something
  better myself now, so I'll just stick to it :-)

 If somebody would come up with a mode that used lambdas and arrows to
 render things nicely in my editor, I wouldn't mind.  But I don't think
 the benefit for me would be great enough to justify the effort (I'm
 not much of a lisp hacker).

I wouldn't mind either. Everything looks really nice, making your code really 
easy to read, it's not just the greek leters, the 'forall's, the arrows '=', 
the 'and's and the 'or's.
But the Isabell/Isar/Proof General (which I haven't used in a long time) mode 
had more to it than just that. The menus were pretty good, buttons (with 
icons) for some commands... it turns Xemacs into a very nice GUI for isabelle.

J.A.

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe



Re: efficiency question

2002-02-08 Thread Jorge Adriano

 I'd say that's because in the second case you also got to apply the (,),
 besides the (+)/(-) constructor during the transversing...
 Am I right?

opss... I meant to write: the (,) constructor besides the (+)/(-)...
J.A.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe



RE: efficiency question

2002-02-08 Thread Konst Sushenko

(moved to haskell-café)

I ran Hal's code on my computer, and with test2 I get a stack overflow (so I had to 
use +RTS option for it to finish). test1 does not overflow stack (of standard size, I 
mean without +RTS). Which implies that test2 uses more stack space than test1. why 
would it use more stack if not because of laziness?

konst

 -Original Message-
 From: Hal Daume III [mailto:[EMAIL PROTECTED]] 
 Sent: Friday, February 08, 2002 4:35 PM
 To: Jorge Adriano
 Cc: Konst Sushenko; [EMAIL PROTECTED]
 Subject: Re: efficiency question
 
 
 I agree that it's the overhead of (,), but I don't see why 
 there would be
 any overhead for doing this.
 
 --
 Hal Daume III
 
  Computer science is no more about computers| [EMAIL PROTECTED]
   than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
 
 On Sat, 9 Feb 2002, Jorge Adriano wrote:
 
  On Friday 08 February 2002 23:52, Hal Daume III wrote:
   I've tried using a strict fold:
  
   foldl' f a [] = a
   foldl' f a (x:xs) = (foldl' f $! f a x) xs
  
   but that has no effect (or minimal effect).
  
  That wouldn't work even if if laziness is the problem 
 because that would only 
  cause the elements of the list to be evaluated to head 
 normal form, the 
  elements of the pair would not be evaluated so you'd have a 
 'suspension of  
  (minus and plus) operations'.
  
  instead of 
   (\x (a,b) - (x+a,x-b))
  try 
   (\x (a,b) - (((,) $! x-a)$! x-b) )
  
  I just noticed that you were the one who sent me the DeepSeq module.
  This is the kind of place where I want to use it.
  Instead of $!, try $!!.
  
  
  And Konst Sushenko wrote:
  My guess is that it is due to the laziness of the 
 addition/subtraction
  in (,)
  
  Seems to me like lazyness is not the right guess because 
 both functions Hall 
  first posted were lazy. So I think it's just the overhead 
 of applying (,) 
  besides (+) and (-) in each step. Do I make sense or am I 
 missing something?
  
  J.A.
  
 
 
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe