2009/1/14 Neil Mitchell :

Hi

...

1) In a Python string it is available the \U{name} escape, where name is a character name in the Unicode database.

As an example: foo = u"abc\N{VULGAR FRACTION ONE HALF}"

Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want:

"foo\E{show i}bar"

i.e. embed expressions in strings. I think this would be fantastic.

Hi, why not simpy "foo\E{i}bar" ?

...

2) In Python it is possible to import modules inside a function.

In Haskell something like:

joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath)

Looks a bit ugly, but kind of useful. I'd make the syntax:

joinPath' root name = joinPath [root,name] where import System.FilePath(joinPath)

It does mean you need to read an entire file to see what functions it imports, but perhaps that is the way it should be. I could also imagine a syntax:

joinPath' root name = import.System.FilePath.joinPath [root,name]

i.e. doing an import and use at the same time.

and why not simply System.FilePath.joinPath (without the import.) ? Cheers, Thu

On 2009 Jan 14, at 10:26, Neil Mitchell wrote:

...

...

...

As an example: foo = u"abc\N{VULGAR FRACTION ONE HALF}"

Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want:

"foo\E{show i}bar"

i.e. embed expressions in strings. I think this would be fantastic.

why not simpy "foo\E{i}bar" ?

What if i is a string? You'd get: foo"i"bar

Having different behaviour for string vs everything else would be equally bad.

...except that show already *has* different behavior for String vs. everything else. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Wed, Jan 14, 2009 at 3:12 PM, Neil Mitchell wrote:

...

2) In Python it is possible to import modules inside a function.

In Haskell something like:

joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath)

Looks a bit ugly, but kind of useful. I'd make the syntax:

joinPath' root name = joinPath [root,name] where import System.FilePath(joinPath)

It does mean you need to read an entire file to see what functions it imports, but perhaps that is the way it should be. I could also imagine a syntax:

joinPath' root name = import.System.FilePath.joinPath [root,name]

i.e. doing an import and use at the same time.

This can be done with a fully-qualified name (or two). Not quite as succinct, but I assume the scope of these imports is only local anyway.

joinPath root path = jp [root,filename path] where jp = System.FilePath.joinPath filename = System.FilePath.takeFileName

or

joinPath root path = System.FilePath.joinPath [root,System.FilePath.takeFileName path]

Cheers, D

On 2009 Jan 14, at 10:39, Manlio Perillo wrote:

Neil Mitchell ha scritto:

...

Hi

...

1) In a Python string it is available the \U{name} escape, where name is a character name in the Unicode database.

As an example: foo = u"abc\N{VULGAR FRACTION ONE HALF}" Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: "foo\E{show i}bar"

How this should/can work? There is Text.Printf for this.

I vaguely recall seeing some TH go by that did this (albeit with $() TH foo).

Sometime they are necessary, to avoid circular import problems (but this not a problem with Haskell).

...in theory. In practice GHC needs help with circular imports, and some cycles might be impossible to resolve. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2009 Jan 15, at 5:55, Manlio Perillo wrote:

Brandon S. Allbery KF8NH ha scritto:

...

[... about Python import local to functions ...]

...

Sometime they are necessary, to avoid circular import problems (but this not a problem with Haskell). ...in theory. In practice GHC needs help with circular imports, and some cycles might be impossible to resolve.

This is interesting. Where can I find some examples?

http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation... The "impossible to resolve" is my interpretation of a discussion on the lists several months ago. I don't see any mention in RWH offhand. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

When Haskell was designed there was a bried discussion (if my memory serves me) to have import be a decl, so it could occur anywhere a normal declaration can occur. I kinda like the idea, but some people didn't and it never happened. -- Lennart On Wed, Jan 14, 2009 at 3:12 PM, Neil Mitchell wrote:

Hi

...

1) In a Python string it is available the \U{name} escape, where name is a character name in the Unicode database.

As an example: foo = u"abc\N{VULGAR FRACTION ONE HALF}"

Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want:

"foo\E{show i}bar"

i.e. embed expressions in strings. I think this would be fantastic.

...

2) In Python it is possible to import modules inside a function.

In Haskell something like:

joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath)

Looks a bit ugly, but kind of useful. I'd make the syntax:

