LINUX.ORG.RU

Lisp Asp .Net MVC

 , , , ,


2

7

C# официально устарел и отправляется в помойку, т.к. теперь веб-фреймворк Asp .Net Core MVC доступен из Common Lisp.

Можно так писать:

;; Asp.Net MVC controller
(define-dotnet-callable-class (example-controller
                               (:base-type . ControllerBase))
    ()
  ;; Echo the 'Hello' message to client
  (:method index :string ((name :string))
    (format nil "Hello~:[~;, ~:*~a~]!" name)))

https://github.com/Lovesan/bike/blob/master/examples/aspnet-mvc.lisp

На линуксе работает на SBCL и на CCL, проверял.

Конечно, нужно немного дополнительных телодвижений, т.к. .NET прокси-классы генерируются в рантайме, и поэтому их надо руками указывать в качестве контроллеров, но это в принципе все при желании автоматизируется макросами и другими средствами метапрограммирования.

Также, пока bike не поддерживает аттрибуты, но это наверное добавлю позже.

Ну и с extension-методами пока не придумал что делать, пока их классы надо руками писать.

★★★
Ответ на: комментарий от alysnix

Вот это и есть blub paradox.

Какой-нибудь программист на бейсике на описание указателей тоже скажет, не надо писать всякую ерунду ни на бейсике ни на си. В его языке указателей нет, он без них хорошо живёт.

monk ★★★★★
()
Ответ на: комментарий от monk

языки со стандартом ISO – полный шлак

Так у CL нет стандарта ISO. А тот лисп, который со стандартом ISO (ISLISP) — это другое.

Сорри, попутал. Стандарт ANSI тоже канает за бюрократию и ад.

hateyoufeel ★★★★★
()
Ответ на: комментарий от monk

Как на Си++ написать with_cc?

https://alandefreitas.github.io/futures/adaptors/continuations/

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

Есть ещё более старые и нестандартные варианты: https://github.com/Naios/continuable

hateyoufeel ★★★★★
()
Ответ на: комментарий от alysnix

Потому что, как показывает практика, языки со стандартом ISO – полный шлак.

отсюда не следует вывод, что языки без стандарта iso - выдающиеся.

Конечно не следует. Но расклад такой: наличие стандарта – хоть ISO, хоть ANSI – превращает язык в дремучее окаменевшее говно. Отсутствие этого стандарта не влияет никак.

Тут фанаты стандартов могут заявить, что «зато после стандартизации может быть вагон компиляторов!!!!!», но на примере C и C++ мы видим, что, во-первых, вагона не будет, а во-вторых авторы компиляторов всё равно либо обосрутся, либо специально забьют на стандарт, и ты в любом случае получишь простыню из #ifdef.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Тут фанаты стандартов могут заявить, что «зато после стандартизации может быть вагон компиляторов!!!!!», но на примере C и C++ мы видим, что, во-первых, вагона не будет, а во-вторых авторы компиляторов всё равно либо обосрутся, либо специально забьют на стандарт, и ты в любом случае получишь простыню из #ifdef.

ИМХО, вы путаете причину и следствие. Наличие стандарта не провоцирует появление независимых реализаций. Тогда как при наличии этих самых независимых реализаций существование стандарта может хоть как-то помочь разработчику.

Собственно, что и видно на примере Си и C++, когда стандартизировать язык начали когда уже был зоопарк компиляторов. И в середине 90-х те же Borland и MS пытались добавлять собственные расширения в C++. Благодаря стандарту их потуги можно отправлять в пешее эротическое.

Так что если уже есть несколько реализаций, то стандарт помогает писать простыню из #ifdef меньшего размера.

Если же реализация всего одна, то надобность в стандарте, действительно, сомнительна.

ЗЫ. Ссылка на тред 2020-го года с заключением «пришли к неутешительным вывода» повеселила отдельно. Чтобы в результате ЛОРовского срачика были сделаны какие-то выводы… Смешно.

eao197 ★★★★★
()
Ответ на: комментарий от hateyoufeel

Конечно не следует. Но расклад такой: наличие стандарта – хоть ISO, хоть ANSI – превращает язык в дремучее окаменевшее говно. Отсутствие этого стандарта не влияет никак.

Не превращает, естественно.

http://metamodular.com/2021-01-25-2.text

But there is also the non-technical aspect of it. For some reason, the people who make these suggestions seem to think that it is a huge disadvantage for Common Lisp to have a standard at all. Let me explain what I mean. These people are typically used to using languages with a single implementation and with no standard at all, like Python, C#, Java, Javascript, Haskell, etc., and they are not bothered by that, it seems. These languages evolve by some committee getting together every so often to decide to include some new stuff in the language. Often, like in the case of Python, they don’t even care about generating fast code, because everyone writes C code for speed anyway. And these people also use third-party libraries without blinking, whether the features of those libraries were approved by a committee or not. But somehow, to these people, the fact that Common Lisp has a standard is now problematic. To them, new features HAVE TO be included in the standard in order for them to use these features, but they don’t have that requirement for other languages they use. But having a standard that doesn’t move is a good thing. It means you can make sure your code still works decades after you wrote it, provided your system is conforming. Somehow, these people are also bothered by the fact that Common Lisp has several implementations. They think it is totally important that every feature they use must be included in every conforming implementation, so the only way forward is to create a new standard, and force the implementations to follow it. But that is silly since they are perfectly happy to use a language with a single implementation. So why are they so uncomfortable using a single Common Lisp implementation, like, say SBCL?

