LINUX.ORG.RU

[вещества][лиспы]скобочный веб

 


1

4

Мечта идиота. Чтобы все эти разнабойные языки (html, css, js, xml, xlst, ...) померли и был один веб на s-expr. Макросы обязательно (и это лучше чем xlst)
Типичная вебстраничка была бы такой.

(html
  (head
    (title '(Web page))
    (style
      (match '(body .footer)
        :color red
      )
    )
    (script
      (alert 'Hello world')
    )
  )
  (body
    (div :id 'foo')
  )
)
Прошу прощения на неканоничные скобки. CL конечно же как скриптовый язык. html и css - доменные. И браузер на лиспе, расширяемый.
Что думают многоуважаемные лисперы? Подьемно сделать революцию?

★★★★

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

Отдаёшь контент - проверь, то ли ты отдаёшь, или нет.

«то» бывает разное, кстати. Поэтому валидация на сервере должна быть, как минимум, конфигурабельной :)

Deleted
()
Ответ на: комментарий от Miguel

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

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

ну, хотя бы на правильную сбалансированность скобок чтобы проверяло

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

Но если разработчики все вместе сделают это, то верстальщикам бежать будет некуда.

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

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

Если идею ТС относительно лиспа реализовать

Да она давно реализована. Просто пользоваться для реальной разработки этим очень неудобно. Никто и не пользуется.

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

Ну так я же говорю не только о html, а вообще о текущей ситуации в веб-приложениях

Ты говорил о бинарном формате. Который якобы проще парсить, чем HTML.

Так-то я согласен, что текущая ситуация с HTML и CSS — это пушной зверёк, но текстовый вид, ИМХО, абсолютно ни при чём.

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

Коммунизм во всем мире построить сложнее, чем заставить Mozilla, Microsoft, Apple, Opera Software придти к соглашению :)

Deleted
()

Подъемно сделать революцию?

Да. Для этого нужно:
1. Реализовать веб-браузер который будет это понимать.
2. Реализовать конвертер (хотябы как модуль для apache), который будет для не понимающих браузеров выдавать html, css, javascript.

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

Коммунизм во всем мире построить сложнее, чем заставить Mozilla, Microsoft, Apple, Opera Software придти к соглашению

Если это соглашение невыгодно абсолютно всем? Наоборот.

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

И если веб-девелоперы поймут преимущества lisp, то революция свершится.

Во-первых, не лисп, а секспры. Во-вторых, преимуществ у них нет, а недостатки имеются.

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

чтобы не ломать верстку нужно четко верстать табличками/колонками/hsplit/vsplit а не костыле float ами

красиво отрисовывать из коробки - это ты имеешь ввиду анимашки фейды?

про внешние движки и языки гугл уже заикнулся, дарт - первый шажок

тормоза - это понятие относительное но UA должен работать по возможностям, те даже тупой html без css уже был читабельным. Информация - все, не возможность написовать 3д кубик скриптами или снег не должна препятствовать получить инфу, как и отсутсвие какого то модного эффекта в css
индетификация пользователя это уже из области Single sign-on из энтерпрайза
про возможности пользовательского устройства - это вроде тупые капсы как в d3d хотя тут порочный путь, лучше считать что есть мин набор и ничего более чем считать что возможно есть все, всегда найдутся идиоты которые будут тербовать от пользователя суперфич потому что без них хоть помри никак сайт не заработает, это то что мы наблюдаем сейчас, когда пишуть костыли называя их словом fallback, например эмулируя webgl через канвас или даже 1 пиксельные дивы. Хотя тут взаимоисключающие параграфы с опциональностью возможностей скриптинга и css. Обе идеи ок но тогда придется положить что скриптинг всегда есть, css оставим только позиционный или перенесем его в семантику что даже лучше, тогда останется только css для красивостей. Так оно более менее.

Производителям тяжело наверное найти баланс между фичастостью и размером UA а. Если раздувать фичи доступные скриптам в конечном итоге у нас будет NET4.0 на почти гигабайт. Хз. Можно лениво подгружать классы из удаленной репы но в африке интернет все еще по траффику. Врядли юзер захочет включать такую фичу. Тк ждем когда безлимитный интернет станет на всей Земле.

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