joinPath' root name = joinPath [root,name] where import System.FilePath(joinPath)

It does mean you need to read an entire file to see what functions it imports, but perhaps that is the way it should be. I could also imagine a syntax:

joinPath' root name = import.System.FilePath.joinPath [root,name]

i.e. doing an import and use at the same time.

Nice ideas, but they probably want implemented in a Haskell compiler and using in real life before they are ready for Haskell' like thoughts.

Thanks

Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

What I would really like to see is locally scoped imports but with parameterized modules. (so modules could take types and values as parameters) The places where I most want a feature like this is when I have a group of helper functions that need a value that is outside the modules scope, but that in general doesn't change. Usually we just curry the functions, but that generates a lot of wasted code. A good example might be the token parsershttp://legacy.cs.uu.nl/daan/download/parsec/parsec.html#Lexical%20analysisin parsec. Rather than have something like this: whiteSpace= P.whiteSpace http://legacy.cs.uu.nl/daan/download/parsec/parsec.html#whiteSpace lexer lexeme = P.lexeme lexer symbol = P.symbol http://legacy.cs.uu.nl/daan/download/parsec/parsec.html#symbol lexer natural = P.natural http://legacy.cs.uu.nl/daan/download/parsec/parsec.html#natural lexer ... We could do something like: import ParsecToken lexer Having an import/module feature like this would replace almost all cases where someone might wish for a macro system for Haskell.

...

Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want:

"foo\E{show i}bar"

"foo"++show i++"bar"

Change the language - save two characters.

For simple cases, doing "foo" ++ show i ++ "bar" isn't bad at all, but when you have five or six or ten (show i)s that you want to mix in, it can get pretty hard to read. On Wed, Jan 14, 2009 at 11:43 AM, Ketil Malde wrote:

"Neil Mitchell" writes:

...

...

1) In a Python string it is available the \U{name} escape, where name is a character name in the Unicode database.

...

...

As an example: foo = u"abc\N{VULGAR FRACTION ONE HALF}"

Why not:

import Unicode.Entities as U

foo = "abc"++U.vulgar_fraction_one_half

...

Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want:

"foo\E{show i}bar"

"foo"++show i++"bar"

Change the language - save two characters.

...

...

2) In Python it is possible to import modules inside a function.

In Haskell something like:

joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath)

...

It does mean you need to read an entire file to see

Well, then you might as well allow multiple modules per file as per the recent discussion. And multi-module files will possibly let you achieve the desired encapsulation without actually changing the language.

-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Jan 14, 2009 at 12:48 PM, Tim Wawrzynczak wrote:

...

Having an import/module feature like this would replace almost all cases where someone might wish for a macro system for Haskell.

Don't say that until you've tried Lisp macros... read some of Paul Graham's essays or try some Common Lisp for yourself... macros can be an incredibly powerful tool, but "macros" from C, etc. aren't really macros, they're more like find-and-replace expressions :)

You're probably right. I've played around with LISP macros a little, but it seems that most of the cases where you would use a macro in LISP you don't need one in haskell due to lazy evaluation. Although I haven't played around with them enough to say much one way or another. Do you know of a particular example where a macro would be a big help in haskell?

Well, like many good programming tools, Lisp macros are another abstraction, but instead of dealing with data, they deal with code.

I didn't know Lisp puts such an emphasis on the difference between code and data.

Jonathan Cast wrote:

Haskell already has a couple of abstraction tools for dealing with code. One is called `first-class functions'; another is called `lazy evaluation'.

And for all the rest there is TH? M.

Tim Wawrzynczak wrote:

Woah fellas, I wasn't trying to start a flame war, I was merely commenting that those who have not used Lisp don't really understand the power that macros can have in a language (such as Lisp) that supports them, and where code and data can be used interchangeably. And I've never used TH so I can't comment on that. Don't worry, I'm on your side :)

Oh, I didn't mean that in a bad way. :-) I was just thinking that if something turns out hard to express in pure functions, you can always resort to Template Haskell. Martijn.

Hallo, On Wed, Jan 14, 2009 at 5:06 PM, Max Rabkin wrote:

On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast wrote:

...

Do you have an example of a macro that can't be replaced by higher-order functions and laziness?

