Является ли C# код кодом на языке Lisp?

6yrop

The reliance on expressions gives the language great flexibility. Because Lisp functions are themselves written as lists, they can be processed exactly like data. This allows easy writing of programs which manipulate other programs (metaprogramming). Many Lisp dialects exploit this feature using macro systems, which enables extension of the language almost without limit.
http://en.wikipedia.org/wiki/Lisp_%28programming_language%29...

margadon

6yrop

"С СУЩЕСТВЕННЫМИ ограничениями по синтаксису"

Lisp is a form of syntax (and a few primitives like Eval and quote) that makes it easy to write programs that manipulate programs.

Serab

yolki

6yrop

Serab

6yrop

Я понимаю так, что можно расширять синтаксис и для этого предоставлены большие возможности, но почему отсюда должно сделовать, что можно любой язык заэмулировать, я не понимаю.

6yrop

Если что, я лисп не знаю, только слышал

apl13

но почему отсюда должно сделовать, что можно любой язык заэмулировать, я не понимаю.

apl13

6yrop

apl13

Мое имхо такое, что все же специализированный синтаксис (SQL) для людей более понятен, читаем и т.п. Я не прав? Вот тут даже lisper-ы сами говорят, что, по крайней мере, "Undoubtedly, select is harder to learn to use than query. (ref1)"

apl13

