I just wonder if Fan would support the following features:

• bind operation from JavaFX. it looks that fan just missing this feature from javafx, and others is more than javafx. But data bind will makes GUI more easier.
• SQL support. such as SELECT * FROM TABLE WHERE id = :id, or INSERT INTO TABLE VALUES ( :id, :name ) etc.

I think the SQL support will make fan a best choice for database focused business application, just like the 4GL language. and we will no need for JPA, Hibernate any more.

bind operation from JavaFX. it looks that fan just missing this feature from javafx, and others is more than javafx. But data bind will makes GUI more easier.

See previous discussion related to this topic.

SQL support. such as SELECT * FROM TABLE WHERE id = :id, or INSERT INTO TABLE VALUES ( :id, :name ) etc.

Take a look at sql docs - we have pretty good sql support already.

One of the features still to add for Fan 1.0 is DSL plugins - this will allow the community to experiment with all sorts of language features.

How about the following DSL support?

the Sql example for update

addBook := db.sql("insert into Books (title, author, year)
                   values (@title, @author, @year)").prepare
addBook.execute(["title":"David Copperfield", "author":"Charles Dickens", "year":1850])
addBook.execute(["title":"Hard Times", "author":"Charles Dickens", "year":1854])
addBook.execute(["title":"The Jungle Book", "author":"Rudyard Kipling", "year":1894])
addBook.execute(["title":"Captains Courageous", "author":"Rudyard Kipling", "year":1897])

the DSL example

Str? title, author;
Int? year;
addBook = SQL<| insert into Books(title, author, year) values (:title, :author, :year) |>
addBook.execute { title = "David Copperfield", author = "Charles Dickens", year = 1850 }
...

the Sql example for select

stmt := db.sql("select title, year from Books
                where author = @author and year > @year").prepare
dickensNovels := stmt.query(["author":"Charles Dickens", "year":1850])
kiplingNovels := stmt.query(["author":"Rudyard Kipling", "year":1890])

the DSL example:

Str author;
Int year;
stmt := SQL <| select title, year from Books where author = :author and year > :year |>;
dickensNovels := stmt.query { author = "Charles Dickens"; year = 1850 }

the DSL version has the following features:

• it can be validate during the compile time based on target database, avoid sql grammar error
• it using less hard code strings to avoid wrong spell errors such as "author", "year"
• it can be pre-optimized in the compile time.

Since i am just a newbie for the fan, i am not sure what i think right or wrong. Please give me advice.

@wangzaixiang

I am not planning on implementing a DSL for SQL in the near future - although I think it would be a great idea.

If anyone is interested in that project, it might be a great thing to roll into the core.

I see. Can you give advice on the SQL DSL design?

I see. Can you give advice on the SQL DSL design?

I'd prefer to see something like this:

Str? title, author;
Int? year;

sql := SQL<| insert into Books(title, author, year) values (${title}, ${author}, ${year}) |>

result := db.execute(sql)

with compile-time validation of SQL, runtime auto-escaping of variables, and so forth.

runtime auto-escaping of variables

Not just that but also automatic use of prepared statements for DB statement caching. I presume this is what wangzaixiang had in mind. Some systems prefix SQL vars with : like that. I'd be afraid that $ would be taken to mean "insert string value" rather than "prepared statement parameter".

I'd be afraid that $ would be taken to mean "insert string value" rather than "prepared statement parameter".

"insert string value" is exactly what I would want it to mean. Whether or not the statement is cached is an implementation decision the user can and should be shielded from.

Yes, the dsl is just followed by an old lanaguage named 4GL or Embeded SQL Compiler(esqlc), or something like the sqlj.

It is not "insert string value", because SQL support not only string, but also Date, TimeStamp etc.

A Question: the RegexDSL and the StringDSL are both simple without access scope variable, but the SqlDSL need to access variable outside, so, how to access the compiler's symbol table in the DSL plugin?

It is not "insert string value", because SQL support not only string, but also Date, TimeStamp etc.

Yes, but so does Fan, and the SQL plug-in should convert between Fan and SQL types seamlessly.

need to access variable outside, so, how to access the compiler's symbol table in the DSL plugin?

It's definitely possible, but I haven't looked closely to see exactly how.

how to access the compiler's symbol table in the DSL plugin?

I'll need to do the same thing for a matrix DSL I'm planning. I just haven't worked on it for a bit, so I can't give hints. Actually, I need to compile full expressions within the DSL. I'm planning to look at fansh to see how they handle it there. Would this be a good place to look, Brian and/or Andy?

DslPlugin has full access the entire compiler infrastructure including AST.

However, I haven't tried to write a sophisticated plugin myself either. It is definitely possible, but I would expect a lot of rough edges that will require nicer APIs in the compiler itself.

Ideally the ability to eval a snippet of code in the context of the larger API easily would be ideal for fansh, dsl plugins, and IDEs. I think that is something that we don't make easy today (as all the problems with fansh illustrates).

I haven't looked deep at the compiler code for about a year, but the public docs on Compiler and Parser don't seem to expose an expression level. Maybe I'm forgetting the right place to look.

I don't want to eval code, by the way. I want to compile it and embed the compiled code as part of custom expressions and statements generated from the DSL. But I imagine eval and compile could both be related.

Looked at the fansh Evaluator source now. No, I don't think I want to be generating extra types like that for every expression when building Matrices. Maybe could hack one type with several methods, but even that wouldn't be a good long term solution. And I'd still need to see if I could bootstrap that class into the compiler process.

Since we're talking about compiler API, I've been wishing too to have the method and expression (at least) parse methods be made public.

if it all it takes is to make those methods public, no problem

but I think it will probably be more involved that (if anyone wants to send me a patch, I'd like to take a look)

I'm needing to work on that stuff now, so I'll let you know. I know there's quite a bit of infrastructure to manage, but then there'd have to be.