So, in essence what these people are trying to do is to ruin the fact that we have excellent backward compatibility, that we can have compilers that generate fast code, and that we have several conforming implementations that can run any conforming program. This is of course not their goal, but it would be the net effect. For a new standard to be even remotely successful, one would have to have representatives for all creators of Common Lisp implementations to participate and agree to the new features. And that includes the commercial vendors. If a single person is attempting a thing like this, it would most likely result in a new language, with a single implementation, and a compiler generating slow code. I for one would not use that language.

Реализации отлично развиваются. Стандарт этому вообще никак не мешает. Но и более того, лисп - расширяемый метаязык, его можно как угодно менять. Чтобы сделать какой-либо дополнительный оператор, не обязательно ждать подачек от комитета или от гвидофюрера по 10 лет.

lovesan ★★★
() автор топика

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

Forum0888
()
Ответ на: комментарий от hateyoufeel

https://alandefreitas.github.io/futures/adaptors/continuations/

Тут что-то странное, имеющее не больше отношения к продолжениям, чем map в C++ к одноименной функции в лиспах.

https://github.com/Naios/continuable

Здесь оно же. Продолжением тут называется ручная стыковка через .then().

Автоматического преобразования произвольного кода в код с продолжениями как в cl-cont тут нет.

monk ★★★★★
()
Ответ на: комментарий от lovesan

Чтобы сделать какой-либо дополнительный оператор, не обязательно ждать подачек от комитета или от гвидофюрера по 10 лет.

Если что-то достаточно простое типа ООП, то да. Неограниченный сall/cc не получится. syntax-case тоже не получится.

monk ★★★★★
()
Ответ на: комментарий от eao197

ИМХО, вы путаете причину и следствие. Наличие стандарта не провоцирует появление независимых реализаций.

Я про это нигде и не писал сам. Но защитники говностандартов очень часто приводят этот аргумент.

Благодаря стандарту их потуги можно отправлять в пешее эротическое.

Правда можно? Тогда почему не отправляют? Нестандартного кода под MSVS просто вагоны.

Чтобы в результате ЛОРовского срачика были сделаны какие-то выводы… Смешно.

Ну, я сделал выводы. Если ты их не сделал, то кто ж виноват-то?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Правда можно?

Можно.

Тогда почему не отправляют?

Кто? Вы?

Нестандартного кода под MSVS просто вагоны.

Как и под GCC.

Очень многих устраивает жизнь под одним компилятором.

Кого не устраивает и кому нужно поддерживать сразу несколько разных, тот может ограничиваться стандартом (благо он есть). А под ifdef прятать то, что в стандартном C++ выразить не получается.

Ну, я сделал выводы.

Тогда и говорите в единственном числе. А то у вас «пришли» во множественном числе. Как будто вы про себя и свое ЧСВ сразу :)

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Очень многих устраивает жизнь под одним компилятором.

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

Кого не устраивает и кому нужно поддерживать сразу несколько разных, тот может ограничиваться стандартом (благо он есть).

Ага, писать код два раза. Зачем этот стандарт нужен?

А под ifdef прятать то, что в стандартном C++ выразить не получается.

Или то, где поведение различается между компиляторами. Я вижу дохрена кода с #ifdef CLANG, хотя между шлангом и гцц разницы считай никакой. Опять же, зачем этот стандарт нужен #2?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Ага, писать код два раза.

Можно пример?

Я вижу дохрена кода с #ifdef CLANG, хотя между шлангом и гцц разницы считай никакой. Опять же, зачем этот стандарт нужен #2?

А я не вижу такого кода. Вероятно, нужно задать какой-то глубокий риторический вопрос?

eao197 ★★★★★
()
Ответ на: комментарий от hateyoufeel

В окамле есть полиморфные модули, про которые я выше писал. Прикинь, можно импортировать модуль и передать ему параметром другой модуль!

Посмотрел https://v2.ocaml.org/manual/moduleexamples.html. Я это лет 7+ назад видел, просто тогда не сравнивал и не задумывался.

А в чём вообще фишка? В том, что модулем назвали то, что в более других языках называют интерфейсом/шаблоном? В тех языках эти вещи тоже бывают first-class титизенс, их можно импортировать и передавать друг другу параметрами.

utf8nowhere ★★★
()
Ответ на: комментарий от hateyoufeel

Тут фанаты стандартов могут заявить, что «зато после стандартизации может быть вагон компиляторов!!!!!», но на примере C и C++ мы видим, что, во-первых, вагона не будет, а во-вторых авторы компиляторов всё равно либо обосрутся, либо специально забьют на стандарт, и ты в любом случае получишь простыню из #ifdef.