Кому-то на практике нужна вёрстка без логики?

Конечно! Статическую верстку делает верстальщик, кастрированную «логику» (управление антикопипаст-средствами + выплевывание из вьюхи предварительно обработанных списков, массивов и хеш-таблиц, пропущенных через фильтры 9 из 10 которых занимаются кастомизацией *отображения*) через систему шаблонов внедряет программист, все что сложнее - находится на уровне вьюхи

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

XML (а значит, XHTML) парситься достаточно просто.

Никто не говорил что сложно, поинт был в том что долго, ресурсозатратно

Во всяком случае, намного, намного проще, чем битый HTML.

Невалидный xhtml браузеру проще парсить, чем точно такой же html? С чего бы?

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

Ты всерьёз предлагаешь искусственным образом ограничивать разметку?

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

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

Ничего разумного так и не получил

Расскажи, что именно ты хочешь получить?

Не-а. Если бы у Гугля хватало ресурсов, чтобы отрендерить все страницы во всех браузерах и напустить на них OCR — они бы так и делали

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

Таких ресурсов у них нет, но они очень стараются понять именно как должна ВЫГЛЯДЕТЬ страница.

И в какой-то степени им это удается, на уровне тех задач которые они преследуют, учитывая технические ограничения нашего времени

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

Наоборот, все только начинается...

Ой ли? Mobile Safari нормально показывает 99% интернетов

Контекст - html для отображения gui (не обязательно веб) на мобильных девайсах

1% глобальной аудитории, из которых 1% нужна фича -> не пройдет

У обычных юзеров как правило есть «техподдержка» — приятели, разбирающиеся в компах.

Это не серьезно, из одного процента гиков на «техподдержку» своих знакомых ведутся единицы

жручесть попрошу пруфлинк. Что именно парсинг xml занимает кучу времени.

Мне кажется это очевидным, но могу и пруфлинк скинуть чуток попозже

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

Невалидный xhtml браузеру проще парсить, чем точно такой же html? С чего бы?

С того, что при нарушениях типа «незакрытый тег», если это XHTML (application/xml+xhtml), браузер выбрасывает ошибку и ничего больше не парсит, а в случае с HTML (text/html) он должен задействовать костыли, но все-таки хоть как-то отобразить страницу.

Никто не говорил что сложно, поинт был в том что долго, ресурсозатратно

Долго? Его можно ускорить только если заменить XML на что-то более компактное, но, учитывая размеры типичного XHTML-файла, это экономия на спичках.

Deleted
()
Ответ на: комментарий от alienclaster

Мне кажется это очевидным, но могу и пруфлинк скинуть чуток попозже

Да объясни уже хотя бы на пальцах, чтоли.

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

Да объясни уже хотя бы на пальцах, чтоли

Чем сложнее синтаксис, тем его «разбор» (лексический, синтаксический, семантический анализ) требует >> процессорного времени. У xml синтаксис сложный, в сравнении с s-exp.

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

Этап синтаксического анализа будет похож и у лиспа, и у XML. У XML будет немного сложнее лексический (но зато на нем будет можно много чего сделать), но пренебрежимо мало скажется на скорости парсера.

А вообще, это будет иметь значение, когда изобретут интернеты, у которых скорость передачи данных превзойдет скорость парсинга XML, а сами XML вырастут хотя бы до нескольких сотен мегабайт.

Deleted
()
Ответ на: комментарий от Miguel

А если контент динамический, то сколько ни тестируй — всего не выловишь

в каком месте динамическое содержимое мешает тестированию?

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

Я всерьез заинтересован получить ответ на изначальный вопрос.

Изначальный вопрос был, цитирую:

Почему </x> обязательно после bar, а не после foo?

Ответ: потому что от сервера пришло: «<x><y>foo bar</x> baz». У браузера НЕТ никаких сомнений в том, где должен быть </x>: сервер ему СКАЗАЛ.

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

Логически абсолютно ясно, что вариант «<x><y>foo bar</y></x> baz» более правилен, чем «<x><y>foo bar</y> baz</x>». Он ближе к тому, что пришло от сервера.

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

Расскажи, что именно ты хочешь получить?

