Re: Language Feature Request: String Evaluation

[S. Alexander Jacobson]

In principle I can do this, but:
1. how do I hide the import of show String to replace it w/ my own?
2. If I do replce show String what else will break?
3. If instead I define an eshow function that strips "", how do I minimize
the perforamnce hit of quote stripping?
4. If I want to share my code, I have to share both the actual codebase as
well as the preprocessor code.  This seems like sucha  basic language
syntax issue that I shouldn't have to worry about which version of haskell
your collaborators are running.  Everyone writing their own preprocessor
will severely balkanize the language.
5. How does the use of this pre-processor interact w/ tools like Derive
and PolyP which are also implemented as preprocessors?

That being said, I would be happy to take a shot at HacWrite if it had a
shot of becoming part of the language definition (or if it was a standard
part of the various haskell distributions: ghc, hugs, hbc,etc.) and if
Magnus would allow it.

Is there a good lanugage reason to object to this feature?  It seems like
a no brainer imprpovement.

-Alex-


___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop

On Tue, 8 Jun 1999, Lennart Augustsson wrote:

> "S. Alexander Jacobson" wrote:
> 
> > HacWrite certainly seems like an improvement over Haskell.
> > However, it is just not as good as the scripting languages.
> > HacWrite still requires the author to differentiate between strings and
> > other types, still requires explicit use of show and still requires more
> > typing and curly balancing.  Isn't this nicer?
> >
> > "insert into mytable values (NULL,'$var1','$(var2+var3)','$var3')
> >
> 
> So add your own little modification to HacWrite.  It would be easy enough
> to add $ interpolation.
> 
> -- Lennart
> 
> 

Re: Language Feature Request: String Evaluation

[Keith Wansbrough]

> > Alex, you might want to explain to people (such as myself)
> > who don't know how Perl etc decide how much white space to insert
> > in the string that's broken across a line.  One space?  None?
> > What of the indentation spaces on the new line?   What if
> > you really want those spaces to appear in the string?
[..]
> #!/usr/bin/perl
> 
> print "hello 
>   world\n";

I never use multi-line strings in this form; instead I use the "here-document" form:

#!/usr/bin/perl

print <<] )   :
: Native of Antipodean Auckland, New Zealand: 174d47' E, 36d55' S.:
: http://www.cl.cam.ac.uk/users/kw217/  mailto:[EMAIL PROTECTED] :
:-:

Re: Language Feature Request: String Evaluation

[Magnus Carlsson]

I've been using a preprocessor to Haskell that I call HacWrite, which
adds a new kind of string appropriate for entering text.  Such strings
can span multiple lines and can be escaped using curly brackets:

  var1 = 2*2
  var2 = 4*var1
  var3 = «Foobar»
  sqlstring = «insert into mytable values
(NULL,'{show(var1)}','{show(var2)}','{var3}');»

Text is enclosed within «these characters» (which are hard to find on
my keyboard, so I let Emacs insert them when I press '"'). To support
markup, stuff that follows a space inside an escape is treated as
text:

   «This {bf sentence contains words in boldface}.»