Кратко.

Стандарт определяет наилучший вариант из всех возможных.

Может ты смотришь не стой стороны.

saufesma
()
Ответ на: комментарий от fluorite

С точки зрения результата подойдёт. С точки зрения «генерить AST» — нет. На Си++ вместо преобразования кода просто втыкаются ассемблерные вставки либо вызов потока для сохранения стека.

cl-cont делает CPS-преобразование переданного кода.

monk ★★★★★
()
Ответ на: комментарий от monk

Там язык - это impala, а thorin - это IR в стиле CPS. Выше у тебя замечание про «просто ассемблер» vs «настоящий CPS». Мой тезис в том, что никакой принципиальной разницы для фронтенда создавать CPS или SSA (как делает llvm) нет. В плюсах просто традиционно манипулируют астом через llvm.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Опять пришли к «это не надо».

Иногда надо. Например, на базе CPS очень получаются очень хорошие HTTP-сервера с состоянием. Продолжения из буста, насколько я понял, нельзя сохранить, например, в std::map (исходя из continuation is only move-constructible and move-assignable).

monk ★★★★★
()
Ответ на: комментарий от fluorite

Или вот ещё пример:

(define-binary-class id3-tag
  ((file-identifier (iso-8859-1-string :length 3))
   (major-version   u1)
   (revision        u1)
   (flags           u1)
   (size            id3-tag-size)
   (frames          (id3-frames :tag-size size))))

Описанный таким образом класс может сериализоваться и десериализоваться, причём формат сериализации можно указать произвольный. На C++ приходится каждое поле вручную записывать в serialize.

monk ★★★★★
()
Ответ на: комментарий от monk

cl-weblocks

Weblocks was created by Slava Akhmechet. Автор даже для своего ныне покойного стартапа (rethinkdb) его не взял.

Seaside

ммм, Squeak. Ну может быть. Но это не лисп.

racket

Ну я просил «готовый к промышленному применению». Прости, решения от кучки ссорящихся академиков не готов внести в эту категорию.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

И это тоже. Тёмная сторона преимущества лиспов.

Кстати, в Racket эту проблему на 90% решили. Заставили писать от документации, выкинули (точнее, очень сильно порезали) отладчик и сделали контракты на модули фактическим стандартом. В результате, это первый лисп, где для использования пакета я не лазил в его исходники. Но по этой причине для многих лисперов Racket — не лисп.

monk ★★★★★
()
Ответ на: комментарий от fluorite

Ну я просил «готовый к промышленному применению». Прости, решения от кучки ссорящихся академиков не готов внести в эту категорию.

???

Где кто ссорился по поводу racket/web-server???

Вообще-то, из перечисленных он наиболее готов к промышленному применению (у меня стабильно работает уже 7 лет).

monk ★★★★★
()
Ответ на: комментарий от monk

Я про ракету в целом.

Why I no longer contribute to Racket

In January 2020, I told two members of Racket’s core team that I would no longer be contributing to Racket or partic­i­pating in the Racket commu­nity. Why? Because of a history of inten­tional, person­al­ized abuse and bullying directed at me by another member of the Racket core team: Matthias Felleisen.

Вообще-то, из перечисленных он наиболее готов к промышленному применению (у меня стабильно работает уже 7 лет).

Спасибо за ясное и чёткое подтверждение, что на лиспе нет ни*я нормального готового софта.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Я про ракету в целом.

Такое встречается почти в любой команде. Недавно Столлмана из FSF выгоняли. Теперь и программами GNU не пользоваться?

Спасибо за ясное и чёткое подтверждение, что на лиспе нет ни*я нормального готового софта.

Какие технические претензии к racket/web-server? Что в нём не нормально или в какой части он не готов?

monk ★★★★★
()
Ответ на: комментарий от fluorite

Но это не лисп.

Это примеры необходимости реализовывать хранимые продолжения. В лиспе и хаскеле их можно написать. В Racket и Smalltalk они уже есть.

На Си++ ни одного веб-сервера, который бы автоматически делал ссылки на вызовы процедур я не знаю.

monk ★★★★★
()
Ответ на: комментарий от monk

Какие технические претензии к racket/web-server? Что в нём не нормально или в какой части он не готов?

Ну давай. Захожу на https://github.com/racket/web-server. Первое, что вижу - красная плашка CI failing. Последний раз CI был зелёным когда - год назад. Всем похер. Спасибо, закрываю вкладку.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

Всем похер.

Кстати, даже не похер. На https://github.com/racket/web-server/blob/master/.github/workflows/ci.yml исправлено ещё первого ноября.

Но https://github.com/racket/web-server/actions/runs/6998014640/workflow почему-то использует старую версию.

monk ★★★★★
()
Ответ на: комментарий от lovesan

на лиспе пишут, он отлично подходит для больших и сложных систем, в отличие от golang, c, c++, rust, java, C#, и так далее

При этом есть куча больших и сложных систем на golang, c, c++, rust, java, C#, но нет ни одной на лишп. Опять реальность не соответствует чьим-то фантазиям.

slew
()