Я хочу следующее:

1) Как оно выглядит. Как набор строк. Каждая строка — либо реплика, либо имя персонажа. Строки с именами персонажей предпочтительнее всего центрировать. Реплики — более сложная часть: они тоже делятся на два вида. Именно, некоторые реплики должны начинаться в начале строки, другие же — в том месте, где закончилась предыдущая реплика (при том, что между этой репликой и предыдущей может быть ещё имя персонажа). Примерный вид я привёл.

2) Как оно должно выглядеть в исходнике. Как можно ближе к логике. Варианты:

<name>Шура</name>
<start>Остаться можно мне?</start>
<name>Кутузов</name>
<continue>Лет, позабыл я, сколько</continue>
<start>Тебе?..</start>
<name>Шура</name>
<continue>Семнадцать!</continue>
<nameКутузов</name>
<continue>Да-с... А коль узнает кто,</continue>
<start>Как этот граф, что ты... ну, не мужчина?</continue>
<name>Шура</name>
<start>Шестой я месяц тут. Никто за время то</start>
<start>Не заподозрил ни лица, ни чина!..</start>
Другой вариант:
<name>Шура</name>
Остаться можно мне?
<name>Кутузов</name>
Лет, позабыл я, сколько<break />
Тебе?..
<name>Шура</name>
Семнадцать!
<name>Кутузов</name>
Да-с... А коль узнает кто,<break />
Как этот граф, что ты... ну, не мужчина?<break />
<name>Шура</name>
Шестой я месяц тут. Никто за время то<break />
Не заподозрил ни лица, ни чина!..<break />
Как-то так.

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

Контекст - html для отображения gui (не обязательно веб) на мобильных девайсах

Ну и? Тем же вебкитом, который в сафари, отображается на отлично.

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

в каком месте динамическое содержимое мешает тестированию?

На тот момент, когда производится тестирование, не до конца известно, что именно нужно тестировать.

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

Конечно! Статическую верстку делает верстальщик

И что, «статическая вёрстка без логики» хоть где-то возможна? Можно примеры кроме пяти страничек «О компании»?

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

MVC же. Логика отдельно, верстка отдельно.

Ну, буквально же на днях вспоминали различие идеализации от практики.

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

Коммунизм во всем мире построить сложнее, чем заставить Mozilla, Microsoft, Apple, Opera Software придти к соглашению :)

Я, вот, затрудняюсь оценить, что сложнее :)

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

MVC же. Логика отдельно, верстка отдельно.

MVC, к сожалению, неюзабелен. Еще никто не научился строить MVC без межмодульной связи между M, V и С.

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

Логически абсолютно ясно, что вариант «<x><y>foo bar</y></x> baz» более правилен, чем «<x><y>foo bar</y> baz</x>». Он ближе к тому, что пришло от сервера.

Ну и в случае с-экспров сервер распарсит это как "(x (y foo bar)) baz" в чем проблема?

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

Ну и в случае с-экспров сервер распарсит это как "(x (y foo bar)) baz" в чем проблема?

В какой момент сервер стал заниматься парсингом?

Если же ты имел в виду клиента, то объясни, по какой логике он должен так распарсить?

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

В какой момент сервер стал заниматься парсингом?

Клиент, конечно же.

Если же ты имел в виду клиента, то объясни, по какой логике он должен так распарсить?

По той же логике, по которой он так распарсит в случае обычного html.

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

По той же логике, по которой он так распарсит в случае обычного html.

Нет. При парсинге обычного HTML браузер использует знание о том, какой открывающий тег соответствует найденному закрывающему. В секспрах этой информации нет.

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

Нет. При парсинге обычного HTML браузер использует знание о том, какой открывающий тег соответствует найденному закрывающему.

Ну в твоем примере это ни на что не влияет, т.к. пропущен закрывающий тег. В этом случае не важно секспр у нас или хтмл - информация есть в обоих случаях. Нету ее в том случае, когда закрывающий тег - есть, а открывающего - нету. Но я не знаю ни одного браузера, который в подобном случае достраивал бы открывающий тег «наугад», так что эта информация оказывается бесполезна. Приходим к выводу - «битые» секспры восстанавливаются в точности так же, как и битые хтмл-теги.