Here, `bf' is a markup function from text to text.

I've found HacWrite quite useful for document writing (see
http://www.cs.chalmers.se/~hallgren/Thesis/ for a longer example :-),
but I'm sure it could be useful for CGI-scripting and the like as
well. 

/M

S. Alexander Jacobson writes:
 > A popular thing to do with computer languages (especially scripting
 > languages) is to  manipulate text and insert variables into strings.  
 > It is extremely irritating to escape in and out of strings via ++ in
 > Haskell or + in Java/Javascript.  
 > e.g. 
 > > var1 = 2*2
 > > var2 = 4*var1
 > > var3 = "Foobar""
 > > sqlstring = "insert into mytable values "++
 > >  "(NULL,'"++(show var1)++"','"++(show var2)++"','"++var3"');"
 > 
 > It would be much nicer if Haskell did what perl,php, and tcl do:
 > > sqlstring="insert into mytable values (NULL,'$var1','$var2','$var3')".
 > Even nicer would be:
 > > sqlstring="insert into mytable values
 >   (NULL,'$var1','$(var1+var2)','$var3')".
 > 
 > (Notice both the embedded evaluation and the fact that the string runs
 > accross multiple lines)
 > 
 > Supporting this feature involves either:
 > a. a syntactic transformation after you have type information (don't
 > 'show' strings)
 > or 
 > b. redefining show string not to return quotation marks
 > 
 > To me the second makes more sense, but either way, this feature would make 
 > haskell programming much less annoying.
 > 
 > 
 > -Alex-
 > 
 > PS Why does show string return quotation marks?  It seems inconsistent.
 > 
 > ___
 > S. Alexander JacobsonShop.Com
 > 1-212-697-0184 voice The Easiest Way To Shop

Re: Language Feature Request: String Evaluation

[Jon . Fairbairn]

On  8 Jun, Paul Hudak wrote:
>  show x should be a string that when printed looks like the value that
>  you would have to type to generate it directly.  This example is most
>  instructive:

[...]

and this is just cute:

main = putStr (quine q)
quine s = s ++ show s
q = "main = putStr (quine q)\nquine s = s ++ show s\nq = "

-- 
Jón Fairbairn [EMAIL PROTECTED]
18 Kimberley Road[EMAIL PROTECTED]
Cambridge CB4 1HH  +44 1223 570179 (pm only, please)

Re: Language Feature Request: String Evaluation

[Martin Norb{ck]

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Tue Jun 08 1999, S. Alexander Jacobson ->
: Fair enough, but then the function should not be called show.  The spec
: for show here is an internal serialization format.  I guess the right
: thing to do here is define eshow which does not quote strings.

eshow :: String -> String
eshow =3D id

or am I barking up the wrong tree?

n.

--=20
--[ www.dtek.chalmers.se/~d95mback ]---[ PGP: 0x453504F1 ]---[ UIN: 4439498=
 ]--
Opinions expressed above are mine, and not those of my future employees.

--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia

iQCVAwUBN10lFBl6xbhFNQTxAQFksgP+NYUeMJWQuEphLD4WghhvtZ/WybJ2atVE
O0LKIPS3oOhb8fCT54gWlhkjwSKvZpwLAXO0lsfxEECg1MRdnARoCoUKmmWhiwlW
ytmg64NFBMeDs3qFiEJWnA2h1lYAhV5+nCa3O4PEbty94WGnWggG2xwf1v1ERMip
t5O2mhArvBE=
=+LgJ
-END PGP SIGNATURE-

--6TrnltStXW4iwmi0--

The speed of useless printing

[Jerzy Karczmarczuk]

Anatoli Tubman:

> How can I *efficiently* print (i.e. find the decimal, or in
> general N-ary, representation of) large Integers, like factorial of 1?
> 
> The implementation of showInt taken from Standard Prelude:

  ...

> (2) crawls like hell (when fixed with strictness).
> I don't know whether the slowness is because of GC, or because of
> slowness of quotRem.  Anyway, 10! can be computed much,
> much faster than printed (using GHC).
> 
> So, can printing be done any faster?
> 
> I realize that the issue is mostly theoretical.  No one in real
> life needs to print numbers so large.
> --
> Anatoli Tubman <[EMAIL PROTECTED]>




No, I don't have the answer. I object only to the last sad remark
that we don't need it *really* in practice. We do.

The arithmetic compression algorithm, which is one of the best
among the lossless schemes, transforms a huge file into a huge
number (ok., not "big", but long, essentially equivalent to a
very long binary fraction). The decoder "prints" such number.
How to do it incrementally is far from trivial, but it has been
done, and that's why people use more often a *worse* Huffman
coding. Arithmetic "bit-stuffing" is patented...

On the other hand, we cannot be sure that the long integer
algorithms in Haskell are really efficiently implemented, sometimes
I have the impression that a few things have been thrown-in
without too much thinking about the optimization.

A typical case is the rational package. If you read an appropriate
passage from the II-nd volume of Knuth, you will see some simple
but clever tricks reducing the num/den explosion by recognizing
the possibility of simplification before computing the common
denominators. The Prelude (at least of Hugs) uses the high-school
techniques.

===

Did anybody try to verify the efficiency of a cascading algorithm:
first you split the numbers in chunks `mod` 1 (e.g.), which
goes much faster than slicing this horrible sausage `mod` 10, then
print sequentially the chunks. The numbers involved are much smaller 
then, and the complexity is substantially reduced.

(Anyway, some time ago I wrote a completely crazy program which
computed and printed 2000 digits of the decimal expansion of PI
reconstructed from a hexadecimal fraction. It worked on my small
laptop (even under this primitive OS which Hans Aberg dislikes),
but:
1. I represented those fractions as lists, not as huge blocks that
   Integers are,
2. Their processing was as lazy as it could be, or even more.
)



Salutations distinguées.

Jerzy Karczmarczuk
Caen, France.

Re: Language Feature Request: String Evaluation

[john]

python, does something similar.. they have a """ which allows pre-formated text.
so you can do (psuedo-code)... 

string license = """
GNU GENERAL PUBLIC LICENSE
   Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 Everyone is permitted to copy and distribute verbatim copies
. . .

""";

I just thought id mention it.. it is quite a handy feature... the interpreter
also has a help routine which will pull a certain string out of any loaded
modules as its documentation string. sort of like a basic 'man' funcionality in
the interpreter... a rather neat idea, unlike comment documentation systems,
the strings can be extracted from a compiled module at run time in any case
the pre-formated strings are useful and i prefer that syntax to the
here-document syntax... although quoting rules still need to be worked out...
John

On Tue, Jun 08, 1999 at 06:17:41PM +0200, Magnus Carlsson wrote:
>   sqlstring = «insert into mytable values
> (NULL,'{show(var1)}','{show(var2)}','{var3}');»
> 
> Text is enclosed within «these characters» (which are hard to find on
> my keyboard, so I let Emacs insert them when I press '"'). To support
> markup, stuff that follows a space inside an escape is treated as
> text:
-- 
--
John Meacham http://synergy.foo.net/~john/
 [EMAIL PROTECTED]
--

Re: Language Feature Request: String Evaluation

[Lennart Augustsson]

"S. Alexander Jacobson" wrote:

> HacWrite certainly seems like an improvement over Haskell.
> However, it is just not as good as the scripting languages.
> HacWrite still requires the author to differentiate between strings and
> other types, still requires explicit use of show and still requires more
> typing and curly balancing.  Isn't this nicer?
>
> "insert into mytable values (NULL,'$var1','$(var2+var3)','$var3')
>

So add your own little modification to HacWrite.  It would be easy enough
to add $ interpolation.

-- Lennart

Re: Language Feature Request: String Evaluation

[S. Alexander Jacobson]

HacWrite certainly seems like an improvement over Haskell.
However, it is just not as good as the scripting languages.
HacWrite still requires the author to differentiate between strings and
other types, still requires explicit use of show and still requires more
typing and curly balancing.  Isn't this nicer?

"insert into mytable values (NULL,'$var1','$(var2+var3)','$var3')

-Alex-


___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop


On Tue, 8 Jun 1999, Magnus Carlsson wrote:

> I've been using a preprocessor to Haskell that I call HacWrite, which
> adds a new kind of string appropriate for entering text.  Such strings
> can span multiple lines and can be escaped using curly brackets:
> 
>   var1 = 2*2
>   var2 = 4*var1
>   var3 = «Foobar»
>   sqlstring = «insert into mytable values
> (NULL,'{show(var1)}','{show(var2)}','{var3}');»
> 
> Text is enclosed within «these characters» (which are hard to find on
> my keyboard, so I let Emacs insert them when I press '"'). To support
> markup, stuff that follows a space inside an escape is treated as
> text:
> 
>«This {bf sentence contains words in boldface}.»
> 
> Here, `bf' is a markup function from text to text.
> 
> I've found HacWrite quite useful for document writing (see
> http://www.cs.chalmers.se/~hallgren/Thesis/ for a longer example :-),
> but I'm sure it could be useful for CGI-scripting and the like as
> well. 
> 
> /M
> 
> S. Alexander Jacobson writes:
>  > A popular thing to do with computer languages (especially scripting
>  > languages) is to  manipulate text and insert variables into strings.  
>  > It is extremely irritating to escape in and out of strings via ++ in
>  > Haskell or + in Java/Javascript.  
>  > e.g. 
>  > > var1 = 2*2
>  > > var2 = 4*var1
>  > > var3 = "Foobar""
>  > > sqlstring = "insert into mytable values "++
>  > >  "(NULL,'"++(show var1)++"','"++(show var2)++"','"++var3"');"
>  > 
>  > It would be much nicer if Haskell did what perl,php, and tcl do:
>  > > sqlstring="insert into mytable values (NULL,'$var1','$var2','$var3')".
>  > Even nicer would be:
>  > > sqlstring="insert into mytable values
>  >   (NULL,'$var1','$(var1+var2)','$var3')".
>  > 
>  > (Notice both the embedded evaluation and the fact that the string runs
>  > accross multiple lines)
>  > 
>  > Supporting this feature involves either:
>  > a. a syntactic transformation after you have type information (don't
>  > 'show' strings)
>  > or 
>  > b. redefining show string not to return quotation marks
>  > 
>  > To me the second makes more sense, but either way, this feature would make 
>  > haskell programming much less annoying.
>  > 
>  > 
>  > -Alex-
>  > 
>  > PS Why does show string return quotation marks?  It seems inconsistent.
>  > 
>  > ___
>  > S. Alexander Jacobson  Shop.Com
>  > 1-212-697-0184 voice   The Easiest Way To Shop
> 