I believe I do: one macro I found useful when writing a web app in Lisp was something I called hash-bind, which binds variables to the values in a hashtable, with the variable names as keys. For example:

I have one for binding GET/POST variables to regular variables transparently and with error checking, just inside the body of the macro. -- -alex http://www.ventonegro.org/

Hallo, On Wed, Jan 14, 2009 at 5:16 PM, Max Rabkin wrote:

On Wed, Jan 14, 2009 at 11:11 AM, Alex Queiroz wrote:

...

I have one for binding GET/POST variables to regular variables transparently and with error checking, just inside the body of the macro.

Noooo! You reinvented PHP. What happens if a request variable shadows the name of another variable used in the body?

I list the variables I want to bind in the form. I do not ask to automatically bind all of them. :) (query-let (id name job salary) (if (> salary 1000) ...)) -- -alex http://www.ventonegro.org/

On Wed, Jan 14, 2009 at 1:14 PM, Jonathan Cast wrote:

On Wed, 2009-01-14 at 11:06 -0800, Max Rabkin wrote:

...

On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast wrote:

...

Do you have an example of a macro that can't be replaced by higher-order functions and laziness?

I believe I do: one macro I found useful when writing a web app in Lisp was something I called hash-bind, which binds variables to the values in a hashtable, with the variable names as keys. For example:

(hash-bind (a b) hashtable body) == (let ((a (lookup hashtable "a")) (b (lookup hashtable "b")) body)

I found this very useful in places where I was given URL request parameters in a hashtable and wanted to extract some variables from it. I don't believe it can be replaced by a higher order function (though I may be wrong).

Thanks! When you *know* there's a good reason people say something, and can't find a good example of *why*, it's a tremendous relief when when you find one. Sort of restores your faith in humanity :)

jcc

I thought of another good case (Shamelessly stolen from Paul Graham's 'On Lisp'). When defining a function to average the results of the list, you could define avg like this: (defun avg (&rest args) (/ (apply #'+ args) (length args))) Or as a macro like this: (defmacro avg (&rest args) `(/ (+ ,@args) ,(length args))) The reason the macro is better is that the length of the list is known at compile time, so you don't need to traverse the list to calculate the length of the list. Food for thought, anyway.

(defun avg (&rest args) (/ (apply #'+ args) (length args)))

Or as a macro like this:

(defmacro avg (&rest args) `(/ (+ ,@args) ,(length args)))

The reason the macro is better is that the length of the list is known at compile time, so you don't need to traverse the list to calculate the length of the list.

I'm trying to work out how awesome the (+) operator is that you can add the values together without needing to traverse the list ;-) D

With macros you can define new variable binding constructs. That's something I occasionally miss in Haskell. -- Lennart On Wed, Jan 14, 2009 at 6:48 PM, Jonathan Cast wrote:

On Wed, 2009-01-14 at 12:39 -0600, Tim Wawrzynczak wrote:

...

You're probably right. I've played around with LISP macros a little, but it seems that most of the cases where you would use a macro in LISP you don't need one in haskell due to lazy evaluation. Although I haven't played around with them enough to say much one way or another.

Do you know of a particular example where a macro would be a big help in haskell?

Well, like many good programming tools, Lisp macros are another abstraction, but instead of dealing with data, they deal with code.

Haskell already has a couple of abstraction tools for dealing with code. One is called `first-class functions'; another is called `lazy evaluation'.

...

They are a syntactic abstraction.

What is this good for? I suspect most Lisp macros are parametric in form, rather than really syntactic; I know that every example of a Lisp macro I've seen is parametric in form. Parametric macros --- macros that don't deconstruct their arguments --- don't usually need to be macros at all in modern functional languages. Do you have an example of a macro that can't be replaced by higher-order functions and laziness?

...

They're often described as "programs that write programs."

So are code generators. The most common example of a code generator is probably YACC --- but Parsec replaces it, with better readability even, with first-class parsers (built atop first-class functions).

jcc

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Jan 14, 2009 at 10:13 AM, David Leimbach wrote:

...

joinPath' root name = import.System.FilePath.joinPath [root,name]

How is this different from

joinPath' root name = System.FilePath.joinPath [root,name]

I'm sorry I didn't mean "different", I meant "better than"? I don't get

the advantage.