Это не говоря уже о том, что даже если бы возможности восстановления у секспров были бы ниже - недостатком это бы не являлось. Просто писали бы страницы с нормальным балансом скобок. Так что вопрос, чем секспры хуже хтмл, открыт.

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

Ну в твоем примере это ни на что не влияет, т.к. пропущен закрывающий тег.

Именно поэтому и влияет.

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

Просто писали бы страницы с нормальным балансом скобок.

Ха-ха.

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

Именно поэтому и влияет.

Нет. Влияет только в случае пропуска открывающего тега.

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

И информация о том, какой тег закрывается, в твоем случае не используется, то есть по той же логике он ставится и в случае секспров. Когда тебя попросили объяснить логику - ты сказал «потому что так». Посмотрим на твой пример:

от поступает в браузер от сервера текст: «<x><y>foo bar</x> baz». На самом деле там должно быть <x><y>foo</y> bar</x>baz, но закрывающий тег разработчик пропустил. Браузер, балансируя теги, сможет исправить этот текст как «<x><y>foo bar</y></x> baz».

Переформулируем на секспры:

от поступает в браузер от сервера текст: "(x (y foo bar) baz". На самом деле там должно быть (x (y foo) bar) baz, но закрывающий тег разработчик пропустил. Браузер, балансируя теги, сможет исправить этот текст как "(x (y foo bar)) baz".

Где тут проблема?

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

Не тупи. Если бразуер собран без libastral.so, он может получить лишь "(x (y foo bar) baz)"

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

И информация о том, какой тег закрывается, в твоем случае не используется

Ты слепой?

Браузер, балансируя теги, сможет исправить этот текст как "(x (y foo bar)) baz"

Я в который раз прошу тебя предъявить хотя бы намёк на АЛГОРИТМ, который позволит браузеру это сделать. Мой предъявлен.

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

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

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

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

Постоянно на ЛОРе встречаю, когда кто-нибудь из хардкорных лисперов пишет пост сплошь из скобочек, в середину которого впендюрен смайлик.

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

Постоянно на ЛОРе встречаю, когда кто-нибудь из хардкорных лисперов пишет пост сплошь из скобочек, в середину которого впендюрен смайлик.

Нет, ты напиши мне лиспокод, который сгенерирует некорректный секспр. Очевидно, у тебя ничего не выйдет, т.к. мы секспры генерируем за счет квазиквотаций и применения операций над списками, каждая из которых всегда возвращает корректный секспр. По-этому если наш написанный на лиспе сервер тупо запустился - это уже гарантирует, что он будет отдавать только сбалансированные секспры, иначе бы наебнулся ридер при старте сервера. Вот тебе и преимущество использования секспров (а точнее, использования древовидного представления вместо plain text'а).

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

Нет, ты напиши мне лиспокод, который сгенерирует некорректный секспр.

(print "(ya nekorrektnyj sexpr")

мы секспры генерируем за счет квазиквотаций

Вы можете генерировать что угодно чем угодно, речь не о вас.

Вот тебе и преимущество использования секспров (а точнее, использования древовидного представления вместо plain text'а).

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

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

(print "(ya nekorrektnyj sexpr")

Это строка, а не секспр. Я хочу секспр.

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

Потому что HTML _можно_ генерировать некорректно. А секспры нельзя в принципе. Чувствуешь разницу?

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

Это строка, а не секспр.

Через HTTP передаются именно строки. Или, по крайней мере, сериализованный вид (чего угодно).

Потому что HTML _можно_ генерировать некорректно. А секспры нельзя в принципе.

Можно. (print "(ya nekorrektnyj sexpr").

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

Через HTTP передаются именно строки.

А эти строки получаются как print sexpr'a, который валиден заведомо валиден, т.к. невалидный мы сгенерировать не сможем.

Можно. (print "(ya nekorrektnyj sexpr").

Неправильно. Правильно: (print '(ya nekorrektnyj sexpr"). Теперь попробуй сгенерировать еще раз.

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

А эти строки получаются как print sexpr'a

Кто сказал? Это заявление эквивалентно «строки получаются как print DOM-дерева».

Неправильно

Что, не заработает?

Miguel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.