Re:

[Lennart Augustsson]

Anatoli Tubman wrote:

> How can I *efficiently* print (i.e. find the decimal, or in
> general N-ary, representation of) large Integers, like factorial of 1?

Use hbc?  It uses the gmp routine to convert an Integer to a String.
Converting 1! to a String takes much less time than computing it.

-- Lennart

rules, bottom, seq

[S.D.Mechveliani]

To my  
>> People say, that the transformations like   x - x -> 0  :: Integer  
>> are hardly ever applicable, because  x  may occur `undefined'.

Fergus Henderson <[EMAIL PROTECTED]>  writes

> This issue was already resolved -- someone already mentioned the solution.
> But obviously you missed it, so let me restate the answer: instead of
> using the transformation
> 
>   x - x   ==> 0
>   
> you should use the transformation 
>
>   x - x   ==> x `seq` 0

>> Probably, the compiler can prove "defined" very often.

> Indeed.  It can then simplify things further, using the rule
>
>   x `seq` e   ==> e   if x is not _|_


How nice. Thank you. 
To my mind, this consideration shows the wide applicability of rewrite 
rules in compiling of functional programs. Just what i tried to prove.


--
Sergey Mechveliani
[EMAIL PROTECTED]

RE: Language Feature Request: String Evaluation

[S. Alexander Jacobson]

> Alex, you might want to explain to people (such as myself)
> who don't know how Perl etc decide how much white space to insert
> in the string that's broken across a line.  One space?  None?
> What of the indentation spaces on the new line?   What if
> you really want those spaces to appear in the string?

Use whatever space is in the file.   e.g. in perl:
---
#!/usr/bin/perl

print "hello 
  world\n";

---
Will output:
hello 
  world
---
(there are 2 spaces after hello)

If you are generating HTML, XML, SQL, or even Haskell then white space
doesn't matter.  What matters here is convenience to the programmer
generating the text.  Obviously if whitespace layout is important that you
don't want to leave things up to the handling of the programming language
syntax. But, in that case, you are free to use the more traditional:

print "hello\n  world".
  "more text";
print "the . operator in perl is concatenation";
--
The feature I am describing does not take anything away from the
programmer, it just makes it easier in the 80-99% case when the consumer
of the data does not care about whitespace.

The biggest subtlety for Haskell is not the core language per se, but the
interaction with the > literate programming style.  My instinct is that
the correct answer is that filtering on "^>" should be turned off inside
"". So that:
> main = do 
>   putStr "hello
world"
>   putStr "more text"

would parse correctly.  On the other hand an XML-like delimiter like

main = do putStr "hello
 world"
 
would be a nicer and more modern formalism that would not have this
problem.   (the xml tags would have to be at the beginning of a line so as
not to be confused with "if 23").

-Alex-


___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop

Re: Language Feature Request: String Evaluation

[S. Alexander Jacobson]

eshow needs to apply to show to non string types.

-Alex-

___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop

On Tue, 8 Jun 1999, Martin Norb{ck wrote:

> Tue Jun 08 1999, S. Alexander Jacobson ->
> : Fair enough, but then the function should not be called show.  The spec
> : for show here is an internal serialization format.  I guess the right
> : thing to do here is define eshow which does not quote strings.
> 
> eshow :: String -> String
> eshow = id
> 
> or am I barking up the wrong tree?
> 
>   n.
> 
> -- 
> --[ www.dtek.chalmers.se/~d95mback ]---[ PGP: 0x453504F1 ]---[ UIN: 4439498 ]--
> Opinions expressed above are mine, and not those of my future employees.
> 

Re: Language Feature Request: String Evaluation

[S. Alexander Jacobson]

On Tue, 8 Jun 1999, Paul Hudak wrote:
> I agree that Haskell's string notation could be improved, but note that
> you could write:
> 
> > sqlstring1 = "insert into mytable values \
> >  \(NULL,'"#var1++"','"#(var1+var2)++"','"++var3++"')"
> 

That is arguably even more ugly than just consistently using ++.
It still requires the user to remember which variables contain strings and
which variables contain other things.  It then create two operators for
concatenation.  ugh.  

If I were to go in this direction, I would create a
class whose default implementation is show and a concatenation operator
that detects whether applying show to its arguments results in a quoted
string.  Then strip the quotes.  Again, synax like:
"'blah','"#var1#"','glah'"
is still ugly but an improvement.  

If HaskelL MUST have this type of syntax, then there should be a standard
operator for #.  Since # is used as flip($) and in TREX, I don't think it
is an available symbol.

> In particular, note that literal strings can be broken across lines
> using the backslant character, and (of course) "embedded evaluation"
> comes for free.

Again, the backslash character does not help much.  Typicall one will do
major editing of these string functions over the course of development.
As you reduce the first line of the string and increasee the second line, 
managing these backslashes becomes a real pain.  Perl, PHP, and
TCL actually allow pages! long strings.  You don't want to do backslash
management on text this long.

I strongly urge you to take a day to do web/database development inn any
of these languages and you will see how much better it can be.  
 
> > PS Why does show string return quotation marks?  
> > It seems inconsistent.
> 
> show x should be a string that when printed looks like the value that
> you would have to type to generate it directly.  This example is most
> instructive:
> 
> data Foo = Foo
>   deriving Show
> 
> show Foo ==> "Foo"
> show (show Foo) ==> show ("Foo") ==> "\"Foo\""
> show (show (show Foo)) ==> show ("\"Foo\"") ==> "\"\\\"Foo\\\"\""
> 
> etc.  This is actually quite consistent.

Fair enough, but then the function should not be called show.  The spec
for show here is an internal serialization format.  I guess the right
thing to do here is define eshow which does not quote strings.

-Alex-

___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop

Re: Language Feature Request: String Evaluation

[Paul Hudak]

> > var1 = 2*2
> > var2 = 4*var1
> > var3 = "Foobar""
> > sqlstring = "insert into mytable values "++
> >  "(NULL,'"++(show var1)++"','"++(show var2)++"','"++var3"');"
> 
> It would be much nicer if Haskell did what perl,php, and tcl do:
> > sqlstring="insert into mytable values (NULL,'$var1','$var2','$var3')".
> Even nicer would be:
> > sqlstring="insert into mytable values
>   (NULL,'$var1','$(var1+var2)','$var3')".
> 
> (Notice both the embedded evaluation and the fact that the string runs
> accross multiple lines)

I agree that Haskell's string notation could be improved, but note that
you could write:

> sqlstring1 = "insert into mytable values \
>  \(NULL,'"#var1++"','"#(var1+var2)++"','"++var3++"')"

which is pretty close to what you want, given the definition:

> (#) :: Show a => String -> a -> String
> s # a = s ++ show a

In particular, note that literal strings can be broken across lines
using the backslant character, and (of course) "embedded evaluation"
comes for free.

> PS Why does show string return quotation marks?  
> It seems inconsistent.

show x should be a string that when printed looks like the value that
you would have to type to generate it directly.  This example is most
instructive:

data Foo = Foo
  deriving Show

show Foo ==> "Foo"
show (show Foo) ==> show ("Foo") ==> "\"Foo\""
show (show (show Foo)) ==> show ("\"Foo\"") ==> "\"\\\"Foo\\\"\""

etc.  This is actually quite consistent.

  -Paul

Re: rules and bottom

[Fergus Henderson]

On 07-Jun-1999, S.D.Mechveliani <[EMAIL PROTECTED]> wrote:
> One more question on the program simplification and `bottom'.
> 
> People say, that the transformations like   x - x -> 0  :: Integer  
> are hardly ever applicable, because  x  may occur `undefined'.

This issue was already resolved -- someone already mentioned the solution.
But obviously you missed it, so let me restate the answer: instead of
using the transformation

x - x   ==> 0

you should use the transformation 

x - x   ==> x `seq` 0

> Probably, the compiler can prove "defined" very often.

Indeed.  It can then simplify things further, using the rule

x `seq` e   ==> e   if x is not _|_

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.