(c-sharp-def '(GenericList < string > list2 = new GenericList < string > 

(c-sharp 'Console :point WriteLine ("Hello world!" (Console :point WriteLine("Farewell world!"

karkar

т.е. Lisp мощный инструмент, но ограничен определенной синтаксической формой

Not only does lisp provide direct access to code that has been parsed into a cons cell structure, but it also provides access to the characters that make up your programs before they even reach that stage. Although regular macros work on programs in the form of trees, a special type of macro, called a read macro, operates on the raw characters that make up your program.

6yrop

необходимость пробелов между шарповыми токенами зависит от того, сколько трудолюбия ты в этот макросы вложил

But Lisp is different. Lisp macros do have access to the parser, and it is a really simple parser. A Lisp macro is not handed a string, but a preparsed piece of source code in the form of a list, because the source of a Lisp program is not a string; it is a list. And Lisp programs are really good at taking apart lists and putting them back together. They do this reliably, every day.

6yrop

В нем есть Read Macros, которые позволяют парсить произвольный текст, не только sexp'ы.

6yrop

Так что при большом желании да, можно C# сделать частью лиспа. В немерле, другом макросоориентированном языке, так и сделали примерно - запилили компилятор шарпа немерловыми средствами.

karkar

6yrop

реализуешь

6yrop

реализуешь

karkar

While the transformations of code done by regular macros are only used for turning lisp code into new lisp code, read macros can be created so as to turn non-lisp code into lisp code. Like regular macros, read macros are implemented with functions underneath so we have available the full power of the lisp environment. Like macros that increase productivity because they create more concise domain specific languages for the programmer to use, read macros boost productivity by allowing expressions to be abbreviated to the point where they aren't even lisp expressions anymore. Or are they?
If all we have to do to parse these non-lisp domain specific languages is write a short read macro, maybe these non-lisp languages really are lisp, just in a clever disguise. If XML can be directly read in by the lisp reader[XML-AS-READ-MACRO], maybe XML, in a twisted sort of sense, is actually lisp. Similarly, read macros can be used to read regular expressions and SQL queries directly into lisp, so maybe these languages really are lisp too. This fuzzy distinction between code and data, lisp and non-lisp, is the source of many interesting philosophical issues that have perplexed lisp programmers since the very beginning.

6yrop

а например добавить новый вид строковых литералов, добавить LINQ или SQL выражения и использовать их посреди лиспового кода.

6yrop

Dasar

Идеальное решение — в точности синтаксис SQL/LINQ плюс работа с этими выражениями как со структурой данных.

6yrop

nemerle же все это делает - чем он тебя не устраивает?

6yrop

Dasar

в рантайме с SQL-ем? я такого не видел, запости ссылку.

[PegGrammar(Options = EmitDebugSources, start,

grammar

{  

  any                   = ['\u0000'..'\uFFFF'];

  digit                 = ['0'..'9']+;

  spaces : void         = ' '*;

  

  num                   : int = digit spaces;

  unaryMinus            : int = '-' spaces simplExpr;

  ...

 }

})]

public class CalcParser

{

    private num(digit : NToken) : int

    {

      int.Parse(GetText(digit

    }

    

    private unaryMinus(_minus : NToken, se : int) : int

    {

      -se

    }

  ...

}

6yrop

Dasar

karkar

Идеальное решение — в точности синтаксис SQL/LINQ плюс работа с этими выражениями как со структурой данных.

apl13

т.е. готового ничего не получаешь? Тогда, что остается от lisp-а?

(define-syntax pseudocode-function ...)

(pseudocode-function '(Int Increase(Int x) (return x + 1'

> (begin (display (pseudocode-Increase 10 (newline

11

apl13

ну и со статической типизацией, да

6yrop

Именно так и будет. В процессе парсинга исходника компилятор, встретив LINQ выражение, вызывает твой read macro, тот генерит обычные деревья, они становятся частью общей структуры программы. Когда другие макросы потом что-то делают с этим кодом, они работают с привычными структурами, не подозревая, что часть этих списков была получена не чтением скобочек, а разбором LINQ выражения.
Если вдруг нужно после преобразования опять получить LINQ, на то есть pretty-printer'ы.

Func<int> M1(int a, int b, int c) //Code1

{

    return  => a + b + c;

}

Expression<Func<int>> M2(int a, int b, int c) //Code2

{

    return  => a + b + c;

}

Func<Value<int>> M3(Value<int> a, Value<int> b, Value<int> c) //Code3

{

    return  => a + b + c;

}

Func<int> M1(int a, int b, int c) //Code1

{

    return  => a + N1(b, c);

}

int N1(int b, int c)

{

    return b + c;

}



Expression<Func<int>> M2(int a, int b, int c) //Code2

{

    return  => a + N2(b, c);

}

int N2(int b, int c)

{

    return b + c;

}



Func<Value<int>> M3(Value<int> a, Value<int> b, Value<int> c) //Code3

{

    return  => a + N3(b, c);

}

Value<int> N3(Value<int> b, Value<int> c)

{

    return b + c;

}

6yrop

Func<string> M4 //Code4

{

    return  => "a + b + c";

}

Func<string> M4 //Code4

{

    return  => "a + " + N4;

}

string N4

{

    return "b + c";

}

karkar

apl13

6yrop

Ты чего хотел-то?

6yrop

Подозреваю, что Шуреск хочет, чтобы как в функциональных языках, но чтобы без функциональных языков.
Вот и спрашивает, можно ли в функциональных языках так, чтобы без функциональных языков.

6yrop

Ты чего хотел-то?

SELECT  A1,

        B2

FROM    A

        LEFT JOIN B

            ON A.A2 = B.A2

WHERE   A1 = 'test1'

        AND EXISTS (

                SELECT  1

                FROM    C

                WHERE   C1 = 'test2'

                        AND A.A3 = C.A3        

            )

SELECT  A1,

        B2

FROM    A

        M1

WHERE   A1 = 'test1'

        M2            



? M1(?)

{

    return LEFT JOIN B

            ON A.A2 = B.A2;

}



? M2(?)

{

    return AND EXISTS (

                SELECT  1

                FROM    C

                WHERE   C1 = 'test2'

                        AND A.A3 = C.A3        

            );

}

 

Dasar

А для Code2 произошла катастрофа – мы не можем пройти по “b + c” как по структуре данных.
[...]
1.3 (-) плохое смешивание с обычным кодом, extract method и т.д.

6yrop

какое обоснование этого тезиса? только то, что конкретная библиотека не умеет ходить по коду методов?

Dasar

6yrop

6yrop

Dasar

ну во-первых надо в рантайме, а там C#-а уже нет, там IL

Dasar

ну а ты как думаешь, зачем они ввели Expression<T> и специальную обработку компилятором для него?

6yrop

частную задачу в виде запиливания linq

6yrop

sql-linq

Dasar

что за задача?

6yrop

какое обоснование этого тезиса? только то, что конкретная библиотека не умеет ходить по коду методов?

Expression<Func<int>> M2(int a, int b, int c) //Code2

{

    return  => a + N2(b, c);

}

int N2(int b, int c)

{

    return DateTime.Now.Day > 13 ? b + c : b;

}



Func<Value<int>> M1(Value<int> a, Value<int> b, Value<int> c) //Code3

{

    return  => a + N3(b, c);

}

Value<int> N3(Value<int> b, Value<int> c)

{

    return DateTime.Now.Day > 13 ? b + c : b;

}

  

Dasar

по хитрому алгоритму его частично выполнять в CLR-е

6yrop

весь хитрый алгоритм состоит из осознания, что есть структура вида: tree<expression>, и что для каждого expression либо есть аналог в sql, и тогда его можно перевести в sql и там выполнить, либо аналога нет, и его необходимо выполнять на уровне кода.

Dasar

имхо, что выполнять, а что отправлять должен решать программист-пользователь.

6yrop

luna89

Dasar

В то же время, приложения, написанные в 80-е на plsql, выглядят сейчас абсолютно современно (и будут также выглядеть через 20 лет).

luna89

Скорее это обычно говорит о застое в определенной области.

Dasar

А чего тебе не хватает в SQL и PL\SQL?

luna89

высокоуровневой параметризации - что обычно и пытаются достичь с помощью кучи разных способов. в том числе, с помощью sql-linq

  and ( column1 = :param1 ) 

Dasar

После этого генерация sql сводится к добавлению условий вида

Но почему-то в данном случае никто не городит монструозные фреймворки для борьбы с ней.

luna89

это только верхушка айсберга для высокоуровневой параметризации.

Dasar

6yrop

Можешь привести реалистичный пример, несводимый к тому что я написал?

6yrop

Таким образом, динамическая типизация осталась, но ее очень немного и на практике никаких проблем она не создаст.

Встраиваемый SQL обеспечивает статически типизированный подход к явному выполнению запросов. Как обсуждается в разд. 7, одним из существенных недостатков встраивания является отсутствие поддержки динамических запросов.
...
Мы полагаем, что отсутствие поддержки динамических запросов является основной причиной отказа от большинства форм встраиваемого SQL [27].
http://citforum.ru/database/articles/impedance_mismatch/
  

6yrop

в функцию всегда может прийти null